Eating our own dogfood: how research and testing works at Sketch
An inside look at how we approach new features and updates
Over a million people rely on Sketch to do their best work — from freelancers to some of the world’s largest and most influential design teams. Building and maintaining a product that’s become an essential part of so many workflows is a great responsibility. And it’s one we take very seriously.
With that in mind, we wanted to give you a glimpse behind the scenes at how we work — and how ‘eating our own dogfood’ does more than just help us catch bugs before each release.
‘Dogfooding’ is the practice of actively testing your own product in real-world scenarios before it ships to customers. For us, that means using new development builds of Sketch every single day, and designing new features within Sketch itself.
It all goes back to why Sketch exists in the first place. “We started Sketch to solve a need that we had ourselves. That was really the primary motivator,” says Pieter Omvlee, our CEO and co-founder, “and we really just hoped that others would see our solution and prefer it over the competition.”
Luckily for us, Sketch has become the de facto tool and the starting point for some of the world’s best products. That introduces a whole new set of challenges — but we’ve adopted a unique way of solving them.
“Dogfooding has always been at the core of how we build our product,” explains Tanya Nativ, our UX Researcher. “We’re in this fairly unique position where we are also the users.”
“Dogfooding has always been at the core of how we build our product. We’re in this fairly unique position where we are also the users.”
Users can be choosers
Since the app first launched almost ten years ago, our teams have used our own software to design new features and UI updates — and that still holds true today. The approach has two big benefits.
First, because we use the app every day, we’re our own worst critics. “We strongly believe that you can only build a great product if you’re the customer,” says Pieter. “It really takes actually using the software — sometimes in anger — to see how it can be improved.”
We use a number of different builds of the Mac app at each stage of the testing and development process.
Second, using our own product means it’s easier for us to understand and act on customer feedback.
“Obviously we know that while we’re our own customers, we are not all our customers,” says Tanya. “We always listen to them to learn how they deal with different problems and struggles and use our product in different ways, for very different purposes.” The result is a holistic approach — one that incorporates both internal and external feedback, along with insights and data from our QA team. And when it comes to bringing it all together, our research and design teams lead the way.
Building blocks
“When it comes to new features we always start with discovery research, which helps us to spot opportunities, and learn about users and their day-to-day experiences,” explains Tanya. We may already have ideas about what we want to build or improve, so we combine our research with these initial ideas to get the ball rolling. Once work formally starts, we assemble a small team, and they’ll start as high level or as detailed as we need them to — depending on the feature.
“We strongly believe that you can only build a great product if you’re the customer. It really takes actually using the software — sometimes in anger — to see how it can be improved.”
“We try to translate our ideas into something real, however rough, as quickly as we can,” says Pieter. “Working with real data and real use cases always beats mockups, fake data and idealized use cases.” Once the design team has something to share, they pass it back to the research team to find out what other users think — both our customers and the wider Sketch team.
“Once we have something to validate, we start user testing as much as possible — and as early as possible,” continues Tanya. “The ideal testing phase starts with mock-ups and early builds, and ends with a beta version. Testing is an ongoing process, so we always test and iterate as we go. And once the feature is released we listen carefully to the user feedback.”
Problem solving
Great ideas are always welcome at Sketch, whether they come from inside the team or from our customers and community. But part of the testing process is making sure we’re not adding something for the sake of it, without addressing a deeper issue. “If people ask for a solution or a feature, there’s often a few levels of ‘but why?’ buried in there,” says Pieter, “and that can often lead to a different solution to solve the underlying problem.”
But with so many ideas on how to make Sketch better, how do we choose what to work on first?
“It’s not an easy task, of course!” Tanya laughs. “But mostly, adding features and fixing bugs that impact the majority are our first priority.” Of course, there’s always the occasional feature that no-one knows they need until the have it.
“If people ask for a solution or a feature, there’s often a few levels of ‘but why?’ buried in there, and that can often lead to a different solution to solve the underlying problem.”
Sticking to our roots
With over one million customers worldwide, that majority can be pretty big these days. Pieter reflects that things have changed a lot in the last ten years. “When we started it was just one designer and one developer,” he says. “Today we’re over a 100 people and there’s just no way you can get there without things changing. I can’t just jump into the code anymore and immediately know what every line does and why it was written. The application is way too big for any one person to keep in their head — so we work together.”
The team might have changed, but our approach hasn’t. We still believe that a small focussed team can achieve the best result in the shortest time. So now we just divide up our developers and designers into small teams. That way, we can stay as nimble and quick as we always were.
“I think our approach is working out well,” muses Pieter. “On average we’re shipping one update a month and still introducing major new features. I hope both our designers internally and our users welcome them with open arms.”
This is the first in a series of posts that will peek behind the curtain and show you how we make Sketch. We have plenty things to show you, but we want your input, too. So what would you like to know about? Let us know, and stay tuned for more stories.