Establishing a Design System in a Large Enterprise
Treat other’s objectives like your own.
About a year ago we started building our own design system at GSK. I know what you’re thinking:
“Oh great, another blog post about design systems.”
Eyes roll. The masses yawn.
But wait! Maybe this is a good thing.
I’m here to tell you that designers are not done promoting the value of design, and design systems are the easiest way to quantify that value. The more stories we can make available to the field, the better off we’ll all be, so I’m going to share the story of how we introduced a design system to one of the largest pharmaceutical companies in the world, the most interesting part of which has nothing to do with components or Sketch.
As you may have read in Ian’s previous post, GSK is in the midst of Tech Transformation, and as the company shifts towards making more of its own digital products, it was imperative that we establish a common method for doing so. Without this process, we’d see a duplication of efforts, as individual groups would likely end up solving some of the same problems.
Disclaimer: If you already know what design systems are due to the many, many blog posts mentioned above, kindly skip ahead, or check out this twitter account (you probably already know about it). For those of you new to the field or simply interested in learning more about design and design systems, the below is for you (see above about promoting the value of design).
What’s a design system?
Design systems are a process for operationalizing the creation of digital products. They create a common language between designers and developers, which enables teams to build websites, apps, and other experiences quickly. With the time your team gains, you can focus on things like accessibility, iteration, and user research. Ultimately though, at GSK, all of these benefits lead to improved user experiences for our patients and Health Care Professionals.
Early Days
Our team started working on the design system in September of 2018. At the same time, all of us were just getting started at GSK. While we were keen to show progress and provide value, we were still learning the landscape and getting adjusted to the company.
In the early days, we had challenges with documenting requirements for the design system, as we were still gaining an understanding of what we were trying to accomplish. We learned it was important to communicate a clear understanding of what our goals and milestones were in way that our tech teams could understand.
Setting Up
As time went on, we became more comfortable in our new environment and made a few strategic decisions around how we would build our design system. Given that GSK contains multiple brands, we knew we would need theming and support for many languages and frameworks. This lead us to Lit Element, which is considered to be the next generation approach to authoring web components that are native to modern browsers. It’s important to mention that we’re not the first to do this, as companies like Ionic, Intuit, Salesforce, and Apple have made similar decisions.
We also decided to leverage Material Design in an attempt to strengthen our theming capabilities and reduce our time to market. If we were going to scale the system to accommodate all the brands under the GSK umbrella, we would need guidelines and best practices that were mature and stable.
The more we learned about Material, the more questions we had, so we reached out to Google for some support. They were kind enough to welcome us to their New York office, where they piloted a new Material Design learning curriculum which provided a deeper understanding of all the excellent work they’ve done. Big shout outs to Liam Spradlin and Avani Agarwal! You’re excellent design partners.
Our theming approach was of course inspired by the design tokens used by Salesforce, and the Atomic Design construct spearheaded by Brad Frost. We simply wouldn’t have been able to make our system themable without breaking down our visual design decisions into the smallest, atomic level. Component-based design FTW! No more hard-coding values!
With so many great resources out there for design systems, the way forward felt somewhat paved. The design and development communities do a fantastic job of documenting processes and techniques, and most people are more than willing to lend a hand.
Distributing The System
As far as design tools go, you could probably guess that they are a big part of design systems, which makes it critical to understand your users’ software of choice. Because of this, we did an audit of tools used within GSK to better understand what users were actually designing with, and Sketch turned out to be the winner (it’s also the industry favorite).
At this point, with the software tool of choice defined, we spoke with Sketch and found a way to push updates we made to the system directly into our users’ Sketch files using Sketch Cloud.
This is obvious, but I highly recommend Sketch. However, there are many people at GSK who use PCs, which means we need to accommodate them as well. Sketch turned out to be a great place to start, due to its ability to work well with other PC based software, such as Axure. More on that in a follow-up post.
But really…
Did you enjoy that insight into our tech strategy? Good! Was it maybe a bit dry? Perhaps.
Choosing a framework, language, and supported design software are important decisions, but we slowly learned that design systems are more about people than they are any tech standard or design style. As you might have been able to tell… we completely missed that (facepalm). It turns out that choosing your approach and setting up your design system is the easy part.
Remember that interesting thing I mentioned at the beginning of this article?Here it is: no one outside of tech or design care about your tech or your design. Not your colors, not your buttons, not Sketch and certainly not LitElement.
Why? It’s simple — because they’ve got their goals and their own challenges just like you. So, help them solve their problems first, and the rest will follow.
Problems First, Components Second
As we picked up speed and word spread about our team, someone reached out with an opportunity to combine several disconnected chat bots into a single experience. When you begin working with teams outside your own, you’ll often find that someone, somewhere, has similar goals and may have even started to do the things you’re doing. They can be powerful advocates in the creation and adoption of your design system.
Our team was naturally excited about using this relationship to prioritize the creation of components based on real user need and demand. However, because we’re the centralized team that manages the system, when it came time to present the work, our review was another learning lesson.
We presented the stakeholder with a slide of all the separate components that would be necessary to create the chatbot experience. Confused, and a little quiet, she simply nodded and said, “OK, these look…great.”
That certainly didn’t go as planned, but what happened? Not content with the feedback we received, the team went back to the drawing board to discuss what went wrong.
To put it simply — Lego doesn’t put a picture of all the individual bricks on the box. They put a picture of the super sweet castle.
And that’s when we realized that we needed to present the components together, in a prototype of what the actual unified chatbot experience would look like.
That next review was a huge success, and I don’t think we mentioned components or design systems at all. Our stakeholder was able to paint a picture of the future she saw for help experiences at GSK, and in turn was able to share that vision with her peers. Help your co-workers solve their problems, then then contribute those solutions back to the system.
Lucky for us, helping others is an important part of our ongoing Tech Transformation. Our org. voted that “Work Together: Treat other’s objectives like your own” was the most important behaviour in building the culture we want at GSK. And our design system? Well, it will enable us to do just that.
A turning point for our team, that moment marked our transition into treating the design system like a product. In the early days, we didn’t track demand or make an attempt to capture the business case — we knew it was valuable and assumed everyone else did too. But as I mentioned earlier, if you’re just starting your design system and your team has many objectives, the system will always be the first thing to get pushed aside. Document the value and explain your objectives early and often to protect it from getting de-prioritized.
Since we’ve established that design systems are about people, like the stakeholder mentioned above, it’s important that you make some friends. Along the way, we worked with our Corporate Reputation and Brand team, and the rest of the UX community of practice at GSK to help shape the system. It doesn’t just belong to us. Everyone’s had a hand in its creation.
But that’s our story, which means these solutions may or may not be right for your business or team. However, you should get used to explaining design and design systems to people that aren’t familiar with design. You probably take for granted how much you know about your profession.
Creating a design system can be overwhelming. There’s so much to do, from nomenclature to a governance process; you’ve got to tear off smaller pieces.
Today, we’re about to make the GSK Design System available to the entire company. We’re offering a base set of 36 components, a brand approved theme, design standards, a Sketch library file of robust symbols, a way to push updates directly to designers’ Sketch files, and matching code available via npm install from Azure artifacts or CDN.
Pretty neat stuff — all of which will help reduce the average time to ideate, design, develop, and ship a website at GSK to 1 month. We’ve only scratched the surface on things like governance and deprecation, but with a solid base established, we’re prepared to scale the system.
