TicketBiscuit sells tickets in several niche market. They brand their product to several markets: music venues, train rides, dance recitals, and high school sports. The products are distinct, each toggling features on and off based on the domain. This caused a major challenge when it came to updating the product. Styleguides are typically used to solve the needs of disjointed products. TicketBiscuit had this challenge, but also had the challenge of keeping 4 brands up to date.
To further complicate things, TicketBiscuit supports several different products. There is a portal to for customers to buy tickets, mobile apps to scan and redeem tickets, a dashboard for clients to create and manage events, and a box office for staff to sell tickets online or at the door.
Stakeholders for this project included the CEO, CTO, project manager, a subject matter expert from the support team, QA lead, a lead developer, and two designers.
Fortunately the problem and solution had been backlogged for a while, so there was no time wasted deciding what to build. We definitely needed a styleguide. Instead, I separated out key goals for each stakeholder that I believed could be resolved through a styleguide.
CEO and CTO: create a set of vocabulary enabling stakeholders to see the interface as a set of parts, rather than a set of pages.
Once every stakeholder realized a styleguide could resolve these concerns, it was easy to garner support. Organizing and presenting these goals to the stakeholders helped me gain the time necessary.
I based much of the planning and execution on Brad Frost’s Atomic Design. From the beginning, I was focused on identifying the irreducible parts of the interface, and putting them together into reusable components and patterns.
I started by auditing all of our interfaces. Taking screenshots of things like buttons, typography, navigational patterns, and grids. All of these screenshots were cropped and organized together on standard A4 pages and printed out. I taped these to a wall and put post-its and pens on a nearby table. I encouraged stakeholders to come by and add comments on sticky notes and place them in a relevant spot.
Simultaneously, I referenced existing brand guides that our marketing team managed. These brand guides lacked details necessary to build web products, but provided a good baseline for how to use colors and set typography. I cross-referenced this against the wall of interface parts to identify the places in our product where we branding was weak.
This research helped me determine what parts of our interface were good and worth keeping, and which parts could be discarded.
Card sorting helped me organize the components in a way that made sense.
I used Sketch to layout the different parts of the styleguide. I took advantage of symbols to hot-swap things like color and brand. This was a way to prove concept early on. These Sketch files included all of the necessary parts of the interfaces
Ultimately, I created a sketch files full of symbols corresponding to each site component. This was duplicated for each brand, but it was easy to switch out colors and fonts once the symbols were established. Subtle variation in line height also existed between the components in each branded .sketch file.
A few samples from the styleguide templates. Once the components had a generic layout, the brand could easily be swapped. Copy was also swapped so stakeholders would have more believable mocks.
Designers would need to maintain these templates and keep them up to date with the living styleguide. That was documented.
The frontend was made significantly easier by utilizing PatternLab. Each component was templated with Mustache. Patternlab makes it possible to expand a component and see how its templated. This becomes even more useful when components are nested. For example, a form within a container.
PatternLab makes it easy to not only display components at different screen sizes, but also to look at the code that makes a part. This was useful for frontend developers.
The job was done using SASS. This was organized in a conventional way. Typography was seperate from containers, which was seperate from button styles. Brand colors and configurations were imported at the top, which flowed down into individual components. This made brand hot-swaps easy, and ensured that the components were modular.
A critical part of delivering a styleguide to an organization is ensuring there are rules and processes in place to sustain the effort. If it isn’t managed, the styleguide can quickly become outdated and irrelevant. I established naming conventions and documented them. The components were organized in the .sketch files consistent with the way they were organized in the living styleguide.
The styleguide outlined how to build frontend components. The mustache structure should help frontend developers think of the interface in terms of partials that can be referenced rather than as raw HTML to be rebuilt over and over. As part of documenting the styleguide, a timeline was suggested for integrating the styleguide across all of our interfaces. It was important to show how much time would be saved in the future by investing the time into standardizing our interfaces..
Implementing the styleguide will also allow the organization to circumvent the existing stylesheet problems by starting clean with SASS organized by components. QA should also benefit from the stylesheet as style changes will be systemically testable in the future. I documented the need to recreate every partial in the styleguide, but did a good chunk of it in order to demonstrate proof of concept. A kitchen sink full of partials is all QA will need to look at in the future, rather than dozens of different pages.
The styleguide proved to be a crucial way to resolve many systemic problems within the organization in one fell swoop. It established credibility for the design team and also oriented the entire product towards a focused direction.