login.gov is the U.S. government’s first shared authentication platform


Contribution — leading long-term user experience design, service design, prototyping, research strategy and activities (user interviews, usability testing, comparative analysis, academic and desk research), product strategy, building and maintaining agency partner and stakeholder relationships.
Context — February 2016 - present, at 18F, with U.S. Digital Service. 
Details — Check out login.gov or the open-source github repository.


Project background


Hundreds of government websites require the U.S. public to log in. Many of these log in systems use old technology or outdated encryption standards. As a result, visitors often have an inconsistent, confusing, or unreliable experience simply logging in to government websites. On the agency side, each maintains their own log in system, duplicating work across the government.

login.gov is the U.S. first government mandated shared authentication platform (single sign-on system) for government websites. It’s like the commonly seen buttons that appear around the Internet, “sign in with Facebook” or “sign in with Twitter”, but for government websites. It improves visitors’ experience by allowing them to log in to multiple government agencies with the same username and password. It also increases federal efficiency and effectiveness by freeing up resources and time for government agencies to focus on their core missions — providing services and benefits to the U.S. public.

I began my journey in identity management during my work on login.gov’s predecessor, MyUSA in 2015. When it was announced that login.gov would be the one and only government supported and funded identity management project, I requested to join the team.

I have been a key designer and researcher on login.gov, shaping its product strategy since inception. I’ve developed deep domain knowledge and intuition about the unique usability, privacy and security challenges a single sign-on solution poses for users and our partner government agencies.

Explore a few links:
login.gov open-source github repository
Blog post — Building a modern shared authentication platform
Blog post —  Government launches login.gov to simplify access to public services

Building login.gov in post-Snowden U.S. means we work tirelessly to protect people’s privacy and uphold security standards


Just within the last 5 years, the U.S. public has experienced Snowden’s revelations about the National Security Agency and global surveillance, the Office of Personnel Management data breach, and most recently the Equifax data breach. The U.S. public’s perception of privacy, security and online data has been shocked into overdrive, make many folks extremely anxious and privacy conscious, and other folks complacent  — assuming that the government already has all their data and there is no privacy left to keep. People have many conflicting feelings about trust, safety and convenience.

Under these circumstances, login.gov is 18F’s most high profile, high risk, high pressure project. As a team, we care deeply about the U.S. public’s privacy. We care about meeting and exceeding security standards. We also want login.gov to be an easy (as possible) gateway to people’s government benefits.

During our last team offsite, we drafted our strategic pillars to keep us grounded in our values as we make difficult choices and decisions:
  • Help agencies focus on their core missions, not identity — login.gov should not get in the way of people’s ultimate goal of reaching their agency, save taxpayer dollars, be a trustworthy partner to agencies as they integrate with login.gov. We do the work so agencies don’t have to.
  • Lower barriers to accessing government services for the public — Decrease the friction for people who currently do use government services online, and make it possible for people who are currently unable to do so. 
  • Protect users’ security and privacy — Be stringent about security and privacy practices at every moment of the login.gov experience. 
  • Drive accountability and transparency — Help improve public trust in government by being open source, sharing our process with the public and agency partners early and often, publicly abide by security and privacy standards.


Discovery: testing different identity management models to learn what works for the U.S. public


Identity management (a quick definition) — An “identity” is a group of attributes that describes a unique, single entity within a set of records. For engineering purposes, an “identity” has nothing to do with how people describe themselves. It is how a system can be sure that someone isn’t pretending to be you.

Identity management has three components:

And, identity proofing relies on record matching:

There have been numerous identity management efforts within the U.S. including MyUSA, Connect.gov. There are also a variety of other similar efforts in other countries. Our team studied the service architectures of ten other countries, including the vastly different systems of GOV.UK’s Verify, Canada's My Account, and Denmark's NemID. 

Mapping out the beginning-to-end process of how one applies for, receives, activates, uses, and renews their account helped us become familiar with what works for different cultures and environments, and to question and hypothesize with what could work in the U.S.

As an example, below is the life-cycle of NemID:

Discovery activity 1 — Watching representative users try prototypes 

I put together clickable prototypes that mimicked the three drastically different systems, and we tested them in a span of 2 weeks in 3 states. Our goal was to 1) experiment with models that are already present in the world, and 2)understand how the U.S. public respond to these models.
  • Unified — a single service provider by a government agency (based on Denmark’s NemID).
  • Federated — a broker links users to multiple service providers, commercial or private (based on UK’s Verify).
  • Split — users verify their identity with the government (this this case, IRS) but have a choice of sign-in providers, government or bank/financial. (based on Canada’s My Account)

Discovery activity 2 — A literature review; we compared our results to previous studies and other data sources:
  • Academic and corporate research
  • Qualitative design research for related government projects: library patrons (Federal Front Door), veterans (VA), small business owners and federal employees (MyUSA)
  • Usage data for Connect.gov and UK Verify
  • Surveys and other mass opinion measurements

At a high level, we learned that participants saw the need for identity proofing. However, security worries and pervasive misunderstandings about federated identity management led to discomfort and confusion in choosing a provider and entering sensitive data. For those already wary of online interactions, that discomfort fed anxiety and sometimes prompted abandonment. A couple of specific findings:
  • Brand associations matter as much as demographic coverage. Where possible, participants continued an existing trusted relationship. If familiar brands didn’t make sense, participants hunted for clues.
  • We need to give choices for out-of-browser interactions, whether it be via phone, mail, in person, or a host of other options, to make sure the system is accessible to as many people as possible.
  • Signal security in multiple ways. Participants needed to see signs of security to feel safe.


