TELUS Design System: Building a community

Collaboration can be hard. The real skill lies in making something that other people find attractive and enjoyable to use. In a previous post, I discussed how design systems can help organizations craft great experiences at scale. In this post, I’d like to go into more detail about how we addressed collaboration specifically and some of the implementation challenges we faced along the way.

Platform problems

In 2014, before we began our design system journey, TELUS had a master CSS stylesheet fondly named Frogger. This gave outcome teams a Bootstrap-esque arsenal of buttons, form styles, etc, that they could use to build consistent experiences between AGILE teams. No one team owned this CSS, and people quickly began to develop their own overrides to solve problems specific to them. As the digital team grew, more of the custom styles began to diverge. Duplications began sprouting up all over the site, wasting time and compromising the award-winning TELUS brand. 

This problem wasn’t just limited to design: each team had adopted their own programming languages and frameworks in response to their individual challenges. The leadership team realized that this was a platform problem and so we needed a platform solution. 

Wiping the slate clean

To service the feature teams, we were given a once in a lifetime opportunity to rebuild TELUS Digital’s infrastructure from the ground up. After extensive research and testing, we set about building a React/NodeJS stack with governance based upon clear, open source principles. This setup became known as the TELUS Digital Platform.

This open source contribution system worked brilliantly for the technical side of the platform, but when it came to design we immediately began experiencing growing pains. Without a “straw-man” the design system took a long time to get off the ground. Gaining consensus between design leads on the direction was difficult. Each person had a different, but equally valid opinion. Also getting the component systems architecture consistent was problematic. Tech leads are some of the busiest people at TELUS, so getting them in one room to come to a decision isn’t easy. We weren’t seeing much benefit beyond what Frogger had provided and the slow pace of progress led to negative feedback from our internal teams. So we took the hard decision to pause the initial roll-out and decided to tackle this problem head-on.

Where design meets theory

When working with a large team of designers and developers it’s important to strike the right governance balance. Communication across time zones and between disciplines required a well thought out approach, so we got comfortable, bought a lot of books and began researching. 

Nathan Curtis is one of the top Design System thought leaders. In 2015 he wrote a fantastic article about his so-called Federated Design System approach, which is a must read if you haven’t already digested it. We found many of the answers to our problems in his post, which outlines three types of Design bureaucracy that he has experienced; Solitary, Centralized, and Federated. 

At the same time, we had been thinking about Network Theory and topology. Being a telecommunications giant, network topologies are our forte. We understand that how you choose to organize the flow of information can hugely affect the rate at which it travels and its resilience to errors. 

By combining these two ideas we were able to see the whole picture. With this lens, our problem became razor sharp. We had started out with a solitary model: the CSS Master sheet. This was analogous to a mesh network with many nodes, each connected to one another. Mesh networks create a very fault-tolerant system, as mistakes don’t spread easily or fast. However, while they help facilitate onboarding, consensus becomes increasingly more difficult as they scale, as does the likelihood of individual teams making mistakes. The decision to move to an open source model didn’t change the network topology, it just repeated it.

The centralized model can be compared to a Hub and Spoke network topology. Hub and Spoke networks are accurate because a single source of truth pushes out consistent information to each ‘spoke’. It’s also very fast because only the central hub approves each decision. However, scalability can be problematic, as all information needs to pass through the central ‘Hub’. The only way for the network bandwidth to increase is by increasing the size of this central bottleneck.

The federated model described by Nathan is basically a Tree and Branch network - the perfect hybrid. Tree and Branch networks are:

• Easily scalable - just add a new branch

• Consensus driven - branch node validates all decisions

• Fault tolerant - errors are confined to single branches

• Process friendly - branch node helps expedite information relays

Phased approach

Ultimately, it became clear that the ‘Federated’ model was the clear winner and would be our design system’s end state, but we had some catching up to do with the rest of the platform. Now that we could break down the problem clearly we could analyze the trade-offs of each option. We decided to start with a centralized system, as this was the quickest and most accurate way forward. This would help us create the atoms and lay the rails for a fantastic, scalable design system. In the future, as we rolled it out to all teams, we would transition to a federated solution.

Fast forward to 2017. Version 1 had been through 56 beta iterations and was thoroughly tested by internal and external teams. We released it to much fanfare from the organization at the TELUS Brand Partner Summit in Toronto. It was time to begin acting on our promise to decentralize and move to a federated model.

We’d had a lot of time to think this through, and from December leading to the new year, we formulated a plan of attack. 

Split components within a monolithic repo

Components had to be packaged independently so that each individual release didn’t necessitate an upgrade across the entire system – essential if you don’t have a team centrally co-ordinating every single release.

Split components into Core and Community

We noticed that two kinds of components had developed. The most basic atoms were used by almost every team and represented the TELUS brand’s core principles. We decided that because these components were so crucial they should maintain centralized ownership as this is the least error-prone communication method.

Build out the branches

To build the branches and put these ‘branch nodes’ in place, we developed the concept of Digital Platform Ambassadors - a pairing of each business unit’s design and tech leads. These leads represent the most connected points for each outcome team and would hopefully provide the most direct communication within the system.

Agree upon community principles and guidelines

The final step was to agree on how we are all going to communicate and work together. In one meeting the DPA agreed on these principles and ensured that we had the right level of buy-in from each business unit. They also determined the frequency, format, and process for all future intakes.

Ready to scale

Now the time has come to remove the training wheels. We believe that we have developed a product and set of processes that teams can’t live without. Over the next few weeks, we’ll begin to step aside, and rather than being the central limiting hub for the system, we will transition to being one of the branches. To that end, we have open sourced the TDS-Core and Community components via Github and created the accompanying documentation. We hope that the process to discover and share design-ready components speeds up dramatically over the next few months as teams begin to work together to create components that can be leveraged by all. And as the amount of components begins to increase, we hope to also see an explosion in productivity and creativity as teams stop focusing on the mundane in favour of the extraordinary.

Do you think you have what it takes to be on #TeamTELUS? Apply today and reference this post in your application. Click here to apply!