UX Collective

We believe designers are thinkers as much as they are makers. https://linktr.ee/uxc

Follow publication

Designing without a User

Kit Merker
UX Collective
Published in
4 min readApr 30, 2020

PProduct managers and designers love to talk about Users. We tell stories (epics even) and try to see everything from the User’s perspective. We create detailed personas with rich backstories. We describe their wants, needs, and desires.

But what if there is no User for your product?

No, I don’t mean that no one will buy your product (otherwise, the answer is pretty easy).

I’m talking about products where no human will use it directly. Userless products exist all around us, but we can’t see them. These invisible products are the infrastructure for other things we can see.

For example, think of payment processing gateways, APIs for image categorization, and authentication services. Who is really “using” the service? Sure, some developers and operators care about interacting with them. And there is an end-user somewhere who will interact with a product somewhere along the causal chain that leads to these services.

But are the interactions from these users enough to properly design your product?

There is another set of users, and these are other automated systems. As we see more automation and software that is interacting from “machine-to-machine” without a human in the loop, the more we have to rethink the User of these software services.

However, M2M communications differs from conventional Human-to-Human (H2H) communications due to its unique features .… These features create various challenges for existing communication networks which are primarily optimized for H2H communications. — Emphasis added. Protocol Design for Machine-to-Machine Networks

If we focus exclusively on the needs of developers and operators, we may miss crucial use cases that would lead to better design.

Photo by Franck V. on Unsplash

Anthropomorphizing Automation

The Oxford English Dictionary defines anthropomorphism as the representation of Gods, or nature, or non-human animals, as having human form, or as having human thoughts and intentions.

In this case, I am using the term to represent software or machines. In Model-Based Development, anthropomorphized components replace human tasks to aid design:

“Anthropomorphizing is useful because it enables us to systematically distribute behaviors so that they can be more easily managed. It comes down to envisioning a herd of rather dense clerks…” — Lahman, H. (2011). Model-Based Development: Applications. (n.p.): Pearson Education.

Describing the needs and intentions of software components is rather natural. I have used it in conversations with teammates or when presenting how complex infrastructure products like Kubernetes work. Anthropomorphism is easy because it’s a tendency of human psychology.¹

Non-Persona Non-Grata

A User Persona is a fictional representation of your ideal customer.² Adding consistent personas to your User Stories helps organize them around the various actors that interact with your product. Personas help teams empathize and prioritize features and make better design choices.

When automated systems are the main users of products, we don’t have personas per se. Instead, we have what I like to call Non-Personas.

A Non-Persona is a fictional representation of an anthropomorphized version of your ideal Non-Users.

How can we turn Non-Personas into Non-User Stories?

User Stories, Sans User

The typical User Story created by software product managers follows this basic template:

As a <user >, I want <something> so that <benefit>.

User stories help us shift our focus away from implementation and briefly describe the goals and benefits that a user might enjoy. Because they are implementation agnostic, User Stories allow greater freedom in how to satisfy user desires. Stories can be easily sorted and shared and help align the team.

To create Userless Stories, we will anthropomorphize the other services and insert them into the Story, like this, written for the User of a container orchestration platform:

As a Web Application, I want to scale horizontally so that I never crash when lots of people visit me.

If we are writing a Userless Story for a database, I could use the same non-persona:

As a Web Application, I want to write data idempotently so that I can retry inserts.

Combining User stories and Userless Stories can give a richer understanding of what matters in your product. Using one format for both allows you to prioritize and manage both the same way.

Complex systems with many interactions need great design, just like user-facing software. If you’re building infrastructure, you can try anthropomorphism to create Non-Personas and write Non-User Stories.

Just like Personas and User Stories, these artifacts will give you a convenient design tool that communicates clearly to everyone on the team.

[1] Hutson, Matthew (2012). The 7 Laws of Magical Thinking: How Irrational Beliefs Keep Us Happy, Healthy, and Sane. New York: Hudson Street Press. pp. 165–81.

[2] How To Define A User Persona — CareerFoundry. https://careerfoundry.com/en/blog/ux-design/how-to-define-a-user-persona/

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Written by Kit Merker

Ideas for technology product entrepreneurs

Responses (2)

Write a response

This is amazing. I'm interested in scenarios where we are trying to solve problems of non-human by involving humans. For example pet adoption for stray dogs, deforestation, forest fires, etc.

--

Well put!
This article reminded me of how we wrote user-facing scenarios for every single change, including all supposedly backend-only changes. The assumption, like you mentioned, should be that every feature is affecting the user(which might be a…

--