The design process that’s ready to roll.🎲
All things being equal, I like to follow the tenants of Design Thinking. The dirty little secret is that most organizations struggle to adopt this approach, and stakeholders invariably crave something faster, so we have to take shortcuts.
The dirtier little secret is I still do Design Thinking, I just do it as lean as possible. (Don’t tell anyone!)
Empathize 💜
Market Research & Competitive Analysis
Gathering data about the market and competitors surrounding a given product is a good starting exercise for product design, especially if the client hasn’t come in with positioning already clear. I’ll typically do a little cursory desk research as a matter of course, just to familiarize myself with the space the product occupies if I’m not already well-versed.
Personas & Empathy Maps
Even if clients or teams don’t believe in producing personas or empathy maps, I include them in my process as a grounding element to keep myself and other UXers on the same page. Keeping the user needs and goals distinct and documented provides me with a source of truth to guard against scope creep on projects, and to ensure we’re solving the right problems.
Surveys & Interviews
If I don’t already have data on prospective customers or users, conducting surveys or interviews is a quick way to gain useful data that will form the backbone of other key parts of the process, such as personas and Jobs to Be Done. The combination of the two usually gives me a solid starting point.
Customer Journey Maps
Although customer journey maps are an extensive exercise, the long view they provide is irreplaceable. If a product seems to be struggling to find its path or lacks enough customer data to otherwise produce a reliable roadmap from, I’ll usually recommend going through the work of building out a journey map to help build alignment within the organization.
2. Define 📃
Jobs to Be Done
Using the Jobs to Be Done framework is one of the quickest ways to ensure alignment on the product or feature goals I’ve found, even on teams that balk at other artifacts of the UX process. They’re fast to produce and easy to connect to return on investment for stakeholders.
Storyboarding
Telling the story of the customer’s encounter with a product or feature is one of the best ways I know to pause and look at things more objectively. Whether it’s a short narrative outline or actually sketched out like a traditional storyboard, I find telling the aspirational tale of the customer and product together does a lot for helping stakeholders visualize and understand the end result. It’s also useful to give marketing a starting point from which to tell the product story.
Problem Statements
I’ll write problem statements as a precursor or companion to Jobs to Be Done when necessary since it can help to frame the problem explicitly alongside the user’s goals and needs the way Jobs to Be Done depicts. This way the goal of the product or feature is covered from all directions.
User Flows
There’s no better way to explore gaps in a product or process than to capture the user experience in a user flow. I do these in varying levels of fidelity depending on the need; some have occasionally evolved into service blueprints. But they will almost always reveal some unhappy path or missing element we might not have stumbled on otherwise.
3. Ideate & Iterate 🎨
Sketch
Sketching out visuals (yes, even ugly ones) is one of the fastest ways to get people to grasp a concept. Early on, it might be part of the storyboard process, later on it’s the first step in wireframing concepts out, but there’s never getting around sketching when building a product. Besides, it’s fun.
Wireframe
When we have solution concepts to run with, or a user flow to guide the experience, some fidelity of wireframe will invariably get put together to start to realize possibilities of the interface or layouts. In cases where I’m doing more service design than product design, this step might only manifest for select outputs like emails or smaller customer touchpoints.
Brainstorm
I refuse to allow design to happen in a silo. When we have our data in order, one of the first things I’ll do is gather the team (ideally a mixed crowd, not just designers) and give us some ground rules and activities by which to brainstorm potential solutions. It brings everyone into the process and generates incredible ideas in record time compared to going off solo.
Visual Concepts
Assuming the design has an interface of some kind, visual concepts will come into play sooner or later. In some cases, if I’m working with a product so new there’s no branding, I may find myself going through branding exercises and using mood boards, style tiles, and similar tools to define the visual look and feel of the product before applying them to the wireframes.
4. Prototype & Test 🧪
Content Strategy
Although I’ve listed this here with prototyping and testing, content strategy can and usually does take place much sooner; often alongside user flows and wireframes. It’s here that it gets fine-tuned and fleshed out, once designs are stable. I’ll end up working on copywriting for touchpoints in the interface, ensuring the content has a consistent voice and terminology is uniform across the product and its various pieces and parts.
Style Guides and Design Systems
At some point early in the visual design process, I’ll have amassed enough UI components that it’ll be worth the while to organize them into a library. Some projects aren’t big enough to warrant a fully functional design system right away, but a style guide for developers and fellow designers to reference is a crucial tool to ensure the design is faithful to my original intent no matter who takes over. It’s also a kindness to my future self who may be away from a project for weeks on end.
Hi-fi Wireframes & Prototypes
Once the visual concepts have been sorted out, wireframes will either have their look upgraded to feel closer to the real thing, with UI styles applied, or inched closer in that direction with real content and some branded colors to help give testing participants a reasonably accurate representation of the product when they go through prototypes.
Testing Plan
No two products need exactly the same testing prescribed, so somewhere in the process I’ll evaluate what we have built and what exactly we need to test for. Are we looking for alignment to the original user goals? Are we testing for usability? Is this an early test for market fit? I’ll outline the needs of the test, the success measures, and some potential tests we could run to get the answers we need, based on the available timeline and budget, then carry forth with the plan. And from there I collect the findings to determine what changes we need to make.