One of the things I get asked a lot by people interested in user experience design is “How do you do what you do?” The sometimes want specifics, but often the question is broad… what is your process? So, let’s talk about design process.
NOTE: The process that I am detailing here is high-level, and intentionally so – we will dive into the details in later sections of UX 101. Also this process is “generic” – many design teams have their own approach and process different than below, and that’s fine. The process I’m covering here is a good start to understanding what designer should do and when, and we should all be ready to accept different ways of doing things.
Step 1: People
It all starts with people. It’s called USER experience design, after all. Whatever functionality or tool needs to be designed, it needs to be designed with the end-user in mind. Producing functionality that doesn’t align and solve actual user needs results in the creation of offerings that have no audience… and no success.
So, how do you (to paraphrase) “People First” design? You do something that is actually quite difficult for some people to do… you start talking, and listening, to other people.
Later on, I’ll cover what it takes to be a good UX designer, and one of the main characteristics I’ll flesh out is curiosity and empathy. You have to be curious about other people’s problems, and empathetic to their problems and challenges. If you care about people, and want to make the world a better place… you have the makings of a solid UX professional.
The tactical ways you can get a sense of what users want/need/desire are many: reading some books on cognitive psychology can give you some academic grounding, you can have informal focus groups with friends and family, you can do formal research and ethnography, you can look at analytical data, you can look at message boards and forums on the Internet… lot’s of weapons in your quiver. The key weapon, as noted above… start talking, and more important, be listening.
(Note: some large design projects require the creation of an “Information Architecture”, which is a visualization of the information that is being presented in the final experience that is being designed. As this should be a “user-centered” activity (you want the structure to align with the way users think of the information, for ease of use and navigation) I consider this part of the “People” phase. You’re welcome to disagree…)
Step 2: Sketching and creating candidate solutions
“But, I can’t draw!” Some of you might think. Nonsense. When I say sketching, it could be on paper, using a design tool, on a whiteboard, or even a narrative outline in word. The key to this step in the design process is to create candidate solutions to whatever you are designing, “getting down” your thoughts in a way that is understandable and sharable. If you can’t draw or build out a design, then partner with someone who can. A good design team has people who partners with each other, and as they say, “a rising tide lifts all boats.”
One thing to remember in this step is that perfect is the enemy of good. This is not the time to tweak and hone your sketches… it’s about creating and ideating with no restraints. Try and think of the ideal experience for the user, and yes, many of your ideas may not be feasible or practical… but that’s fine. You’ll have to face the hard fist of technical feasibility later on.
The key to this step is to start out by really brainstorming and coming up with a lot of different designs and approaches. You want to create options because if you settle too quickly on one approach, you may quickly find that approach fails when you get to the next step, and you are (quite literally) “back to the drawing board”.
Step 3: Testing
This is where the lessons will be learned, the moment where you present your candidate solutions to test participants and you find out how right or wrong you are. You will find out, in all likelihood, that many of the Great Ideas you have don’t work or make a lick of sense to the end user. Taking your design concepts into usability tests is often humbling… but it’s also a learning experience as well.
There’s many ways you can capture user feedback, both formal and informal. Many UX professionals call initial user testing “formative” and the “second pass” I detail below “summative…” no matter what you call it, the key is to get feedback and identify what works and what doesn’t.
Depending on the scope of what you are designing, you may have to do two or more rounds of initial testing to zero in on an effective design solution.
Step 4: Revising and extending your design
By this point in the process, you should have “landed” at one or two candidate solutions that have tested well… though tweaks are needed. That’s what you’ll be doing here, fleshing out the solutions and making the design more substantial and “real.” You can do this in many different ways, and many people start formal design documentation at this point. I prefer to create functional prototypes of the design so that when we validate it in the next step, it has a higher degree of “verisimilitude” to the test participants.
(I also like using the word “verisimilitude.”)
Step 5: Design validation
Again, get people involved! Have them try and use the design you have created to accomplish the task the tool is intended to support. These tests will be more formal than the early, more exploratory testing, and you will still find issues and “bugs” in the design. And that’s fine, you still have time to tweak things before you do the last step…
Step 6: Documentation and delivery
This is where the experience you have designed is detailed to the nth degree, and delivered to the people who are responsible for executing the solution, which is usually developers. The key is to not “over” document, but to detail the design as much as needed but no more or less. When it doubt, ASK. The team receiving your documentation will be able to tell you the level of detail that is required… and it may be more than you expect.
Remember, design documentation is NOT the final deliverable… the product that is being created is, so don’t look at design documentation as an end in and of itself, but as a means to an end.
Final thoughts on process
The process detailed above is a holistic take on UX design, and it does not cover how it works in different types of processes such as Agile or the traditional “waterfall” method. We’ll cover those processes, as well as “Lean” UX, as a later date. Also not discussed is stakeholder communication and management throughout the process… that is a big enough topic that it deserves a separate discussion.
NEXT: A few words on Service Design and Content Strategy