Civic platformsCase study
Search.gov.
Rethinking the search engine behind thousands of federal websites, for the agencies who run it and the public who use it.
Back to all work
- Role
- Product and UX lead
- Where
- GSA, Technology Transformation Services
- Scale
- Search for more than 2,000 federal websites
- Projected savings
- About $600K a year
The problem
A shared service had grown features nobody used.
Search.gov powers search across federal websites, but over the years it had piled up outdated, underused, and redundant features. The admin console agencies used every day was inefficient, and the platform wasn’t keeping pace with how federal digital infrastructure was changing. Years of patches had made it hard to ship and expensive to run, which raised a real question about long-term sustainability.
How I approached it
- 01Map everything the console doesI catalogued every action an agency can take in the admin console, alongside the open product questions each one raised.
- 02Talk to the agenciesGenerative conversations with three groups of agency partners, high impact service providers, small agencies, and large agencies, recruited through Slack communities, email, and agency newsletters.
- 03Find what’s worth keepingQuantitative and qualitative evidence, plus a card sort, to separate the valuable features from the underused ones and the ones ready to sunset.
- 04Turn it into a planA product vision, goals, and a roadmap covering budget, team structure, resources, and requirements, with a communications plan and a risk plan to carry it.
What I owned
Product management and UX, together.
- Admin and public UX
- Feature sunsetting
- Cloud.gov migration
- Jemison rebuild
- Product vision and roadmap
- Stakeholder communications
- Risk management
- Agile facilitation
Research
Conversations, not task tests
I designed the research to be conversational rather than task-based, so agencies would tell us how their work actually goes: what they do every day, which panels they rely on, where they get lost, and what they never touch.
Two audiences
Built for agencies and for the public
Search.gov has two very different users. Agency teams use the admin console to set up, tune, and brand search for their websites, and the public uses the results pages those teams publish. I had been an agency customer of Search.gov myself on other federal products, so I knew the console from the customer side before I joined the team.
For agencies, I worked on the UX and UI of the admin platform: making it easier to use, and making it easier to brand results pages so search looks like the agency’s own website. For the public, I worked on the UX and UI of the search experience itself.
Website plan
What makes government search different
I wrote the Search.gov website plan: its purpose, its goals, and the case for agencies to move from hosted results pages to Search.gov’s API and embeddable snippets. It started from how people search government sites, which isn’t how they search the web.
- Mission-drivenPeople look for official information, services, and rules, not shopping or entertainment.
- Task-orientedMany searches are a step in getting something done, like applying for benefits.
- High trustSearchers expect authoritative, accurate answers from .gov sources.
- Urgent and specificDisaster help or a tax deadline can’t wait for a vague result.
- Many languages and needsQueries come in many languages and from people using assistive technology.
The rebuild
Jemison, a search engine rebuilt from the ground up
I partnered with the lead engineer on Jemison, an open-source prototype for a simpler, faster Search.gov, named for Mae Jemison, the first African American woman to travel into space. Together we made the case for a guided transition from the old platform to the new one.
- About 1/15 the codeRoughly 4,000 lines, down from more than 70,000.
- About 90% lower running costsInfrastructure from roughly $900K a year to under $100K.
- Nearly 3x the capacityAbout 50,000 queries a minute, up from 18,000.
Partners
Keeping agencies with us through the change
A rebuild means partners lose some features for a while, and they had already lived through an unreliable service. I co-led the relationship side of the transition plan: being honest with agencies about what went wrong and why, sharing what the new system would and wouldn’t do at launch, inviting early adopters, giving each partner a UX contact, and checking in on a regular schedule.
Risk
A risk plan for the move
I wrote the risk management plan for the transition. It covers technical, security, operational, compliance, vendor, budget, and user risks, each scored by likelihood and impact, with a mitigation, a contingency, and an owner. A separate section covers the API that agencies build on, and the user risks commit the team to WCAG 2.2 and testing with diverse groups.
Less to maintain, more that works.
What it set up
Recommending which features to sunset, based on what agencies told us, put the platform on track to save about $600K a year. I designed and co-documented the move to Cloud.gov, including the workflows and system transitions, and handed the team a roadmap, a communications plan, and a risk plan to carry it forward. Jemison set the path to a search engine with a government-owned index, at a fraction of the cost to run.