- Webmaster and UI Specialist (me)
- Senior PHP Developer
- Senior Java Developer
- Team Manager
- Department Director
What I did
- Product Design
What I used
My team at City Hall built more apps than we could maintain.
The two back end developers had each shipped over a dozen internal tools for a wide range of use cases, including a database of public board members, problem reports, road project management, and City Hall’s internal staff directory.
As our backlog of projects grew bigger and bigger, we needed to ship more apps in less time.
Developers often designed UI themselves, mostly printing SQL data into HTML tables.
- Visual refresh. Update the look and feel of City Hall’s internal tools without increasing the workload for the two back end developers.
- Treat all developers as equals. Make sure code samples and documentation deliver equal value to the PHP developer, and the Java developer.
Starting with a fresh coat of paint
I focused on a visual refresh of elements that were common to the apps that were already built.
Going responsive, one small opportunity at a time.
Parking enforcement officers needed to track broken meters and the work orders to repair them—right from their City-issued phones.
I seized on an opportunity to help the team do something it had never done before.
Making the pattern library themable
My team proudly makes its open source software available for other cities to use, so our UI needs to be adaptable to their branding.
Generating code samples for different tech stacks.
My team consisted of two specialists: one PHP developer, and one Java developer. The design documentation and code samples needed to be equally valuable to both of them.
Planning for growth with semantic versioning
I established a workflow with the following steps:
- Build new apps using the bleeding edge version of the pattern library.
- When a new app is ready to start user testing, ship a new release of the pattern library, and update the app to use the new release instead of the bleeding edge version.
- Use semantic versioning to communicate expectations about backward compatibility.
Outside feedback was mostly positive.
Shortly after we unveiled the new design in the Staff Directory app, one high-ranking person from another department commented: “I usually hate everything you guys do, but I like this. This is good!”
Internal reception of the pattern library was mixed.
The theme for internal tools fulfilled the goal of implementing a refreshed look and feel, without adding to the developers’ workload.
Although the initial goal was fulfilled, my goals for growing the library were unmet. The team didn’t invest in adding new patterns after the initial introduction. When gaps in the pattern library came up, developers did what they had always done: Design and implement a solution independently—without input from a design specialist, usually with an off-the-shelf jQuery plugin.
The theme for the City website helped me win buy-in for more challenging design projects.
What I learned
When getting buy-in for a design system or pattern library, lean in to the productivity benefits with the engineering manager.
Around the industry, there is a lot of talk about how hard it is for designers to get buy-in on design systems. In my case, a developer with seniority swore he would never use this pattern library, because he was offended by some implementation details. However, our team manager was onboard with the pattern library, because he and I had already agreed to a plan for using UI documentation and code patterns to help the team ship more work in fewer hours.