Chapter 6

Identify Outcomes and Expectations

Summary

Your content and message – and your audiences – live on dozens of paths and hundreds of combinations. Understanding what they’re looking for when they access your project will have a large impact on the steps that follow.

Does This Apply?

Just as you need to know the people you’re building for, you also need to know what they expect out of your project. Both building to and tempering expectations often becomes the major, overarching thread of a full-stack web project, so knowing what those expectations are gives you a head start (and fewer headaches).

Narrative

In the fall of 2013, the United States federal government, driven by passage of the Patient Protection and Affordable Care Act (PPACA), created HealthCare.gov, a health insurance exchange website designed to help those who don’t already receive health insurance better understand their options.

To say this site was the crown jewel of the administration’s fight for more affordable health care isn’t an overstatement: it served as a public representation of years of attempted health care reform. It was the answer to a promise – a promise that, in part, defined the first half of President Barack Obama’s time in office. And, on October 1, 2013, despite the beginning of a government shutdown, the site launched, ready for the world.

Well. Almost ready.

You see, HealthCare.gov, by any sense of the metaphor, stumbled out of the starting gate. It was new and a little confusing, and it was immediately panned by the Obama administration’s political rivals. But, more than that, it was plagued from the beginning by technical issues. The complexity of its interconnecting systems wreaked havoc on how information was passed from one page to the next, and it was constantly being flummoxed and overpowered.

But, even if the technical side had held its side of the bargain, the user experience – the user paths, the labeling, and the information architecture – was designed in a way that promoted failure. Confusing homepage buttons made it difficult to know where to even start. Help text and navigation

were focused on terms used by the agency, instead of plain language that a site user might understand. Forms seemed overcomplicated, carousels hid useful wayfinding text, and technical failures were hidden until a user completed the process.

Your website is part of a larger story, and because of this it must follow a logical story structure. Donna Lichaw, in her book The User’s Journey, calls this the narrative arc: the application of a beginning, middle, and end, buoyed by rising action and excitement until it is released. There’s background exposition that hits a pain point (the inciting incident) and action rises until it reaches climax (the point of action).

For the people who visit your site, the climax is the moment before they reach their solution, and the success of that moment can either end with a slow denouement or a rapid and harsh cliffhanger. HealthCare.gov definitely started its life as a promising solution, but as it encountered real people with real problems, it lost the plot. Users arrived on the site with an expectation for how their experience might roll out, and instead the site brought them to the brink and led them directly off of a cliff.

In order to provide satisfaction – and to keep them from being thrust into their own personal cliffhanger – we start by understanding what a site user is looking for.

Episode 6: Identify Outcomes and Expectations (w/ C. David Gammel)

Corey and Deane talk about understanding the audiences of the The Web Project Guide book, and the concept of predicate knowledge. Then, C. David Gammel, author of Online and On Mission, joins the podcast to talk about how to prioritize outcomes when stakeholders all have their own interests, understanding the expectations of those who use your website, and how to best introduce domain knowledge.

41:13 | C. David Gammel

Past Episodes

Defining Expectations and Outcomes

An expectation is what someone wants and expects – it’s a combination of personal preference, social cues, and history. In Thinking, Fast and Slow, Daniel Kahneman talks about two kinds of expectations: passive expectations, in which you are conditioned to not be surprised by an occurrence — such as how running into a friend at a grocery store is less surprising if you know they live in the area — and active expectations, in which you are conditioned to expect certain occurrences given the clues around you, such as how you expect to find ice cream in the same spot no matter the grocery store.

These two forms of expectation frame many of the emotions we encounter on a website: we shouldn’t be surprised by things we don’t expect, and we should feel successful with the things we do expect.

An outcome is an action or feeling that comes as the result of your time on a website. Outcomes can be:

  • An action, such as completing a task: “I successfully purchased a new screen-printed poster”
  • A change, such as understanding a concept: “I now understand the history and culture of lucha libre masks.”
  • A behavior, such as an emotion: “I am happy after watching that cat video.”

Outcomes should be measurable. They represent what you’d like to have people do, and they represent what people expect to do. To frame both these terms, think of expectations as emotional benchmarks. The outcomes we provide for a site user are perceived to be successful or valuable only if they match or exceed those benchmarks.

Researching Expectations: What Are They Looking For?

In our world, the discovery (or research) phase is a kind of nebulous period in which we as web practitioners are making our best attempt at understanding the overall goals of the site.

We think that’s worth noting – that we said “goals,” and not, say, “users” or “functionality” or “features.” While everything we’ve covered up to this point might be considered a part of a “discovery” phase, all actions and exercises are leading toward one outcome: to better understand how to make the web project a success. To understand the expectations of what someone wants.

There are two ways to go about this:

  • Workshops: A discovery workshop is going to focus on learning more about users, sure, but it’s also going to dive into our assumptions about what those users expect when they come to your site.
  • Interviews: Interviews dive deeper into individuals, and can be the best possible source of actual user truths: if you want to understand user expectations, ask the users themselves.

