< Plotting UX

What is User Experience (UX)? That’s a big question and a lot of considerably more talented people have tackled this subject much better and more eloquently than I probably can. But it’s been forefront in my thoughts lately. So I figured I’d share where my thoughts about UX are heading by drawing a loose parallel using an increasingly popular notion of how it relates to plot development in storytelling.

From my perspective, a User Experience is how someone, or a group of someones, experience something. While not initially apparent, plot development in a story is useful as a comparative tool. Be it an app, theme park ride or meal, the contributing elements of a user experience—and a compelling story—are all present: Understand (Exposition and Rising Action), Build (Climax) and Launch (Falling Action and Resolution). By looking at the UX process as a story’s plot development—a formula successfully used for hundreds of years—these disparate elements combine to form a richer whole. Translating these storytelling elements into a technology-based, UX process might feel odd, but let’s take a look shall we?

Understand

In stories, exposition and rising action is often the longest part of a story. They set the stage, introduce the characters and set them off on their adventure. (Every story is an adventure—even paranormal teen romances with teenage girls fawning over sparkly, moody, ancient vampires. Stories I will never read.) Within the technology field we typically call this the ”Discovery” phase, where the problem is identified, defined, possible solutions explored and a direction chosen and planning done to implement the next phase. I’ve swapped out Discovery in favor of Understand because this is the root of what we’re trying to accomplish in this phase.

Often this critical phase of User Experience Design is dramatically shortened because, “You’re talking waterfall, we do agile here. We’ll iterate through this as we go! Besides, we’ll stretch our budget further this way.” This does the eventual experience a great disservice by removing the best possible opportunity to truly understand—and begin an effective process of finding an appropriate solution to—the problem. Research, exploration and planning (like exposition and rising action in a story) provides you with the foundation and vision of your experience, which you can then iterate and build upon to your agile heart’s content. Shortcutting here can, and usually does, lead to a disorganized development cycle, confused users and unhappy clients.

Build

The climax is supposed to be the most exciting part of a story. Your characters engage their nemesis in battle and are triumphant, or are defeated and left to regroup. In building a product or service this point in our story marks the beginning of crafting the code, aka the “Create”—or as I like to call it the Build phase—where things starting falling into place for you and a light appears at the end of the tunnel, distantly.

While it doesn’t appear logical that the initiation of coding your product or service serves as the climax of a project, it truly is. The effort required to reach this point often has involved significant work and overcome many difficult challenges to reach this point. If the research, exploration and planning have been done correctly by involving the technical team early and often in the Understand phase, everything should—theoretically—fall into place from here on out without too many surprises. When it does it’s magical and everyone’s euphoric ready to dive into the next phase and continue on the adventure.

Launch

In the last book you read, the final chapter or two wraps up most of the loose ends, gives you a warm fuzzy and sends you on your way. Many organizations have called this phase “Delivery”, I like Launch better.

Why? Well, with most digital products the end of a project marks the completion of a phase of work on a product. It is rarely, if ever truly finished beyond passing some arbitrary date on the project plan calendar, but the completed work should launch. There will always be tweaks and improvements to be made. Psychologically we need to finish the book, close and return it to the shelf and start another one, even if it’s a sequel.

For me, delivering a completed project is a satisfying feeling. It means we were able to stick to it and deliver something of value to our customer. That’s not to say it’s perfect or won’t be refactored by the next team to work on it (or us), but for us our work is completed and out in the wild—just like the last book I read. And hopefully I’ve learned a thing or two along the way that will help me make the next project I work on that much better.

< Back