Federalist

Federalist was conceived as an answer to the arduous and expensive process federal government agencies face when creating simple, content driven websites. As a static website generator, it utilized technologies familiar to modern website developers but not necessarily familiar to content creators and website owners. To scale Federalist into a successful product required testing our assumptions about our target customers, and validating the market need.

It was the smallest team I have ever worked with: two developers, a visual designer and myself. This allowed us to have informal roles and work fluidly. I shared the product manager responsibilities with the developer who initially conceived the project, and served as strategist , user research lead, and UX designer.

User Research Goals

  • Understand the context and needs of government website managers
  • Inform product-market fit and product roadmap
  • Test assumptions about the technical skill level of potential users

Approach

We needed to talk to real people who were creating new government websites and people managing government websites with primarily static content. To do this, we recruited federal employees to participate in an interview and prototype usability test. These were performed both remote and in-person.

With the team being small and distributed nationally, I trained two team members in research observation, note-taking, and basic facilitation. We created a structured system for data gathering which expedited synthesis.

Key Insights

The driver to test a prototype was a long disagreement about the technical capacity of the customer base and their willingness to learn git and markdown. It turned out that not only did the majority of participants not have these skills, they were already beyond their workload capacity and simply would not have the time to become proficient.

The current options available for creating and maintaining government websites on wordpress and drupal was expensive and sloooowwwww. Security requirements created a centralized infrastructure through which a single text change request could take six months to execute. The participants simply could not update their websites in a frequent or timely way.

The primary job focus of most website owners was not communication or technology related. Managing their websites often fell into their responsibilities because of their proximity to the content.

Solutions

I designed an editor which included a markdown generator, workflow, and navigation builder. We also worked with the Social and Behavioral Sciences Team to develop a set of templates designed for government website content.

Having validated the market need, we secured funding for our product roadmap, and adding a visual designer to the team. After maturing the product, it currently serves:

  • 134 production .gov sites
  • 9 federal agencies
  • 65+ million visitors per year
  • 400+ prototypes developed
  • 639+ updates per week