ASK THE RIGHT QUESTIONS
User experience design, in my mind is simply an umbrella term that encapsulates a wide array of definitions and techniques associated with product design. I don’t believe there is one clearly defined sequential process that will ensure the right design for any product we might be working on. The classic waterfall model of Research - Design - Validation - Launch and back to Research is at times slow moving, especially in the current context of product design. It has its advantages, for example, in helping maintain a certain amount of structure, but fails to adapt as fast as requirements shift.
In my 5 years as a UX designer, I’ve been exposed to a wide range of design approaches, each with their unique advantages and disadvantages. I’ve always preferred approaches that are more fluid in nature. Perhaps the most critical component of any design process is trying to understand the problem. Almost every design problem on the internet will have multiple posts reiterating this as the most crucial piece of the puzzle.
My approach is to try and identify the essence of a problem, in an almost Feynman sense i.e. from first principles, both from a business and user perspective and designing toward whatever need or issue is uncovered. Why are we building this product? What need is it addressing? What’s wrong with what’s there currently? Has anyone asked for it? and so on. All of these are important to ask before we start the task of putting pen to paper.
- Design with first principles and not by analogy. Identify the fundamental issues.
- Do not reinvent the wheel. Design patterns work. They might not fit custom use cases, but when possible, use tried and thoroughly tested patterns.
- Have design critiques early and often.
- Have conviction in your design work, but be pragmatic at the same time.
STRATEGIES & FRAMEWORKS
At Yahoo, we are increasingly adopting the idea of creating a vision brief for any feature we start working on. Simply put, a vision brief is a document template that allows us to capture high level ideas with having all of the relevant stakeholders in the room. The sections of the template are -
- What problem are we trying to solve?
- What are the best in class experiences for it?
- What is our approach?
- What specific use cases are we designing for?
- What are the specific goals we want users to accomplish?
- What is the best outcome?
- What is the worst outcome?
- What words best describe the users experience?
After the initial discussion around these areas is complete, we try and create Vision Statements, that may be broad or specific, as a tool to refer back to when we are further along in the design process. It is an incredibly useful resource, when validating the design solution to ensure that every requirement was addressed and also as an aide to keep everyone on the same page.
The typical structure for a vision statement is -
We believe that doing X for Y audience will help them benefit they’ll achieve. We’ll know this to be true when result we’ll see in the world.
We may not always have answers to each of these questions upfront, considering that a lot of them need some form of generative research. Regardless, it is an excellent starting point. I think of Vision Briefs as a hypothesis of statements that you need to validate. They may be completely off base, but its a baseline nonetheless.
I’ve participated in multiple design sprints modeled around the Google Ventures idea of trying to solve a problem with a structured approach over a period of five days.
I won’t get into the details here, but it is a very effective framework when trying to ramp up quickly. The five stages (one for each day) are -
- Unpack : The first day is usually filled with stakeholder interviews across the board to understand and identify what it is we are trying to solve. Having the participants come in and talk about the issues and what they envision as a solution is a great platform to start from. The end product is an end to end user story that the designers can divide and conquer the next day.
- Sketch : The second day is dedicated to sketching up ideas to address the issues we discovered during the interviews. There are techniques (Crazy Eights, Voting, Focused Critiques etc.) to make sure the session is productive and has some real solid outcome.
- Decide : The goal of the the third day is to consolidated all of the design thinking of the previous day and to come up with a step-by-step storyboard of what we envision our final design outcome to be.
- Prototype : This day is dedicated to creating an end to end prototype using any tool the team might be comfortable with and which is good for collaboration. The prototype does not have to completely polished in terms of the interaction or the visual design. It simply needs to be enough to get feedback on the areas that were deemed critical when we started.
- Test : The final day is to test the prototype with actual users of the platform.
This five day structure is especially useful when a problem is complex and amorphous in nature. We have had great results on our team using this model and I would highly recommend it. The issue however, is the five day time frame. A lot of the designers do not have that kind of bandwidth with looming deadlines and deliverables.
This framework might be my favorite design approach as it aligns most closely with true User Centered Design. In a nutshell, it is the GV sprint format but a few critical differences. The power sprint is a 1-2 process, with the stakeholders, designers, product managers, researchers & the users in a room together.
Having users present throughout the process of brainstorming, designing and validation is extremely useful. The preparation for a day like this would involve creating a document like the Vision Brief (explained above) and having some exercises planned like affinity diagramming, card sorting, focus group style discussions, sketching, team competitions etc. to best utilize everyone’s time.
The power sprint provides a way to eliminate the barrier of communication between the designers and users. The approaches and frameworks noted above are highly effectively and are things I’ve used and lead multiple times in my work as a designer.
Sprint Driven Tasks
The day to day of a UX designer. I've been part of multiple projects over the years that involve the steps mentioned here.
SOME ADDITIONAL THOUGHTS
Pragmatism and empathy in design
Done is better than perfect.
- Do some scrappy hallway research.
- Take a best guess when not enough information is at hand. You can always change it.
Empathy for your teammates is as important if not more important than empathy for your users.
Be kind to your team mates. All great design comes when everyone works together. That sounds folksy, but it's true.
Business needs are important.
Too often, designers will lose sight of the big picture when standing up for their design work. I want to make sure I word this right; standing up for your designs is important, but making sure you ship products is even more critical. I’ve encountered several designers over the years who feel like project managers, engineering or some other stakeholders are roadblocks. I think its important to realize that we are, at the end of the day, on the same team.