Understand your users. It sounds so simple, but it’s often ignored. Mainly because people are stuck in their own heads. But thankfully we’ve got a bit of a head start.
Christian and I have worked in the industry designers ourselves, and we’ve used a lot of painful products in the past, so we get the need. We’ve been there.
And our guiding principle at Streamtime is that we recognise that humans use our products, not robots.
We know people are not simply machines. That you get the best creative work when people are at their best in their whole lives. And that human brains don’t act like computers. We’re more complex, and more brilliant, than that. Our behaviours are driven by countless factors, not just emotionless calculations.
And since we’re designing for humans, we make it a point to talk to those humans all the time.
In fact there’s no better way to understand the hopes, desires, and aspirations of those you’re designing for than by talking with them directly—so that we can empathise with our customers to create a product that sparks joy.
That means before we start a new stream of work we go and talk to our users. We run interviews to get first hand feedback, asking open-ended questions to prompt customers to tell us what their pains and frustrations. This is before we even start looking at what changes we’ll make.
We nail down this customer feedback into user stories — who’s asking, what do they want to do, and why do they want to do it?
Often people will suggest something really specific, like a feature request. But if we implemented every feature request we got, we’d end up with Frankenstein’s monster.
Instead we keep asking questions. We dig deeper. We nail down a story that speaks to the core of the problem, rather than just jumping to the solution by building exactly what was asked for.
Sometimes there will be a bunch of user stories that feed into a broader problem. So we can tackle the biggest one, head on.
The reason we do it this way? Is that because sometimes there’s a better solution that the particular feature that users have asked for.
Seeking out feedback from day one to day done
So all this talking results in insights that we can take forward to inform our design work. But as we move through our design process we don’t just sit back and design something, build it and release it. We’re still listening.
Because while we’ve heard the problems, we need to make sure our solutions work. So we test those with our users too.
That means we can validate our designs and our thinking. Then we incorporate that feedback to progress our designs even further.
And we test before launch because it’s lower risk. As Marty Cagan says, “the overarching purpose of any form of prototype is to learn something at a much lower cost in terms of time and effort.”
For us that means everything from lo-fi paper mockups, to experiments coded within the product.
This allows us to release in confidence, knowing our users will find it useful. And it’s good to build relationships with the people that will be using our work day in, day out.
The best thing about all this? Well it turns out if you take people on the journey with you, they love it. They love knowing people behind the product and that we’re constantly listening to them. That in-turn serves to create more loyalty to the product, generate more referrals and further our user base.
Keen to learn more?
We’re sharing our Product Design Playbook. 10 rules we follow when we design. Head here to read other posts from the series.
