In one year, our product team designed, coded, and developed a complete SaaS app (more on that here). Things were functioning as intended, we were able to begin user testing, and it even looked good! No small feat for a very complex system.
However, there was missing link between myself and the developers to be more efficient. We wanted to cut time from wireframes to implementation. I had a style guide and prototypes, but digging through them when building a new feature was costing time and increasing tiny UI and interaction variations across the product.
We took a step back and examined our workflow:
- Style guides only solve for the present. What about design updates?
- What if we wanted to build a new product tomorrow?
- What about the HUGE disconnect between current designer and developer languages? I’ve always been interested in improving this.
It Takes Two
Very simply, a designer is conceptualizing everything in the form below using some type of design program (and hoping the finished product looks consistent.)
Yet, a developer is working in a text editor writing programming languages (in our case React, HTML, CSS).
These are two dramatically different spaces to play in. (strong). It’s no wonder the current process of most software app teams are imperfect.
The end goal is always the same-to have the specs, designs, and finished product all in alignment.
Solution: Pattern Library
To ensure consistency throughout the system, I created a pattern library to house all our assets and provide direction to the developers, expediting design to code delivery time.
A pattern library is a step beyond a style guide because it takes the visual components to their final code state and organizes them. There are a few great open-source pattern libraries out there including:
Creating a pattern library follows the same beginning steps as creating a style guide. I already had visual components sliced and grouped. I also annotated my design files with various interaction states.
The forward-thinking and most critical step is to code everything, just as a developer would. The extra challenge for me as writing our components in React, because I didn’t know it yet. React is not necessary for everyone, but it was the base of our software. Therefore, I needed to write the pattern library in the same language for it to be useful to the developers.
The completed pattern library was structured similar to our software and contained Source (.jsx) and corresponding Less/Styles (.less) files.