The right answer, as always, is probably somewhere in between. There is a great amount of value in conferring with users and bringing them into the process – in fact, in nearly every case it’s ideal. But there’s also a balance. Users know what they want, but they know what they want based on what they already know.

Progress and new innovation don’t just come from the expectations of users, but also from the creative solutions of those deeply tied to the business itself. Both matter.

At Blend, we often engage in discovery workshops right off of the bat. In this model, the discovery workshop is designed to:

  • Get all stakeholders on the same page regarding site audiences and potential outcomes.
  • Allow us as web practitioners to better understand the organizational dynamics and the client’s industry itself.
  • Form a starting point for the project.

Then, once we understand the product and the business goals of the site, we can ask about expectations with real direction.

Contemporary and Competitive Analysis

Despite our desire to be, among all things, unique and special, at a general level most businesses or organizations are neither. It doesn’t matter if you sell fish lures, provide tax guidance, or inform parents of student activities, there’s definitely someone else out there who probably does it. And you probably already know this – after all, you encounter competition, meet with people from similar organizations at conferences, and look for insight among those who may have gone before you.

Use this to your advantage.

There’s no shame in sneaking a peek at your competitors. I promise you they’re doing the same thing.

What’s more, deeper study into your competitors may find that you’re doing something that they’re not. You may be providing a unique service, or surfacing different kinds of information on your site, or changing your overall messaging and marketing focus compared to the rest of the industry. While your business or organization may not be, at heart, a unique endeavor, it does have uniqueness built into it. These are your differentiating factors. Knowing these differentiating factors – and understanding how competitors and contemporaries handle their differentiating factors – can be crucial to communicating your value.

What you’re looking for is three-fold:

  • Missing Details: Is there something related to our proposed audiences that we are forgetting to take on? Or, are there entire audiences that we’ve forgotten to include? (If so, jump back a chapter!)
  • Confirmation: Do our decisions make sense as compared to those who do similar work? Are we on the same page when it comes to understanding motivations?
  • Opportunities: Are there things that we’re doing, solutions we’re providing, or expectations we’re fulfilling that seem untouched by the industry? Are we trailblazing in a direction that others have let go?

With all of these remember that you are not the same as your competitors. Brand new ideas in web content and design are few and far between, but competitive analysis can provide a spark toward finding your unique ideas and developing new questions and potential outcomes. You cannot take your competitors’ ideas as a guide, though: don’t look at a competitor and think, “Yeah, this is what we need to copy, right here, right now.” That does your company – and your users – a disservice. Your users are there to hang with you. Show them something unique. 

Outcomes: The End Point of a User Journey

Audience research is usually focused on figuring out what they’re going to do while they’re on your site. I promise you they want to do something. They might want to find a product or watch a video. They may want to figure out why they ended up on this site in the first place. They may even want to immediately leave – in and of itself an outcome, though not necessarily a positive one.

We do this by baking expectations and potential outcomes into our interviews. Beyond just knowing who they are, we need to know what their process is. We need to ask them questions like:

  • What do you expect when you arrive on the site? Note: this is very different from asking “What do you want to do when you arrive on the site?”
  • When you want to rent a movie, what do you expect the process will be like?
  • When you finish paying for your items, what do you expect the next steps will be?

Questions like this shift the focus from what the user wants to do (because no one really wants to check their email for a receipt from Amazon) to what they expect – in this case, you expect there to be a receipt, even if you’re not immediately going to print it and frame it forever. This focus on outcomes over features – on “what do you expect” rather than “what do you want to do” – allows us to be more accommodating in our site functionality. It allows us to make sure everything is purposeful. It saves us from having a half dozen blogs for the simple outdated reason that someone we talked to mentioned a blog once.

Straight up, the hardest thing to overcome in any project is understanding that what we think a user wants and what a user thinks they want may not necessarily be congruous to what their actual expectations require.

Documenting Outcomes

After all of this research, you’re going to end up with an unwieldy list of potential site outcomes. There will be a LOT of outcomes, because everyone wants something, and they all want something different.

Imagine, if you will, that you’re helping determine site functionality for SpeakerBox, a totally fake company that sells aftermarket car stereo parts – the stuff you use to customize your “sweet ride” to “totally bump” to the new, I dunno … Dr. Dre album. We’ve interviewed a ton of people, and we’ve conferred with our central web and marketing team, and we have come up with a giant list of potential outcomes for the site:

  • Learn about whether or not SpeakerBox carries parts for my vehicle
  • Learn about whether or not SpeakerBox carries parts for my stereo brand
  • Purchase a SpeakerBox product
  • Find a SpeakerBox warranty
  • Learn about what kinds of services SpeakerBox offers
  • Find information about the corporate board and employees
  • See how SpeakerBox’s products match up to their competitors
  • Get information on investments
  • Get information on how to install a SpeakerBox component
  • Find news and updates on the organization and the industry
  • Gain confidence in SpeakerBox’s quality
  • Contact a sales representative
  • Find and request a repair
  • Learn about SpeakerBox’s return policy
  • See new products as they are announced
  • Find imagery to use in circulars and promotions
  • Search and apply for a job
  • Log in to vendor support
  • Learn about employee benefits
  • Find online retailers that sell SpeakerBox components
  • Find physical locations that sell SpeakerBox components

