Designing without a User
How to write non-user stories for non-personas.
Product 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.
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/
