As a user experience designer (and occasional developer) at a tech startup, I’ve seen many different types of friction between designers and developers. Designs handed off to engineers may be missing critical functional or visual specifications, include patterns that diverge from existing styles, or specify things that are overly costly to implement. Code created from designs may change flows unexpectedly, stick to existing patterns when new ones are needed, or not deliver the pixel perfection that designers expect.
When our team began work on a rebrand, I was focused on keeping these issues to a minimum. How could we communicate effectively to see a new look and feel come to life?
Initially, it was an easy sell to convince the design and tech teams that we needed a style guide: a living document to keep us in sync on how to use our new styles.
On the design team, our challenge was to take a brand package and bring it to life in a consistent, cohesive way across our website, app, stores, and packaging. We knew that ultimately each designer could not start from scratch on every new project, but we wanted to give ourselves the time to let our imaginations run wild and play with the new visuals.
To do this, we held design hack days, where we cloistered the design team in a room, uninterrupted, to envision where this new direction could take us. After several days, we had dozens of beautiful new concepts, but we hadn’t figured out all the nitty gritty details, so we continued working individually to flesh out different touchpoints.
I brought the design team together to create the style guide. It started as a Sketch file, where I gathered common elements and left blanks for components we needed to add.
An early Sketch file we deliberated over
As individual team members worked on different touchpoints, we met to hash out each component of the guide. How were we using fonts? Colors? What signified interaction? We debated details like inner shadow on inputs, button states, and font hierarchy; we worked as a team to agree on a set of visual and interactive styles that contained enough variety to serve our many needs, but no more. These styles filtered back into individual projects so designers stayed on the same page.
As the design team solidified the styles, I coded the guide and published it online. Then, I worked with our developers to make it more useful. I added SASS variables, HTML elements, and CSS classes for quick reference. I also added our designers’ descriptions of how to choose between styles and make design decisions for the site.
Swatches, names, hex codes, and SASS variables live together in our style guide
Although we had gotten buy in to create the style guide, there was a period of time where it felt like nothing visible was being accomplished. In a sense, this was true – we weren’t changing styles on the site until we settled on our guidelines. However, the payoff for having a guide soon became clear.
As designers worked on the rebrand, we avoided recreating the wheel on each page – we stuck to visual treatments and interactive patterns we had collaborated on. Since there were relatively few treatments, we were able to cut down the need for detailed specifications. We could tell a developer “this is a title” or “this is sage” and know that they had an easy reference to check against.
Styles reserved for editorial usage
Our guide also streamlined work for our developers, who were newly empowered to take a first pass at design and make design decisions without always needing a designer. Our new styles were both more semantic and more consistent, so we were also able to cut down on bulky HTML and CSS.
On our office wall, there’s a poster imploring us to “Move fast and break things,” and I do love the attitude that we should always be pushing fearlessly forward and trying new things. That said, we shouldn’t only focus on tangible output.
To work well together as designers and developers, we need to be willing to invest time in communication – to learn what the other side really cares about, what they’re willing to compromise on, and how to express our point of view in a way they understand.
The style guide continues to evolve as a conversation between designers and developers. In our next iteration, we plan to tackle responsive font styles. I’m sure there will be plenty of debate about how things should work. Ultimately, I believe the upfront time will be worth it, that we’ll avoid friction and communication overhead to see a shinier product with the same effort.