Making artifacts to help build team consensus and design the first version of login.gov 


With the discovery research grounding us, the entire team went to work. The back-end developers and devops teams began building the base architecture in a way that lives up to NIST’s security and privacy standards. Starting from the U.S. Web Design Standards, our visual designer began branding exercises and front-end developers began building out the basic user flow.

The user experience and research team (myself and another colleague) began to draw the user flow in a mural (an online whiteboarding application). The user flow includes each screen, or a placeholder, the various options a user has at each point, what user data is being collected, what and where it is being transferred — and most importantly, at this point, the technical and user experience-related questions we had to bring the team to consensus. 

This user flow, over time, became a tool for conversation amongst the team, a thing to reference when asking questions, or to confirm a point. It also became an artifact that we regularly shared with NIST and other security and privacy organizations when sharing our progress and discussing challenges.


A couple of details:


Our building of this iteratively-changing user flow inspired many questions. We took to github to get the right people involved to resolve them, and updated the user flow to reflect the decision made. Below is a snapshot of our discussions: how a user could recover their account if they didn’t have what they needed to log in, the types of two-factor authentication we might integrate into login.gov, and lots of discussion around the various identity verification options that are open to us. 

Based on the user flow and discussions, I created the first beginning-to-end wireframes, which we iteratively, over time, adjusted, improved and refined as we had discussions and conducted usability testing.


Getting creative with research and tracking long-term usability issues

Usability testing in public areas

We did usability testing every few sprints. Some with participants found through research recruiting firms, and others were people in our extended communities. But the majority of our research participants were found through a research recruiting method called intercept testing — we asked people walking in or waiting in the public lobby areas of government buildings to try out our login.gov prototype and share their opinions and feelings. We chose to go to public government buildings because it was not a stretch for them to imagine that they might come across login.gov while trying to accomplish a government-related task — they were in this government building to do the same.

login.gov happened to be the first project team at 18F to conduct many of these types of sessions. Following the culture of learning and sharing at 18F, we wrote a guide for intercept testing for other project teams to use.

One of my sessions was with 18F’s first intern, who joined me for a full day of learning how to interview for usability testing and take notes.



Keeping track of usability issues over time

For every round of research, we narrow our focus to learn about specific parts of the login.gov user. But the high-level research questions continue to revolve around three concepts: comprehension, capability and comfort:
  • Comprehension — Do people understand what’s happening, the choices they’re making, and what they would do next? 
  • Comfort — Are people okay with the information we’re asking them to give? Do they feel safe? Do they trust that they’re interacting with a legitimate entity and that their data is protected?
  • Capability — Can people get through the flow? If they lose track, can they get back? Where are they getting confused? Where is it inconvenient? Where does it require resources they may not possess?

After experimenting a few ways of documenting insights that came out of usability testing sessions, I realized that we needed to be easily see if we are tangibly improving the user experience of login.gov over time. I started using Google Sheets to document research observations, overall severity of the usability problems, participant quotes and recommendations (or further questions the research inspired).

Documenting results from each research sprint in a new tab in the same Google Sheet, and color coding the severity ratings were key for us to quickly glance at which parts of the user flow were improving over time, and which parts remained to be problematic for users. Tracking research findings in this way also helped us prioritize our UX, content and visual design work for the following sprints.


I led facilitated interview synthesis processes with other login.gov  teammates, so that they had a closer view into the research process, and observe first-hand what our users were saying and feeling.

Facilitated interview synthesis in a mural (online whiteboard)

The benefit of seeing all of the participant quotes and observations under specific parts of the user flow, such as Personal Key, Failure to proof, or transition from login.gov to agency, helps us find patterns of difficulty or success in the user experience. When patterns had been established, I made recommendations for changes and improvements in our UX, content and visual design strategy — sometimes solo, other times with the collaboration with teammates.


I also post the recommendations in github, where all the other work was taking place. We may use completely different processes in the future to track research long-term usability issues. The process must meet one requirement: research should live in the same place (or as close as possible) to where the other design and development work takes place, so that as many teammates as possible are either directly involved in research activities or see the results of it. 


Where we are now — getting feedback from real users & making login.gov accessible for more people with more strategic research


We have a lot of moving parts on this project. It’s one of the larger project teams at 18F with 25 people, and 3 scrum teams:
  • End user — design and development teams working on the login.gov platform. I’m part of this team.
  • Agency integration — folks, mostly based in Washington D.C., working with government agencies to understand their user and technical needs. I collaborate with this team and our agency partners often.
  • DevOps — development team working on scale and reliability strategy

We are beginning to go live with several government agencies (CBP Jobs, Global Entry, and a few others I’m very proud to be working with).

We are receiving lots of rich feedback from users reaching out via our call center in Florida and the help email address. We know that login.gov’s security standards are quite high (including requiring two-factor authentication at every sign in, or a financial record in order to verify your identity) and will be prohibitive for many of our agency partners’ customers (low literacy and low tech literacy, low income and/or access to traditional financial organizations). The feedback we are getting confirms that, and we are actively addressing this challenge to improve login.gov’s accessibility.

Acknowledging that a small design and research team of 3 people can’t do everything all at once, I am leading the processes of expanding our ability research with strategic partnerships with external research groups. I also work with our agency partners to communicate the user experience of login.gov, respond to their concerns and questions, and plan and conduct collaborative research sprints together with them.

I’ll leave you with a few screenshots of login.gov as it is today: