An in-depth look at the strategy behind the TELUS Design System

Content and Design · Jul 26, 2018

The Digital team has evolved and grown. From less than 50 to a team of more than 400, we’ve rapidly expanded to meet the needs of our customers in an increasingly complex and competitive environment.

We quickly realized that what worked for 50 could never work for 150, let alone 400 and beyond. To scale effectively and make it easier for team members to deliver great customer experiences, we needed to rally around a common vision of platform thinking and designing systematically. We needed a system that would allow us to pivot efficiently, simplify delivery and accelerate what we do through reuse and consistency.

In the future, it'll be more important to design long-term systems that can pivot to change, optimize, and reinvent their products, without having to start from zero each and every time. - undefined

Building a design system of coded UI components makes it easier to build and maintain digital experiences: we can evolve our experiences without having to start from scratch. To make a system meaningful in our context, it must be grounded in TELUS brand philosophy and aesthetic while empowering autonomous teams to easily build, share, maintain and evolve consistent TELUS experiences.

Reorienting a team to work this way doesn’t, however, happen without a little thought and a lot of organizational support. Friction is inevitable. Teams have ingrained ways of working. Designers and developers have their own personal workflows. People mistakenly believe that standards and frameworks are an unnecessary constraint.

Teams need to migrate from old, disparate technical solutions and harmonize around a common platform. Time and money are needed to grow and care for a design system and help teams transition onto it. In short, a strategy is needed to:

  1. Uncover user needs and business pain points

  2. Articulate a vision and benefits

  3. Identify guiding principles

  4. Devise a product architecture

  5. Develop a product roadmap

  6. Build a team

User and business needs

We treat our design system as a product. And a product exists to solve a user/customer problem in a way that is beneficial to a business. Ideally, in a way that is technically feasible and maintainable. The first step is to develop a deep understanding of who our users are and what they need. 

The main users of our design system are delivery teams across our enterprise who design and build digital experiences: POs, data scientists, scrum masters, testers, designers and developers whose workflows are impacted by the transition to a design system. We spent time meeting and listening to them, and chatting about what has (and hasn’t) worked before. We wanted to capture insights and ideas that can be woven into our problem definition, or better yet, leveraged within the solution. Giving users an opportunity to provide input and feel involved in product development makes it easier to win their buy-in later.

A couple of recurring themes surfaced during our conversations with users:

  1. Aligning on the latest design/dev standards and maintaining consistency across teams is challenging.

  2. Sharing code and design ideas across organizationally and geographically distributed teams is challenging.

In addition to user needs, we had to understand what problems we could solve for the business. A company of 40K people has a lot of competing demands for attention and money. To cut through that, our work had to be tied to business priorities. Two key ideas came to the forefront:

  1. Our brand is a key differentiator and delivering a great customer experience is central to it. As customers increasingly interact with us via digital experiences, we need to present a consistent brand experience irrespective of the team, business unit or external partner developing it.

  2. Delivery teams shouldn’t have to start from scratch every time they initiate a project. To help them keep up with shorter market cycles we must enable them to deliver work faster without sacrificing quality.

Product vision and benefits

Based on our understanding of user and business needs we set about creating a product vision with the goal of providing a more consistent digital customer experience for customers while also making it easier for delivery team members to efficiently and consistently build on-brand experiences.

This goal served as the basis for our product vision: Enable delivery teams to share ideas and efficiently deliver on-brand consistency

Elaborating on this further we agreed it would be a product grounded in the TELUS brand philosophy and aesthetic. It would contain standards, a catalogue of reusable design/code patterns, and the practices needed to manage and maintain a living design system. 

The benefits of this are:

  1. For customers: More seamless experience across digital touchpoints.

  2. For the business: Stronger and more consistent representation of the brand digitally

  3. For delivery teams: Easier to develop digital experiences and share learnings across a shared system.

With our vision and benefits now better understood, we could begin to define some guiding principles and product architecture.

Guiding principles

When shepherding a product or big idea through a large organization, it’s helpful to agree on guiding principles at the outset. It’s easier to align on these in advance rather than negotiating product design, features, architecture or scope during the heat of delivery. 

  1. Powered by you - The system needs not only user adoption, but it needs to be a living collection of design and code ideas fed by a community of users.

  2. Make it easier to use than not - The best way to win user adoption is to make it easier to use than the alternatives – be those “rival” frameworks or the more traditional ad-hoc approach to design and dev. This requires constant evolution based on user feedback. 

  3. Iterate frequently - Few, if any, products are perfect right out of the gate. Especially when you try to scale them. We’ve made (and will continue to make) many mistakes along the way. Our plan to deal with these is through constant iteration. It took 55 alpha and beta iterations to get to a stable V1.

  4. Create things that are broadly relevant and fundamental - Lots of teams use our system and want different things added to it. Deciding what gets added can be tough, so we focus on providing the fundamental building blocks of a digital experience, including elements that are useful for multiple teams.

  5. Keep it simple and ensure it scales - A design system contains lots of things: design standards, coded UI elements, a contribution process. It’s easy to over-engineer and add lots of complexity. In our opinion, the more engineering or rules that get added, the more likely it will be wrong, brittle, hard to understand, maintain, and difficult to scale.

  6. Be transparent - When rallying support and adoption for a new product and way of working, the importance of communication and transparency cannot be understated. Often when we hit a roadblock in adoption or support, it was due to a lack of communication. We spent a lot of time refining how we communicated out release announcements, system changes, roadmap, feedback sessions, and tending to our Slack support channel.

