Teaching an Old Dog New Tricks: Revamping Legacy Web Products

Integrating UX into Web Product Redesigns Using Cloud-Based Platforms

How one product team ensured a new version of an old tool can better help the federal government track funding outcomes for child care programs.

Childcare center with caregivers and children

The Office of Child Care (OCC), part of the U.S. Department of Health and Human Services, supports American families by helping provide access to affordable, high-quality early care and afterschool programs. In doing so, OCC administers the Child Care Development Fund (CCDF), which provides about $8 billion each year to states, territories, and tribes to provide support to children and families in finding childcare programs that will fit their needs and prepare children to succeed in school.

Ensuring good stewardship of CCDF funding to grantees is also part of OCC’s mission. Therefore, OCC also funds technical assistance (TA) programs that enable TA specialists to help states meet federal requirements and use funds effectively with positive impacts for families. The TA provided is tracked in a web-based system called the TA Tracker, or TAT.

Users of TAT include federal leaders, experts providing TA oversight, and TA specialists, all of whom have had evolving user needs since the original system was built in early 2012. Furthermore, government requirements for security and other types of digital compliance have also changed. The new operating environment demanded the old TAT be rebuilt in technology that was more compliant, had a lower technical maintenance burden, and that better served user needs, saving people time and making oversight more efficient.

A team of government contractors at ICF — a global advisory and digital services provider —  supported OCC in the new system build. They used a human-centered design (HCD) approach to effectively update the technology, serve users better, and provide the government with enhanced reporting dashboards.

HCD focus puts user needs ahead of technology decisions

Before ever considering the technology stack, the product team took an HCD-first approach by recommending primary research about the legacy tool’s workflows, pain points and gaps, as well as overall user needs for the new system. A series of user interviews helped the team write detailed user stories, descriptions, and design guidelines, backed by representative user quotes to help articulate concepts to government stakeholders.

The user stories matrix the team created covered system architecture, content, design, reporting, workflow and governance requirements. And it helped the UX team create as-is vs. to-be user flow maps that were crucial in evaluating an appropriate technology solution. Users, especially TA specialists making day-to-day entries in the system, expressed plenty of frustrations with the legacy tool, such as, “We’ve gotten to the point where we have too many fields, and the tool is too confusing and too much work to use.” Another user stated, “We have to get in touch with an admin regularly to get things deleted from the system because people accidentally enter incorrect data.”

These insights allowed the UX team to write many initial user stories that could help with an analysis of alternatives that would ensure the eventual new platform was capable of meeting user needs. Examples include:

  • As a user, I need to be able to understand user interface elements and field descriptions so I can make correct entries.
  • As a user, I need editing permissions for my own entries so I can fix minor mistakes faster without involving an admin.
  • As a user, I need a space to work on drafts without it being visible to others so I can document progress without it getting pulled into an official report.
  • As a user, I need my commonly used tasks and entries to display when I log in so I can make the most of my time within the tool.
  • As a user, I need to be alerted by the system when there are actions to be completed on an entry so I can ensure data is up-to-date for reporting.

Using the resulting requirements documentation from the user research period, the team conducted a technical analysis of several approaches and determined that a cloud-based, low-code, commercial-off-the-shelf (COTS) platform like ServiceNow would best fit the requirements of the new tool while allowing for optimal flexibility, speed to launch, and cost. However, the use of a COTS product did put certain guardrails on how the team would approach design and ensure compliance with the agency’s digital toolbox (itself based on the  U.S. Web Design System’s user interface components).

Building a user-friendly COTS experience driven by content strategy and UX design principles

Structured content design is an important part of the content strategy for any web product, and a COTS tool made that even more apparent because of the form-based nature of the data being collected in each TA entry. As a content strategist analyzed the taxonomy used in the legacy tool, it became apparent that there was a significant amount of taxonomy bloat — many tags and form field options were duplicative or hadn’t been used more than a handful of times. Through card sorting and testing with users, the content strategist was able to architect a more logical, user-friendly, and streamlined taxonomy and content specifications for how form fields, tags, and other data points in the system should be connected. Especially because of COVID-19, the team identified more than 900 TA entries tagged “other,” which did not allow OCC the ability to report descriptively about the TA delivered under those records. Now, with new governance in place, managers are alerted to assign a more appropriate tag anytime “other” is selected (or create an appropriate new tag in the case of special cases such as COVID-19). Any tags not used in a six-month period automatically trigger a review by managers to see if they should be made inactive.

The updated content specifications helped the development team understand how to configure the COTS tool and feed data into TA records, dashboards, and reports. And it helped the UX designer quickly understand what content types and attributes the user interface (UI) needed to be able to support at each step in the workflow. Thanks to the existing pattern library the UX team had already created for OCC, the designer was able to use the COTS platform’s built-in UI customization features to ensure components matched up as closely as possible in terms of appearance and interactivity. User testing then validated the team’s approach prior to launch.

Rebuilding TAT took the team only nine months, thanks to the groundwork laid by starting with analytics data and user insights regarding the legacy tool and using that information to strategically plan a user-centered design approach and define the right technology mix. TAT’s speed to launch was further made possible by having clearly structured content and design components to inform the development process, which itself was accelerated by using ServiceNow. A COTS solution won’t be right for every situation, but the team learned that by combining the power of UX research and design with the foundational functionality of the low-code tool, many legacy applications can be redesigned to quickly meet new requirements and better address more user needs than ever before.

The design process for revamping legacy web products

When UX teams are engaged by product owners about replacing legacy IT systems with a newly designed COTS system, they can follow these steps that the TAT team found key to success:

  1. Use analytics: Analytics from the legacy tool help to identify representative users and understand behavior patterns and user flows.
  2. Interview users: Research the workflow, what problems the system does and doesn’t solve for them, what changes would make their jobs easier, which features cause them frustration, and how well they understand functionalities and UI labels.
  3. Map the as-is state vs. the to-be state: Validate the workflows and pain points and illustrate the existing system juxtaposed to the ideal state to find gaps and pinpoint potential efficiencies.
  4. Develop user stories and a requirements matrix: Segment stories and related requirements, descriptions and representative user quotes into categories that make sense to the different project workstreams (e.g., system architecture, data entry, reporting).
  5. Conduct a technology evaluation: Review many platforms and technology stacks to decide which solution will best serve the organization and end users by mapping features to functional requirements (a spreadsheet works).
  6. Document content types and attributes needed to support workflows: This will vary by system, but getting the structure right from the start will help designers and developers ensure the right pieces of content and data are connected to achieve desired outcomes.
  7. Document design patterns: Having UI components in a pattern library will speed time to deployment and ensure a consistent experience throughout the life of the system.
  8. Document necessary reports and dashboards: Knowing what data points must feed into reports and dashboards will help ensure the design process accounts for input of that information by end users.
  9. Prototype and stage the system: The great part about COTS platforms is that you can quickly make adjustments to the out-of-the-box tool to have a working prototype that’s staged and interactive for testing purposes.
  10. Conduct usability testing: As with any design project, the team needs to identify areas for improvement prior to launch by observing users as they attempt to complete high-priority tasks using the prototype.
  11. Implement version 1.0 changes and launch the product: Produce the working tool, and be sure analytics are integrated into the system to enable continuous improvement through the synthesis of metrics data (and user feedback) that will inform the product backlog for future releases.