Case Studies: Design process story

This post is part of a larger series of posts aimed at helping designers present themselves online. Learn more about “Crafting Your UX Portfolio” here.

Design is an intentional — but at times, chaotic — process.

You’re intentionally exploring and re-defining multiple problems and solutions from different perspectives to learn as much as you can, and then refining and polishing until you’re confident in the way you’ve solved a problem.

This chaotic process lends itself nicely to story-telling. You don’t need to talk about all the details; you just need to plot the main points in a way that lets readers explore what you experienced.

Outlining your story

Writing for design is much like any creative endeavor. It works well when you define the bigger picture, outline your goals, and then dig into the details, exploring as you build. You learn as you explore, and it helps you redefine the bigger picture — the entire work becomes clearer and clearer as you work towards the end.

Start with an outline of your project (whether it’s an entire project, or just a small piece of a much larger endeavor.) Projects come in all shapes and sizes, from a 1-week sprint to a 3-year product, so the following questions aren’t one-size-fit-all. Instead, use these questions as a guide to get you started:

• What were the problems you were hoping to solve? How did you learn about the problems? Were they hunches, or already validated through testing?
• Who did you speak to about the problems? Who did they impact? Did you define use-cases? Did you find patterns of users (e.g. personas) after talking to them? Were you not able to talk to any users?
• For your initial solution exploration, what did you come up with? Did you define success goals with your potential solution? How’d you decide to explore these paths?
• What did you sketch? How did you sketch? Mockups? Did you need to devise any sort of patterns, e.g. style guide, UI pattens, or brand guidelines? Show examples.
• What did you test? How did you test it? Any prototyping? More interviews with users?
• What did you learn from the tests? What surprised you about the results?
• How did the problem change as you learned more? How did you adapt (iterate, refine, pivot) the solution as you learned? Which of your most precious ideas did you kill off in the process?
• How did you decide you were finished? Was it a clear marker, or did you have to make a tough call?
• What was the final result? How did it get made? How did you measure its efficacy? Did you measure success?
• How did you feel at different parts of the project? When were you most excited? When were you most frustrated?
• Lastly (and one of the most important)… what did you learn throughout the process?

If you try to answer these questions in order, with just one or two sentences per question, you’ll find that you have a nice outline of the process from start to finish, and it might have taken you about 10 minutes.

You’ll find that your design process story will incorporate the other parts of your case study. You’ll talk about the problem statement, the users/audience, the team, your role, constraints, and lessons learned. That’s good. Although we highlight these pieces separately in the case studies, don’t worry about repeating these things when sharing your story.

Frame the story to share your beliefs

By telling stories about the work you’ve done, you have the opportunity to share your beliefs, values, and things that are important to you. It helps you connect with people that share those beliefs.

You can take the same exact experience and frame it differently to share different experiences with your reader. Let’s see it in practice:

1. You might tell a story of how you spent weeks iterating on what was originally a complex interface, filled with dozens of different interactions, until you were left with a simple, elegant solution. You crossed the chasm of complexity to find simplicity on the other end.
2. You might tell a story of how there were a thousand directions to go, but you focused on the problem at hand by interviewing user after user, learning what the most frustrating parts were to them. Those insights helped you hone in on the 3 things (of a thousand) that you ended up designing. Research and empathy guided you to a better fit.

In the first story, you’re sharing your belief that iteration will get you to a great, simple solution in the end. You share your value of designing a simple interface. You share that taking time to iterate is important to you.

In the second story, you’re sharing your belief that user frustration will guide you to the best solution. You share your value of saying “no” to the things that aren’t most important. You share that taking time to really understand a problem is important to you.

But both stories could have come from the same project. How you frame your story helps you share your beliefs.

Keep in mind while writing…

1. Show the hiccups and messiness.
   Experienced designers know that no project goes smoothly, and they’re not afraid to talk about why. Fresh designers think that perfection is ideal, so you may be tempted to edit your work to hide the messiness. Don’t. Be open about the chaotic process that is design. Everyone runs into hiccups and messiness.
2. Don’t stress the lingo.
   Wireframes, Mockups, Design Thinking, Static vs Dynamic website, User Research, Personas, Content First, Responsive design, Human Centered Design, Cognitive Load, Card Sort, Mental Model… There are tons of design buzzwords out there. Don’t worry about knowing them. It’s much more important to have an easy-to-understand story that showcases your process. But if it helps you feel more comfortable, you can review the lingo via this glossary, or this message exchange.

Next up → “Case Study: Retrospective & lessons learned”