Scrapping our Style Guide
A Case Study on valuing agile function over branded form.
UI style guides have become typical additions to the Product Designer’s portfolio; and why wouldn’t they? As a holistic piece, a style guide has the ability to showcase systems design, visual design, an understanding of common IxD patterns, unified branding principles, opinionated color theory, and the ability to make use of Sketch’s or Figma’ Libraries for scalable Design-Ops (just to name a few).
It’s no wonder that I jumped on the opportunity to create and enforce a style guide when I joined the nascent team at Tribe Dynamics.
How naive I was. 🤦
Atomic Design
To those that have found themselves as the first or only designer on a new product, the world is your oyster. In my case, a Bootstrap website was my oyster.
I had become an advocate for Brad Frost’s Atomic Design Principles by early 2015, so I partnered with Tribe’s first developer on a conquest to create a branded experience, extending from our web-app through our published reports.
After building into a Sketch Library, we continued forward with the intention of building a Live Pattern Library for our core “organisms” that would allow us to speak the same language between design and development.
Our intention was to streamline our communication, and from the outside it seemed as if we had succeeded after a few iterative cycles.
From a design perspective, we went for a minimalist approach for our organisms; favoring a focus on the content over decorative styling. This fell in line with our user’s primary actions, which were focused on consuming and managing all of the content being created about their respective brand. Further, we designed to make sure that each organism would be its own component, which we could adjust the styling of, and add to, based on user behavior and feedback.
However, from an implementation standpoint, we fell short.
Django Templates vs. Component-based development
It wasn’t long before we realized how poorly set up our Django back-end was to support the design language we were producing and iterating upon.
You see, we were attempting to dynamically build and iterate on individual components with the atoms and molecules we had designed, but Django was never intended to scale in this way. It forced us to focus on the the entire page, when we intended to work on smaller sections.
As we continued to iterate, we had to go back to make sure the Pattern Library we had developed wouldn’t break with each and every tweak; a problem that only became more and more prevalent as we started to grow our product and product teams.
Maintenance over delivery
Our team was small and young. The more time we had to spend maintaining our Pattern Library, the less time we had to actually focus on researching and solving real client needs. It’s no wonder that some of the most well-known systems are built and maintained by large teams that have the time and organization to dedicate to the task.
We had naively thought we could stand with such giants; a noble effort, but something that ultimately led to slower design and development cycles, not to mention an inconsistent product experience.
An opportunity arose
By the end of 2017, we were preparing to work on a new product direction that extended upon our popular Competitive Leaderboard offering. This gave the team an idea: what if we took the opportunity to move our app into a modern web framework?
With a team of 2 designers and 4 developers, such an idea seemed impossible; we’d be subjecting ourselves to the ongoing maintenance of two systems, while attempting to move our styling into a new Pattern Library.
Vue and Vuetify
It was then that our lead developer suggested Vue.js as the best path forward; and from there, we discovered the Vuetify.js component framework. ✨✨✨
Vue would allow us to build right next to our old Django templates, but with modern javascript, and Vuetify provided us with the most common UI components and IxD patterns based on Google’s Material Design.
Experimenting with Implementation
At first, we attempted to maintain at lease some of our styling for the transition. However, this only provided a half-way solution that didn’t allow us to make use of the full power of the Vuetify framework.
Further, reading through the Vuetify docs showed that we had all of the components we would need to make the change.
With some minor adjustments, we were able to map all of our existing functionality into Material UI and Patterns. Building out some d3.js graphs, and providing our brand’s font and accent color gave it just the right amount of “Tribey-ness” to keep the experience cohesive.
Iterating on the functionality allowed us to build in patterns and interactivity that were previously impossible without a single-page application implementation. Win-win-win.
So, what did we learn?
Shipping this update to a select group of clients allowed the organization to realize the importance of functionality over form. While we had hoped to create, implement, and maintain our own styling throughout the app, by outsourcing our Pattern Library to the Vuetify team(🙏), we were able to focus on delivering solutions to our users in a modern, fast, scalable, and maintainable way.
Over time, we’ve started to add our own styling into the mix when given the opportunity, which can most readily be defined by Material Theming, without sacrificing resources to maintain our front-end framework.
As for our clients, they’ve reaped the benefits of working with a team that can take their ideas from inception to production faster than ever before.
A side note
In no way would I suggest that a product team ignore the need for a Style Guide and associated Pattern Library. My feelings are quite the contrary: If you have a team that has the resources, knowledge, and skills (not to mention the buy-in) to spin up your own Style Guide, the benefits can be remarkable.
However, for a small team, such an undertaking can be illogical. There are plenty of frameworks out there to get you started, and at the end of the day, your focus should always be on your users.
To that end, scrapping our style guide and pattern library for an outsourced solution has proven to be the most fruitful, as it has allowed us to dedicate our time in the most impactful manner: on the problems of our clients.
