Who Are Our Users?
By the Code.gov team
In our last story we shared that we had been interviewing our users to better understand how people currently use — and would like to use — Code.gov, the nation’s primary platform for sharing and improving government software.
Based on those interviews we identified several user personas, which we divided into three user categories — the developers, the managers, and the policy implementers. It’s worth noting that these personas are not real people; they’re just based on a collection of real users. Each user persona has their own goals, frustrations, abilities, seniority, risk tolerance, and degree of tech savviness. And they all have different preferred methods of communication. Our personas are also fluid, so as we learn more about our users we’ll keep making adjustments.
The Code.gov team will use these personas to guide the development of our code sharing platform. As we move on to journey mapping and wireframing, we ask ourselves, how does a particular idea affect each persona? Is a certain idea in the best interest of our users? Personas help us keep our users at the forefront of our minds as we build out pages and, ultimately, a website that is easy enough to use that it propels America’s next breakthrough in innovation.
The Developers
Sally, Jessica, Brian, Mike and Omar are alike in many ways. They are all tech savvy, open source software proponents, and mid-career professionals — with the exception of Brian, who is a student. But their differences are what motivates them.
For example, Brian, our hypothetical student, is constantly trying to improve his skill set; he sees Code.gov as a bounty of source of code to explore and test.
Jessica, our hypothetical federal contractor, sometimes uses open source software but is interested in learning more about code sharing across government. She sees the Federal Source Code Policy as a big shift from how things have been done in the past.
Omar, our hypothetical private sector tech employee, wants to see a more open government. He contributes to the open source community to build a name for himself and wants to be a part of the “next big thing.” He has been disillusioned with government in the past but is now interested in seeing how he can give back. He hasn’t heard of Code.gov yet.
Then there is our hypothetical developer, Sally, a civil servant who also thinks government should be open and transparent. She wants to know what other agencies are doing, how it relates to her projects, and whether she can reuse some of their code. She typically struggles to convince her superiors of the value of open source software, but she strongly believes Code.gov can be the tool that finally convinces them.
Finally, there is Mike, our hypothetical federal data scientist. He, like Omar, wants recognition for the contributions he makes to the open source community. He represents a specialized coder — building complex algorithms to handle diverse data sets. He sees himself as a pseudo-academic and uses his open source work to build out his portfolio. He is excited about Code.gov, as it gives him a unique opportunity to show off his code contributions and concrete actions he’s taking to give back to the country through tech.
Management/Gatekeeper
Our management group is made up of those who oversee projects that could potentially be strong candidates for open source.
Paul is our hypothetical product owner at a federal agency and is tech savvy, but is no longer hands-on with day-to-day projects. His goal is to ensure his agency complies with the Federal Source Code Policy. He wants to complete his tasks in the most cost-effective way possible. But since he is not a developer, he finds the look and feel of code sharing websites like GitHub and Bitbucket a bit daunting. Although he is not yet sure how to engage with the platform effectively, Paul believes that Code.gov might provide a solution to seize the benefits of the Federal Source Code Policy on behalf of his agency.
The Policy Implementer
Our hypothetical policy implementer works with his or her colleagues across various federal agencies to push code to — and pull code from — Code.gov
Each federal agency has a liaison who is responsible for implementing the Federal Source Code Policy. These liaisons must ensure that their agency has an updated policy consistent with the Federal Source Code Policy — ensuring that new custom-developed federal source code is made broadly available for reuse across the Federal Government and that their agencies are documenting their software appropriately through their code.json files.
We have two types of agency liaisons as part of our user persona. They are extreme versions of our liaisons, who work every day towards Code.gov’s success. By making the persona’s a bit extreme, we maximize our chances of building Code.gov in a way that empowers our liaisons and eases frustrations, while also meeting their needs. Realistically, most of our liaisons will likely fall somewhere in between Doug and Neil on our user persona spectrum.
Doug is our hypothetical liaison at a large federal agency. He is determined to get his agency to fully comply with the policy, even though he needs the approval of his superiors to achieve his mission. In fact, he reports through several senior managers before reaching the Chief Information Officer. He was not aware of the Federal Source Code Policy until he was assigned the liaison position as an additional responsibility. And, while he is technical, he doesn’t necessarily have the time or expertise necessary to identify all of the repositories that need to be included on Code.gov. He is hopeful that Code.gov can provide him with some tools and resources to help with his new duties and potentially foster a community of agency liaisons to help support him through the process.
Neil is the opposite of Doug. His agency is in full compliance with the policy. He has a reputation for taking on hard projects and getting them done on time and on budget. He is the CIO’s go-to person and is highly technical, so he not only understands how to effectively release code, but he truly believes in the value of open source software. For the most part, Neil has everything he needs to be successful at his job; his only frustration is how challenging it can be to talk to other agencies about the projects they’re working on. He is excited for Code.gov to potentially facilitate cross-agency coordination and collaboration.
Each user persona hangs on the wall of our work room to remind us of our users’ needs so that we build an effective platform that addresses the true desires of our users while alleviating their frustrations. We’re working hard every single day to help the federal government unlock the potential of America’s code. It’s not easy, but it’s absolutely worth it.
(Editor’s Note: Continue reading about our design process — how we mapped the journey each user persona takes through our site).