Right away we can see that if we try to handle all of these at once, we’ll drown in functionality options. We must combine these into several high-level outcome groups, within which we can build a process that handles multiple potential outcomes. So, we look for and find those groups.

Figure 6.1: Combining Outcomes into Logical Groups.

While we still have the same large list of potential outcomes, we now see we’re really only looking at seven high-level outcome groups. This is what we hope people will do when they reach our site, based on our organizational goals, the wants and needs of the people we’ve interviewed, and the tasks provided by our competitors during that analysis. We can feel confident in creating functionality based on these outcome groupings, with the understanding that certain outcomes (for example: learn about SpeakerBox’s return policy) will serve the expectations of multiple audiences (sales partners, potential purchasers, past purchasers).

These high-level outcome groups also provide a bit of context to the overall site. In the SpeakerBox example, we might see a group like “Learn about SpeakerBox as an investment,” and see that it really only relates to a small fraction of site users (current and potential investors) and provides little valuable information that can’t be found elsewhere. Maybe this is a section that does not need to be included in the initial phases – or at all.

From Discovery to Direction

As we wind down our initial research, we’re really starting to nail together a kind of rough outline of purpose and viability. Plenty of research is left to tackle – non “discovery” research, like user testing, and even live research like analytics tracking – but at some point we need to admit to ourselves that it’s time to move from discovery to direction. It’s time to start making decisions. The entire purpose of researching a user’s expected outcomes is to provide better access to those outcomes, most often handled through some kind of site content or functionality.

At this point, we’ve moved from what the design thinking world calls “empathy” and toward what they call “ideation,” shifting our attention from who toward what.

This shift from discovery to direction isn’t without its snags: it requires some kind of mental model to help illustrate how things will piece together when, in fact, it is built into a future site. You could enlist a series of spreadsheets to try to help people understand how content, design, and functionality relate to user outcomes, but spreadsheets are hard to sell. At Blend, we like to create a map of user outcomes that shows both what kinds of questions can be asked and also what kinds of content will be required to support those questions.

In this model, all expected user outcomes are laid along the middle. Because we’ve clustered our long list of outcomes into high-level outcome groups in our example above, we’ll only have seven boxes along the middle line.

Figure 6.2: Lining Up Outcome Groups.

From here, we begin listing the inquiry points a user will have along their path toward a successful outcome. What kinds of things will a user want to know if, for example, they’re interested in maintaining a SpeakerBox product?

  • How interchangeable are standard SpeakerBox parts?
  • How long does the warranty last?
  • Are there any SpeakerBox retailers in my area?
  • Are there resources for me so I can install my own SpeakerBox product?

Figure 6.3: Pairing Outcomes with Questions.

And so on. These questions stack on top of the outcome group, illustrating the level of complexity.

With this mental model, we must do something to counter this weight; we need to buoy each outcome with the necessary content and functionality types required to make the outcome work. Under “Maintain a SpeakerBox product” we put content concepts and content types that help solve the questions listed above: in this case, things like “Warranty Content,” “Installation Videos,” and “Retailer Maps.”

Figure 6.4: Supporting Outcomes with Content Solutions.

With this work, we’ve created a set of functions that satisfies the expectations of those outcomes. This is one of many ways to illustrate the shift from “what we expect” to “how we’ll solve the problem” – whatever you can use to help move from discovery to direction will be helpful in tying real content and functionality needs to actual user needs, whether that’s adapting archetypes or personas to include more detailed outcome success, or whether that’s simply grouping common outcomes and matching them to tasks in a spreadsheet.

Now the question shifts away from “What do we do?” and toward “How much of this do we already have?”

Inputs and Outputs

Inputs for this are the same as for determining user audiences, but outputs might slant a little more toward things like the aforementioned mental model, a deeper and richer persona/archetype that ties together expectations, or even a formal declaration of site features to be researched and designed during wireframing and content modeling.

The Big Picture

Gathering expected outcomes and overall project expectations occurs during the research or “discovery” phase of a project, and it happens in parallel with the last chapter on understanding the users themselves.

Staffing

Much like user research requires an understanding of how to get usable and thoughtful information out of people who really don’t want to talk about websites, thanks so much, this level of determining expectations takes someone who can speak to people, empathize with their needs, and understand the connections between what they think they want and what they actually need. Again, your designers and content strategists should be able to handle this as it relates to gathering information, understanding requirements, and translating it into actual functionality.

Resources

Books