Designing UI Patterns for Government
How we’re building web design standards at the City of Austin
As the UI Design Lead for the Design, Technology and Innovation Fellows at the City of Austin, I’m focused on how we can create and define web design standards for the City.
The City’s current site was designed and developed nearly eight years ago. User interface patterns and best practices have changed dramatically since then, and users are accessing government information through an increasingly diverse range of devices and languages.
Taking inspiration from recent government efforts like the City of Boston’s site redesign and 18F’s U.S. Web Design Standards, our goal is to create an accessible, responsive, and robust set of standards that make it easier for the public to use the City’s sites.
Part of a bigger exploration
Just updating the UI for the City of Austin’s site would improve the overall experience, but we understand that’s not enough. Several other Fellows’ projects are deeply engaged in work to research and prototype new digital services strategies. The outcomes from these projects will ultimately inform the platform(s) the City’s sites will be built on and the components we’ll need to account for in the standards.
Starting small
While that research is ongoing, we’ve looked for opportunities to begin incrementally building core components for the City of Austin Web Design Standards. We’ve identified projects outside of the main austintexas.gov site where we can iterate within a more focused scope across different use cases.
These projects allow us the freedom to adapt and refine design patterns in self-contained sites. This bottom-up approach to designing the standards means they should be well-tested and proven by the time they are eventually applied to austintexas.gov. With a nimble team (1 designer and 1 front-end developer), we’re exploring creating fresh, responsive, and accessible components.
We’re currently wrapping up a project with the Department of Development Services to improve the residential permitting process. One of the deliverables from this project is a beta site guiding residents through permitting some of Austin’s most common projects. Since the site didn’t previously exist and it’s supplemental to DSD’s main site, we had a lot of freedom to push out in new directions.
Re-use when possible
When starting design and development for the permitting site, we looked for existing systems we could use or adapt to get us up and running quickly. Using and creating open source libraries and components is crucial for designing for government—it’s more efficient and offers greater transparency into the process.
We started with the USWDS as our base and began customizing from there. One thing we noticed early on was that the grid wasn’t really meeting our needs, so we swapped it out with Flexbox instead. For icons, we primarily borrowed from the extensive Font Awesome library.
This saved us time (and taxpayer dollars) by not recreating commonly used icons like map markers, arrows, etc. We’re also implementing Google Fonts for free, fast-loading fonts.
Make it last
In addition to re-using where possible, we also had to strike a careful balance between being modern without being too trendy. Government sites can go for years (even pushing a decade) without being refreshed. UI for government needs to last.
We want the City’s design standards to be simple, clean, and have a clear hierarchy that makes it easy for users and content editors to navigate through a site. Because there are many editors/content maintainers updating the site, the use cases for components need to be logical and clearly articulated in order to maintain consistency.
Information for all
Accessibility also guides UI and development decisions and they often affect each other. For example, in our Applications & Forms section, users can download a specific document. It’s clear in the UI that the “Download” button refers to the title it’s near, but a person using a screen reader wouldn’t have that context.
We explored what it would look to have the buttons read “Download [form name]” but many of the documents had long titles (“Request to Rely on Applicant Certifications of Compliance for Single-Family Development — New Construction or Addition”) and created absurdly wide buttons that still truncated. The UI decision to have the buttons read “Download” meant that on the developer side we would need to ensure the ARIA tags for each button specifically called out what the user was downloading.
Accessibility also includes language access. The City is actively working to make its services available across more languages. On the permitting project, we implemented Google Translate and targeted the main languages spoken in Austin. There are pros and cons to using an automated translation service, and we’re using this project as an opportunity to test with the public.
Designing across different languages brings up unique challenges. Words expand or contract based on the language, and defining components that are able to flex under these conditions is crucial to maintaining a consistent experience for all members of the public.
Next steps
My next exploration is the UI re-design for ATXfloods—a web app that alerts users to low-water crossings. Research and UX re-design efforts are already well under way.
While ATXfloods will inherit some of the core elements established in the permitting project, it will have its own specific, software needs. It’ll be a great direction to push the standards — discovering what needs to be added, what breaks, and what sticks.
If this sounds interesting, we’re hiring! We have open positions for Senior UI designers, Senior UX designers, developers, and more.
