Why user research matters in service design

As a user experience enthusiast, I believe wholeheartedly that, for a design to work, we need to always “start with user needs, and keep them involved”. Considering this is CAST’s very first digital design principle, it’s reassuring to know that I’m not the only one to think this!

But why are user needs — and the user research used to identify those needs — so important? Below, I give my thoughts on this, while sharing some examples of what we’ve learned at Action for Children, to really illustrate the importance of user research in service design.

User needs — why should we care?

1. If a service isn’t useful, then it’s hard to know why a user will engage with it. What need is the service meeting; what problem is it trying to solve?
2. Sometimes we — the people designing and delivering services — will think we know who and what a service is for. But without being service users ourselves, do we ever really know? Also, how can we know how it feels to use that service? How can we identify what’s working well and what isn’t? What are the extra benefits that a service creates for someone; what additional needs are being met? If we can’t answer these questions, then let’s ask the people who can. By directly engaging with service users, we can get a much better understanding of their situation, what’s important to them, and what problems they’re trying to solve by using our service.
3. If we don’t test what we think we know about our users, we run the risk of making decisions based on untested hypotheses — and if our hypotheses end up being wrong, we can waste valuable time, money and energy on designing services that won’t actually work.

Which hypotheses have we challenged with user research at Action for Children, leading us to design better services?

We recently explored the mental health needs of children aged 10–13, to see if a digital tool could help them. One reason for this age group was because we thought that children aged 10–13 would share similar life pressures — as a group typically lumped together as ‘pre-teens’.

However, when conducting user research, we found that the pressures of a 10 year old are very different from that of a 12 or 13 year old. While 10 year olds are often worried about transitioning from primary to secondary school — often the first major change in their life, and as such the first major test of their resilience — 12 and 13 year olds were worrying about the more typically ‘teenage’ issues of exams and relationships.

Lesson learned #1: even narrow demographic groupings can still be too broad when looking to pinpoint user needs. This is especially important when designing for children — a lot can change in 3 or 4 years!

—

To counter the closure of children’s centres, and the face-to-face advice that support workers give to parents, we started to explore digital alternatives. Since parents told us that the personal, trusted relationship they had built with support workers was the reason they then disclosed hidden needs — often much thornier, serious issues than initially presented — we thought that any digital solution in place of a children’s centre would need to replicate this personal, trusted relationship, if the same hidden needs would be disclosed to virtual support workers. Therefore, in our first prototype, we designed a feature that meant parents could always speak to the same support worker when they came online for advice.

However, in our pilot of this digital support service, we found that parents behaved very differently online, and did not need a personal, trusted relationship with a support worker to ask for help on serious matters. It seemed to be the organisation that was trusted, not the individual. Also, the perceived anonymity and reduced stigmatisation of getting help online meant that users were behaving in a way we couldn’t anticipate from their use of physical spaces.

Lesson learned #2: even user needs gathered directly from users should be probed further, to ensure that these needs have been interpreted correctly.

Lesson learned #3: user needs and behaviour may change if the channel of interaction changes.

—

Teenagers in foster care didn’t feel that they were getting much information about the foster family and home they’d be moving into, before they arrived. This made an already traumatic and confusing time even more unsettling. We started designing possible solutions for this problem, such as an interactive tool for the young person and foster carer to virtually ‘meet’ before a placement started, so they could learn more about each other. We thought this digital solution would work for young people since, it’s 2019, surely all teenagers have phones and internet access right?!

Wrong. Many teenagers in foster care lack access to digital devices, or have limited access for their own safety. Additionally, young people in care often lack the time to prepare an in-depth profile of who they are for their new foster family — they may be told they’re moving house with only an hour or two to pack and leave. So, we focused instead on creating a solution that is much less resource-intensive for the young person. The Big Welcome allows foster carers to create profiles of themselves and their home, which a social worker can give a young person (not just teenagers) access to — even in emergency situations e.g. by letting them use their device in the car on the way to their new home. This solution gives young people more information and reassurance on their new home, without excluding those who lack the time or access to something more interactive.

Lesson learned #4: accessibility is critical to consider, even at the earliest stages of ideation.

—

Without user research, the above hypotheses may not have been challenged — or at least, not challenged early enough. We could have spent money and time designing the wrong thing for the wrong user group, which in the end they may not have needed, wanted, or been able to use. Therefore, to avoid this, it makes sense to start with user needs, and keep those users involved throughout the design process.