Harnessing Agile to Build Great Designs

Startup + Agile + Design

Agile should mean that we’re making quality products, right? Similar to the user centered design process, agile promotes continual iteration and learning from people who use your product. Why is it often so challenging for a product organization (startup or not) to balance the inherent need for speed against the quality that all designers strive for?

It’s rich and fruitful to be a designer working at a product development startup. We’re making things. We’re making and launching things iteratively. We’re getting fast feedback from customers and users. All of these is a beautiful thing. I’m lucky enough to work at a startup that values design and has design courage. User experience design is one of three equal pillars in our product development organization, along with product management and engineering.

In the beginning… Iteration 1

As a startup, we need to move fast. We launched our v1 product about a year ago and are on 2-week sprint cycles. With our 3-pillar approach, we’ve been continually revising the ways that we work. Initially for every project, design had to start first. Design had to be 1–2 sprints ahead of development. While we’ve done away from the need to wireframe, we still had a heavy process with design ideation and conceptual exploration for every feature. This worked OK for a quarter or so, but we realized that design was making things too slow. We were holding up the rapid rocket ship process of needing to launch fast and launch early because we were too hung up on the quality of our designs.

“If you are not embarrassed by the first version of your product, you’ve launched too late.”
— Reid Hoffman

That was the design hubris that we’d fallen into, sadly led by me.

Go faster… Iteration 2

So we changed, we adapted and made our process leaner while still maintaining that the product quality was important. We are a company that values the overall product experience, especially to make the product experience of data more simple and more easily understood by a non-technical audience. We looked across our product and weighted the different areas of the product into three buckets:
1. Minimal. Simple features with existing well-established patterns. For example: an administrator screen to manage user permissions.
2. Functional. Complex feature that needs to be well thought through and on parity with competitors. For example: a way to combine two datasets into one.
3. Awesome. Product differentiators that we will hang our hat on and will be a primary reason for a customer to buy our product. For example: a unique interaction model that gives suggestions to non-technical users for how to prepare their data.

Minimal

For the first type of work, we would either do no design or the lightest possible touch of design. Practically what that means is that we may have a 30 minute white board session to agree upon the goals, sketch up some flows and screens, and specify what patterns to use for the UI. After it’s developed, there would be some light back and forth to ensure that the solution still meeting the right product goals. And finally, this would happen during the iteration when code is being written.

Functional
This type of work would start a sprint or so before code-writing with a well grounded sense of the feature’s goals. These goals are determined by product management over several rounds of discussion with design and engineering. The design goal is to develop a functional solution that follows established patterns, both within our product and commonly accepted across industry so that users can accomplish their tasks quickly and with little to no fuss. We care very much about usability and the experience flow of users through their screens, HOWEVER, the important thing to note is that no extra cycles are spent ideating or doing concept work to re-think this feature and deliver it in the most innovative ground-breaking way possible. With those constraints in place, design works a lot faster.

Awesome
Our final class of work refers to product differentiators that can make or break someone’s experience with our product. This could be a killer feature that’s not available anywhere else or some delighter microinteraction that can drive a user’s emotional connection and satisfaction with the product. This ideally would change their experience of the product from something utilitarian used every day to something that they love and rave about to their friends. As a startup that needs to move fast, you can’t have too many of these Awesome Items as it’d be de-focusing. Leaderships in product and design need to agree up on these items and their priority. For these projects, design could be up to a quarter ahead of code development. We can pull out the stops and explore and ideate freely to come up with the best possible, most innovative solution to solve the problem and user goal. Our guiding principle and design foundation is always the user goal. We have to ask ourselves the same questions. Why are we building this? What does the user gain? How will we know when we’ve achieved the goal?

We create multiple directions and multiple explorations. The entire team is involved in this as not all ideas come from designers. Ideation and sketch sessions are with everyone in the company.

Putting it all together
No matter what the design support, every area of the product needs success criteria to evaluate how we know we’ve achieved a releasable feature. Yes there’s areas that may be slightly embarrassing but it’s OK. Release it and make sure that there’s enough time to refine and tweak and keep iterating towards quality.

Continue to learn… Iteration 3 and beyond

Who knows where we go next? We’re still exploring the end of our second iteration with retrospectives to see how we can adapt the process. Some things we’re interested in exploring more are:

• How do we better integrate non-designers into the exploration / ideation process for an Awesome piece of work without distracting them from code-delivery on their current sprint?
• How do we make sure we’re solving the right problems?

No matter what, we’ll keep trying and keep making sure that our end product is both released quickly to get iterative validation and also has a level of quality that we’re comfortable with. We’ll be ping-ponging between those two axis for many more iterations of this process to come.