User outcomes

What's this about?

In this lesson, we’ll shift our focus from considering user experience as an testing metric to considering user experience as an outcome. We’ll learn why it’s just as important to think about users at the beginning of a project as it is throughout the project’s development. We'll also discuss accessibility concerns and how to ensure that what we're building is as inclusive as possible.

Lesson outline

• Mapping users to outcomes (15m, solo)
• Outcomes, not outputs (10 min, solo)
• Viewing: Tools of the UX trade (45m, solo/friend)
• Viewing: Acessibility (45m, small group)

When we learned about user experience in the iterative development primary indicator lesson Consider the User, we saw user experience as iterative, meaning that user input is called on repeatedly throughout the process of testing and developing a software project. In this lesson, we explore how that user input factors into what the team builds.

Mapping users to outcomes (15m, solo)

Timer: (15m timer)

Let’s get into how we connect users to outcomes. Maybe you’ve thought a bit about how a good project should focus on outcomes instead of just outputs. It’s not about how many new features a software project can put out, but rather how these features work for their intended audience. It’s helpful to start by mapping out what users need and want from a project at the beginning, before any actual development work happens. It’s important to know where you’re going before you start, and usability is just another outcome we want to track towards.

If you have information about a current project and how it’s currently working for users, that’s a great place to start. Digging into the data about who uses the project, how they use it, and how they fare with using it will help the team see areas for improvement that center the user. You have to know where users are getting tripped up or lost in order to build something better for them.

Think of areas in your own state’s projects that address current user’s issues and problems. Make a note of them for later discussion, as well as how important you think these issues are to the success of the project.

Outcomes, not outputs (10 min, solo)

Timer: (10m timer)

When you think about it, a good experience for someone using a software tool is just another outcome or a goal that we want to track toward in development work. There’s a whole field of practice, called user experience (UX), dedicated to ensuring that users have a smooth and enjoyable time using a software tool.

Even so, it can be easy to put a business outcome or goal in place of a user outcome. Read through Shifting Our Team Goals to be UX Outcomes, which discusses this in depth.

After you read this, go back to your notes on your projects. Have you seen any of them tracking business outcomes instead of user outcomes? Write down how they might improve.

Viewing: Tools of the UX trade (45m, solo/friend)

Timer: (45m timer)

Once you get the ball rolling on a software project, it can be easy to get caught up in hitting project milestones without starting from a place where users want or need them. To avoid this, a team will start out with considering the user at the beginning of the development process. Usually a UX designer or someone with a similar title does this work of investigating user needs, but someone doing this work doesn’t necessarily need to have “UX” in their title.

There are a few tools of the trade that may help you recognize this process:

• Personas
• User stories
• Epics

Watch the video below as Anissa Deanna gives us a glimpse into this process and tells us what these terms means and their purpose in planning projects. Her video is from an Agile perspective, but gives a good overall overview of the terms and the process.

   As a ____, 
   I want to _________, 
   so that I can ___________.  

Now take the time to consider the following questions, writing notes in your notebook and then grabbing a colleague to discuss and trade stories and answers:

1. “As a X, I want to Y, so I can Z” — think about how this applies to your state’s projects. Do the projects have the same user stories or do they differ? If they differ, how?
2. Think of who might do this work on your projects. They might not always have the title “UX designer,” as Anisse mentions in the video, she has had to play multiple roles on her projects. Can you think of specific people who do this? What are their titles? How does the team split the work?
3. What personas could work well in your projects? Brainstorm some with a friend and write them down to share when we meet as a larger group.

Viewing: Acessibility (45m, small group)

Timer: (45m timer)

When building these user stories, personas, and epics, we have to make sure we’re as inclusive as possible—of those with disabilities and of those with other accessibility concerns. Making sure there are multiple ways to access a tool often has the great side effect of making the tool more usable for everyone. For example, captions on a video help not only those who are unable to hear the video, but those watching in a quiet area where they can’t turn on sound. Watch the video below from W3C, an organization that sets web standards, on accessibility on the web.

Write some questions down about your projects. Do they address these issues? How could they be improved?

In the guides

This lesson is the beginning of a journey. If you're interested in learning more, there's material in the 18F Derisking Guide that you'll want to check out.

From the Federal Field Guide:

• User-centered design
• Seek constant user feedback
• Agile contracts for agile procurement

From the State Software Budgeting Handbook:

• User-centered design
• Procure services, not software
• Measure success iteratively

Wrapup (5m, solo)

Take a few minutes to share your reflections on this lesson.