Adzerk Team Blog

In a more traditional organization, there’s often an entire team who dedicate all of their time to developing comprehensive studies, aggregating user data, conducting surveys, and the like.
 
In the fast-paced world of a startup, you don’t really have the time to do all of that. In fact, there’s a movement afoot that says UX Designers shouldn’t be indulging in such ponderous exercises no matter what sort of organization they’re working with. Gathering as much user data as possible is not the problem; data is always a good thing. The problem lies in the tools and methods that have come to be utilized in integrating the data into the software development workflow: deliverables. It’s easy to get bogged down in a slow and cumbersome cycle of wireframing, surveying, studying, testing, rinse and repeat ad nauseum. In the meantime, you’re not fixing known problems or bringing all this data to bear on the development of new features for one of two reasons. Either you’re moving so slowly that the development team has cut UX out of the loop, or new development is being held up while waiting for designs to be perfected. Either case is no good.
 

Enter Lean UX

Or, the principles of Agile Development applied to traditional UX design. Lean UX values team collaboration over completeness of design. At Adzerk, as previously mentioned in Andy’s post about AgileZen and Kanban, we’re working with Agile Zen and the principles of Kanban to simplify our development cycle and place emphasis on delivering working software as a team, as quickly and simply as possible. In order to integrate UX Design into this process, we came up with the following steps:
 

Figure out what we’re doing

We create a user story in Agile Zen. This usually happens as the result of a bug or as part of a larger feature request. It always includes at least some team discussion beforehand, often with a whiteboard and some preliminary sketching, during which as a group we come up with the primary use cases and user flows.
 

User Validation

This phase can include quick click tests, surveys, or just a phone call to a customer we know would be interested. The main idea is to present what we’re thinking and get feedback. The feedback we gather is then incorporated into the next phase.

UX Working Phase

This is where the feature is fleshed out and designed. The deliverable is working UI code, although paper prototypes are often created as well. We rarely spend time committing anything to pixels prior to the actual code.

Development

After a feature is developed, it’s deployed to production as soon as it’s committed to GitHub. This is where our nifty feature flag system comes into play.
A feature flag keeps unfinished work from being accessible or messing up the application for users, and also allows us to turn on new features selectively for particular customers without turning them on for everyone. This allows an even tighter feedback loop- in a recent example, we redesigned one of our reporting pages. A few emails and chats before we started provided good information as a baseline, and then 3 days later we flipped the feature flag for those specific clients to see what they thought. This process gives us the ability to let customers be involved almost as closely as members of the Adzerk team, which we really dig, and our customers do too. The short turnaround times also keep us honest, and prevent feature creep.

“Supposing is good, finding out is better”

—Mark Twain

Ongoing Evalution

We have a few tools that we use to keep tabs on how things are going, apart from the world of rapid feature development. We run a series of quick weekly reports to keep the team updated on how things are going. Problem areas are noted and addressed as a part of related features/stories to keep from holding up new development. I’ll post in more detail in the future about the specific metrics tools we use.
This system is constantly evolving, as is the use of Kanban in our general development workflow, but for now, we’re hitting the two key areas of getting feedback from customers into the design conversations on the team.

Comparing Notes

Other startups in the world are facing this problem. How have you solved it in your startup or organization? We’re always looking for good tips and feedback to incorporate into our process. What have you found that works, or doesn’t work?