Build Your Own Adventure: Exploring UX Design With D&D
In this blog
With your staff raised high, you walk through the darkness, lighting the way for your friends behind you. A hand grasps your shoulder, "wait. I heard something." Everyone stops. Listens. Waits. Your heart skips a beat. Something is breathing heavily behind you.
What do you do? What motivated you to go into the darkness in the first place? What compels you to keep moving forward?
Even more importantly, why are you reading about adventuring in an article about User Experience (UX) design? Let's back up and explain.
A venture into UX
We, as people, are driven to take on tasks that we find rewarding. We seek out experiences that challenge us because this gives us a sense of accomplishment.
User Experience design may be a new field to some of you. Briefly, it is a discipline whose goal is to optimize software for ease of use and enjoyment. Its core concepts reach far beyond technology, having been successfully utilized across product design for over six decades. Moreover, these techniques have been used by the gaming industry to great success.
We opened this article with a scenario familiar to anyone who has played Dungeons & Dragons (D&D). How does a game that requires the purchase of multiple rulebooks, weird dice, hours of preparation and gameplay enjoy a growing fanbase for over 45 years?
The answer: it is a gaming experience created by the players for the players. Whether a game lasts for one night or 20 years can depend on how well the Dungeon Master (DM) knows their players, listens to their players, and runs a game for their players' needs. A good DM creates an epic user experience.
In D&D, every game is composed of different players -- all with differing desires. It's the DM's job to make sure everyone at the table has a memorable experience. If the DM fails, the game fails because players will get discouraged and stop playing. It doesn't matter how complex the plot, or epic the collection of monsters; if players aren't invested in their character's adventure, they just won't play.
Software development encounters the same risks. It doesn't matter if you have the quickest load time, the slickest animations, or the perfect marketing strategy -- if your understanding of what your users want and need is wrong, they will not use it. To save time and money, it's crucial to begin any software development with an understanding of who your users are and what they want.
So how do we know what we need to build and who will use it? Let's start at the beginning.
The adventure begins
Three days earlier…
Music fills a small tavern where you've come for drinks and a night off. Your attempts to gain the king's favor and join his court of magicians had failed yet again. But the music stops when the door flies open, and a local shepherd cries that the princess has been carried off by Arghast, the warlock overlord of the neighboring country. The king offers a reward to whoever can bring her back. Instantly, you stand up and exclaim, 'I will do it!' But you are not alone. Three others, now standing, also declare they will go. Draven, a cloaked elf with knives at his side, seeks a pardon from the king. Gareth, a small halfling dressed in furs and wielding a crossbow, is down on his luck and needs money. And Aurelia, a dwarf dressed in plate mail with a massive sword on her back, hopes to prevent a war from breaking out. Each of you looks around, surveying the others. With a curt nod, you all agree. 'We will find the princess!'
Every adventure begins with a problem. Someone needs to be saved; someone has to be stopped; or, simply, the heroes need money to buy that flying carpet. Software development should begin the same way. Someone can't go out and get their own groceries; someone needs to find a new nanny; someone needs to stay connected with their grandchildren. First, identify the problem. Then, work toward a solution.
In our time together today, we're not concerned with finding the problem. We'll operate under the assumption that our problem has already been discovered. For information on how to ensure you're solving the right problem, check out Katie Smith's article.
So once we've established the problem, who dictates the proper solution? In UX, as in D&D, the answer is: the players -- the users of the experience we are designing and delivering.
In D&D, a game only lasts as long as its players are invested; in software, adoption and continued use are achieved only when users find it beneficial. Users' input is the most valuable foundational step of any project. So how do you get information from your players?
Understanding the party (aka: your users)
Having set out from the town, our party turns north toward the path at the base of the mountain. Suddenly, Gareth stops and exclaims, 'Oh! Wait, maybe we should go another way!' The party stops and turns. He continues, 'Why don't we head west and try to access his fortress from the caves that run through the mountain.' You raise an eyebrow. 'Aren't those caves infested with giant insects?' The party all turns toward Gareth. He shrugs and says, 'Oh, come on. I'm not afraid of some bugs. Are you?' After much discussion, the party gives in and turns west… something the DM had never anticipated.
One of the most popular techniques for gathering information on users is to make educated assumptions based on previous experience and expertise. This is also the worst technique. Every Dungeon Master and every UX designer has encountered this scenario. They think they know what their users will do, and then they're proven wrong. Sometimes after a frustrating amount of time and effort.
No matter the level of expertise in app development, design, or even UX, no one is an expert in users' problems, attitudes, and behaviors until they take the time to talk to them and observe them --- to walk a day in their shoes. And getting user input early and often makes sure that we build the right thing for the right people the first time.
Simply observing people is not enough. We must turn our observations into explicit and shareable references to which the entire software team can refer back. It's helpful to mold it into a useful visual for easy access. In D&D, the party is represented by their character sheets (fig 1). In UX, we use design personas (fig 2). Design personas are archetypes of real groups of people we studied and observed, and they help us focus on common behaviors and motivations. They engender empathy with our users as we design and build products suitable for real human beings.
We know our users better. Now let's figure out where they're going and what they're doing along the way.
Preparing the journey
The party heads west, no longer traversing the clear-cut path up the mountain; but slogging through dense woods, trusting Gareth's memories of tales and folklore to guide the way. Along the way, Draven's legs became swollen after blood-sucking creatures attacked him while crossing a river. Aurelia was sung to sleep by an enchanted harp during her watch, allowing the whole party to be robbed of their gold. Your life was almost ended by a troll attack, but you managed to unleash a wave of magical energy ripping through them one after another. Troll eyes being very valuable at the nearby market, you hope to recoup some of the gold lost. Finally, you reached the imposing entrance to the caves and entered the darkness.
Once you've learned more about the users, you need to understand their journey. In D&D, there are two broad categories for how to run a story - the railroad and the sandbox.
Railroad games are those that follow one strict path. No matter what players try to explore or change, the narrative rides the rails the DM had set down. Railroading is criticized for sapping players of their agency. The DM writes the plot, and the players are there for the ride.
Most software is created along a railroad. Even if we took the time to make personas and know the users, we then go back to our offices, design, develop and release software to those users without asking further questions. We're still making assumptions.
Sandbox games are open-ended. Players can explore any corner of the world without any real constraints from the DM. Player agency abounds in the sandbox. What it lacks is direction. Purely sandbox games often fail to grab player attention because players feel lost without some guidance about where to go.
Software development can suffer from sandbox faults as well. When we fail to narrow our focus and try to make software do everything regardless of user needs, we can create the same feeling of confusion and helplessness. We still need to design the experience to be the best for our users.
So how do we find the balance? How do we know when to railroad and when to sandbox? As always, we listen to our users. Gathering feedback is relatively easy in a D&D game. Most games are played in person. You can see live reactions to everything you do. If players are bored, frustrated, angry, or annoyed an attentive DM will see that.
Being with your users in person and seeing how they complete tasks before, during, and after interacting with the software is crucial in crafting a successful user experience. One way to accomplish this is through a contextual inquiry, where the user is observed and interviewed while completing a task in their own environment. This helps you understand your user's pain points and analyze the many factors that influence their behavior.
Contextual inquiry focuses on discovering a user's entire journey. Not only how they use new or existing software, but also what other surrounding factors impact their experience. Ideally, an app solves a specific problem for a user; but users are dealing with multiple issues at a time. In our lives, we are constantly bombarded with interruptions, stimuli, and other distractions.
So while we can't expand the scope of software to try and deal with every interruption, we need to acknowledge that our users aren't operating in a vacuum. People are going to make mistakes. They are going to be distracted. They are going to have bad days. In order to create the best user experience, we have to account for these extra interruptions and work around them.
Contextual inquiries are valuable pieces to understanding the puzzle that is your users. Other research methods such as remote usability testing, user interviews, and surveys can further complement this data.
After conducting user research, one way to help visualize all the competing pulls on a user is to create a journey map. Journey maps are visual representations of a persona's experience to help build empathy and find solutions to pain points along their user journey (fig 3).
Through careful research and observation, we better understand our users' behavior. As we move into design and development we must keep in mind their objectives and obstacles while fulfilling their desire for both agency and direction.
Upwards and onwards
And so we return to our heroes...
With your staff raised high, you walk through the darkness, lighting the way for your friends behind you. A hand grasps your shoulder, "wait, I heard something." Everyone stops. Listens. Waits. Your heart skips a beat. Something is breathing heavily behind you. You turn to see a monstrous creature. It has six legs, piercing yellow eyes and ferocious pincers. It towers above you all, staring down at Aurelia. Gareth gulps nervously, but Aurelia pulls out her sword and attacks. The monster lets out a shriek and battle begins.
After numerous days of collecting data and learning to understand your users, you are ready to begin the process of designing and developing your product. Setting up your project with an in-depth understanding of your users supported by qualitative and quantitative data may seem like a daunting task. However, doing this process effectively will set you up for success in creating an experience that benefits and delights your users while setting the groundwork for future adventures to occur in your design career.
The party is assembled, the quest is before them, and now the adventure begins. Your focus is now on developing your product, however, your quest to understand your users is far from over. As you work through this next stage, you will reconnect with your users time and time again to verify assumptions you've made and test to ensure your designs ultimately serve them effectively. We will be continuing this journey in a future installment. Until then, journey on!
… To be continued