The City of Boston
Creating an organized and integrated repository for design and development resources, brand guidelines, and more for the City of Boston.
The Challenge
After partnering with IDEO in 2016 to rebrand the main digital interface, Boston.gov, the City of Boston had not only a new aesthetic, but a commitment to web accessibility and an interest in streamlining design to development processes.
This led to the creation of Fleet, the patterns library that UI developers use to build content. While the developers are happy with Fleet, designers wanted the ability to add designs and layouts to a central library, and adding new patterns to Fleet is tedious.
How can we create a system where developers can easily access design assets and brand guidelines, and designers can easily add new components and styles?
The solution: a design system.
Role
I set up the design system framework in ZeroHeight. I also created several components for the design system. Finally, I worked on usability testing with another UX designer.
Timeline
10 weeks
Context
I was a UX and product fellow on the City’s Digital Team, a division of the Department of Innovation and Technology. I worked directly with two UX designers, developers, and the City’s director of design.
Tools
Adobe XD, Airtable, Notion, ZeroHeight
Evolution of Boston.gov
Home page from December 27, 2015
Home page from October 4, 2021
Above are images of the Boston.gov home page: in 2015, a year before the redesign with IDEO, and in 2021, five years after the redesign. The components used in the current page came from Fleet—the patterns library—which is hard for designers to update and manage. This is one of the biggest reasons why the Digital Team decided to create a design system.
Sample of the colors from the City of Boston design file.
Design Goals
We needed to create an open source design system that:
defined principles and guidlines,
served as a home for all design and development resources,
and a collaborative component library.
The goal was to improve design to development hand-off by building a component library with specifications. This design system would be used by designers, developers, and external partners.
The design team selected ZeroHeight as the platform for the design system.
Comparative Analysis
I looked to other municipalities with established design systems for inspiration and guidance when building the City of Boston’s design system in ZeroHeight. They were helpful for figuring out how to structure the content I was combing through from the multiple sources at the City of Boston, how to talk about a brand, and they gave me ideas for navigation and categorization.
Planning
Our external partners built a master file that served as a starting point for building the component library in ZeroHeight.
I also gathered assets from several other sources to pull into the design system, including:
brand guidelines,
the writing guide,
iconography, and photography.
I began with listing out all sources of information that needed to be cataloged in ZeroHeight.
I kept my process organized with handwritten notes. Since I was mainly working alone these didn’t need to be shared with the team, but when I began working with another UX designer, I moved my notes into Notion so we could monitor progress together.
Assembling Assets
ZeroHeight was chosen because its interface is user friendly, making it easy to build and maintain. It also syncs directly with Adobe XD, the software that the City uses for its design files, making it seamless to upload new components quickly.
I worked with one other designer on this project, and I managed the main City of Boston design file, pictured here. These are some of the assets and components from the file I worked from.
This is the Adobe XD file I worked from, which contained almost all of the main City of Boston components (it contains assets for desktop, tablet, and mobile devices). These assets were created by an outside design agency, but I and other designers created components to fill in gaps that existed in the file that we found as we worked through it. I also prioritized standardizing the naming conventions in this file to make components easier to find and more organized once they were uploaded to ZeroHeight.
Building the Design System
The City of Boston design system will be an ongoing project for the Digital Team.
Video Demo
I made this demo of the design system as part of a presentation I gave to the City of Boston’s Department of Innovation and Technology virtually in August 2021, as we were wrapping up the project.
Screens
Landing Page
This is the first page users will see when they go to the design system. It contains links to the patterns library and brand guidelines, and other relevant links about the City of Boston’s brand.
Welcome Page
This page explains why we created the system, contains the same relevant links from the landing page, and the side navigation houses our support page, which teaches users how to best use the design system.
Style Guide
The design system is organized into two categories: the component library, which contains design assets, and the style guide, which includes brand resources for typography, colors, logos and seals, photography, iconography, and illustrations. This page is from the colors page, where users can click on the color codes to directly copy them from ZeroHeight.
Component Library
The component library is the bread and butter of the design system—it houses components from 3 different City of Boston design “sub-systems”, and I worked with another designer to consolidate and standardize these systems in Adobe XD before uploading everything to ZeroHeight. After everything was uploaded, I created the organizational structure for the component library.
This is a page from the Component Library (Iconography). Designers or developers can download assets (.PNG or .SVG files) directly from ZeroHeight.
Using the Design System
Downloading Assets
This is what users see when they click on an asset in the component library. They will be able to download a 1x or 4x .PNG file or .SVG file, view version history, and a few basic attributes.
ZeroHeight does have Storybook integration, but the City opted not to use it. The City’s developers use the files that the design team creates to build what will go on all digital platforms, so this integration was not necessary. Having the components built and in one place is meant to make the designers’ jobs easier, more so than developers.
Addressing Challenges
I encountered some challenges throughout the process:
Some assets were incomplete (e.g. no hover state for all sizes) and needed to be created.
Some components needed to be rebuilt in XD in order to be compatible with ZeroHeight.
Design file needed to be debugged.
Sorting out these issues inspired me draft the support guide for the design system, which contains best practices for uploading assets to ZeroHeight, naming conventions, and other procedures for keeping the system organized.
Many of these issues brought up bigger questions about strategy, and how the team wants to use the design system in their work.
I kept my process organized with handwritten notes.
Support Guide
After building the design system, I wrote a best practices guide so that when I left the team there would be a record of how the system was built and how designers and developers could best manage it moving forward. It includes information about uploading assets, creating components and artboards, and naming conventions.
Best Practices for Using the Design System
The support page is intended for designers and developers at the City of Boston, as well as contractors and vendors working on City projects. I included:
The naming conventions page from the support guide
General best practices. Once in ZeroHeight, team members can only access the components and artboards uploaded from the file, not the file itself; so it's important to save uploaded design files in the City of Boston Google Drive (linked in ZeroHeight).
Uploading assets. I wrote instructions for using the ZeroHeight plugin in XD, marking components and artboards for export in XD, which file types to export, renaming your file, and managing files in ZeroHeight.
Components vs. artboards. ZeroHeight can only show default states of components, so I and the designer I worked with turned all the components into individual artboards so all variants (hover state, clicked state, multiple layouts, etc.) would be visible in ZeroHeight.
Naming conventions. I devised a simple guideline for naming components that designers can follow for adding new components.
Usability Testing
We sent out a survey to the Digital Team via Slack.
After the design system was built, we wanted to test it with the designers and developers who would be using it most.
We designed a survey with Likert scale questions, and were able to get responses from 4 team members.
Our initial feedback showed:
It’s easy to use. 3 out of 4 felt the system was easy to use and didn’t require prior knowledge.
It’s well organized. No one found it unnecessarily complex, and no one found inconsistencies within the system.
People are excited to use it. 3 out of 4 would use it frequently for projects they work on.
More training might be required. No one was confident in their ability to add design assets to the system, so the team might need to provide training in addition to the support guide.
The Design System in Practice
After establishing the design system in ZeroHeight, the City’s digital presence has a higher level of design maturity. In just a few months, it’s already being used by members of the Digital Team in different capacities:
Designers use it as a reference for working on new projects. They also keep it up to date by updating and adding new components, which is especially important as the City prepares for a new mayoral administration.
Developers use it to check specs on the website, including colors, fonts, text styles, and other components (e.g. cards, drawers, navigation).
Content strategists frequently use the quick access links from the design system when crafting new content for the City, like the writing guide, the Fleet pattern library, and the language and communications guide.
Reflections 🧠
Before this project, the City didn’t have a design system in place—and although this was intended to be a resource primarily for designers and developers, it has already been used by the whole the Digital Team.
Everyone on the team is part of contributing to the brand voice and design with each digital deliverable, and the design system helps the team do this.
The City of Boston design system is a work in progress that will be continuously managed by the Digital Team at the City of Boston.
Overall, the process to build the design system was relatively seamless, but this was because of the hard work the City had already done to refine their brand and patterns library, and the fact that I was working with components and guidelines that were already built. We were not working from scratch to build the components, brand, and creating the structure for the design system library.
Keeping every aspect of the process organized, from working with clean files to standardizing naming conventions, significantly helped keep this project running smoothly.
Recording everything and keeping track of the process of building the system itself was equally as important—as a temporary member of the team, it was important to catalog the decisions I was making and the processes I was using to build the system to ensure that the design system would be usable for everyone who worked on the team.