How We Design Products
Merely designing and shipping a product is hard, and I’m not even talking about a good product. There are plenty of things that could (and often will) go wrong, especially when you’re designing for others (as most consultancies do). Keeping stakeholders engaged and on board with your creative direction, all while keeping waste to a minimum is tricky business.
Our team get most things done asynchronously through GitHub (and Slack) and is averse to meetings and many of the gimmicks of human centered design. But we’ve learned to invest in running product design sprints with our clients (with mucho doodling and post-it-ing). We started running design sprints a few years ago, but over the past couple years, and with inspiration from people smarter than us (Google Ventures & Thoughtbot), we’ve refined our approach and our clients love our product design workshops (and so do we).
We thought we’d share what we’ve learned (before it makes its way into our upcoming playbook).
Overview
We design products the same way we develop them, in iterative sprints. Each sprint is formed of at least a part of this series:
- Understand: set up the context and outline the problems and goals you’re designing for.
- Diverge: generate as many solutions as possible.
- Converge: align the team around one idea (user stories and/or user flows and/or UIs).
- Prototype: quickly build a prototype you can test.
- Validate: test the prototype with users outside your team to learn what works and what doesn’t.
We occasionally skip some of the steps. It is not unusual for example in the initial stages to run a couple “ideation” sprints with only step 1 to 3 (understand → diverge → converge) to help get the team familiar with the process
Preparation
Prior to kicking off a product design cycle, we also spend some time preparing things:
- Selecting the team and its facilitator.
- Start identifying users for testing.
- Setting a schedule (do this ahead of time, you want to make sure everybody will attend).
I also sometimes do a first round of stakeholder and/or user interviews (I’ll develop on this in a future post) and start collecting whatever existing data I can put my hands on: analytics, existing strategies, surveys…
Last point, you want to get a couple tools ready:
- Whiteboards, post-its, notebooks, sharpies… Basically everything you’ll need to doodle the heck out of your ideas.
- A place to consolidate and share your notes (I usually use Hackpad).
Understand
This step is dedicated to framing the discussion and evaluating our design problem by answering these questions:
- What data do we have? Analytics, user interviews, user feedback, surveys….?
- What is the business opportunity?
- Who are our users?
- What pain or problem are we solving?
- Why would people use this?
- Who can we draw inspiration from? Who’s the competition? How does their product work?
- How do we define success? (very important point)
At the end of this step, the team should come up with a sketch of the critical user story and understand how we will define and/or measure success.
Diverge
This phase focuses on generating as many ideas as possible to solve the design problem we’ve identified. Have people working individually or in small teams:
- Each individual/team sketches at least 3 versions of the user flow and UI.
- Teams/individuals then go around and silently evaluate others work.
- You can then open the discussion to the whole group to explain and debate of the solutions generated.
Converge
We’ve generated a bunch of ideas, now is time to settle for one variation that we’ll prototype and test. Pick what you think is the best and avoid design by committee:
- Identify conflicting and non-conflicting ideas from the solutions generated at the diverge step.
- For each idea, list the key assumptions (about the users, business, budget, technology…) that may help weight them.
- Storyboard your picks.
- List how you will test your assumptions for the ideas you picked.
Don’t skip this last point: you don’t want to start building without knowing how you’ll validate.
Prototype
Time to make stuff. You may build a set of paper mockups or a functional Web app. We often start with simple wireframes or a minimalistic proof of concept:
- Keeps it rough and minimal (you’ll probably trash/change most of it anyway).
- Write real text.
- Try and get feedback as you go, preferably from people outside your team.
Validate
We now need to validate our assumptions (see Converge). Set at least 3 user interviews:
- Keep the team separate from the users (Skype, Google Hangout or anything that allows both camera AND screenshare).
- Take notes through the interviews (again, Hackpad is a good idea here).
- Score your ideas (green for good, red for bad and black for everything else) for each interview.
Depending on how you scored, you may need to run another product design sprints (or several) until you’re ready to take things beyond a prototype.
A few things to keep in mind
- Move as fast as possible and iterate.
- Sketching is always the first step, may this be on a whiteboard or on paper.
- Content and function drive the design discussion, not the other way around.
- Work on as few elements as possible.
- Steal ideas from others.
- Be transparent; update others of your progress (in our case on GitHub, Hackpad and Slack).
Must read
Stay tuned
Follow our newsletter or our WeChat account; every other week you'll receive news about what we're up to, our events and our insights on digital products, omnichannel, cross-border ecommerce or whatever the team fancies.
-
Add us on WeChat
-
Subscribe to our newsletter