Most Teams Make Personas. Few Build Worlds.
7 min read
Most Teams Make Personas. Few Build Worlds.
The problem: Too many design teams treat personas, journey maps, or information architecture as one-off deliverables. Leaders see them as busywork—documents that get made, filed away, and forgotten.
The solution: Reframe these tools as part of a bigger discipline: worldbuilding. Just as writers build a fictional world so their characters’ actions make sense, UX teams must build a modeled world so product decisions have context.
Key takeaways:
- UX tools like personas and journey maps are not just outputs; they’re pieces of a living model of how users actually behave.
- The most useful personas focus on a person’s beliefs, behaviors, and motivations, not just their job title.
- A mature understanding of the user’s world reduces costly rework by letting teams “test” ideas against a simulated environment before launch.
- Good design is an ongoing, collaborative act of storytelling, not a one-time project.
- Organizations that invest in model-building gain clarity, alignment, and a sharper edge against competitors.
🎧 Listen to the Humans First episode to hear the whole conversation.
Why UX activities feel like busywork
Personas had their moment in the spotlight. Then they fell out of favor. Why? Because most became caricatures: job titles with a pet name and a stock photo. They captured tasks, but not behaviors. An accountant who does payroll every Thursday tells you nothing about how they’ll respond when the situation changes.
And personas weren’t the only casualty. Most leaders have seen personas, journey maps, or information architecture presented as polished outputs. They look neat, get stapled into a deck, and then disappear. No wonder executives dismiss them as overhead.
The problem isn’t the tools themselves—it’s how narrowly they’re used:
- Personas often devolved into stock characters with little predictive value: “Nurse Nancy, age 42, works the night shift, owns a dog.”
- Journey maps got reduced to step lists without context.
- Information architectures that catalog terms without connecting them to user understanding become little more than taxonomies.
When treated this way, these deliverables don’t change decisions. They become shelfware.
Worldbuilding shifts the mindset behind traditional UX tools
Personas, journey maps, and information architectures were never meant to stand alone—they’re parts of a bigger picture we call worldbuilding.
Think about how important worldbuilding is in literature and entertainment. Just like a great author builds a fictional world in order to write a believable story, UX teams need to build a modeled world before building the product. When you see these tools through that lens, they stop sitting in a dusty Drive folder and start becoming essential parts of day-to-day decisions.
UX tools are no different:
- Personas and user models are characters. The most useful ones aren’t tied to job titles but to motivations, beliefs, and tendencies. They allow teams to predict behavior in new situations, not just summarize a job description.
- Journey maps are settings. They document the other people in the room, the simultaneous tasks competing for attention, and the flow of information before and after the software interaction.
- Information architectures are the language of the world. Shared vocabulary and structure act like the “rules of magic” in a fantasy novel: they define what can be said, how it’s understood, and how the characters navigate the interaction.
- Service blueprints and engineering models define environmental rules. They capture the processes, systems, and constraints that dictate how things play out in reality.
Seen this way, these aren’t isolated deliverables. They’re facets of one discipline: building a coherent model of the world your product must live in. And once that model exists, teams can simulate decisions against it.
Learn more: Engineering, User, & Design Models
Practicing worldbuilding: step into the writers’ room
Imagine sitting in a writers’ room for a long-running TV series. The world is already built. The characters are established. The audience knows their quirks, their strengths, and their blind spots.
Your job isn’t to invent everything from scratch—it’s to write the next episode. To do that well, you need to respect the world that already exists. You drop familiar characters into a well-developed setting with a new problem and see how things play out. In the writers’ room, that happens through conversation: someone throws out a scenario, and the room reacts. “That character would never do that.” Or, “That actually makes sense—it opens up a new thread.” Weak storylines get cut before they’re written; strong ones get refined until they feel inevitable.
Designing products works the same way. Drop your personas into an environment that already has rules, expectations, and other users in place. You can then “play out” scenarios in the model with your team before a line of code is written.
- Add a workflow, and the journey map shows whether it competes with existing tasks.
- Introduce a new term, and the IA reveals whether it fits the language users already know.
- Offer a complex feature, and personas predict whether some will thrive with it while others ignore it.
In our military experience, rigid training can make personas seem less relevant: “they’ll follow procedure every time.” But worldbuilding reveals the truth — no human stares at a screen for eight hours without distraction. Accounting for the realities of human behavior, even in highly structured environments, makes designs more resilient and believable.
The better you understand the world, the more believable your solutions will be. That’s the power of worldbuilding: it’s not documentation, it’s simulation. A weak model forces you to guess. A mature world surfaces truths.
Go deeper: Improving Your Organization’s Design Maturity
Here’s what worldbuilding has looked like in practice
This approach isn’t just theory. It plays out in the projects we see every day:
Personas: characters drive the plot
We once contrasted two users in a healthcare context: one kept meticulous paper logs, the other relied heavily on the software to track information. Drop those same characters into a different scenario — say, managing financials — and you can imagine exactly how they’d respond. One saves every receipt in a manila folder. The other categorizes every transaction. worldbuilding makes those patterns visible, no matter the role or industry.
Journey maps: the setting shapes every situation
In one project, operators worked in control rooms filled with dozens of screens, constant alarms, and chatter from teammates. It wasn’t realistic to design as if they were calmly focused on a single product. Mapping that environment changed how we prioritized visibility, hierarchy, and interruptions—it grounded the experience in their actual world. Every scene plays differently depending on what else is happening around it.
Information architecture: language builds the laws of the world
In another project, we debated whether to call a feature a “template” or a “document.” The distinction seemed small, but the label shaped how users would think about creating and editing content. Choosing consistent, forward-looking language built continuity into the world and prevented confusion later. Words aren’t decoration—they’re the physics that hold the story together.
Engineering models: rules ground you in what’s possible
In complex platforms, one rule change—say, how permissions work—can ripple through the entire ecosystem. Documenting those dependencies isn’t busywork; it’s how you define the world’s logic. When you understand those underlying mechanics, you can predict what will break before it does—and prevent creating something that’s impossible to build.
The strategic payoff of worldbuilding
Good design isn’t a one-time project. It’s an ongoing, collaborative act of storytelling. In a long-term engagement, a persona should mature from a sketch into a fully realized character. That’s not rework—it’s compounding clarity. The payoff is faster alignment among teams, efficiency by ruling out bad ideas early, and an increased competitive advantage—you’re not just chasing features anymore.
If your team isn’t building worlds, what reality are your products being tested against? You can’t build a believable product without first building a believable world.
