The lean product design process: A guide
This guide was originally written as a reference guide for a newbie product team I was consulting with. I’m publishing it here for my students, clients, and anyone it can be helpful to.
This guide is intended to clarify what it looks like to get from an idea to something ready to start building, using a lean product design process. These steps are in an order - but think about the process as a cycle, where research happens every few weeks to sense check that we’re still on the right track, and each step can be used and iterated on wherever it’s needed.
Contents
1. An idea for a new feature or goal
2. Sketch out the idea
3. Identify risky assumptions
4. Create a prototype
6. Write a screener to find people to interview
5. Write the moderator guide
7. Organise and book in research round
8. Run ~6 user interviews
9. Synthesise findings and discover insights
10. Decide what’s validated and to be implemented
12. Visual design the validated features only
13. Story writing
14. Design screens for each story
15. Dev-design pairing
16. What comes next?
1. An idea for a new feature or goal
Ideas come from many places: From leadership; from data; from previous customer insights; from a hypothesis; from the customer service team; from someone else in the team.
The best ideas are phrased around problems to solve or goals rather than features. For example:
“Our customers aren’t using our loyalty cards, and we think it’s because they’re forgetting the coffee loyalty card exists. We want to work out why and fix it (and we think an app might be the way).”
is a better place to start than
“We want to build a loyalty card app.”
The first gives us the freedom to learn unexpected things in the research, stay open-minded, and come up with the best way to solve a problem. It also allows us to invalidate our hypothesis (“We think customers aren’t using their loyalty cards because they’re forgetting they exist”). We could be wrong that that’s a problem, so we should use research to check. And if we are right that it’s a problem we want to solve, we could still be wrong about a loyalty app being the best solution. The best way to solve a problem isn’t always the first one we come up with of, so it’s always worth checking before we spend a bunch of money and time building something. This is how research reduces risk and saves businesses money in software development.
Part of the job as a product person is to receive requests from the business in the form of the second example, and reframe them to be more like the first example. Our goal is to solve customer problems while executing business requests (not just to execute business requests). Yes - sometimes this means convincing business stakeholders, over and over again, of the value of research. That is our battle…
2. Sketch out the idea
If there is a clear early idea of what a solution might look like, spend a small amount of time - less than 1-2 hours ideally, as a team - sketching it out. Drawn on paper, using words, etc.
The purpose is to create the lowest effort possible prototype to get in front of customers to test the idea.
If there is not a clear idea on what the solution to the idea could be, that means the first round of research is purely generative.
How to sketch out the idea:
👉 Run a scenario & team sketch session workshop
3. Identify risky assumptions
We always want to derisk new features or ideas before we build them. The risk grows when we’re making guesses about things and we haven’t checked them against real users, real data, or real business realities. Guessing isn’t enough to be sure.
To identify the stuff we’re guessing about, we need to get the team together to workshop what assumptions lie behind the idea, and what’s riskiest about it.
👉 Risky assumptions & learning goals workshop
Some example risky assumptions could be:
Sarah visits the same coffee shop over and over.
Sarah would download an app purely for the purpose of saving a few dollars on a morning coffee every few weeks.
Identifying risk assumptions helps us to know what research needs to happen next: whether that’s research with customers, research into technical feasibility, and research into business viability, and in what combination.
Once we have our risky assumptions, we need to turn those into learning goals. All the assumptions might not translate into learning goals for user research - they might look like learning goals for technical research or data gathering.
Remember to scope down learning goals - if it’s important, it will come up again.
Assign people to each thing that needs to be done.
If customer research is required, kick off research as below:
Tools
Why do customer research?
The primary reason is to validate whether or not the idea from step 1 is something that is valuable to customers. In short: is this thing worth building or not? It might be technically feasible, and it might be something the business wants, but if customers don’t see the value in it, they won’t use it. And if customers don’t use it, it probably wasn’t worth spending the time and money to build.
Research helps with this in three ways:
Validating specific ideas, features or goals
Building general empathy for the users contexts, mental models and needs
Uncovering opportunities by discovering user needs and pains
👉 Research Round Trello template
4. Create a prototype
This is where wireframes come in.
Create a quick prototype for testing - wireframe-style is sufficient. Visual design is not needed at this early stage, if the learning goals are around validating the value of the functionality as opposed to the usability of it.
It’s okay to throw stuff into the prototype that would never make it into development, but is purely there for testing an idea with the audience or to act as a conversation point. For example, if I was really interested in how dedicated someone would be to not calling, I might put a big “Call Now” button on each page to see if I could “tempt” them into calling. I could see at what point in the flow they would do so, and could use that moment to talk about calling vs. not calling.
Another way of testing a hypothesis is to design an experiment.
6. Write a screener to find people to interview
We write a screener based on the persona, really answering: are we speaking to people whose opinion we actually care about (in terms of this idea)?
For example, if we’re building a product about coffee loyalty, we don’t care at all if people who never drink coffee find it confusing. It’s not always that obvious though: we probably also don’t really care if people who don’t have a single loyalty card in their wallet don’t want the app. Maybe they’re not our target audience. We want to talk to coffee drinkers, who frequent our coffee place regularly, and care about getting loyalty bonuses, and have a smartphone, and are savvy enough with that smartphone to be likely to download an app like ours.
5. Write the moderator guide
Now, looking at the learning goals we have from before, it’s time to write a moderator guide (or conversation guide) to use during user interviews.
My preference for moderator guides is to pre-write all the questions beforehand. The reason for this isn’t to then go ahead and ask every question on the script (rapport and a natural conversation is better), but I find having pre-thought-out the way I will phrase a set of key questions means there’s less mental load in the moment when you’re interviewing.
7. Organise and book in a research round
I would challenge you to make this piece as short as possible - it’s okay to feel a little bit like “omg, we’re not ready for this!”. I frequently book in research for two days away and force myself to be ready for it when it happens. It’s better to move a bit faster and leaner than to spend a bunch of time preparing beautiful prototypes and perfect moderator guides when you’re going to end up iterating on them anyway.
Here’s a few steps:
Find 6-7 participants via various methods:
By using a recruiter (Farron, Stable Research, etc):
Engage with Farron
Send screener
Coordinate with contact to get the right people booked in
By using the team’s personal networks:
Create screener using Google Forms or similar
Send it out via Facebook, LinkedIn, Twitter, etc
Ask team members to do the same
Coordinate responses and who’s booked in using a spreadsheet
Organise payment for them ($100 gift cards work well)
By using your real customers:
Select a subset of customer emails to contact (legally!)
Blast out a link to the screener
Select participants and coordinate with them to book in
Book meeting rooms or a location for 2 days
Organise moderators and note-takers from the team
Organise whether you’ll stream the interviews via Zoom, etc, and share the link
Organise a camera, audio recording, etc
8. Run ~6 user interviews
Who runs them? Whoever is best suited in the team - usually PM or designer, but others if they are keen and happy to learn how to do it well.
🔗 [Deck] User interview techniques
🔗 On the conversational user interview
Note taking
The role of the note taker is an awesome opportunity to bring lots of different people from the team in to the room during a user interview and getting face-to-face time with customers. This is so valuable for building empathy amongst the team and energising and reminding us all why we are here: to solve customer problems!
There are different methods on taking notes in user interviews, better for different purposes. Here’s more on that:
9. Synthesise findings and discover insights
Synthesis is best done ASAP after the final user interview, while it’s still fresh in everyone’s minds. Here’s how to run a synthesis workshop with the team (this is an awesome time to bring in anyone who was in a user interview - diversity of thought is super useful for getting lots of “a-ha” moments, and it’s also great to keeping the team on the same page).
Record insights
Finally, you’ll want to record the insights you found. The goal here is to hit the sweet spot of documentation: just enough to be able to communicate them outwards to the business and forwards to people in the future who might join the team… but quickly enough not to take more than max an hour or two of your time now. We don’t want to see a beautiful deck of research insights, because that time would be better off spent implementing those insights by iterating on the product!
Some ways to record insights:
Type the insights and a few key quotes into a document (better for printing and sticking on walls)
Put the insights and a few key quotes into a deck (better for talking people through)
Put the insights into a Trello board
10. Decide what’s validated and to be implemented
Following from synthesis, you should have a set of actions for various people in the team. Part of coming up with those is deciding as a team whether you’ve validated or invalidated anything in the idea, the designs, or the value proposed.
What this looks like is really just a conversation with the team who were involved with the research round. Look at the learning goals and ask yourselves, can we answer these? What have we learned? What do we feel comfortable moving forward with? What needs more clarity?
Remember the adage: The only failed experiment is one with unclear results.
If we tried things that were a total bust with users, we should be happy that we tried it this early and found that out before we built it! This is why regular research allows more boldness and creativity: go ahead and test out crazy ideas. The most time we can waste on them is the week or two of the research round.
12. Visual design the validated features only
This is now when visual design comes into the story. Implement visual design on validated functionalities only. By doing it at this later point, no time is wasted making features look beautiful that might never get built.
13. Story writing
Now it’s up to the PM to break the new validated feature down into smallest pieces that provide user value, and turn those into stories.
We should be able to release the software to the public after each story. So, for example, if we were implementing the screens above, a story would not look like this:
Create red “Emergency call” button
Acceptance criteria:
Display the red button (visual styling)
That doesn’t provide user value yet. We couldn’t release it to the public, because it’s just a button that doesn’t do anything!
A better story would look more like this:
Sarah can call 000.
Acceptance criteria:
Display the red button (visual styling)
On hitting the button, it calls 000
Sarah sees that the call has begun (another screen would need to be included here!)
This is better, because it’s focused around the user value - calling 000, more than the visual styling or the implementation.
The story also wouldn’t look like this:
Sarah can see her location, and hit the “Emergency Call” button to call 000, and have her location recorded and sent to Emergency services
Acceptance criteria:
Display the red button (visual styling)
Find Sarah’s geolocation
Display Sarah’s geolocation on a map (visual styling)
On hitting the red button, it calls 000
Sarah sees that the call has begun
Sarah’s location is recorded locally
Sarah’s location is sent to Emergency Services
There are multiple pieces of functionality on this page, and each of them can be built separately to one another. It would be okay to build just the call functionality, and release that without the visual map - that would still be providing user value.
How/when does this happen in conjunction with design?
Visual design and story writing can happen at the same time. It would be normal for stories to get written from designs, and it would also be normal for designs to get created from stories.
This is where it becomes really important for the PM and the designer to be on the same page if you’re working as a product team. If you’re constantly communicating and you’re totally aligned together on where you’re going as a team next, it should come naturally to work out what needs to be done next. This is also where it becomes extremely useful to be able to sit next to each other so you can just chat…
14. Design screens for each story
The process of what screens look like for each story is different for every designer. Some people upload the finalised screen with highlighted elements that relate to that story, a bit like this:
Some people edit the screen down so that it only shows the relevant elements to be added in that story, and thus have many iterative versions of the same screen floating around.
It really depends on the engineering team, and what they’re comfortable with.
15. Dev-design pairing
There’s nothing as painful as trying to communicate design tweaks between design and engineering, going back and forth a bunch of times, and both getting totally frustrated about it. It’s also not a good result to let a feature get released to the public without being approved by a designer’s eye.
A quick solution to this conundrum is letting the front-end design get built to about 80% pixel-perfect. Explicitly ask the engineering team not to spend hours on trying to get things pixel perfect if they’re really tricky. Then sit down once a week or so for dev-design pairing and get that final 20% nailed down.
The reason this works better is that that final 20% can sometimes take up a disproportionate amount of time in twiddling and tweaking things, and with a designer’s eye on it, we can usually make some compromises that still both look good and are reasonable to implement. We also avoid the horrible back-and-forth of “move the button 20px to the left”.
🔗 How to do dev-design pairing
16. What comes next?
Through the process of seeing how users react to the stuff we’ve already done, seeing how they feel about our new ideas, and seeing how easily they can use things the way we’ve designed them, we should have a bunch of action items to implement. Those might be usability changes, iterations to features, it might be cutting things out or adding things in. It might be fixes to data, or APIs being built, or stories being written.
And probably, through talking to users about their context and hearing about their pains, we might be starting to form ideas about what we could do next. Ideas which need to be validated before they’re designed, built and released to the public. And so the process carries on.
In product, we’re always kind of juggling the present, the past, and the future.
We’re thinking about the long term vision - where do we want to get to one day?
We’re thinking about short-term goals - what epics and feature sets can we work on to keep rolling onwards towards that vision?
We’re thinking about tomorrow - what stories are the engineers building to take steps towards finishing the feature set we’re on now?
And we’re also thinking about yesterday - is what we built last week working the way we thought it would? Is there anything we should iterate on because it’s working differently or being used differently to how we expected? We’re course correcting what we’ve already done as we keep moving forwards.
Agile product development is a little bit like a road trip. We know where we’re going - the name of the city, and what we want to do there, and we have a fairly decent idea of what it’s like there. But we don’t know all the streets, or the layout, or really a lot of things about the city yet.
We also have a pretty great idea of how to get there. The towns and highways we need to tick off. But we wouldn’t set the car in the exact direction of that city from home and then leave the car driverless until it got there - you don’t know what you’re going to learn along the way about better ways to get there, roadwork, or interesting side trips that could end up being the best part about the trip.
We need to have an idea of the big navigational picture, as well as doing the tiny bits of work moment to moment to keep the car on the road. We’re constantly scanning the road and making tiny course corrections.
This is what agile software development aims to do - because the world of software moves so fast, we need to constantly keep our eyes on the road and make small course corrections to stay on the right track. And we need to have the freedom to follow up on interesting side trips or take a different route if we hit roadwork, while still moving towards the final end goal. What’s an amazing idea in 2015 will have different requirements and maybe a different implementation in 2018. Agile is a way of structuring the way work is done to allow for that flexibility.
Questions or thoughts? Feedback? Wanna work together?
Let me know on Twitter! @nicolarushton
