Your service isn't for everyone, so don't design it for EVERYONE

The biggest design mistake that many companies make is to tell themselves that their product or service is for everyone.

One of the most frequent, and often one of the longest, conversations I have with clients is in trying to convince them that they can't design their product for everyone.

When I meet a new client, one of the first questions I ask is, “who is this product/service for?”

“Everyone,” is the most frequent answer.

Designing for everyone makes sense on paper – few companies want to create services with limited appeal. But it’s next to impossible to create something that pleases all customers, all the time; and it’s even harder to do this with a service that’s trying to accommodate dozens of competing requirements.

“Don’t design for everyone. It’s impossible. All you end up doing is designing something that makes everyone unhappy.” – Leisa Reichelt – Head of Service Design, Australian Government’s Digital Transformation Office

Everyone, and no one

When designing for everyone, the definition of ‘everyone’ becomes a problem. Often this definition reverts to the idea of designing for the ‘average customer’, but this rarely makes things easier.

When designing for the average, you create average results at best. And trust me, I know from bitter experience. In my early days I would attempt to design services that met the many different and differing needs of companies' broad target markets.

When designing for the average, you create average results at best.

Here's the problem, there is no such thing as an average customer. At best the ‘average customer’ is a straw man created from a caricature of an ideal customer, but quite often it’s simply a reflection of the primary stakeholder.

These mental sketches of the ‘average customer’ are never fixed, they change to meet business requirements, they change from person-to-person, and I’ve even seen them change dramatically following a shift in management.

With no fixed concept of who the actual customer actually is, those working on the project are often left searching for answers to an unanswerable question – ‘what if?’; ‘What if the user does this?’ ‘What if the user wants that?’ With so many open questions each ‘what if’ is added to a growing list of project requirements.

Without knowing who the actual customer is it becomes very difficult to identify the difference between what the customer needs, what they would like, and what the business would like the customer to need.

Up close and personal

Understandably for many clients, if we recommend not designing for everyone, the question becomes ‘who are we designing for?’ (‘and are they a large enough market?’). To answer these questions we work with the client to create small number of personas. These are agreed-upon descriptions of different types of customers.

What makes personas different from ‘average customers’ is that they’re based on data – such as user interviews, stakeholder interviews, analytics, and observations. Working with the client, we look for patterns in the data. With these patterns we create detailed descriptions of specific users, and we design for them.

For example, say we’re working for a hospital; in theory everyone at some point is a ‘customer’.

In this context you might find that you can place ‘everyone’ into various groups, and divide these groups into many sub-groups,

• doctors (including student doctors)
• patients (emergency, long-term, and short term, elderly, young)
• expectant mothers
• midwives
• neonatal staff
• surgeons
• consultants
• nurses (including student nurses)
• administration staffs
• cleaning staff
• service providers (catering, sanitation, etc.)
• visitors
• etc.

That’s a lot of potential design-confusion right there. But we could (by analysing the data) further reduce this number to a more manageable four groups, and prioritise these,

1. Medical Staff (doctors, nurses, consultants, surgeons)
2. Emergency Patients and Staff (A&E patients, expectant mothers, neonatal staff, midwives)
3. Long & Short Term Patients
4. Visitors

We’ve placed doctors, student doctors, nurses, and many others into one group. While their roles, and positions may be different they share many similar needs. We’ve also separated emergency room staff and placed these with A&E patients; again these two types of users share so many similar needs that we can view them as one at this point. When a doctor is not working in A&E, or an A&E patient is recovering they then fall into the Medical Staff and Long/Short Term Patient personas respectively.

We’ve removed service providers, cleaning staff and admin staff. We removed these, not because they’re unimportant, but because their needs are met by the needs of the other groups. We call these served personas.

If we look at this grouping you’ll see that the four personas represent what could be described as reasonable extremes. These are people who use the service intensely (either a lot in a short amount of time, and/or a lot over a long period).

From this list of groups we then create personas - detailed descriptions of four individuals who represent the needs, behaviours, and expectations, of each individual grouping. After we create these personas every design decision, every option, and every suggestion is assessed against how it would help one or more of these personas.

None of these are easy decisions, but they are absolutely necessary. If design is simply the creation of solutions to existing problems, then we must first identify the most significant problems, and the people who suffer those problems. From there we can build solutions that alleviate them, and often this means placing some smaller problems (which are usually more visible) on the backburner until more pressing (and often less visible) ones have been solved.

CapEx vs OpEx

By prioritising and fixing more pressing issues first, and doing so with more focus, we can help clients and their customers reap the largest benefits from their investment. Those smaller problems aren’t ignored, they simply wait until the more pressing issues have been resolved.

Quite often clients see such design projects as a once off capital expense, where a sum is spent on a once-off basis to fix known or perceived issues. However, we recommend that clients invest a small amount as an operation expense to identify and fix small issues before they grow to become large ones.

Little and often can do more to help clients create innovative solutions than once-off large investments.