You don’t know your users as well as you think. You might not know them at all, it might just be a handful of assumptions and educated guesses. But you know what?
That’s OK. In this blogpost, I’m going to tell you why you don’t know your users as well as you think and more importantly, what you can do about it.
If reading isn't your thing, our commercial director Craig, takes you through the subject in this video from our YouTube channel.
Users – An overview:
So, users… they (or should that be ‘WE?’) are a fickle bunch. Powerful too. If you annoy or pester them or you give them a poorly made product, they’re going to talk with their feet and leave or leave a 1-star review and then leave.
Probably for a competitor. Yeah, that one you really don’t like.
Users have the power now, not you. Your product isn’t necessarily going to be the only option a user has. It not only has to meet the basic demand but surpass them. Are you going to stick with that app that sends constant notifications at all times of the day? Or the one that sends you that one timely intervention when you need it?
The more we know of a user – their behaviours and demands – the better the products we can make. So how do we go about learning more?
Two words: Design sprint.
What are design sprints?
Developed at Google Ventures (GV), what we know as a ‘design sprint’ was created by Jake Knapp & John Zeratsky. It’s a toolbox of exercises bringing together aspects of behaviour science, design thinking and business strategy to assist various organisations in building better products for their users.
At Eden we’ve been running design sprints for over 6 years now and have honed the design sprint outlined by Jake & John into something that suits us and that we can adapt for various clients.
But at its core design sprints are about one thing. Knowledge. Gaining it, sharing it, acting upon it and learning from those actions. These design sprints bring all the stakeholders into one place and together, thrash out everything they know about user behaviour and internal processes before pitching potential solutions, building a prototype and testing it. This information is then open to all stakeholders to assess and scrutinise before making better business decisions. For example, on one occasion, the testing reported that users hated the idea. They couldn’t see themselves using the product at all. As a result, the client pulled the plug on the project. All before a single line of code had been typed out.
The design sprint enabled the client to know their potential users better and so could make better decisions as a result.
Why utilise design sprints?
We’ve all seen this triangle, right? The whole pick two – you can’t have three? Well, design sprints are the only thing I know of that breaks this rule.
They’re fast – not one client has completed a design sprint and isn’t blown away by what they’ve learned and accomplished in such a short time. They’ve gone from having no clue to a tested prototype with actionable and tangible feedback in about a week.
They’re great value for money – you can run a sprint on your own or hire someone to help you run one. But all you need is a couple of days, some stakeholders and stickers and you’re off! You get amazing results without committing to a full design or build.
They’re great – people taking part in design sprints feel involved in the design process and engaged with it too. It’s not someone else’s responsibility, but a shared one. It unites disparate parts of organisations and gives them a single source of truth to rally around.
They’re flexible – the same framework can be used to help solve a wide range of problems including digital and physical products, establish new features or the exploration of new markets. They can also be used for companies of varying sizes, from start-ups with two people at the helm to international financial institutions that employ thousands. If that wasn’t flexible enough, they can even be carried out in person or online remotely; an important factor in times such as these. Some companies have run sprints across time zones; with participants in various parts of the world.
The stages of a design sprint
The stages of design sprint can be roughly broken down into five key areas; with each one building on the discoveries of the last.
Stage One: Information Gathering
The first stage of a design sprint in ‘Information Gathering’ and compromises of the following tasks:
Ask the Experts
The facilitator takes the lead here asking each person in the group questions about the project and problems they face and are trying to solve. As the expert answers the questions posed and discussions emerge, everyone writes down How Might We notes.
How Might We…
So as the expert answers questions, others will write out details the believe pertinent in the form of a ‘How Might we’. This is a powerful phrase and its open-ended nature is intentional. It’s freeing. We don’t have to do what is stated, simply something for consideration. The notes are collated and voted on and become important a little later on.
Long Term goals
Now we need to establish what our long-term goal is. The long-term goal is based on the perfect outcome for the project and starts with ‘In Two Years’ time…’ This gives us something to keep in mind over the course of the design sprint and give us criteria to hold problems and solutions against.
With the positive long-term goal identified, we need to switch tack and raise the problems and roadblocks that will get in the way of us achieving that goal. These will also be what we try and solve over the course of the design sprint.
We now look to gain a better understanding of the user and their journey through from discovery and learning to use of the product. We establish a list of actors and goals, and then connect them via various steps.
With our map complete, we now refer back to HMW’s and use the ones that gained the most votes to help target where the causes of greatest concern lie on the user journey. This targeting then highlights to us where we should focus our energy moving forward.
Stage 1 Overview
You don’t know everything, no one does. But as a group – we are able to learn as much as possible from the various sides of the business. These sides may not regularly communicate with each other but nonetheless have a vested interest in the project, and so by coming together, we share our combined knowledge and learn what each person knows of customers and internal business operations. It’s here we see the first cracks appear in those assumptions. Questions like ‘I always thought we had to it this way?’ soon falter under scrutiny and an excitement about what suddenly is possible, flickers around the room.
It's also we start building that empathy for users. We start to understand them better. Why they behave in certain ways.
For their sprint, one client brought in a person who worked in their call centre, dealing with customers on the phones every day. They listened to all the problems one by one, quietly making notes. When it came their turn to be speak, they had one question. ‘Do you know what the no.1 call, we get to our call centre by far is?’ Suggestions were made and dismissed with a simple, ‘nope’. As the proposed answers quietened down, they revealed it to be: ‘What time’s the coach to the airport?’ It turns out this question was posed to call centre staff multiple times by customers over the course of the holiday. Some even from the arrival at the hotel.
What we see here is key information provided by someone who would potentially have been left out of a software development meeting. So, use the breadth of people around you, not just the tech experts, because ideas and insight can come from anywhere. As we’ll prove again in the next stage.
Stage Two: Sketching
The second stage is ‘Sketching’. We now take the info gathering and find possible solutions.
Firstly, we examine competitors and other software in the form of lightning demos, pulling things we like and don’t like from them. This can be as diverse as a transition on a website, button placements or gamification elements from FIFA and the Sims. Anything is open for cross-examination and consideration; we’re simply trying to build a list of features that we can potentially bring to the project.
Notes and ideas
Working independently, we start to our own notes, pulling out various bits of information we feel important to start working out our basic ideas.
At this point, our quick idea sketches probably start looking the same. Crazy 8’s break all this down. You have 1 minute to draw a new idea. We do this 8 times. By the end you should have series of notes and idea sketches to base your final idea on.
We now capture and refine all the information we’ve gathered from HMW’s to user journeys to lightning demo and filter it through the individual to become a final concept sketch. Once finished, they are put on display for all to see.
Stage Two: Overview
You’ve all heard the saying ‘a picture says a thousand words’? Well, in design sprints, we can make a bit of an adjustment. ‘A picture can hold a thousand ideas.’ And it’s this ethos which we now strive toward.
We now seek to refine the thing we’ve learned and apply them to create an idea in the form of a ‘sketch’.
Now, when you run a design sprint, you’ll soon learn that the word ‘sketch’ is the one that causes the most terror in those taking part. You can see the colour leave their cheeks, when you utter it. ‘But I can’t draw!’ they’ll cry.
But rest assured, assessing any level of drawing talent is not what this is about. It’s all about bringing ideas into the light with pen and paper. We’re looking for the big ones that can be key features and become the driving force behind the product. We’re looking for small ones that can be simply be how screens are arranged and navigated to that makes life simple. The only criteria the idea needs to have is that we believe it will be of benefit and valued by the users. After an initial reluctance, most ease themselves in by drawing round phones, drawing in the various bits of interface to frame their ideas. Some draw little storyboards, like little comic books of solutions, with little characters and speech bubbles in them. How you go about drawing them is entirely up to the individual, it just needs to be understood as clearly as possible.
One client wanted to devise a way for their workmen to report things they’d seen on site and, with great foresight on part of the client, invited one such workmen into the session. He was a bit quiet and unsure of whether he should have been there, but it was his sketch and insight that became critical to the product. ‘The phones we get given are tiny and us workmen tend to have fat, sausage fingers…’ he explained. ‘Someone mentioned Alexa earlier, so thought what if I could speak to the phone and have the app figure out what I was saying and fill in the report for me?’ His sketch, though crude, perfectly captured his insight. We could see his solution clearly in what he drew and it wasn’t a surprise to see his sketch receive a healthy amount of sticky dot votes.
So again, we see an insightful solution brought to the fore from an unlikely source. There were designers and tech experts in the room who drew prettier solutions, but it was the sketch of the workman with ‘fat, sausage fingers’ who hit upon the winning idea.
Stage Three: Storyboards
We now look to make decisions on our sketches and pull of the ideas we want to include in the storyboard.
We start with a round a silent voting, where everyone gets unlimited votes. We need to generate a heatmap of what people like about the sketches and ideas on display. The votes can be for layout, functions or the whole concept. We want to gain first impressions on the ideas.
We now discuss the ideas more thoroughly, highlighting what we all like and maybe things that were missed. The facilitator leads this discussion. Then we have to pick out the key ideas we want to take forward to the storyboard phase.
User Test Flow
This step is to help streamline the storyboard process and give us a framework to follow. Each person decides upon a start and end point for the storyboard and fills in the steps in between. We then vote on the one we feel has the best flow and taken forward to the storyboard.
The storyboard is a major step for the design sprint, and where we see the fruition off all the work we’ve done so far. All the ideas and sketches and tense time frame come to the fore as we discuss and create the storyboard. This becomes the basis of the prototype.
Stage 3 Overview
Now is where we bring the bests ideas discovered and voted for in the previous sketching stage and collate them into a storyboard. This storyboard is the culmination of our efforts so far and becomes the foundation of the prototype.
The phase tends to be the where reality starts sinking in and with it a bit of doubt. Suddenly everything that what just ideas and suggestions becomes more tangible and real. Fear starts to creep in – what if we’re wrong? Can we do it?
But this doubt and fear is the key reason why the design sprints work and why we encourage them. They minimise risk. And so, it’s at precisely times like this that we encourage clients to ask, and therefore test, the bigger and scarier ideas. That way you’ll get better and more interesting feedback in testing from users.
A good example of this is where one client was looking at ways to allow customers to take a more hands-on approach and minimise the strain on call-centres to handle routine questions. The idea that excited everybody in the sprint was the use of chatbot and felt like a good fit. But when it came time to storyboard some of these chatbot interactions, the reality of using one reared its head. ‘How do we handle something it doesn’t know? How do we integrate it with our systems?’ And while we’re not dismissing these as trivial concerns, at this point we don’t even know if a customer would be happy to use one, and it’s this question that should have greater priority.
So, when doubt creeps in, be bold and ask the bigger questions of storyboard. Prioritise the questions based on what you need to know, not what your doubts dictate.
Stage Four: Prototyping
They storyboard now finalised, we now turn our attention to converting the storyboard into something functional and testable.
Build initial prototype
At this point, our designer who 99% of the time is usually the facilitator of the sprint, goes away and creates an Invision prototype. This is usually a series of still images, trigged by interacting with hotspots that transition to a new image.
We then send this off for feedback from the client/other members in the design sprint to ensure everything is as they imagined and to make any recommendations for improvements.
Stage 4 Overview:
A good prototype is a bit of a magic trick; they need to convince users that it’s the real thing, that everything they see has function behind it. And so, prototypes have to be of as a high-fidelity as possible. Not for any point of pride, but it helps the user believe that what they are testing is a real product and this fact improves the feedback you get as a result.
That said, a prototype doesn’t have to all encompassing. Our first few prototypes were intensive, multi-screened affairs where every eventuality was catered for within. Stressful and lots of work, most of these screens were never accessed by users, because this weren’t related to what we were specifically testing. We stuck too rigidly to the high-fidelity and found that testers have always been fine understanding the scope of a prototype when explained to them.
On one frustrating occasion, the feedback for the prototype was incessant. The colours not quite right, the buttons should be rounded, can we have it do this instead? They asked if they could cancel the testing phase and have more time to work on the prototype. We advised against it – the prototype is a means to an end; the feedback from testing is the key outcome of a design sprint. But reluctantly we agreed and more time was dedicated to the prototype. As a result, the client was happy with the prototype, but they had no feedback beyond the internal team they presented it to.
The key thing to take from this is? Be wary of getting bogged down in the details, keep focused on the larger goal of getting something tangible in front of users. A pretty prototype is good (and we make very pretty prototypes indeed), but if it’s at the cost of getting that feedback and answers to those questions, you’re failing to address those assumptions and you’re failing to gain genuine insight.
Stage Five: Testing
Now it’s time to put our prototype to the testers; a tense but ultimately rewarding stage.
Testers can come from a variety of places. You can pay an external testing agency, catch people in the street or internally. Wherever you find them, ensure they are typical users of your product. So, if it’s for the general public, don’t test internally, as this allows a level of bias to creep in that might affect the feedback.
Create Test Questions
We now need some kind of framework to follow. Using the information gathered in our design sprint, we need to figure out what exactly what we want to learn from our users and set out a list of questions and tasks to help us figure this out.
Compile Feedback & Results
Once testing is complete, we need to compile it in some way so it can be shared effectively and from this, build a list of next steps and tasks to take the project forward.
Stage 5 Overview
Who has seen something like this? There’s a term for it. They’re called Desire Paths or Desire Lines. These paths or lines, are UX made manifest. And what can we learn from this? Users will always find a shortcut, or a better, quicker, simpler way of doing things that the designers may not have considered. This is no different when you come to building your products. You could have built something as beautiful and ornate as a walkway through the park, but if there’s a train station or bus stop on the other side, users will soon find the quickest way to it.
This is why testing is so important. Users will suggest things that you were possibly to close to the problem to see. ‘I’d swipe here…’ or ‘Can I not go back to that screen from here?’ These insights will give you a clearer picture of what’s important to users. And they’ll appreciate being involved in this process and may even suggest whole new features for you to consider, that had potentially been missed.
Allow yourself to be surprised by your users, and you might discover something much better than you had initially thought possible. Allow your findings to be scrutinised – learn from you users and put your prototype to the test.
In one design sprint, we did a round of testing at York train station. You might have even seen us running from platform to platform with tablets, phones and test questions in hand. The most effective tactic we found was keeping an ear out for the delayed train announcements and heading to that platform – a captive market; they couldn’t go anywhere and we knew they had time to spare!
The feedback we got was amazing and from a wide-range of people. We had students, pensioners, off-duty police and even someone who had previously worked for a competitor, all giving us feedback – for free! The novelty of playing with a tablet whilst waiting for the delayed 1046 to King’s Cross was, it seemed, payment enough.
Examples of successful design sprints
Thats enough talk about design sprints – let’s see the results.
- Unibank for Skipper
- Envision for Hillarys
- Small Claims for Minster Law
- Property Condition Report Android App for a Facilities Management Client
To summarise then – you don’t know your user as well as you think and, in all honesty, you’re never going to know everything about them. Technology is always going to change the rules of engagement. Who would have thought five years ago that we would have been using voice as a staple user interface to turn on the lights in our home, to turn the heating down or to simply tell us a joke?
But the difference now is that you have a design sprint framework to learn quickly and effectively and a way to truly embrace failure as means to make progress.
When the next amazing piece of tech comes along, don’t race to implement it solely because it’s the shiny new thing you can brag about. Users don’t care about that; they care about what it can bring to them, and how it makes their lives easier and/or better.
So, take a breath and run a design sprint. Pool the vast amount of knowledge you have and utilise the people around you to propose various solutions; pull out the best ideas and test them out. If the response is good, great – go ahead, get it built! But if it’s not, you’ve just saved yourself a lot of time, resource and stress.
Design sprints aren’t a magic bullet; they’re not going to teach you everything about your user. There’ll still be gaps. But these sprints will shrink some of them and fill-in others, to help you create a better and clearer understanding of your users, what they care about and what is important to them. As a result, they won’t want to leave you for that competitor you don’t like.
So, no - you don’t know your customer as well as you think. But that’s OK. Because next time you’ll know a bit more.