
Jeff Attwood encourages developers to eat their own dogfood:
I’ve found that much of the best software is the best because the programmers are the users, too. It is UsWare. It behooves software developers to understand users, to walk a mile in their shoes. If we can bridge the gap between users and ourselves– even if only a little– we start slowly converting our mediocre ThemWare into vastly superior UsWare. To really care about the software you’re writing, you have to become a user, at least in spirit.
This is good if you’re writing an IDE, not so good if you’re writing a word processor and actually kind of plain wrong if you’re writing a medical or trading app where developers lack the knowledge and experience of typical users. As Jeff himself has noted elsewhere, “If the application you’re writing isn’t intended for expert users, having the developers dogfood it won’t necessarily buy you much, because developers are highly unrepresentative of typical users. Beyond fixing critical bugs, it could even hurt the application: developers tend to add advanced, complicated features that are useful to them.”
At this point, I’m supposed to launch into a tirade about how the inmates are running the asylum, but I actually think that’s a pretty condescending attitude, albeit one that has includes some arguments to be aware of. It’s also somewhat of a self-fulfilling prophecy. Professional software developers have an important role to play in working towards usability, especially in the very real situation where usability professionals are simply not available.
How do you improve usability when you can’t eat your own dogfood? The solution is to become an anthopologist and watch actual users eat your dogfood. There are a lot of variants of this:
- Paper prototyping. For early design feedback. Incidentally, paper prototyping is a lot more than just lo-fi, hand-drawn, sketches. “Real” paper prototypes are interactive, like a board game, with a little real-time prodding from the researcher and possibly an assistant domain expert.
- Contextual analysis. This goes by several names, but the idea is to sit in the real-world environment of users and see how they interact with the system, as well as other systems, other people, and the general environment. The only problem with this approach is that you can’t do it with an in-progress system; it either has to be the old, extant, system, or the new, almost-complete, system.
- Interviews and walkthroughs. The user sits in a “usability lab” (but probably just an office) and runs a test version of the system, discussing it with the researcher. It may also be that there’s no system involved, just a qualitative discussion.
- Automated monitoring. A fan favourite of privacy advocates everywhere
– so please inform users what you’re monitoring, let them opt out, etc. This involves logging and monitoring of user actions for later monitoring. Thanks to the magic of Ajax, there are now some very powerful tools that will track all activity in the browser and play it back for later analysis. For example, Scrutinizer, written by the talented Nitobi team. Scrutinizer is cool because it actually blurs everywhere outside the mouse pointer area, so is an okay approximation for a full-blown eye tracking system. I haven’t heard of biological testing – especially PET scans – but with growing inteterest in Neuroeconomics, I’m sure it’s coming.
A related problem of dogfooding is that software developers tend to enjoy writing systems for themselves, i.e. those where they really will be eating their own dogfood. This is why we have: a proliferation of IDEs and clones of the veritable Unix “make” utility; quite an unreasonable number of applications about Klingon and juggling; but far fewer about quilt making and the art of kite surfing.
All this goes a long way to explaining why the greatest usability is often seen in software related products. I rate IntelliJ Idea, Firebug, and the general Unix philosophy among the best exemplars of software usability ever created, in any domain. Mainstream business and scientific applications will never be as good as those applications through the application of dogfooding.

Great post Michael! I love quick and easy usability advice like this. I think the whole lab usability testing thing can scare people away from thinking about it altogether.
Thanks for the kudos on Scrutinizer, it’s a neat tool and was really fun to work on. More cool features coming soon.
Have you seen our other usability testing and web ux analytics tool RobotReplay.com ? Check it out, we’re working on V2 right now and would love to hear your ideas.
Put yourself in the baggage handler’s shoes « Shakeout’s Blog // Mar 23, 2009 at 12:26 am
[...] your product! It’s that simple – although it sometimes means going out of your way (and it can be particularly difficult if you aren’t the target audience). And it’s not just about putting yourself in the position of the ultimate customer – you [...]
Quilt making, you say? One of my college professors did her thesis on computer-aided quilt design: http://www.cs.grinnell.edu/~coahranm/mmc_files/mcoahran-thesis.pdf [pdf]
Your analysis resonates remarkably with many developers. Another method to gather user data that falls between interviews and automated monitoring is remote usability testing. It differs from automated monitoring if it is set up carefully, with clear instructions from a moderator and good feedback from a tester. http://www.openhallway.com/ aims to provide these resources. It addresses the difficulty of a usability lab with the restrictions of automated monitoring.
We made it to be simple and straightforward so developers actually do usability testing. Because while most agree with your ideas, they do not actually implement any of them. We try to reduce barriers to get people to actually usability test their projects.