Toolkit

At Nava, we believe that cross-collaboration between designers and developers is essential to creating best-in-class, human-centered products. Often, this means our designers apply human-centered design and user experience (UX) best practices to developer-focused processes, tools, and teams. This can include everything from ecosystem maps that facilitate “big picture” thinking to interactive documentation that optimizes the handoff of work from designers to developers. The practice of treating the developer as the end-user is called Developer Experience (DevEx).

When done well, DevEx can remove obstacles or provide resources that enable developers to focus on mission-oriented work. Though DevEx is still an emerging focus for design, there’s a huge opportunity to help government modernization efforts. By leveraging their research, synthesis, and visual skills, designers can help developers make sense of complex and highly technical work. They can also shape internal communication and processes that make it easier for developers to build effective products.

One way for designers to practice DevEx is to create a data journey map that visually represents how data flows through a system. Data journey maps are different from other journey maps because they follow the perspective of data through various steps, rather than the perspectives of organizations or people. Data journey maps also simplify a complex process so that non-technical readers can understand it. A data journey map can:

• Provide clear documentation of how data flows through a system for developers working on a project.

• Help new developers onboard end-users to a project faster and in fewer steps.

• Create a shared understanding between designers, developers, and other stakeholders, helping teams to quickly identify and solve problems. 

• Help teams identify opportunities to build new features that improve and optimize the overall product or service. 

**Note that “end-users” in this context are partners or stakeholders from an outside organization. 

Building a data journey map for CDC ReportStream

Our designers created a data journey map when helping the Centers for Disease Control and Prevention (CDC) operate and expand ReportStream, a cloud-based platform that transfers healthcare data between organizations, testing facilities, and public health entities. Before an outside organization can use ReportStream, they must establish a connection with the platform to ensure their data is being appropriately submitted and delivered. This “onboarding” process involves various internal and external stakeholders, and a few important, iterative steps. 

To identify ways to streamline the onboarding process, we built a data journey map that illustrates how public health data flows through the ReportStream ecosystem, from initial outreach to the successful onboarding of an organization. From this experience, we followed a few important design principles and best practices that can help other teams build their own data journey maps. 

Helpful definitions:

Below are a few terms we use to describe the data journey map.

• A step is a discrete sub-set of actions that a user may perform. A user could be an internal developer or an end-user at an outside organization. 

  • Example: A developer at Nava receives a submission from an outside organization describing their unique settings and preferences.

• A phase is a group of steps that comprise a process or milestone. Oftentimes, phases are bottle-necked so one cannot begin before another ends. 

  • Example: Nava’s team onboards the organization onto ReportStream.

• A process is an end-to-end system that encompasses a set of phases. 

  • Example: Data from outside organizations moves through ReportStream.

Follow along using our data journey map template. 

You can access a PDF of the CDC data journey map here, and a PDF of the template here.

Best practices for building a data journey map

Listen to developers and observe their processes

Just as a human-centered design team would begin with discovery research to learn about user needs, the first step to building an effective journey map is to understand your developers’ needs and processes. When your users are technically adept, this means becoming conversant in their tools, technology, and concepts so that you can meet them where they are. It’s important to understand the full value and potential of your offering, the effort involved in operating it, and the universe of support that comes with it.

In our case, we did not begin our project intending to build a journey map. However, after listening to developers, observing the onboarding process, and reviewing documentation, we saw how chronologically mapping the flow of data could help us identify ways to improve this service. 

We chose to follow the perspective of data, rather than people or organizations, because understanding the flow of data through the ReportStream ecosystem is crucial to providing an effective onboarding experience. We also wanted to ensure that data flows through ReportStream with little need for maintenance, which also makes for a better onboarding experience.

When partnering with developers to build a data journey map, here are some initial questions you might consider asking: 

Process-level questions

• How does the process begin?

• What makes an end-user successful during this process, generally?

• Who are you interacting with in this process? How many end-users do you interact with at once? 

• What’s the end-goal of this process?

• What tools/materials/assets do you use in this process?

• Is the process linear or do steps branch off/diverge?

Phase-level questions

• What phase(s) comprise this process?

• What issues do users experience at each phase?

• What separates different phases in this process?

• How long does each phase take?

Step-level questions

• Which step(s) comprise this phase? This process?

• What issues do users experience at each step?

• What separates different steps in this phase? In this process?

• How long does each step take? 

Iterate, get feedback, then iterate again

Once your design team has a handle on developers’ needs and a baseline process structure, use that information to build out the first prototype of the journey map. This prototype likely will not address developers’ every need—that’s why your team should get feedback on the prototype, iterate based on feedback, and then rinse and repeat. This process is called agile development, and it can help you hone your journey map so that it brings clarity and coherence to each step. When we tested our map with developers, they helped us identify steps that were in the wrong order, obsolete, or inaccurate. 

When testing your data journey map with developers, here are some things to keep in mind: 

• Because developers may or may not be familiar with design and research processes, be specific when asking for feedback. Ask developers for their thoughts on specific parts of the data journey map, and less about the journey map as a whole. For higher-level questions, product folks may have a more holistic answer for you.

• Developers may be busy with other technical tasks, so shorter feedback sessions that are more frequent and ad-hoc can be helpful.

• It’s okay if your design team doesn’t have the same level of technical knowledge as your developers; you bring your own expertise. Don’t be afraid of asking questions that seem obvious. These types of questions can help you simplify concepts and bring clarity for technical and non-technical folks alike.

Here are some questions you might ask developers during the iterative stage of developing your data journey map: 

• Am I missing any important or critical parts of this step(s)?

• How do you engage with your end-users at this step? What channel(s) do they use?

• How do these end-user(s) feel about this step? Is it usually easy for them, or is it difficult?

• What are the tools/documentation/materials involved at this step? How do these resources help you accomplish your goals at this step?

• What are your challenges/frustrations at this step? What are some potential solutions?

Set developers up for success

A data journey map in itself isn’t enough to improve the developer experience. To unlock the full potential of a data journey map, design teams must continue to iterate on the map as process changes arise. They should also share the journey map across disciplines to create alignment, including with the product team and other designers. This can help non-technical staff understand the flow of data, and it can surface more opportunities for improving the map and the system it depicts. 

Conclusion

A data journey map can be a powerful tool for designers seeking to improve DevEx on their project. For example, our data journey map streamlined the onboarding process and made it quicker and easier for developers to bring organizations into ReportStream. It also helped us strategically scale ReportStream to ingest data for new types of diseases. Finally, the data journey map provided a common and consistent language for our teams to use when discussing stages of the onboarding process.   

However, data journey maps are not the only DevEx tools that designers can build. There’s no limitation on the needs that designers can solve for, so keep an open mind. The work can be challenging and ambiguous, but by building alongside developers, gathering feedback and iterating, and bringing in cross-disciplinary expertise, designers will be well-equipped to improve their team’s DevEx.