Product architecture

Though it’s called a design system, it’s aimed at developers as much as designers, and it must always deliver value to the business. We tied these concerns together by building a conceptual framework that started with the brand and its values. From there we defined and articulated design principles – the high design level rules to help team members create on-brand experiences. We then designed foundational elements such as our typestack, button style, form elements, etc. Armed with these atomic design elements, turning them into coded UI elements was a small conceptual leap.

tds stack

Product roadmap

Our design system product roadmap evolved constantly. But the initial plan had three main phases.

Phase 1 - Alpha, test the hypothesis

Our first goal was to build out enough features to test usage and contribution models with a small group of users. We needed to flesh out the technical architecture (a core CSS library with a react component library deployed via versioned NPM packages) and align on design tooling (Sketch & InVision) so that our design team could easily share files and assets within teams as well as across tribe. We had to gauge whether different teams could use the system simultaneously. This concept was later used to verify our central design system hypothesis (teams working on a shared platform) was viable in our context… and it was! A small number of our teams were able to build experiences using a constantly evolving design system. 

Phase 2 - Beta, build a stable system

Once we were reasonably comfortable our teams could work on a shared design system, we invited more users to test its stability. This proved difficult as our initial architecture was not optimal (React component styles would clash with global CSS) and our UI components were filled with global CSS; limiting the ability of teams to integrate the system code into existing pages. We pivoted hard and restructured our code. Creating a stable and scalable product was of paramount importance so we delayed completion of Beta for 6 months while we optimized code architecture to improve stability and simplify code integration. 

Phase 3 - Version 1, scale the system

Once the system was architected and stable enough to scale, we launched Version 1 and switched our focus from the product to the practice and governance of the system. We prioritized product adoption and support through comprehensive resources, guilds, communication, and documentation. We improved our operational model by establishing community processes, and thought leadership to support organization-wide ownership of a design system. We divided this work into three main focus areas: product, practice, and governance which helped our team to scale the system.

tds product-practice guidance

Special attention needs to be paid to change management. Transparency and communication are key, with plenty of team touch-points to gather feedback and rally support. These team touch-points included sending out user surveys, hosting technical round-tables, doing lunch-and-learns and road shows. Demonstrating that we acted on feedback, and explained clearly how we track and fix bugs.

Build a team

A lot of the initial design system strategy and technical work can be done with a small team (a strategist, designer and developer - this could be one person!). However, to support ongoing product adoption, development, maintenance, and management, we quickly realized a dedicated team would be needed. Winning organization support for this required a strong product vision, benefits, principles, roadmap, ongoing demonstration of progress, and clear articulation of how these elements would come together to address business and user needs.

We’ve benefitted from having executive sponsors who understand the value of platform thinking and were receptive to our product strategy. This has enabled us to cultivate the support and investment needed to build out a design system product team. 

Our team has gone through a few iterations but has stabilized around the following seven roles:

  • Technical Product Owner

  • Product Strategist

  • 4 Developers

  • 1 Designer

It may be possible to create and run a design system without dedicated people, but we felt significant compromises on scope and ongoing growth would have to be made. To build a system that effectively evolves and scales requires investment, so diligent effort is required in selling the dream to executive sponsors with time spent defining benefits, articulating value, and tying the work back to business priorities.

Next steps for our team

With the first three phases of the product complete we have shifted focus to refining our Key Performance Indicators (KPIs), improving our documentation site, refining our community, improving the design tooling, and creating independently-versioned UI components.

We know the dedicated team will eventually become the bottleneck for scaling the system so we have begun to work on possible solutions. To continue product growth an open-source community-based contribution model will need to be embraced. We are currently tackling this challenge and will explore the topic of community further in a subsequent blog post.

Planning and rolling out a design system at an enterprise is an immensely rewarding challenge. Traversing the fields of design, development, product strategy, community engagement and change management… all the while finding ways to connect this work back to business strategy. Thanks to our sponsors for trusting us throughout this journey - it’s not every day that you are encouraged to take risks and to pioneer the unknown. We’ve got lots more to say about the journey we’ve been on. So stay tuned!

If you’re interested in learning more about our design system, visit our swanky new homepage

Authored by:
Neal McGann
Neal McGann
Neal McGann works on design strategy at TELUS. He supports the creation of digital experiences that are clear and simple.