- • Eliminate repetitive design & development work
- • Reduce the learning curve for any new project member
- • Create a consistent customer experience
The Priceline style guide provides a means of documenting a set of assets that can be reused across our site. By standardizing the way we present certain types of content, our customers will have a clearer understanding of how to navigate the site, and they'll have more confidence and trust when making a purchase through us.
Our first version of the style guide was a means of surfacing commonly used interface elements for an experience that we were actively building. After some research, we decided on a technique that uses KSS to help automate the generation of a "living style guide." This solution allowed us to build these projects in parallel and involved only a small time investment.
Once our living style guide represented the styles we used for buttons, typography, brand colors, icons and a CSS class naming convention, I began organizing discussions with the other designers to gain consensus on those styles and with developers to discuss the naming convention. Because we had been operating without any documented standards until now, each team / designer could evolve the product they worked on as they saw fit. I remember a specific day when 5 different individuals in our department were actively creating their own icon font for their product! This process over time made some of the alignment discussions that followed fairly challenging.
You might think, as I did, that buttons would be an easy component to tackle first. But when a quick search across products yields 26 different button styles, and some things that look like buttons but aren't, you are guaranteed an interesting discussion when trying to come to consensus on a single pattern that makes sense to use everywhere going forward. To resolve the button style conundrum, I led a discussion where we looked at how buttons were being used throughout the site, assessed consistencies/inconsistencies and agreed upon CSS properties for our button set one at a time. I assured the designers that even though this might seem like a pain now, in the long run it will allow us to not have to ask the same questions over and over again. Beyond that, any new hires could refer to this document instead of having to choose a style from somewhere on the site, getting us closer to our goal of a more visually consistent interface.
I worked with Jason and other engineers, to have the style guide hosted on our internal network at an easy to remember url: "http://styles." This made our work easily accessible and visible to everyone in the company. Over time as questions came up, referring to the style guide became routine and "style guide" became part of our vocabulary.
To draw more attention to the style guide, and to illustrate its importance, I demoed the project in a department meeting, which led to an invite to introduce the effort at a company wide meeting. During these meetings I played a game with the audience called "Clickable! Not Clickable!" where I displayed screenshots of interface elements on our site today and asked participants to raise their hand if they thought that what was displayed was in fact a "clickable" element. Even though these elements were taken out of context, they helped to illustrate the point that the way we display our content sets expectations. These were lively and engaging sessions, especially considering that some members of the audience were responsible for creating the interface elements in question. Hammering home the point, I left each of these discussions by restating that "Clickable! Not Clickable!" was not a game we want to be playing with our customers and that the experience we provide for them should feel effortless.
The first version of our style guide was a huge success and we were well underway to establishing a consistent and scalable design language. However, in order to scale the effort, additional contributors would be necessary. We would also need to decouple the living style guide from the confirmation page project so that it could begin to serve as the documentation for a larger set of common interface patterns across the site.
One of the biggest concerns I had at this point was that by evolving from a living style guide, we might be subject to a workflow that was harder to maintain. Ease of maintenance is incredibly important for a project like this to continue to serve as a current and valuable resource.
After some more digging around, I settled on Patternlab as our solution. Jason once again jumped in to help, this time to migrate the project to a Github-like environment so that others could easily get involved and contribute to the project, and even fork the project for their own use if necessary.
Because I had structured the SCSS in a modular and scalable way, the change from KSS to Patternlab was not incredibly challenging or time consuming. Tanya came on board as an intern, and she and I dedicated portions of each week to the evolution of the style guide's content and structure.
The style guide has grown exponentially as a result of the ongoing conversations with designers, developers, project managers, etc. Because we have included design and development assets into the documentation, it has dramatically cut down on the time it takes to build a web app that is visually consistent with an agreed upon aesthetic for the website. It has also been a means to collaborating with other departments and disciplines, incorporating brand voice and tone guidelines, licensed brand photography, and code writing conventions. We have even recorded and included narriated screencasts where we walk through the structure and how to best use the style guide! Throughout this process, and on an ongoing basis, we look outwards to evaluate what others are doing in their own style guides and frameworks. Thankfully there are a ton of great resources available to help guide us.
The style guide has also allowed us to leverage this library of established components to rapidly build prototypes for new experiences and enhancements to existing experiences. Prototypes can be shared with and evaluated by any team simply by sharing an internal url. This has been very useful as we have begun to explore and consider opportunities to build responsive designs. Revisions to our global Priceline header and footer, Priceline's responsive Help page, and many other pages and components have been built and have evolved in our style guide as prototypes before making their way to production.
It is going strong and still has plenty of potential. Here are some ideas we have discussed:
- • A publicly visible prototype url can be used for testing purposes, to help gather feedback on a working prototype.
- • Prototypes that replace existing experiences can be analyzed by our QA department in an effort to catch bugs earlier on.
- • More closely mirroring our style guide and production environments will allow for a more seamless transition between the two.
- • Exposing the style guide to the public will allow for input from a much broader group of designers and developers.