The problem

At PENSCO Trust Company, a financial services company, we were rebuilding and modernizing a number of internal applications as part of an initiative to improve the customer experience. Each legacy application had vastly different UIs and workflows—an employee pain—and as the only designer on the team, I became a bottleneck since I needed to go through the full design and UI development process for each one, creating new wireframes, prototypes, mockups, HTML, and CSS.

The solution

A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
Invision, “A comprehensive guide to design systems"

Learning about how other companies implemented design systems was a game-changer. Assembling existing design components would be much more efficient for both design and development, and having a consistent experience across applications would make employees’ jobs easier.

While keeping releases on track was my first priority, I took an incremental approach to creating our design system, building and rolling out pieces over several months.

A new UI design

New UI theme
The new color palettes and header designs in Sketch

I started with planning out a simple visual theme that would work across a suite of internal applications, from colors and fonts to buttons and menus. Since we already used Bootstrap as a base for our UI, I drew heavily from Bootstrap elements to simplify the build.

I then created a set of page layouts that followed consistent rules of structure and organization so that users could quickly find what they were looking for. Designing new pages was faster when I could start from a template.

A Sketch Library

Sketch Symbol Library
A section of the Sketch Symbol Library

Once I started designing with the new elements in Sketch, I realized that I would need to create a Sketch Library to simplify the tedious process of manually editing and recreating the designs for each app.

Once I had set up all of the Symbols and the Library, I could create new page designs by simply dropping in the appropriate Symbols. If I updated anything in the master Library, the changes would automatically propagate to the other files, saving me a lot of time.

A central CSS repository

CSS library
An SCSS file in the CSS library

With the visual designs created, I began to build out the new UI in HTML and CSS for one of our apps. I wanted to avoid the eventual headache of trying to maintain duplicate CSS in each app’s separate codebase, so with some dev help, I set up a new repo for a central CSS library referenced by all of the apps.

A pattern library and style guide

Fractal pattern library
A page of the pattern library built with Fractal

With the CSS centralized, the other part of reducing UI code churn was templatizing the HTML. I started a pattern library to document and provide guidelines for implementation of the new UI components, giving the devs HTML code snippets that matched the mockups they were given.

I built it with a documentation framework called Fractal so that it would be quick and easy to update. Modular and easy to set up, it also referenced my CSS library so style updates propagated automatically.

After including guidelines on copy and overall usability as well, I presented the documentation to the team as the last piece of the design system.

The Results

Once the design system was fully in place, we saw improvements in many aspects of our design-development workflow.

More time for UX

Since I needed less time to create mockups and code, I could spend more time doing UX work ahead of the dev sprint cycle: conducting user interviews, charting user paths, wireframing, prototyping, and working with the product team on details for app functionality.

High-fidelity mockups were also easier for people to understand than wireframes, so creating those quickly accelerated the feedback process.

Faster visual design

Designing a new UI went from taking days to hours since I no longer had to start from scratch. The guidelines also made it easier to create new design elements.

More efficient front-end development

Faster mockups meant it was easier to incorporate dev feedback in the UI design process. Devs could also pull HTML from the pattern library and focus instead on functionality. This all heavily reduced code churn.

Positive user feedback

After we released the first app with the new design, initial user feedback was positive—they were pleased with the functionality and new UI. More research is needed, however, once multiple apps have been released to see the UX benefits across all applications.

The Learnings

A design system is not one-size-fits-all

Many organizations use design systems to keep UI design consistent across teams, so they focus on the UI design components. As the only designer, however, I quickly realized that I would need a broader implementation that also simplified the development workflow, otherwise I would only have created extra work for myself. Different situations need different solutions.

Better early than late, but better late than never

In an ideal world, I would have created the design system before we started building anything, which would have avoided the churn of going back and updating existing UIs. But, as they say, “The best time to plant a tree was 20 years ago. The second best time is now.” Making the change in the middle of development required a lot of communication and coordination, but once it was complete, it saved a lot of time in building the next application.

There’s a transition period

After I created the design system, everything wasn’t immediately faster—there was a transition period where I had to educate team members and evangelize its use, as well as learn how best to maintain and improve it.

Get everyone on board

It was important to get the full team on board with the benefits of having a design system—devs are a must, but also product and QA. Once they were familiar with the design system and how it saved them time, they became a huge help in its adoption.

It’s a process, not a product

Even after the team started to use the design system, the work was not over. The design system was not a finished product—it was a process that needed constant updates as we gathered more user feedback and added new functionality. However, we found that it saved more time than it needed.

Want to chat? Email me!