When we set out to build Aardvark, we made two decisions: 

1. we wanted to be user-driven — that is, we wanted to be informed by the interests and needs of people who were actually using Aardvark; and
2. we wanted to stay nimble with our engineering by being highly collaborative and adaptive.  

There are various Official Approaches for achieving these goals — such as User-Centered Design and a variety of Agile Engineering methodologies — and in fact, combining those two was the subject of a panel I participated in the other week at the Web2.0 Expo.

We’ve found that the two can go together quite nicely.  This post is about our best practices for combining some elements of User-Centered Design and Extreme Programming (a type of agile engineering), which we’ve developed by iterating on our process design the same way we iterate on our product design.  This is a single process we use for *product development* — as opposed to using separate processes for design or engineering.

Learn From Users

On a regular basis we invite a dozen users into our office to chat about their Aardvark experiences, and one or two interviewers will sit with each of them for about an hour.

In these interviews we’re trying to do three things: 

1. identify problems or needs that Aardvark users have; 
2. identify opportunities for Aardvark development; and 
3. solicit ideas for ways to address these problems and opportunities.  

The main deliverable is a presentation to the team that is primarily written with actual quotes from the interviews.

In addition to these regularly scheduled sessions, we also have ongoing processes to gather direct feedback, external comments (on blogs and Twitter), internal comments (from team members), and factor these into our learnings.

Design

We then set out to design possible features and solutions in response to these learnings.  The full team is sometimes involved in initial brainstorming; then a smaller group takes responsibility for actually working out some proposed designs.  We end up with a few options that seem to us internally to be good candidates for addressing what we’ve learned.

Sanity-Check With Users

This is part of our process that few other startups do.

After whittling down the list to the most compelling ideas, we validate them by manually simulating the feature in our product and seeing how people react.

• For website features, we can test an idea by creating a paper prototype and showing it to someone in our office.  These sessions are closer to guided interviews than traditional usability studies because the goal isn’t to perfect the user-interface yet, the goal is to see if the feature is understandable and appealing.
• For features involving IM or email, we can simulate it “live” to people using Aardvark with an infrastructure that we’ve built just for this purpose.  Shortly after testing a feature live (and seeing how people behave), we follow up with all of the users who encountered it and ask them about the experience, with tremendous response rates (people are very responsive to requests for feedback!).

Design Review With Team

At this point in the process we have a series of new features and tweaks to existing features, all of which respond to actual user needs and have been vetted by our users.  (We have yet to do any significant “ready for prime time” engineering.)  

One of the special characteristics of Aardvark is that all of the people who work here are power-users of the product… we all have strong opinions about Aardvark’s design, because it’s a part of our everyday lives.  So at this point we do a full-team design review (on a weekly basis) where we go through all of the designs ready to be implemented the following week and gather team input.  The team has been involved up to this point, but this is a final review before committing more engineering resources to a project.

Implementation Notes

Every week our engineering team sits down and prioritizes the work for the following week’s release as per an Agile methodology.  We use Pivotal Tracker to manage the process.  Most of the time, if our process is working correctly, all of the work being discussed has gone through this design process over the course of a week to a month, and the engineers are familiar with the designs.  

Instead of having feature documentation, the engineering team briefly discusses the implementation of the feature and writes up implementation notes. 

Implement 

We implement most of our work in small chunks that output some measure of user value.  Chunking our work for implementation allows us to stay on the same page internally (engineers know almost exactly what they need to do), and it allows us to release quickly to users so we know whether we’re succeeding.  We usually release after a week of engineering work (for most bite-sized features), and then begin again… follow up with our users, see how the feature has been received, identify problems and opportunities…

That’s a very rough outline of how it works at Aardvark, for now at least.  It’s proven to be very effective at letting us move quickly+responsively, while keeping everyone involved — both our team, and our users.  In some ways, it can feel like a lot of process, and a lot of attention to maintaining process; but we feel it really pays off in the end and significantly reduces the risk of building the wrong thing.

We’d love to hear if any of these resonate with other startups, and we’d love to learn what additional practices are working for other teams, so we can continue to improve our own process.