My design process has changed a lot over the years and yet hasn’t changed in many ways. Fundamentally, the processes and workflows I learned and worked through in the early years of my career, still underpin today’s modern workflows.
Discovery & Strategy
Known by many names discovery and strategy is the concept that you first learn about the problem you’d like to solve. “Learn” is a broad term, but the idea is you want to understand, from multiple points of view, what the perceived problem is. This might include talking to stakeholders, users, or other third parties about the problem.
Ideally, you’d spend time to deeply understand the problem, brainstorm around it get all the bad ideas out. But time is often a luxury and sometimes you must decide that you know enough to start thinking about solutions.
Whiteboarding
The best part of the design process. It’s quick, dirty, and collaborative. There are almost no barriers to whiteboarding, you can use fancy software or literally a whiteboard or just some scraps of paper and a pen. Anyone can do it and that’s kind of why it’s so great. Non-designers can be part of this process and collaborate, nothing is set in stone.
I like to whiteboard (or sketch) throughout a project. If I’m working in design sprints I think it’s important to have a nice long whiteboarding session at the beginning of the print after the kickoff. This could be something I do with just the design team or with the broader team, there’s kind of no wrong way to do it. The point is to get stuff out of your head and onto a page.
Wireframes
Depending on how rough your whiteboarding sessions are I sometimes find it useful to take some of the better ideas and start laying them out a little more formally. Sometimes I use whiteboarding tools like FigJam or Invision Freehand and whiteboarding is a little less useful as those concepts are already digitized, editable, and of appropriate quality.
But wireframes can still be useful. You can create prototypes out of your wireframes or use wireframing to work out specific layout problems. With design systems wireframes become interesting. Since the components and concepts are driven by the design system it might lessen the need to wireframe or quicken wireframing. Pulling in components from a library alongside rougher, wireframed, elements to produce a screen can help speed up UI work as that wireframe can be handed over to refine rather than starting from scratch for hi-fidelity.
User Flows & User Journeys
Capturing the user’s happy and unhappy paths is an important exercise. What this looks like can vary, and is less important than the fact that it’s being captured in the first place. There are many tools to create these flows, Axure, Miro, OmniGraffle, among others.
It’s been important for me to create flows to firstly understand the journey and physically look at it, but also as a handoff tool for engineering. Flows can help devs understand the journey and have a better understanding of the functional expectations.
Design Systems & Component Guides
They may have their faults but design systems are a sea change in product design. They attempt to do what most processes and tools try to do, bring some order to the chaos. Design systems don’t make sense for any project, but at a certain scale, whether that be the size of the platform, the size of the team, or the number of related apps, they undoubtedly can provide a lot of value.
I’ve been able to both help build design systems and consume design systems. When built well, with cross-functional teams in mind design systems can speed up work, provide inherent consistency and importantly bake in things like accessibility. This allows designers consuming the system can focus on solving the current problem and not worry about reinventing text inputs.
At a smaller scale something like a component guide, a simple set of assets and rules, can help provide some of that consistency and speed you would get from a design system.
Documentation
Sometimes we’d like to not admit it, but being able to write is a key skill for a designer. Writing and design are communication tools, they are also muscles you can exercise. Writing documentation not only gives whoever is consuming your design some crucial context, but it also reframes your own perspective on your work. Writing can illuminate gaps in your thinking or highlight a problem.
Reading documentation can help you write better documentation. While working on a design system, part of my role as a UX designer was to capture all the component documentation. Lucky for me there were some great public design systems I could read and try to understand what I liked about them and why I liked it. It can be a blurry line sometimes but building off of something can be much more beneficial than reinventing the wheel.
