By Andrew Morgan
There is a miraculous mono-user, a creature of such perfection—all adequate attributes and diverse desires—that you cannot help but find some variation of literally everyone within it. If you’ve worked in product development, commercially or within the government, chances are you’ve heard some version of this conversation:
“Who is our main audience for this product?”
“The general public.”
“But, who will be using it? What demographic?”
“Anyone and everyone.”
This is the fabled general public – the singular super-user, a magical amalgam of all potential users. But this is not some benevolent being, resplendent in its inclusivity and sheer expansiveness; it is a harbinger of horrors.
If you see it, run. Flee screaming into the wilds. It brings only sorrow and scope-creep in its wake.
In the government, a common summoning spell is a simple question: “Our users are citizens, shouldn’t this be available to all taxpayers?” Yes. Yes it should. But accessible to the public does not mean designed for.
Design, by its nature, is a series of choices. Some of these choices need to be exclusive. These are made, ideally, by establishing context. We interview users, understand the contexts in which they interact with us, and make choices to ease those interactions and make them better. But these users are specific, they are the people who need or interact with the products or services we are creating on a regular basis. By saying we should design for the general public, we aren’t saying we should make it less user specific. Quite the opposite.
If we were to consider every possible user and hold all their needs to the same level of importance, the resulting product would be so incredibly complex that no one would be able to use it without training and so insanely expensive to produce, no one would be able to afford to build it. There is a cliché for this, that everything being important means nothing is. It is painfully apt, and the most important invocation against designing for the general public at large.
The easiest way I have found to get stakeholders to understand this is to have them play a little make-believe. Imagine hosting a dinner party. Six guests will be attending: Our significant other, our parents, our co-worker and their plus one, and our best friend. We have to feed these people, but have limited time and budget to make a meal.
It’s likely we are going to prioritize the meal around the people who matter most to us. In this this example, our significant other and our parents. But what if the co-worker is your boss and you are vying for a promotion? What if their plus one has a deathly food allergy? What if your best friend has recently decided to start a new diet?
Dinner then gets a little more complicated. And that is with a defined user base.
When designing for the general public it means everyone is involved and their tastes equally important. So, in this scenario (in addition to our six original guests) we may have our neighbor unexpectedly pop in and they really love sauerkraut, a classmate from 4th grade might drop by and they only eat peanut butter sandwiches, or a friend on Facebook in a “fitspiration” group who enjoys protein shakes. All of which we need to accommodate. And those are just the people we know. Which means our dinner party is now either completely custom meals for everyone (not feasible) or cabbage peanut butter protein shakes.
How do we deal with this? Simply, by not allowing all those users to be melded together. We know our neighbor won’t be stopping by. And our Facebook friend lives in another state, they won’t be coming either. So, we focus on the original guest list, we talk to them, and we rank their needs based on who is important to us. This can be uncomfortable, sure. But it is also vital to a successful experience.
Let’s break it down:
- We’ll say our significant other is our main user, because we don’t want to end up in the dog house. We won’t be making food they hate or are allergic to. We also know them really well so they are easy to accommodate.
- Our parents will likely enjoy whatever is made so long as it is edible. But we still want to impress them. Again, easy to accommodate.
- Our boss and their plus one is more of a challenge. We want to make them happy, so we are going to find out their likes and dislikes and make sure we include them. We won’t go out of our way to make something extravagant until we get that promotion. We make sure the dinner includes their needs and fits our budget. It took a bit of effort, but good.
- Our best friend is our best friend through thick and thin. They can eat what we make. Done.
By defining who is most important to us, and building a dinner around their needs, we have created a product within our budget and timeframe that will outright please those most important to us, and satisfy the rest.
This is the best possible outcome. The best products and user experiences are made perfectly for one or two groups, satisfy the majority of others, and merely leave it accessible to anyone not on the list. It seems counter-intuitive at first, but widening your target doesn’t improve your aim. It works for dinner parties and it works for products. But the only way to make that happen is to not make a custom meal for everyone.
There are a handful of UX deliverables around this, like personas, journey maps, and a bunch of other buzz-wordy things UX practitioners absolutely love making. They’re tools to avoid designing for the general public. You don’t need them, but they definitely help. They align stakeholders and developers, bridge business understanding and interaction design, and create a set of parameters. Protect your projects. Build better experiences. And let the myth of the fabled “general public” user group fade into the dark ages of product design history.
Andrew’s job title shifts based on the time of day and relative position of the moon to Aquarius. He currently works to make internal and external products more user friendly, and foster a “user first” culture.