As a Service Designer, user research is core to our practice and time and time again I find myself wondering how to create an insight repo in order to share valuable pieces of information on common behaviours and motivations learned across multiple services so that they can then be shared across industries, domains and other sectors. We often look for analogous examples and metaphors to prompt inspiration and ideation, but at what point can it become more than just inspiration?
In 2018 I attended ‘UX Brighton 2018 — Advancing Research’ which as you can imagine was looking at the place of research within the UX landscape — touching on new tools and methods, and time to extend our research skills to embrace new technologies. I was inspired by Dan Pidcock’s talk on Atomic UX research.
“Knowledge has a half-life. You need to constantly re-evaluate & re-validate what you think you know”
Dan Pidcock
Based on Brad Frost Atomic Design principles: interested in what our interfaces are comprised of and how we can construct design systems in a more methodical way. Much like chemistry, where atomic units bond together to form molecules, which in turn combine into more complex organisms to ultimately create all matter in our universe. Similarly, interfaces are made up of smaller components. This means we can break entire interfaces down into fundamental building blocks and work up from there. That’s the basic gist of atomic design.
An insight is derived from a combination of data points (experiments) crafted into a matter of fact statement, which is then combined together to craft one or few insights.
Taking this approach as an example, at what level would the insight be valid to save and share across multiple industries and services?
If we look at Service Patterns, which are described as sets of practical guidelines for building a service (or bits of services) that are repeated across something like getting a licence or exchanging the ownership of something.
By identifying common patterns we will then be able to prototype new ways of delivering the same types of experience for different services, improving the user experience and streamlining the work that is required to run the service.
“By isolating processes within a service we can improve the way component parts work and create a truly consistent experience of services across government.
Lou Downe.
Much like design system components, service patterns can help us make services replicable meaning it will be cheaper to build and test, and easier to design closer to the user needs. The example above is from a Government service, that are repeated across multiple government services— something like getting a licence or exchanging the ownership of something. The same motivation is there, and the same user behaviour therefore identifying patterns and sharing them across sector makes sense.
Looking back at Brad Frost Atomic design principles, the same can be put into place for service patterns. This was identified by essex.gov.uk where they are experiment with the level of building blocks needed to create a service pattern:
As we got into the as-is mapping of services, we started to identify recurring patterns while better understanding the interactions and dependencies between them.
The more time we spent mapping services, the clearer the list got. It became very apparent that not all service patterns sit at the same level.
We learned that some patterns can represent an entire service, whereas some focus on very specific parts of services. Some start and end very quickly while others might involve a set of interactions that happens over a longer period of time.
We identified and defined three levels of service patterns:
Service Patterns — Level 1
Building Blocks — Level 2
Building Blocks — Level 3
When looking at something as simple as “applying for something” at what point do external factors change those users behaviour and motivation across services? Applying for a bank loan versus a school placement, there may be another level in the service pattern such as ‘service expectations’ that would need to be mapped, such as needing to feel trusted by the service in order for those defined service patterns to be reused across industries.
Taking this to the next level of sharing across industries and sectors I am interested to hear what others think. It left me with some more questions, as Service Patterns in theory sound great but in practice are there much more levels to the atoms we need to uncover to truly understand if this is a pattern we can be reuse.
How can we share service patterns across industries and different sectors and at what point would this break down? What type of motivation and behaviours are common enough that we can reuse from other services?
Leila Byron 