Back

HP Enterprise

Design System

Create a pattern library for an online software marketing platform to improve the quality of the product and reduce friction between designers and engineers.

About the project

At Hewlett Packard, I was part of a division of roughly 40 employees working on a marketing platform for HP’s software solution. The purpose of the team was to help HP compete with other companies in the Small to Medium Business market. Our platform allowed a prospective customer to learn about our software offering and ultimately start a free trial. The goal was to lessen the barrier to entry and allow our solutions to be easily accessible to the smaller companies. With this goal in mind, we opted to create a branding that fit the start-up space better, rather than stick with the standard HP corporate brand.

In creating our own brand, we found ourselves spending hours in Photoshop hiding and showing layers to decide on button styles, and combing through bloated CSS because our pages were all being styled separately. While I was an Interaction Designer on the team, my experience with HTML & CSS put me in a unique position to build us a pattern library to solve these problems. I proposed the idea to our UX & Engineering managers, and the project began.

About the team

For this project, I worked with our entire design team - two visual designers, one other interaction designer, an illustrator, and our manager. As the project progressed, I worked with our front end developers to build a platform to host the pattern library and setup a method to deploy it to our coding environments.

About the work

This project was my first real experience building a pattern library or design system. To be honest, I didn’t really know what those terms were when I proposed the project, but thankfully there were plenty of resources around to help me learn quickly. One key part of this project is that we weren’t necessarily trying to design something new, just document and consolidate the designs we had. To start, one of our visual designers embarked on some brand documentation of our colors, fonts and illustration styles. This mean that I spent about 30% of the time auditing and documenting what we had, and 70% building out the SCSS and site.

Branding

We started with our color palette, which included definitions of when and where to use certain colors by denoting the difference between what is considered “primary” or “extended” . Colors were thankfully the easiest to document, and a good place to start as I put together the site.

Designing UI Elements

Buttons were the component that really started the whole project, and therefore got a good amount of time dedicated to them. Consolidating our button styles felt like the biggest win for me. It was a simple task that improved the quality of our designs, reduced the CSS we were writing, and ultimately reduced the bugs in our final product. The fact that we were speccing out buttons each time we finished a design made no sense, and the pattern library ultimately helped everyone save time.

Documenting design and code specification

The most difficult part about the pattern library was building out the documentation to be useful for both designer and developers. All components came with 3 major parts - the demo, the design specs, and the code examples. Each page also came with the ability to toggle background colors, so designers could see various designs in different views.

Building larger components

As part of the library, I also finalized our header and footer designs. This turned out to be a critical task because we had a few variation of both that lacked consistency. This also meant taking the time to tackle and document the mobile variations.

Setting up resources

My last step was to make various resources downloadable from the site, and build templates with our components. Given that the pattern library’s ultimate goal was to save everyone time, giving everyone quick templates to use was an easy way to accomplish that goal.

Iterating

I kept a change log on the site, at the request of the engineers, to document the growing library. This is often a discipline designers aren’t used to following, but in my opinion is very important for a pattern library or design system.

Organizing the information

Finally, after playing around with a lot of different structure, I organized the patterns into 3 categories:

  1. Styles - Colors, fonts, and our grid
  2. UI - Smaller elements such as buttons, progress bars, or input fields
  3. Components - Larger patterns that we build into our library including our header and footer

Ultimately this worked well for us given how simple our pattern library really was. I also added in a few standard icons for specs, code, assets and instructions. My goal was to keep the documentation light and simple, but I may have reduced usability in doing so. Unfortunately documentation of the library was less important than getting the library itself built, so I wasn’t able to invest the time the documentation really needed to test and improve it.

What would I do differently?

Being a small design team, it wasn’t too difficult for me to keep up with the designers and how they were using the pattern I was defining, but the documentation could still have benefited from more guidance on when and where to use certain patterns.

For example, our forms and tooltips could really have benefitted from some accessibility and usage notes on how and where to use them. It’s a great way to keep us honest about whether a tooltip is the best pattern to solve a problem, or whether we should be pushing our design further.