How can we help?

Design? Check. Strategy? Check. Bulletproof code? Check! People who can manage it in an agile and efficient manner? Check. Someone to help you create your next big product? Of course.


- 1201 18th St. Suite 250, Denver, CO 80202

Grand Rapids

- 125 Ottawa Ave NW Suite 270, Grand Rapids, MI 49503


BLOG:Dogfooding: What it Means to Really Understand

Dogfooding: What it Means to Really Understand

Dogfooding has been floating around the software industry for decades now. It usually means to use the software you’ve made. The term has had a revival in popularity lately because doing so has become much harder. The tsunami of mobile devices that has hit us in the last few years left us with ever diverging platforms and sub-platforms. It’s nearly impossible for any one person use them all, and yet we all want our software to reach the widest possible audience while still being confident in its quality.

My favorite story accredited to the origin of dogfooding goes like this:

The president of the horse-kill operation turned pet food company, Kal Kan, would eat a can of the company’s dog food during their annual investors’ meetings.

I’m imagining a man in a power-suit, quietly forking pet food into his mouth. He makes sure the label is pointed out toward the room while his CFO goes over the numbers.

Presumably this happened quite a while ago. I don’t know whether the company was still serving horse at the time, but that’s not really the point. This was an incredibly savvy - if not downright brilliant - move either way. For the price of an ambiguously derived can of dog food, he bought the following things…

The first and most obvious is marketing. It’s a good story and not only gets you thinking about how your pet’s food tastes, it instills confidence in shareholders like no stock buyback can.

Secondly, sympathy. Like any good chef, that Kal Kan executive now knows what his product tastes like. He can now sympathize with dogs in a way we other, less brave humans cannot. By sympathy I don’t mean pity, I mean common experience.

The third and most important is a byproduct of sympathy. In this executive’s mind, the product is now partially for him. He will almost certainly have a greater focus on the product’s quality. And with any luck, he might also get some insights into the expectations a dog has from its food.

My own dog food

For the last year, I’ve been working on an iPad and HTML5 web app for genomic researchers and bioinformatics technicians. Its aim is to allow professionals to visualize and assign meaning to the genetic data that makes up the genome of person. It’s called Genome Voyager and is in alpha, but you can check in on its progress here.

From my very first day, I was struck with the question, how much dog food I should eat? Having worked on several iPad and web apps, and being a user of the different platforms, I had confidence. But, I’m a user experience guy — not a bioinformatics one. How much subject matter expertise do you need to effectively make high-quality software?

Live it. I obviously couldn’t become a bioinformatics technician, so I had to do the next best thing… pretend. I borrowed my wife’s Cell and Molecular Biology textbook from college. I looked up terms on Google and Wikipedia. I made flash cards. I had my DNA sequenced and analyzed by, just to see what came back (hint: Diabetes). This, of course, only got me far enough to begin to be able to speak the same language as the genetic scientists and follow their conversations between each other. Eventually, the other Universal Mind team members and I could get so far as to be able to make mock filters and pseudo-assessments of genetic variants.

We can’t do the actual work, but we know enough to experience the intended workflow ourselves. This allowed us to discover bugs and pain-points in the workflow that are often too small for an end user to point out, but big enough to affect the overall experience. Lessons are…

Know the product you are designing. If you are making an e-learning app, sign up for a free online college course. If you are building a financial trading app, sign up for an account and then sign up for another with their biggest competitor. If the subject matter doesn’t allow you to become your user, don’t be afraid to pretend.

Know your device. If you are a designer and are given a project for a device you don’t use, find another designer that does. Then, buy the device and start using it. If you are a product manager, the same applies to you. It sounds like common sense, but it’s startling how many organizations build software on a platform that they don’t use themselves. Each platform has its own conventions, UI patterns, and personality. Some of these won’t even be defined by the manufacturer but by third party apps. All of the major device platforms have a Top Free list of their most popular apps. Every couple of weeks, download all of them. Spend five minutes tapping and swiping around each one, and then delete it. This sounds a bit daunting, but the top lists don’t change that much week to week.

Design on your Device: The single most common mistake I see out of young interface designers and those new to mobile, is not checking their designs on the actual device. The pixel density of modern screens vary so widely, you can’t get a sense of scale from photoshop. Scale becomes especially important when considering touch screen devices because the size of your finger will not change. You have to be able to arrange UI elements so that they are either large enough or far enough apart to comfortably use. The situation gets more complicated because a lot of smaller tablets can be manipulated with your thumbs while some phones have screens too large to be used with on hand.

The point is, there will inevitably be nuances on any design/device combination that only become obvious when you hold it. When we were working on the Genome Voyager iPad app, I used an iPad 1, an iPad 3, and an iPad mini to test on. That way I could cover all of the form factors and screen resolutions. There are plenty of apps out there that make it easy to put comps on a phone. Silkscreen, PSD Viewer, and Dropbox are just a few.

Develop on your Device as well: Notice I used the words ‘your device’ because you’re building an app and you’ve been using its intended device the whole time right? Good.

iOS and Android IDE’s both offer desktop simulators which serve as great time savers for a developer, but have all of the same pitfalls as photoshop does and then some. The colors, pixel sizes, animations, memory restrictions and clock speeds are all different on your desktop. These will fool you into thinking that your app is working (or not working) correctly unless you can get your app on a device. My personal rule is that if I’m building anything that interacts directly with the display (which is almost always), it gets compiled on a device held in my hand.

Cultivate Sympathy: Try your best to sympathize with your users through shared experience. Sympathy with your users is a powerful thing and unlike empathy, it flows in both directions. So, try your best to do what they do for a while. And use the device they use. Then you will be prepared when it comes time to eat your dog food.

As Zach Holman notes, “Building the stuff you use means recursive happiness.” The real lesson here is that design is at it’s finest when you design what you know. And the best way to learn is to dive into the subject and context.

A word of caution, eating your own dog food does not come without pitfalls. One is, it’s easy to become overconfident and think that you always know best. We have to always remind ourselves we are not our users, just servants to them. Dogfooding holds an inherent danger of making you think that you know better than everyone else. Remember, you do not. Nothing will replace real ethnographic research, personas and user testing.

Another is a tendency that Alan Cooper is keen on pointing out in regards to developers and happens to anyone that’s close enough to the product… you will inevitably become a power user. This could give you a natural tendency to give undue attention to power users at the expense of beginners and intermediates. Des Traynor gives an insightful bit of advice on that subject - make a practice of signing up for your product weekly. Creating a new user on a weekly basis gets you thinking about your beginner-users and focuses your attention on the critical signup, on-boarding flows.

Dogfooding can be useful and fun. The further you take it, the more fun and useful it becomes. Just remember that we are not actually dogs.