My Approach to Design

The foundation of my design process is exploring the design space to find ways to deliver value to business and users, and then finding ways to validate those designs with real data about users. On a product team, I provide design and research leadership by bringing together the best ideas about how to meet user and business needs, and bringing the team into the research process so they can learn about users first-hand.
In my current work at ITHAKA, I use the Lean Startup method. This approach entails a cycle of Build-Measure-Learn to efficiently determine whether features and products are delivering value by testing ideas as early as possible, before extensive development resources have been spent. I firmly believe that user research is key to building great products.

Of course, judgment, best practices, and experience are an essential part of the design process. They let us quickly constrain the design space, ruling out possibilities that probably won’t work and focusing our attention on better solutions. However, within that constrained design space, it’s important to recognize the limits of our ability to judge which specific solution is best. Rather than rely on opinion or on who can most vociferously argue for a specific design, we can use the many tools at our disposal to gather data from actual users.

Different research methods are more appropriate for different circumstances. I have used interviews, usability testing, A/B testing, and web analytics data to shed light on how successful a design will be. In some cases, you need to understand what users think about a design or what features they may need. In other cases, you need real-world data about whether your design drives users to take the desired action.

The Design Process

There’s no such thing as a one-size-fits-all design process—rather, the work of design should be tailored to the specific problem you address. Nonetheless, there are almost always activities that fit into the following categories:

1. Discovery
2. Ideation
3. Refinement
4. Validation

In the following sections, I describe these phases further and present examples of deliverables.

1. Discovery

The first step to solving any problem is understanding it. During this phase, I may talk to stakeholders, do competitive evaluations, market research, perform heuristic evaluations of the existing design, look at previous research, and more.

During this phase, I help the team identify design opportunities and hypotheses that we can test.

Coming out of discovery, it is important for all of the stakeholders to agree on what problem we are attempting to solve, what constraints are involved, and most importantly, how we will measure success.

2. Ideation

During the ideation phase, the goal is to explore the design space before settling on a single design that we will validate. This means quickly coming up with as many ideas for delivering business and user value as possible in order to contrast them and refine the strongest ideas. The ideation phase calls for speed and tools like pen and paper or dry erase boards.

It is important to focus more on generating many ideas rather than evaluating them. At this stage, I often facilitate design workshops where the product team can get together to pool our creativity.

There isn’t a firm line between ideation and the next phase, refinement—in practice, they blend into each other. Ideation is an iterative process of sketching and re-sketching ideas, using professional judgment and best practices to weed down the ideas. Ideation ends when you have a handful of ideas to refine.

3. Refinement

Refinement is where I take the design ideas that emerge from ideation and iteratively develop them. In this phase, pen and paper and dry erase boards continue to be valuable, but here is where I frequently use Omnigraffle for wireframing or other prototyping tools. Often, I communicate designs to developers by writing Agile stories.

During refinement, I capture the designs at a higher level of detail with each iteration, soliciting feedback from stakeholders each time and adding detail to try to account for the complexities of the system and of human behavior. It is important to recognize when you have reached the point where you have enough of the design fleshed out to validate it with user research. This is when the validation phase begins.

4. Validation

There are many possible approaches to validation, ranging from high tech to low tech and hands-on to hands-off. It may make sense to validate a design with usability testing when it’s still a pen and paper sketch, for example. Or, at another extreme, to build a new page to A/B test against whatever currently exists on the website.

During the validation phase, I lead the planning of how we will test designs. Planning involves explicitly stating the objective of the user research activity and what hypotheses we want to validate. It is important that you know how you will evaluate the effectiveness of the design—that is, determining the metric or metrics that tell you whether the design worked.

Besides planning, I also am experienced with setting up and conducting user research activities, from online card sorting studies to usability testing, and then analyzing and reporting the results. A unique value that I provide as a UX professional is depth of experience with web analytics—in 2013, I wrote the first book on using analytics for UX research.

The Build-Measure-Learn Cycle

The stages of discovery, ideation, refinement, and validation fit well into Lean Startup’s Build-Measure-Learn. Discovery, ideation, and refinement are a way to approach the Build part of Build-Measure-Learn. As an experienced designer, I engage deeply with the Build stage. Then, validating the design idea takes place over Lean Startup’s Measure and Learn stages.

Influences

Some of the influential books I’ve read include the following:

• About Face (Alan Cooper, Robert Reimann, and David Cronin) – This book exhaustively covers the whole design process, which is valuable, but it was the chapter on retiring the “Save” button that cemented the importance of this book. We must always remember to question the assumptions baked into the designs we’re used to.
• Contextual Design (Hugh Beyer and Karen Holtzblatt) – Contextual Design was my introduction to ethnography and gathering data about users and representing the information in meaningful ways.
• Quantifying the User Experience (Jeff Sauro and James R. Lewis) – An eye-opening book on using statistics to describe the results of small-sample-size research (such as usability testing). This book has made it much easier for me to discuss quantitative data with others.
• Usability for the Web: Designing Web Sites that Work (Tom Brinck, Darren Gergle, and Scott D. Wood)- My first design class was taught by one of the authors. This class (and his book) covered discovery, ideation, and refinement and the foundational techniques I use every day such as sketching thumbnails.

Working with Me

Collaboration is of utmost importance to me. Important information and great ideas can come from anywhere, so I want to communicate with as many stakeholders as possible. One of my roles on a team is to facilitate communication. I gather information and reflect it back to stakeholders, usually through the deliverables I create, in order to provoke conversation. Often, it’s just as important that stakeholders talk to each other as it is for me to talk to them—this is often a vital role for UX.

I thrive in collaborative environments where everyone feels like they are in it together and are able to learn about others’ domains. It is important to me that I constantly learn and grow. I enjoy on fresh challenges. I am comfortable working within established processes and workflows, but I find making new processes to be an exciting challenge. In those situations, I create structure and documents as I work, so processes can be repeated and refined.