How do you reduce design time by 75%, development time by a further 33% and get products to market twice as fast you normally might?
By putting users first, according to research from IBM.
Lean-Agile thinking (if you haven’t already seen from our discussion of Lean-Agile principles and what we mean by quality) is keen on cutting waste. The focus is on deploying practices and techniques that enable teams to work effectively, even if it appears inefficient. By placing effectiveness over efficiency, projects and products have a real impact in the long-term.
User-Centred Design (UCD) in its various forms and guises isn’t exclusive to Lean-Agile, but the practices it offers such as User Experience (UX) and research methods, perfectly complement it. By making you put assumptions away, User-Centred Design provides tools which help you make the right thing, regardless of the type of software or device involved.
In this post, we’ll take you through how a user-first approach to software and product development can benefit your organisation by helping you to move away from assumptions. Plus, we’ll look at when the best time to become user-centred is, and we’ll explain how your team can research users and which data is most valuable for them to be thinking about.
Why should you care about users?
Users are people who have a challenge that your product is attempting to help with. They are the people who will hopefully pay money to use your product. So, they are customers, as well as users.
If a product helps them solve their problems, they’re much more likely to want to buy it, to try it and to use it, and then talk to other people about using your product, and to continue to buy from you.
By designing and building the best thing with the right features to solve your users’ problems, you make a difference to your bottom line in terms of sales. But you also make a difference to the bottom line in terms of operational costs by designing and building the right thing: rather than spending time and money designing and building something users don’t want.
Putting users first helps you to design and build the best product for both the market and the users.
The not-so-Lean-Agile approach to users a.k.a. making assumptions a.k.a. not talking to anyone
Sam is determined to do right by users on their team’s latest project. “Box Thing 2” is going to be 100% better than “Box Thing 1”. Last time they didn’t get users involved early enough but this time, Sam’s got a plan.
The plan? Talk to users at the beginning of the project, then draw up requirements and features for the software. Then make some prototypes and launch an MVP. Iterate every two to four weeks so they can test stuff and find out from users if the team is on the right track.
Sam’s been reading a few blog posts and books around Lean-Agile and UX, and they’re pretty sure that their pitch for the processes for Box Thing 2 is going to wow their bosses. Sam can’t remember the last time they felt this excited about a project.
One day, slide deck in hand, Sam heads into a meeting with their superiors. Sam talks everyone through how they see this project going, the long-term savings they can get from leaving assumptions behind, along with working in a Lean-Agile way that uses real user feedback. How, if this goes well, they could develop processes for other teams and products.
Sam talks for an hour. They answer questions for 15 minutes. Then Sam leaves while their superiors start a discussion about this new way of working.
Two weeks later, Sam hears back about their proposal for Box Thing 2. The answer is “let’s just do things like we always do”: in other words, big design upfront, with no chances to learn and improve.
Yet again, no users are involved until it’s too late to turn back, and Sam’s pretty sure they’ve got a Box Thing 1 on their hands again.
Users first, features second
A typical design up-front approach will agree on features and requirements early, frequently assuming what users want. Researched or not, users won’t interact with these features until the product is near complete and is entering testing. At that point it’s too late to make any changes if users find the product is unusable.
Why’s it too late? Usually, it will be prohibitive in terms of time and cost to make things better.
And having the wrong features is costly. For instance, Pendo showed in a 2019 report that in the average cloud software product, 80% of features are rarely or never used. They estimated that these unused features represented $29.5 billion in Research and Development investment by publicly traded cloud companies.
It’s never too late to think about users and their needs
When can you start thinking about users? Anytime. It’s easy to say this, but you genuinely can make your product, your service, your offering better by starting the process of thinking about users. Thinking about users and designing for them, researching and learning about them at any point is better than not doing it.
Look at what happened with Eric Ries and the platform IMVU. Ries in The Lean Startup mourns the six months the team behind IMVU spent not listening to users while they were building their product based on a strategic plan based on assumptions. The success of the IMVU team started:
“[Not] with our brilliant assumptions and strategies and whiteboard gamesmanship but with the hard work of discovering what customers really wanted and adjusting our product and strategy to meet those desires.”1
The information you can gain from researching and learning about your future customers is invaluable. Sure, it’s far better to do this from the start of a product lifecycle but doing it at any time can benefit users and your product.
… And usability tests can be done at any stage to investigate UX
Even after release, your team can do usability testing for a product. This is testing your product or service with real people who will be using it, giving them specific tasks to do. Observe them following those tasks, observe them using your thing, how they interact with your offering and learn from that. You can learn an awful lot about your product when you do this.
If you’ve got an existing product and up to now you’ve never even given a moment’s thought to your users, or you’ve never considered the UX or you’ve never gone out and talked to users—you can still do usability testing. You’ll find out what’s right in terms of what your users like and value, what’s causing them trouble, what’s problematic for them and so on.
If you’ve got an existing product, you’ve probably got numerous examples of fully representative users, which is excellent: that means you’ve got some people that you can go and have conversations with.
Proof of Concept, Prototype, Minimum Viable Product, Minimum Marketable Product
Anytime is a good time to look into UX. If you’re considering a new product or service, maybe you’re talking to investors, or it might be a side project you’re running to see how it goes; even at this early stage it’s a great time to be involving users because you can learn loads before you start designing, coming up with features or coding. Between developing Proof of Concept, Prototype, Minimum Viable Product, Minimum Marketable Product there are points where you can, and should, conduct usability tests.
Or maybe you’re at the Minimum Viable Product stage or have a hypothesis that could benefit from some hands-on hypothesis testing: go to users.
Researching users? Don’t start committing “The Seven Deadly Sins of UX Research”
We’re hoping that at this point you’re interested in getting some real data from users to ensure you design and develop the right product. That you want to make sure your software is what users need.
But before you head off and do that, just take a moment to think about the quality of your research. David Travis and Philip Hodgson have some advice on seven UX research sins you should avoid, to help ensure the quality of your research:
- Credulity is where you believe something without “proper proof”. Don’t go asking users what they want and then accepting their answer at face value.
- Dogmatism is when you believe there is “one ‘right’ way to do research”. There isn’t.
- Bias can happen all too easily. Angling things in such a way that you get the answers you want, or you skew research, so the results line up with expectations and don’t undermine a project. Research should be about finding out the “truth”.
- Obscurantism is not making research results available to everyone on the team. It’s no good having results in one person’s head; the whole development team needs to be involved; sharing information and “observing users”.
- Laziness, this happens when you reuse old research data. The team sticks by personas like they’re the final word in knowing the user. Instead, research needs to be ongoing, making “UX research part of the culture” happening alongside each iteration.
- Vagueness is what happens without focus. Conducting research and trying to answer too many questions at the same time? That can cause vagueness. It also tends to occur with teams who don’t conduct user research often enough. So, you “[…] end up learning a little about a lot.”
- Hubris is when you put data before insights. You’re proud of all the research that’s been done, but failed to turn it into usable, meaningful insights for teams.2
And while we’re talking about things you do not want to do, how you ask questions is also super important. More on that later.
Remember: we’re trying to find out about users and what they need so we design and develop around those needs.
What are user needs?
User needs is a practical term, but it can be unhelpful because people don’t realise it’s shorthand for something much bigger. It masks what we mean, so we end up with a situation where people end up writing user stories around what a user needs without providing the full context of what’s involved.
You end up with user stories that go like:
As a user, I need to do X, so that I can do Y thing.
So we end up with this typical user story structure, and people think that’s what a user need is. People believe a user need is the particular “thing” which goes in a user story.
But user needs are much deeper than that. User needs are things which give a broad and in-depth picture of the user. User needs become clear by finding out:
|User need||What you’re looking for||What this means|
|Context||Their environment is where your product is likely to be used, such as their place of work. It should include what tech is available. And, if relevant, a note on operating conditions they are in—is it an industrial environment or harsh environment—you need to know. It also means finding out if anything is putting constraints on the user: the process they follow, the equipment or tech they use (basically, what they actually do).|
|Motivations||This could be simple things like money or prestige that leads to a job promotion.|
|Goals||The specific things they’re trying to achieve that build up towards meeting their motivations. Like, an accountant producing quarterly update reports. Or like astronauts aiming to do a spacewalk.|
|Journeys||A series of steps making up the broader scenario around a user’s interaction with your product or service.|
|Tasks||These tasks are what needs to happen to achieve goals. But specifically, steps on a user journey, particularly those that involve interaction with your product/service.|
|Different people approach journeys and tasks in different ways. They work in different ways.|
|Emotions||People will have emotional states as they journey towards their goals. Are they anxious or calm? Happy or sad?|
|Mental models||People tend to have a whole set of internalised mental models of things they hold to be true. You need to understand these so that you don’t end up fighting against them.|
|Capabilities||These can vary from situation to situation. Where users might be capable in one case, they may be less proficient in another, and so on.|
|Pain points||These are the things that make it difficult for them to complete their journeys and tasks to work towards their goals. You may learn things your product can help with, and things that it cannot.|
So how do you and your team gain access to information like this?
Ask the right questions
During interviews, you need to ask the right questions. Bad questions get you meaningless, (potentially biased) information and/or ego-boosting (to you) answers.
In The Mom Test, Rob Fitzpatrick looks at the difference between good and bad questions. A lousy question often looks at what should be built, how it should work and be designed. The problem is: people don’t know what they want and (most of the time) they’re not designers. Remember:
Your users own the problem, and you own the solution.3
Good questions look to uncover all those earlier user needs from the table we talked about:
- Mental models
- Pain points
Good questions also don’t zoom in on specific details too quickly. Good questions allow users time to think and reach their own ideas.
Other methods can help you gain further information on these user needs too. Research can also involve observing users in their environment. It can also be seeing the journeys they make and the tasks they do, and so on.
Gather data, give insights
Your team can use numerous techniques to gather data on users and their needs and then present it. We’ve looked at some of these before when we’ve discussed why UX is cool.
But once you have all this data, your team (and stakeholders) need it presented in useful, meaningful insights they can work from. It might be tempting to have pages and pages of research reports, but it’s unlikely your team is going to read them. Even if they do, they may then struggle to pick out useful information.
There are things like personas, empathy maps and journey maps which can present insights from gathered data. Whatever method your team uses, the key thing to remember is that insights need to be:
- To the point
- Easy to understand
- Constantly visible
With something like personas, there’s a lot that can be done to make them stick around in your team’s thoughts. A persona can be visual, with a photo of one person who represents a user group, and they can have a name. Avoid the temptation to include demographic data (such as age, gender, location) and instead focus on including insights around user needs. And make sure they’re no more than one side of paper, stuck up on a wall so that the team can easily see them.
Involving whole teams and rotating research roles also enables team members to get a shared understanding of users and user needs which keeps the time burden on individuals down. It helps to amplify learning and enable emergent knowledge to inform development decisions—both important when being Lean-Agile.
Make assumptions and then dump them
You can make assumptions, but you shouldn’t hold onto them. They’re a good starting point, a way to form a hypothesis, but that’s all.
A proto-persona or the first draft of an empathy map can get you started, but as soon as possible, you need real data, from real users, real customers.
Real data means you have the insight which enables you to make the right thing, with the right features. When you make the right thing, you can follow Lean-Agile’s fundamental principle to cut waste overall, maintain quality and ensure your product has a future.
Be effective so that your product makes a real impact
If you’d like to work with a team of Lean-Agile embedded software engineers and test engineers on your next device, get in touch today.
1 Eric Ries, The Lean Startup: How Constant Innovation Creates Radically Successful Businesses (England: Portfolio Penguin, 2011), p. 50.
2 David Travis & Philip Hodgson, Think Like a UX Researcher: How to Observe Users, Influence Design, and Shape Business Strategy (Florida: CRC Press, 2019), pp. 2-8.
3 Rob Fitzpatrick, The Mom Test: How to talk to customers and learn if your business is a good idea when everyone is lying to you, 1.06 edn (Wroclaw: Founder Centric, 2014), p. 26.
Want to read more about how Lean-Agile software development cuts waste and improves quality?
Then check out our series on Lean-Agile that looks at how you can bring it to your team and organisation.