How do users engage with

By the Team

When we met with our users several weeks ago, we discussed their needs and expectations for the site so we could build well-informed user personas. Now we’re mapping the journey each user persona takes through our site in order to prioritize which features we build first.

As the team came together for journey mapping, we put up all of our user personas on the office wall. This helps us keep our users’ goals, frustrations and desires in mind every step of the way. Led by our user experience designer, we asked ourselves, “How would each user find their way to” He led us through how each user would navigate our site — or in his words — “What are their happy paths?”

We started with our developer persona first

We agreed that developers working for the federal government would likely discover while searching for code snippets, something like “JavaScript, time scheduler, federal open source.” That search would yield links to GitHub accounts for federal repos. It would also yield a link for We would then expect developers to follow the links and land either on the Project Details page or the Home page. If the developers land on the Home page, they would be able to perform the search again and narrow the results. They could then choose the project they want and get to the Project Details page.

Next, we spoke to developers who are federal contractors. They said, government employees would most likely ask their federal contractors to go to to explore reusable software. But once contractors arrive on the Home page, how might we direct them to parts of the site they’ll find valuable? Some suggested creating a Frequently Asked Questions page, which could help direct them to first-order answers they might have about how best to use But we also know that some of our contractors will immediately look for the Search page to discover code repositories. A successful search will direct them to our Search Results page, and ultimately, the Project Details page which, as the name suggests, provides usage, licensing, and descriptive information about each project that appears in our Search Results page.

Data scientists have similar user journeys to government developers, but with one primary difference. Data scientists searching for open data sets may actually find what they need on, rather than With that in mind, we want to ensure that a potential Frequently Asked Questions section thoughtfully directs data scientists to the appropriate resource based on their needs.

Of all our technologists, the private sector developer has the most entry points into Yet, each entry point starts with a public call to action (e.g., a federal agency determines that it needs a mobile app to gather citizen feedback, but it doesn’t have the capacity to do so in house). In answering the call to action, the private sector developer could potentially be directed to an agency’s Announcements page on They could also land on an Upcoming Events page or Help Wanted page on, the latter of which would list requests from federal agencies for help on specific software projects. These requests could appear in the form of discussion issues or bug-fixes, and would be open to technologists of all skill and interests levels.

We think our student developers might learn about via an event, a professor or student organization. When they visit the Home page, they could potentially use a guided wizard that walks students (or any visitor) through a series of questions, ultimately recommending projects for them based on their answers. After the student finishes the wizard, he or she would be directed to the appropriate Project Details page.

After we mapped the journeys of our developers, three things had become clear:

  • The Project Details page would be the most important page on;
  • A fully-functional search feature is important to our developers; and
  • We need tools like Frequently Asked Questions or a guided wizard to help our users get started quickly.

Next we focused on the journeys of non-developers

Our team had a lot of discussions about the journeys of product owners/managers. Our discussion was a good reminder that no one journey fits every customer. Our goal was to get to an ideal journey. journey map

We believed managers would hear of through their agency liaisons or from an email listserv. They may also discover it from the developers on their teams. Starting at the Home page, we would expect managers to perform a search for the type of project they are looking for. We decided it was more likely managers would come to to explore it and the Federal Source Code Policy.

For the most part, we learned that product managers no longer develop code day-to-day. They may go to their agency’s page to see what types of projects the agency tends to release as open source. They may also go to the Agency Liaison Listing page to see who their agency liaison is. Or they may use our Admin Tool we are currently developing, which would allow managers to submit projects for reuse. Managers looking for additional information on open source software and the Federal Source Code Policy would find the Tools and Resources page helpful.

We also spent some time talking about cyber security analysts. Cyber security analysts may be consulted by an agency to decide whether to release a project as open source software. The Tools and Resources page would explain how sharing our source code can improve the quality, efficiency and effectiveness of government software.

Our agency liaisons would begin their journeys on the Home page. But depending on what they need, they may have different journeys. Our liaisons who are working hard to achieve agency compliance with the Federal Source Code Policy may head to our Agency Dashboard page to monitor their compliance score and see how they stack up against other agencies on the list. Having access to this data may help create a sense of urgency for our liaisons and help facilitate speedy compliance with the policy.

Agency liaisons at all agencies will find the Tools and Resources page of interest. These tools can help them explain the Federal Source Code Policy to their agencies, in addition to the economic benefits associated with code sharing and reuse. They can also use the Admin Tool to view and approve their agencies’ open source projects. The Admin Tool page would also allow them to pull and update their project releases. Moreover, they can use their agency page as a way to highlight content they’ve uploaded. Another page, the Agency Liaison Listing page will list all the agency liaisons on one page and will help agencies collaborate on projects and share code.

After mapping the journeys of our non-developers, we came away with the following conclusions:

  • We need to give the agencies a place to highlight the work they are doing to reuse government code that already exists, and sharing it with the public;
  • We need to create an easy way for people to find each agency’s primary point of contact (i.e., the agency liaison);
  • The Tools and Resources page provides value to multiple users with information about unlocking the potential of and the Federal Source Code Policy; and
  • We realized we had another user whom we had not considered — market researchers. These users perform research before contracting for any solutions. Their goal is to identify existing solutions that satisfy their agency’s needs. would become an essential part of this user’s research. Market researchers would start at the homepage, using keywords to search for potential existing solutions describing their proposed project. Their searches would lead them to the Search Results page, where they would click on a project to find additional information or explore similar projects.

What we learned

Through journey mapping, we were able to identify how can better serve its users. And by better serving our users, we ensure that our nation continues to unlock the tremendous potential of the Federal Government’s software through