Experience Designers start with empathy. We get to know people and seek to understand their tasks, goals, and objective outcomes. We observe the touch points in their journey and seek to understand how we can co-create an experience that helps them do what they need to do better.
Working Under the Experience Design Umbrella
I have worked on a variety of projects using systems that fall under the broad category of Experience Design. These include HCD (Human Centered Design), UX (User Experience Design), Design Thinking, Product Design, Service Design, and Agile. They all have one common rule: put the user at the center.
The thing that excites me most about Experience Design is that it can be applied to any situation in which people use a system or object. Once you understand the basic tools, they can be applied to an app, a water bottle, a grocery store, a music festival, or a system of government. In my experience, they help us diffuse emotion and ego within the creative process and make decisions based on data and user needs. Below are some of the tools I have applied in collaboration with cross-functional teams, users, and stakeholders.
Problem Statement
There is an objective for any project, otherwise there wouldn’t be a project. It is important for the entire team to be aligned on the outcome, since this will be the guiding principle for your work together. This may be expressed as a problem statement, mission statement, vision statement, etc. It should help you frame the project by providing an ultimate north star for what success looks like while while leaving room for the many possible paths to that outcome. It is also possible that your problem statement will change as you learn more. Re-examine it throughout your process. Does what you’ve discovered support the original statement?
Research
There are so many ways to get to know users. Interviews, observation, and immersion are all different avenues to understanding. In each situation it’s important to create a framework that will maintain focus on the project without being overly directive. If your initial research parameters are too specific, you may eliminate crucial information or observations that fall outside them. Instead, create a list of prompts that will help your user explore their processes, pain points, and desired outcomes. Listen and/or observe and follow up on what concerns them most.
Assimilation
There is a point in most projects when the amount of incoming information is overwhelming and everything is confusing. Rather than force form on a subject, we need to learn to be comfortable with discomfort.Use assimilation exercises that align with your goal. Are you trying to understand people, discern patterns, evaluate technology, reframe problems? Then observe the natural relationships and gaps that emerge.
Reframing
Once you’ve gathered research, assimilated the information, and observed the emerging patterns and gaps, take a step back. Does what you’ve learned support the original problem statement? What is the root (or roots) of the problem? What dependencies, context, or assumptions have been identified? What do the details mean? How do they change the nature of the problem? What new possibilities have emerged as a result? Is there a more relevant or more innovative problem to be solved?
Personas
A persona is a detailed description of one of your user groups imagined as a single person. It is a useful structure for organizing your research to show how users relate to your experience. There are plenty of frameworks for creating personas. Most include demographics, behaviors and goals. Some may also include a short story, jobs-to-be-done, or statements about their pain points and how they could be better supported.
Persona drawings by Yu luck from the Persona Collection at The Noun Project.
User Journeys
User journeys are a series of touch points within, or related to, your product or experience where the user takes action toward their intended outcome. You can conduct more refined interviews and surveys to understand user experience around each of these points. Are they pain points or satisfaction points? Maybe there are new technologies or processes that better support your users. Maybe a completely different set of touch points will meet the same goal with improved outcomes.
When you’ve completed user journeys for each of your personas, they can be combined into a user atlas, which allows you to examine your system for opportunities for alignment, efficiency, and innovation.
Pre-storyboards
Pre-story boards will help get a jump on story boards and work well with the non-visual part of your team. A useful shortcut is to ask each member of your cross-functional team to step away and describe what happens at each touch point from their perspective.
When the team regroups everyone lays out their descriptions together. This helps them understand the project from the point of view of each skillset and reveals gaps and dependencies. It’s a great vehicle for the team to coordinate their understanding of each touch point.
Storyboards
Storyboards are used to convey the experience of a sequence of events within your project. They can be rough or polished depending on their purpose. If you’re working out the features, space, or interaction for each user touchpoint alone or with a small group they may be quick sketches like the ones I’ve shared here. If you are using them to communicate with your client or leadership, they may be very finished and detailed.
Wireframes
Wireframes are used to explore design approaches and to evaluate the layout of features without being overly engaged in details. They can be used for team discussion, lo-fi prototyping and user testing, or simple visual explanation.
Sitemaps & Wireflows
Sitemaps and wire flows show how the pages of the experience are connected and how a user may and may not get from one portion of the experience to another. I created this sitemap for an internal marketing content site.
Designs
Designs are used to explore hi-fidelity versions of your experience. This is when you hone in on how the details support the project’s over-all objectives. Designs may be used for client presentation, visual explanation, or user testing.
Prototyping & Testing
Prototyping is about testing your product or experience with users. This should start early and continue throughout the life of your product. Whether your test should be high or low fidelity depends on your objective. A lot can be learned quickly about the flow of information or a set of choices using simple props and activities, such as wireframes drawn on paper or acting out a scenario in a physical space. High fidelity testing helps gage user understanding and satisfaction. We can observe their reactions to UI details, content flow, and interactions. They can also be used for market testing and providing a more complete understanding of the experience for clients and leadership.
It it important to be clear about your testing objectives. Put your users at ease. Confirm that this is not a finished product and they should feel comfortable pointing out design flaws and expressing confusion. The prototype is being tested, not them..
Implementation with Agile
In non-digital projects, you may overlap with architects, interior designers, urban planners, or policy makers, to name a few, but if you are designing digital technology, Experience Design will likely move into Agile during implementation. At this point you will need to write Requirements, a detailed list of what you want your product/experience to do and why, based on your previous research and activities.
This will be organized into User stories, or Stories for short. These are one sentence descriptions of a functionality desired by a user. Example:
As a <user-type/role> I want <goal/ability/function> so that <reason/benefit>.
User Stories allow IT teams to organize projects based on points of functionality while focusing on user needs. These are organized into a prioritized to-do list called a backlog and delivered in targeted periods of time called Sprints. They may also be grouped into Epics, a group of stories with a common objective, and/or fall under Themes, which are the broadest area of focus and may span Epics or even projects.
User stories will continue to be written throughout the project. As you work with them, you will add success criteria that can be tested against to evaluate whether the work is complete. Core stories that comprise the MVP (minimum viable product) will be prioritized for subsequent test, learn, and build phases.
Analytics & Measuring
For any product or experience you need to be able to measure your success. Depending on what you’ve built you may be measuring both its use and its output. For instance, if you create tax software you will want to evaluate ease of use and also how the tax forms it produced work for the accountants and agencies that receive them. If you design a factory, you will want to know how easy it is for your workers to produce your product, but also how that product is received by consumers. In this way you can track how improvements in one lead to improvements in the other.
Quantitative: There are very specific quantitative elements you can measure, such number of users, number of downloads, time spent on pages, and user paths. Look back at your use cases, business objectives, and user tasks. What metrics indicate success in these areas?
Qualitative: Metrics often point to where you can dig deeper by talking to your users. Testimonials, anecdotes, feedback, and stories bring analytics to life and help your team and your stakeholders understand successes, issues, and new use cases.