Are non-functional user needs a thing?
I was recently out walking, thinking about user needs (I know, I’m cool) and I was getting a bit stuck on something. I find user needs statements to be a useful tool. They help us get to the root of a problem so we can solve the right thing for users. And they’re frequently articulated in a way that makes sense to me:
As a carer
I need to get financial help
So that I can carry on looking after the person I care for
- This is the standard format GDS proposes for a user needs statement
Where I get stuck is that I have often come across user needs which are expressed more like this:
As a busy frontline worker, I need to do X quickly, so that I can get back to seeing patients.
Or
As an applicant without access to the internet, I need to be able to access information offline, so I don’t miss an important update.
These needs are valid, and articulated in a way that aligns with best practice (more on this below). But semantically, they feel different.
Whereas the first example explains WHAT a user needs, the second two are more about HOW they need it. This distinction felt akin to the split between functional and non-functional requirements (NFRs) in software development. So bear with me while I test this out. Firstly, some definitions.
What are user needs?
As someone who works in public sector service design, user needs are my bread and butter. They make up both the first point of the Government Service Standard:
Understand users and their needs. Develop a deep understanding of users and the problem you’re trying to solve for them.
and the first of the 10 Government Design Principles:
Start with user needs: Service design starts with identifying user needs. If you don’t know what the user needs are, you won’t build the right thing.
User needs are key to helping us understand the problem we’re trying to solve, and the wider context of our users’ lives. They help us design and build services which are actually effective. As Kate Tarling and Ben Holliday say:
“What people need to do at a fundamental level is less likely to change than organisation design, technology, policy or process. It’s more future proof.”
As a tool, they can be misused and conflated with user stories, which can lead to solutions being shoehorned too early into the process. Will Myddelton has written about the dangers of teams misappropriating user needs, and using them as a shorthand for research. Doing this diminishes the complexity and nuance of research, and could lead to worse outcomes. That said, they can be a useful tool, if treated with care.
I use Leisa Reichelt’s questions as a heuristic to make sure user needs are adding value and aren’t just being used to sneak in the biases or preferred solutions of the team and stakeholders:
- If you show this need to a real end user would they recognise it as their own need?
- Does it help you to organise or prioritise the work for your project?
- Does the need describe the problem and not the solution?
- Will the need stay the same regardless of changes to technology, policy or how an existing service works? Litmus test for user needs by @leisa
Coming back to the issue I was having at the start of the blog — it feels like user needs can be a bit blunt as a tool? Kate Tarling and Ben Holliday split them down a bit further into:
Functional need: The practical things people need to do
Emotional need: Feeling stressed or anxious, needing peace of mind or to feel confident about something
This is getting closer to addressing my issue with the semantic differences between the examples above. It’s really important to call out emotional needs. Service teams (particularly tech-driven ones) can often focus too heavily on functional needs.
Emotional need doesn’t quite cover the breadth of what I’m talking about though. If someone is completing tasks solely from a small mobile phone screen because their home internet access has been cut off, this is less of an emotional need and more of a practical one. (Albeit it with the potential for emotional impacts). But it’s also not functional, as it has nothing to do with the service. It would still be a need even if they did not interact with our service.
Functional and non-functional requirements
Functional and non-functional requirements derive from a different world to user-centred design. Whilst I come into contact with them when working on digital services, it is very much not in my wheelhouse so I will defer to the internet for definitions:
In software development, functional requirements determine the functions an entire application or just one of its components should perform. A function consists of three steps: data input — system behavior — data output
On the other hand, non-functional requirements (NFRs)…
determine the performance standards and quality attributes of software… For example, a web application must handle more than 15 million users without any decline in its performance
You may have come across the term ‘ilities’ which is often used to describe the attributes commonly found in NFRs: scalability, maintainability, operability, availability, recoverability, performance, volume, resilience (some of them don’t have an -ility suffix which is disappointing, right?)
Knowing the difference between functionals and non-functionals can help define the scope of a project. If resources are limited — as they often are in public sector projects — the team and stakeholders might decide to forego some NFRs for an MVP release:
If an app doesn’t meet non-functional requirements, it continues to perform its basic functions, however, it won’t be able to provide a great user experience. — Functional vs Non-Functional Requirements: The Definitive Guide
This can also be true when having to prioritise user needs. When scope is limited, we may have to decide to focus on core user needs which help the user get the task done, even if that means not providing the flexibility they need to do it easily in their context.
Non-functional… user needs?
I’m toying with the idea of taking the framework of functional and non-functional requirements, and applying it to user needs to see if this helps resolve the semantic difference that was tripping me up.
Whereas a functional user need describes what users need…
As a carer, I need to get financial help, so that I can carry on looking after the person I care for
…a non-functional user need (N-FUN) would describe how they need to interact based on their context:
As a busy frontline worker, I need to do X quickly, so that I can get back to seeing patients.
Functional needs are service-specific. Non-functional needs are transferable across services because they are based on user context, not the task to be completed. Like with non-functional requirements, this might naturally cohere into a standard set of attributes (like the ‘ilities’). If so, these could be considered in every service context and just dialled up or down as appropriate. Things like:
- Time to complete: needing to complete the service quickly, as users in this context are particularly pressed for time
- Responsive format: needing to provide access to the service in multiple formats because of a higher proportion of non-digital users, or users accessing the service on mobile devices
- Quick response: needing to know the status of the next step in the user journey, to ease anxiety occasioned by uncertainty
Considering NFUNs using a few examples
Disclaimer: It goes without saying that the examples below are very much based on assumptions, and used for illustrative purposes. In reality, any N-FUNs should only be considered based on research with your actual users in their actual contexts.
Example one: digital service for doctors to record patient data
In this setting, time to complete becomes an incredibly important NFUN. The users (doctors) are very busy and need to spend the majority of time on their core task: direct patient care. Recording data is something they have to do really frequently, so they need to minimise time on task as much as possible. On the other hand, responsive format is a less important consideration because they are using standard issue desktop computers with the software already installed, and a stable internet connection.
Example two: applying for a passport
For this service, users are coming from a wide range of backgrounds, levels of digital literacy and levels of access to digital technology. This means that a flexible and responsive format is absolutely key for people to meet their goal. The service needs to be accessible by mobile devices, older browsers, and completely offline (in this case via a form from the Post Office). When it comes to time to complete though, being super quick to complete the task isn’t as fundamental as it was in Example one. Passports only need to be renewed every 10 years, so users access this service irregularly. If you’ve got to prioritise, making the service accessible in a range of formats is more important than optimising the journey to make quicker to complete.
Example 3: testing for COVID-19
I worked in COVID-19 testing for several years. In this context, all of the NFUNs I’ve called out above were important, because we were dealing with a very diverse range of users. There was a great deal of anxiety among users around contracting the virus, and it was clear that timely information was a priority need. Quick response in this context meant letting users know when they could expect their test result, and updating them on the outcome of the test as quickly as possible (typically within 2–3 days). There was an urgent need to prioritise response time because users need to know what next steps to take if they got a positive result, for example getting care for their symptoms, or self-isolating. Contrast this to Buying a rod fishing licence. I can probably stand to wait a week or two to find out about what’s happening next there.
How could this be used in practice?
To inform prioritisation
Of course, if you have time and budget, you would want to ensure you are meeting all needs — functional, emotional, non-functional.
In reality though, you’re going to have to make priority calls at some point. Separating out the ‘what’ from the ‘how’ might help inform those conversations around priorities.
Building up a standard set of non-functional user needs for consideration on new services
Like with NFRs, N-FUNs are transferable across services. Users in a particular context (e.g. doctors in a hectic A&E department) are likely to have some common needs, regardless of which service they’re using. Recognising where something is a non-functional user need could help everyone in public sector service design pool common needs about our users so they can be considered in other services.
“I need to provide proof of my identity and visa permissions so that I can travel abroad” is not going to be very useful to someone building a service to help users adopt a child. But “I need clear and concise information so that I do not make a mistake and have to re-do something” could be.
Where a service design pattern specifically addresses a non-functional user need, insights could be shared so service teams aren’t starting from zero.
What do you think?
This is a partially formed idea, I don’t know if there’s traction in it. And yes, maybe I only wrote this blog post so I could share the acronym N-FUN. Even so, I’d love to hear your thoughts and whether you find this to be a useful framing or not. What other non-functional user needs have you come across in your work?
I would love to hear from you. Find me on LinkedIn.
