In the lexicon of business jargon there are few more cringeworthy clichés than “What does success look like?”. When someone says that in a meeting it’s usually a good time to start a round of buzzword bingo(this will open in a new window).
However, when focusing on the usability and user experience of a new product or service, defining what success looks is actually a very worthwhile activity that is not done often enough on IT and development projects.
Too often the ‘what success looks like’ from the perspective of the user is poorly defined – if its ever defined at all. Assumptions rather than empirical evidence rule the day and the answer to that question simply becomes:
- what the lead developer or designer decides is good enough based on their opinion
- however good it happened to be at the end of the development time (We just need to get this thing launched!)
- whatever the business thinks is good enough for what the business wants it to do (Great – it captures the info we need – lets just go with that)
When you want to rigorously define success from the users’ perspective you enter the realm of user requirements, an important stage in the user-centred lifecycle which can be represented as:
The user-centred design process
Near the start of any project its worth performing user research. This involves learning about the users through surveys, observation, interviews and other techniques ideally carried out in the actual context of use. The next step is to analyse what you’ve gathered to determine what the user needs to perform their task better. What’s going to make or break their ability to do their task with confidence and control? Creating personas, customer journey maps, storyboards and similar can help in thinking this through.
Knowing that, you can start to consider the attributes of the solution that are required to meet those user needs. These are the user requirements that sit alongside other requirements originating from the business, (business rules, marketing policy, data protection etc) as well as regulatory requirements.
Collectively these serve as both constraints and goals during the design process and can be the basis for innovations from the user’s perspective. They should be borne in mind while designing the solution and during evaluation where you carefully compare a prototype product against the requirements established earlier.
If it fails to meet the requirements, then you should iterate to improve the design. This is readily accepted for technical requirements, for example whether the solution reliably and accurately handles data. However, it is less often applied for human aspects of the system – the ‘what does success look like’ for usability and user experience – because no tough decisions have been made upstream to determine the success criteria for UX.
Not having these user requirements to consider during design and evaluation can lead to what I call ‘slopey-shoulder design’ processes. Because there never was any agreement on what is actually good enough in terms of usability, accessibility or user experience, then what you have may be good enough. Or maybe not. You don’t really know because there was no vision of what UX success looks like.
Sometimes late in projects the decision on what is good enough for UX is made up on the spot, with no reference to what the users actually need, again because little effort has gone into discovering this or applying it to the design.
‘But we use Agile design’ is a common defence for not doing even minimal research and evolving the findings into requirements. Yes, performing this in an agile context can be more challenging, there’s a tight schedule to meet and tough resource and time decisions to make. But with so many rapid and remote user research methods and tools available, you should be able to learn relevant things about your users and their context of use, then create research-based criteria to help judge what success looks like from the user’s view. Where there’s a will there’s a way, and what’s often missing is the curiosity and desire to perform user research rather than the means to do it.
Training on user needs, user requirements and putting them into practice
If you’d like to know more about this whole topic of user requirements and user-centred design you are very welcome to attend the advanced 3-day training course User Requirements Engineering: Applying user needs & requirements to user-centred design. Presented by Thomas Geis, a recognised leader in the field and President of the UX Qualification Board, the course will give you a solid understanding and practical application of discovering user needs based on research and turning these into user requirements that you can apply to answer the important question, from a UX perspective, of ‘what does success look like?’ .
Course details : User Requirements Engineering: Applying user needs & requirements to user-centred design (CPUX-UR)
Date: March 19-21 with an optional exam on March 22nd to qualify for the CPUX-UR certification.
Location: Edinburgh, UK
Further details and booking: Please visit our training course page or call 0131 225 0851
You might also be interested in...
Creating Valuable Personas27 January 2021
Personas are a powerful way of communicating user needs to design teams. In this article, Mark Haley describes some best practice for making them useful, usable and engaging.Read the article: Creating Valuable Personas
What are UX errors of omission and commission?26 January 2021
Explore how these often small and subtle errors can create big blindspots for your users.Read the article: What are UX errors of omission and commission?
The User Experience of Voting28 October 2020
As the US election day nears we look at some of the usability challenges in voting.Read the article: The User Experience of Voting