Attention!

The content on this site is a materials pilot. It represents neither changes to existing policy nor pending new policies. THIS IS NOT OFFICIAL GUIDANCE.

Consider the user


Iterative development

Ask how the state incorporates the end user during the development & testing processes.

  • Bad: The team only collects input from end users at the end of the process.
  • Meh: The team collects feedback at the beginning of the process, but does not validate they are meeting user needs during development.
  • Good: The team regularly collects feedback and tests to ensure the product improves the experience for end users.

What's this about?

Testing is a sometimes misunderstood, yet critical aspect of a long-lived software project. This is especially true if you are trying to produce high-quality software in an iterative manner. This lesson will speak to the role that actual users play in the ongoing testing of a major software project.

Lesson outline

If something is hard or frustrating to use, it just won’t get used the way we intend or at all. Without careful thought and planning, it’s easy for a development team to get caught up in hitting goals or milestones of the software without considering the needs of the people who use it.

If we create a piece of software or new feature and only stop to get feedback when all the work of making it is done, the entire effort might be wasted if it’s not useful to the intended audience. That’s why it’s important to check in with users at the beginning, middle, and end of the development process so that their feedback can steer the work toward a great product for them. Ideally, the user input should be as continuous as possible, and so this row in the Rubric is a top priority in the iterative development process.

Consider the end user (5m, solo)

Timer: (5m timer)

First, let’s consider the end user — the person who uses the product or software that we’re building. Who are they? What type of person are they? What are their needs and how does what you’re building solve them? To capture these questions, user experience (UX) designers create “personas” that sort of act like characters in the story of making the software. This centers the user at the start of the development process and helps keep who you’re building for in focus throughout the process.

You may have heard terms like user-centered design, human-centered design, or UX. These all refer to part of this process of centering the end user and their experience with the software.

This short video (2m35s) helps illustrate this process and shows that it’s a cycle — it doesn’t just mean asking users for feedback once and being done with it. Designing for humans means continually checking in as features come to life, testing with real people, gathering their feedback, and making changes to do it all again to get the most useful product for them at the end.

Reflect (30m, solo)

Timer: (30m timer)

Let’s take a short moment to write down some notes about the topics in the video. Empathy may not be something you usually hear about in software development, but it’s an important tool in building something that works for users.

Always Questioning

The 4 main phases of human-centered design that are outlined in the video:

  • Inspiration
  • Ideation
  • Iteration
  • Implementation

Questions

  1. The video explores four phases of HCD (above). Where have you seen this cycle in your own state’s projects?
  2. The video shows a text-to-speech failure. What are other examples of times when users’ needs were not considered in projects?
  3. At which point in the process do you think that empathy is the most critical?
  4. How do you know when enough iterations are done with user testing, feedback, and implementation?

When reflecting on these questions, it may be useful to think of situations in your own projects that worked well (or didn’t work well).

Viewing: Designing for people, not problems (20m, video)

Here we’re going to go a little deeper into human-centered design with two videos. Watch these two videos — at the end we’ll answer a few more questions.

Always questioning

Human-centered design:

  • Tests assumptions — what users say often surprise you!
  • Cuts waste — instead of building something and having it fail spectacularly, you invest a bit of time in a prototype and get feedback on those results
  • Helps an approach with questions, instead of solutions

Questions

  1. What did you take from each video? Anything that surprised you?
  2. Which points from the videos really resonated with you? How do you think they are received in software development?
  3. Prototypes and demos help create proof that an idea as valuable. What value do they have for testing with users? What do they require in order to be useful for feedback?
  4. Why do human-centered design? Have you seen its benefits in your work? Or just in your life?

How do you know if your state is doing this? (30m, solo)

Timer: (30m timer)

There are certain “tools of the trade” in user-centered design that you can look for. At the beginning of the process, there is gathering information on the users through data, surveys, and interviews. This can look like taking a look at current systems and how they are used, and then interviewing a few people who use them to discover pain points.

As the development process continues and there are early demos and prototypes, the iteration and testing process begins. Users try these early versions of the tool and give feedback that is incorporated and ideally, re-tested with the users until the product has improved enough to move to further stages in development. This is the bulk of the cycle of the movement. Hopefully, after enough rounds of testing and user feedback, the final product is basically complete and only needs one final user test to check in before its release. Think about projects in your own state. Where are they getting this right or wrong?

Think if they include in their plans for the projects:

  • User research—like surveys, testing, or interviews with users
  • Evaluation—compiling data from actual users, via web traffic, tests, or surveys and interviews
  • Feedback—using evidence from their users to make revisions to their tool based on evidence and user feedback

Pick a couple of examples of this in your state’s current projects—maybe one that looked good and one that didn’t. We’ll discuss these when we gather as a group.

Sharing experience (30m, small group)

Meet with your small group and connect what you learned in this lesson to situations you’ve seen with your state projects. Consult the notes you took throughout the lesson and try to link them to a story that you can tell about a particular project. It’s probably useful to do some brainstorming on this before you meet with your small group to trade stories.

When you get together with your small group:

  1. Share your stories with each other.
  2. Figure out which ones are the best candidates for a case study or use case that would be helpful to share with other state officers.
  3. As a group, choose useful stories and write notes on how they link up with the concepts shared.
    • Include in your notes:
      • When did this story take place?
      • What were the events or background leading up to this story?
      • How did this story demonstrate an ideal or non-ideal situation?
      • What specific principles from the lesson does this story illustrate?
      • If the story shows an ideal, what were the conditions that made it work? How did it fit with the principles shared in the lesson?
      • If the story shows a non-ideal, what could have changed to make it better?
  4. Share these notes with the larger group when you meet.
  5. After discussion with the larger group, document these stories and their connections to the lesson to help other state officers understand how this lesson’s concepts apply to their work.

Discuss in community (1h, group)

Come together with your colleagues for a conversation.

You can click on the timers below to help keep yourselves on track.

  1. Check in. (5m timer) First, check in with each-other. How is everyone doing? Take a moment to share something positive from the week, either at work or at home.
  2. Understand. (20m timer) Next, take some time to discuss points where you were confused or questioned your material. This would be a great place to probe ideas; help each-other unpack why you feel this way about the readings.
  3. Reflecting. (20m timer) Bring examples from your own states on how they currently incorporate users. Bring questions for your state’s projects if how and when they consider the end user are unclear. As a group, offer suggestions for how you would like to see the state and/or vendor improve in the next iteration. This could be in the form of questions that you want to ask, or it can be recommendations. Imagine and discuss how the state might respond to those questions or recommendations.
  4. Questioning. (10m timer) For the last few minutes, take some time to expand on how state project engage end users in their development process. You have your own experiences as SOs, and those experiences should inform your inquiry. What questions (in addition to the ones asked as part of your solo work) do you think you should be asking? Make sure to share those questions back, so they might be incorporated into future versions of these learning materials!

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:

From the State Software Budgeting Handbook:

Wrapup (5m, solo)

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