Beyond style guides: lessons from scaling design at TELUS
Content and Design · Jul 12, 2018
I’ve worked on many small design teams in my career and we all worked using the same tools, which made sharing easy. We had a (somewhat) organized file structure for each project and we had conversations or face-to-face meetings to collaborate. Easy peasy.
Then I started to work for Koodo. This was the first time I was exposed to a design team that worked on many different projects under the same brand identity. Each designer needed to use the same design language and apply it consistently. The solution was a style guide of shared UI assets created in Photoshop. We called it the Koodo Digital Standards.
Style guides aren’t complicated. They usually consist of a logo, a colour palette, and some design elements that are applied to applications using a set of guidelines.
However, we knew that to create a successful style guide that works across multiple teams we had to have the following:
Alignment on tooling
Ability to share
A way to communicate usage
Evolving into a design system
Design systems are the natural progression from style guides. They generally include a catalogue of designs, accompanied by codified components, documentation on standards, usage, and best practices.
Armed with the knowledge from building the Koodo Digital Standards, I joined Koodo’s parent company, TELUS, and began work on the TELUS Design System (TDS).
In my role as a design lead, I wanted to improve customer experiences across TELUS by building an efficient design system that would be able to scale across the entire organisation - not just within TELUS Digital. There are many benefits to a design system but Fabricio Teixeira outlines why these are the three key benefits:
"1. Efficiency for your team: Design systems save time and money. Instead of creating components from scratch, designers and developers can re-use existing pieces and create new pages with more efficiency and speed.
2. Consistency for your users: Design systems enable your team to create familiar experiences for your audience, eliminating inconsistencies and making sure that every time someone interacts with your company, their experience will always look and feel the same.
3. Scale for your company: With efficiency comes the ability to scale. Design systems allow for automation in the design process — which means companies have the ability to build more with fewer resources."
Scoping the mission
We had the same challenges as Koodo, except now at a greater scale. At TELUS we have four main tribes (My TELUS, Mobility, B2B, Home Solutions) and within those tribes we had multiple squads (Tribes are made up of teams linked by a common interest or subject. Squads are the teams or smaller subset within those tribes). So we didn’t have just three teams, we had over 20 teams and vendors who reported the following issues:
Design standards not applied consistently
A lot of effort is needed to keep files up to date
Updating files with new assets was a big pain
Duplicated effort with teams reinventing the wheel each time
No single source of truth for design (or code)
Legacy designs that are disorganized and not easily updated
Inconsistency across tech + design makes building / updating difficult
Our team had essentially one mission. To simplify the path to production for our teams so they could focus on delivering consistent and seamless end-to-end experiences to our customer.
The path to efficiency, consistency, and scalability
Like Koodo, TELUS already had a style guide so our first step was to transfer the existing components to the new system. This ensured that we would have product parity right away. We wanted a backlog of widely used components across the existing TELUS site to make sure that we are building the key components first.
We needed to create a design system that could be easily adopted and had brand, accessibility, and coding standards baked in. This would allow our delivery teams to focus on the bigger things and solve new problems.
We established a framework to determine a component’s ‘value’ and rating based on the following factors:
1. Is it on brand?
For those who aren’t familiar with the TELUS brand we are well known for our critters, use of nature imagery, clean and simple design, use of white space, and friendly tone. We constantly strive to deliver on our future friendly promise. How do we package all this into the a design system?
We did this by keeping things simple and providing a scalable framework. It’s based on our brand principles, layered on with our design principles, foundational styles, and then our components.
Our components have simple and subtle added touches like animation and motion to indicate interactions. They are responsive in both sketch and code so designers and developers are able to modify them to use in various viewports and screen sizes.
2. Is it accessible?
"At its core, an accessible product is easy to use, easy to understand, and is available to everyone. Being mindful of the basics of accessibility is a key to bringing that experience to our customers." - Oskar Westin, Accessibility Specialist
As with any TELUS digital product we build we are designing inclusively. Each component designed and contributed to the system needs to be responsive, but also accessible. From a design perspective, each component had to meet or exceed the website content accessibility guidelines(WCAG 2.0 AA). We also had to make sure that we weren’t using colour as the only indicator of interaction, but also a change in shape to increase affordance.
3. Has it been tested?
Along with testing our components to make sure they function as they should across different browsers, screen sizes and platform, we also test them to make sure they are usable. We tested our components with real users, in context, whenever we could. We simulated the use cases in our prototypes to ensure that the components could be used and understood easily by our customers.
4. Can it be reused?
Reuse is a big factor when thinking about adding a component to the system. Similar to a design system scaling across teams, we also need to think about the individual component scaling across teams.
We considered how each component could be used in context across tribes with the different content of the My TELUS vs. Mobility etc.
What sort of variations did we need to add to make sure it worked for all teams? Does it work for all teams, or should it be two separate components?
With this framework as a foundation, we sent out surveys, conducted workshops, and facilitated component jams with all of the teams to solidify a core list of components. In partnership with the design leads we then conducted an audit of all live pages, identifying the most used components.
All this information helped to inform our team of the priority of the components and which ones to include in the release of TDS version 1. We were able to identify which components would bring higher value to our delivery teams making them more efficient in their process. We were able to define our minimal viable components list for the system. This list became our backlog, and the most essential components became our version 1.0 release candidate.
We will use this framework to assess future components that are added to our system.
Consistency starts with design. When we align our designs we are better equipped to provide that consistency.
Step 1. Align on tooling
First, we had to align on a tool. This might seem to be a pretty straightforward idea, but with our design team we had some designers using Photoshop, some on Sketch, Zeplin and Invision and when it came time to create a design system where all teams could use, we needed everyone using the same thing. We decided as a team to use invest in Sketch as our design tool and Invision for prototyping, and hand-off.
When we aligned on the use of Sketch, we created a master Sketch file that was released with each version of the Design System. Code matched design. Gone are the days of clunky 250MB + photoshop files. Welcome lightweight Sketch tool.
Step 2. Shared design library
One of the challenges in trying to use a design system is updates. When we made a code release we would also release a new Sketch file. Designers would have to download a new master Sketch file to work from. This was great if all projects always started from scratch. The problem is most teams were in the middle of the design process and when our team would do a release they would have to manually update their designs.
This was a tedious process so most of the time designers didn’t bother which lead to inconsistencies in design and code. We heard a lot of negative feedback regarding this so we needed to find a solution that would allow us to do away with releasing a Sketch file with every release.
In January 2018, InVision released the beta version of DSM (Design System Manager) and thanks to our standing in the Design System community, InVision approached us early to test the new tool. It provided a way to share components, categorize them, update, maintain and share out to designers with each versioned release. It provided different permissions for users and the ability to create multiple design libraries and folders within.
DSM allowed us to release versions and also allowed designers to consume only the changes from the last update. Designers would be alerted to the new release and had a choice to accept the updates or stay with the current version. The changes automatically update into their current work with the DSM. Because the components were in the cloud and named the same the new updates would just replace the old components. Designers didn’t have to find those instances separately so design stayed consistent with code and it reduced any design refactoring.
These important improvements to the design tooling process enabled us to mirror the changes in our coded components. We moved away from a monolith package and began individually versioning components creating a design system that is simple to build and easy to maintain across tribes and platforms.
We now had a single source of design (and code) truth. A platform to build upon and grow.
Step 3: Guidelines
In order for the teams to know when to use what component, we needed guidelines on the usage. Our documentation includes usage, best practices, examples etc. Documentation is publicly available on our component catalogue page. We used Styleguidist to automatically generate the documentation and add examples so users can see how it’s applied. On our documents, you’re also able to modify the code right on the page, using the props to see the live examples.
In our design library on DSM, we also have documentation for designers to learn about the usage of the elements and components.
We had a challenge of creating a design system that needed scale and in multiple ways:
Firstly it needed to scale across multiple teams both internally in TELUS Digital, with outside vendors, and eventually across TELUS.
Secondly, we had to think about the system scaling to multiple applications beyond the web. Will the technology and tools we choose to use, be able to scale to email, native app etc.
We started off as a centralized team working on building out a design system for our delivery teams to use. We always knew that to truly solve the first scaling issue we must open up our contribution model. So once we hit version 1.0.0 we quickly focused on moving towards a federated model. This enabled teams contribute to the system and is beginning to help us scale faster.
We are cultivating a community so teams can build, share, evolve components to contribute back to the design system in a separate TDS Community design library. Ultimately we want to be creating a sense of ownership within the community of the system. We will outline TDS community and contribution in a later blog through our series of Design System blogs.
As for the second problem: we are currently investigating possible solutions to support other platforms so stay tuned for updates over the coming months.
There’s no secret formula for a design system
Every design system is different and works for different teams in different contexts. A static style guide worked well for Koodo; building anything larger would have been overkill. Larger enterprise organizations like TELUS, with multiple teams, require a more robust solution.
A good design system allows for change, variation, and flexibility. If it’s too rigid, teams aren’t able to use it easily. If it’s too flexible, it becomes inconsistent. There needs to be a process in place with governance, but not too much so that we become a bottleneck in the process.
A design system needs to be able to scale appropriately and at the right time. The system itself needs to scale across teams and the components should be continually reused. The ability to share reusable components and effortlessly onboard will make adoption easier for teams just getting started.
Communication is key
Communication is extremely important when working on a design system that affects many teams. From updating teams on releases, changes, bugs, or collaborating on a design that may affect all teams, the TDS team needs to be on top of sharing updates. Communication is also a two-way street. We also need to listen to our users, to make sure what we were building is what they need.
Document, document, document!
Documentation is just as important as communication. After you’ve communicated changes or design decisions as a team, you’ll need to document them. Document usage, best practices, when to use what and why you’d use something over another. We documented onboarding, how to get started, how to contribute, frequently asked questions, and everything else under the sun.
Reflecting on the journey
I have had quite a journey being part of building this great product. Going from the task of designing components in detail and making sure they are responsive, reusable, accessible, and flexible to something greater. Knowing that each component in the system has a huge impact to the rest of TELUS and widely used across teams creates a sense of pride. Most companies aren’t able to have a dedicated team working on something like this so I am quite delighted to tell people I get to build a design system. We are only just starting and I expect many great things to come from our team!