Let users design your product
(They’ll do a better job than you)
All the objections are true: users don’t have design experience; Steve Jobs said never to ask users what they want; users don’t really understand the tech space; they can’t know what everyone needs, because they are too embedded in their own workflows.
And let’s be clear – I don’t mean literally let them sketch it out, design it and develop it.
But it’s important to be able to lead a group of your users in a requirements gathering session. This is much more important than sitting down with a bunch of people in your company and trying to imagine what your business clients might need.
I’ve read that people rarely use their best ideas during brainstorming sessions – which might be true if you get a bunch of people in the same company getting together to generate ideas in the same room.
But there’s a better way to brainstorm:
- Brainstorm with your customers / users – they will give their best ideas, because they want to use the best software possible. They can’t build it themselves, and have pain points that they can’t solve. Their motivation is to help you out.
- Lead it – don’t just let people throw ideas out. Give constraints, and focus participants.
- Let participants set the tone, cluster ideas into groups, and vote on priorities
- Start wire framing immediately after getting ideas up on the board, when the discussion is fresh in your mind
The process is simple – you give a group of users a pad of sticky notes, a sharpie, and 3 sticky red dots (these will be used for voting). Then you give them a topic and ask them to generate feature ideas in a software. I know, I know, fans of Steve Jobs will be howling in protest, but sometimes users know quite a bit about what problems they experience day-to-day. In fact, they know better than anyone.
When someone is done writing an idea down, take it from them, read it aloud to the group and put it anywhere on the board. After 15 minutes, stop discussion and allow the participants to come up and arrange the notes into relevant groups.
Once the grouping is done (as long as a participant can explain the logic behind a group, it’s fine) let participants use their sticky dots to vote on their favorite group of feature requests. The groups with the most dots can be the focus of the next step, wire framing.
Give the participants some paper and allow them to sketch out a story for how the software might work, including the functionality from the most popular groups. Quickly you’ll find that stories are generated, and while no one story will be the end-all, you’ll find that you’ll get a great sense of how your users conceive of their problems, and how they think about solutions. At the very least you’ll hear them tell a complete story from problem to solution.