Scaling the Front End - YouTube

Today, I'm going to talk

about how design systems can enable organizations to deliver

digital experiences with speed, while maintaining quality

and consistency at scale.

And I'm going to base all this on some work

that I've been doing recently with one of our clients.

And what I hope is to provide you

with a lot of little insights and nuggets of information

that you can take back, and you should be

able to apply to your own work.

So hello everyone.

My name's Ryan.

I'm a developer.

And what I really find interesting

is that intersection between design and code.

So I spend a lot of time thinking about

and working on front-end architecture and UI

development.

And so about a year ago, I started

working with one of our clients, Telus Digital,

to help them build and scale their design system.

And so if you haven't heard of Telus, that's OK.

It's because they're a Canadian company.

And they're actually one of the major Canadian national

telecoms, so a pretty big organization.

And ThoughtWorks has been partnering

with their digital arm, which is called Telus Digital,

over the past few years.

So Telus Digital creates a lot of their external internet

and mobile apps.

So telus.com is a very large e-commerce and marketing site.

They have account management websites and web applications,

a lot of one-off sites, as well as a whole collection

of mobile applications, as well--

so mostly web based, but a little bit

of mobile stuff in there, too.

They've grown really quickly over the past few years,

from a very small team into a large, 400-person technology

organization distributed across the country.

And with that kind of rapid growth

comes a lot of challenges with trying to scale.

And what I'll focus on is their challenges

with maintaining design consistency,

and managing their front-end architecture complexity.

And so now I'll go to the next slide.

If we start looking at some examples,

these are four different web applications

from Telus different websites in their ecosystem.

And what you can start to notice is

that there's a lot of inconsistencies going on.

Notice that the header is different in all four

of these different applications.

The search is in a different place,

and also functions differently.

The kind of patterns in use across these different products

are different on each page.

And if you were to actually interact with them,

you would see that not only is the styling

different on a lot of these common interface elements,

but they also behave very differently as well.

And then if you were to look under the hood at all

of these things, you then start to notice that there actually,

if you just take these four, they're

actually built over time by four different teams and four

different times.

So there's four different text [INAUDIBLE] under there

as well.

So what Telus Digital started to notice

was their customer experiences were becoming more and more

disjointed, as you can see, and the technology underneath that

was also becoming more and more disconnected, which was

making it very hard to manage.

And so they found themselves in a land of broken toys.

There was no real way to share designs or code

among these different applications,

because of all the disconnectedness

of their technologies.

So teams had a really hard time staying in sync,

because there is no kind of clear definition of what things

should look like, feel like, and how you should

interact with those things.

And so this kind of led to a frustrating experience

for users, because everything was different.

There was no kind of clear journey

through all of the different touch points,

where people could anchor on to certain patterns

and ways of interacting with their products.

And then they also noticed that they were doing

a lot of duplicated effort.

Teams were building, and then rebuilding the same things

over and over again, which is costly.

So the example that I like to use here

is, if you go back to the header,

it was implemented four different times

at least by those four different teams in these examples I

showed you, at least.

So if I wanted to make a change to that globally

and across the entire site, I would

have to coordinate with multiple teams

over multiple weeks of build, test, and deploy just

to make one very, very small change to the header.

And that's absolutely unacceptable.

And this is kind of what I want to talk about.

This isn't unique to Telus.

I think in my years at ThoughtWorks,

I've seen the same problem with most

of the clients I've been at.

What we have to do is we have to change

the way that we think about design

and about front-end development.

We have to start attacking it strategically

and systematically, especially when we're at scale.

This becomes very important.

So for the rest of this talk, what I want to do

is go into how we have kind of helped and worked

with Telus Digital to address these challenges by adopting

what's called "design system thinking."

So one of the first things that Telus Digital did

was try to kind of wrap their head around this concept,

and try and define their vision for what it means.

And I can really break this statement down--

this is how they defined it-- into two main pieces.

So one, we want to make it easier

for teams to collaborate and communicate

so they can stay in sync.

And then two, we want to be able to deliver digital

experiences-- web applications, mobile apps things like that--

we want to be able to deliver them fast,

while still maintaining consistency and a high quality

of design and code.

And so for this talk I'm going to break that down

into three key areas, where we address this in different ways,

to kind of bring design systems to life for Telus Digital.

And that's in areas of reuse, automation, and culture.

So without further ado, let's talk about reuse.

What we wanted to do was try and remove the duplicated effort

that teams were doing, and kind of be building and rebuilding

in the same kind of user interaction patterns

and interface components over and over,

so that we could reduce the ongoing cost of change.

And then we also wanted to try to unify the customer

experience by providing reusable components to these teams.

And the primary mechanism for doing this

is really a mindset shift.

Instead of thinking about web pages or web applications

as a series of unique pages or screens,

we instead think about them as collections of components.

And these components are--

they have clean boundaries.

And they can be assembled in different ways

to create different experiences.

And then they can be reused by different teams

across different applications to reduce

the ongoing costs of change and reduce duplicated effort.

So if we take one of their pages as an example,

this is a kind of Telus Plan Builder, as they call it,

where I'm customizing a phone plan.

And if we start to apply the concept of reusable components

to this page, we can very quickly

start to break it down into a very small number

of components.

And then these can form our reusable components

that get re-used across different applications.

So after we take that first step,

then what we can start to see is that not all

of these components are created equally.

If you look at something like the heading in blue,

or the paragraph in green, these are pretty simple.

These are your standard typography components,

UI elements.

They don't really make any sense unless they're

within the context of a web page or a web application.

But if you look at something on the bottom right

there, like the Chat that's very different.

The Chat, sitting behind that is maybe a person,

if you're talking to a real person through that chat,

or some kind of AI.

It's a very, very specific use case,

and that same Chat box might appear exactly the same

on every single place.

You don't want to arrange that in different places.

And so what we started to do was take this idea of components,

which is kind of very common these days

with technologies, such as React or View or Angular.

And we started to tease it apart.

And we kind of wound up with two main kind

of categories of components that we

use throughout Telus Digital.

If you look at the section on the left, Global

Header, the Chat, these are what we called "global elements."

And they're essentially API-backed what

we call "micro front-ends" that can be built and deployed

independently from the rest of the page in which they operate.

And these fall into this category,

because they're largely the same across the entire site

or across multiple applications within Telus,

so we want to be able to deliver them independently.

These things maintain their own data and their own state.

And they make their own API calls, often

to very specific APIs that's different than the rest

of the page.

And so for this, we used some technologies

such as React, Node.js, and Docker

to deploy them as containers, so they could be independently

deployed and maintained.

And then on the right, these are our foundational composable UI

components.

And we would distribute them to teams as a library

that we called the "core design system."

And teams could then take these.

They could arrange them in different ways.

They could extend them.

They could build on top of them with their own components,

and create the experience that they wanted to create,

all while staying within the bounds of the Telus interaction

patterns that we wanted to keep and maintain

across different products.

And we used React, again, because its focus

on component orientation is perfect for this type of work.

And we distributed this as an npm library,

so that teams could manage a dependency using proper version

control and integrate that at build time

into their application.

So a lot of really cool things started

happening when we structured things in this way.

We were able to form product teams

around the global elements, so that they

could maintain them separately and deploy them independently.

So that problem I talked about with the header,

you need multiple teams over multiple weeks of coordination.

Now you can do that with one team,

and you can deploy to production in a matter

of minutes or hours.

And then with the design system and these core reusable

components, teams are able to unify

across the different experiences like never

before, because they could share a single source of truth

for what things should look like, feel like, and behave.

So the next section I'll talk about is automation.

And we really tried to drive a mindset of let's just

automate all the things.

So as soon as new teams start up,

they have something they can plug into right away

and start delivering value without having

to, again, reinvent the wheel and build their own tooling.

So there's a lot I could talk about here.

So instead what I want to do is dive into something

very specific, and give you a little more detail about it,

really show you how something works.

And so what I want to dive into is a specific type

of testing called "visual regression testing."

I'm going to drive this through an example,

and actually show some code in a second.

But first, let's define what "visual regression" actually

means.

So what I show you here would be kind

of a simple, branded button component

that you would find in the core Telus design system.

This is actually it, rendered in all of its glory.

So a visual regression would be any kind

of unwanted change to the styles,

or any unexpected change to the visual style of that thing.

So it might be a change to the width.

That could be a visual regression bug.

It could be a change to the font size.

In that case, it's gotten bigger.

That could be a visual regression bug.

Or it could be something that maybe

seems a bit more obvious, especially

with projectors and such, would be a change to the background

color from the kind of branded green

that we want to maybe black, which we don't want.

And so I'll use this for this example.

So what I want to do is walk you through a quick example

of how this might work.

The interesting thing is, I think to a lot of us, who

are able to distinguish between colors very well at least,

this seems very obvious.

It's like, well, duh that's wrong.

But historically, this has been very

hard to do any kind of automated testing around.

It's always had to be someone has

to log into QA or to production, and click

through the entire site to make sure everything

looks all right.

And that means you usually don't do it.

And then later, you find out things are wrong,

and you fixed it.

But we can do better now.

So let's look at some code.

This is two tests to test the visual regression, that button

component.

It's written using JavaScript and React.

So if you don't know those languages, it doesn't matter.

It's really just about the brevity and the ideas

going on here.

The general idea with a test like this

is that we generate images of our components

of our application over time.

And we compare those images to see when and if it's changing

when we expected it to or if we didn't.

And that can tell us if there's visual regressions happening.

In this first test, what we actually do is we

render the button three times in a row.

The primary one is green, secondary one is purple,

and the inverted one is like an inverse.

It's transparent.

In the second test, we're doing something cool, where we

are emulating a mobile device.

And on a mobile device, this button component

will naturally stretch to fill the full kind of container

that it has so you have a nice, big tap area for your finger.

And then we can start to run tests on this.

If we execute this test for the first time,

we'll get some output that looks a little bit like this.

The test passed.

That's awesome.

That's what we wanted.

And the great part is, we get a couple of screenshots

or snapshots dropped into our codebase, one

for each of those tests.

These form what's called the "baseline" for that component

now.

And we can check this into our code base

so that we can remember, this is what the button

is supposed to look like, in this case in all three variants

that we have in a mobile devices.

Now let's say we introduce a visual regression.

We've actually changed the green to black

for our primary button.

And let's see what happens.

Our tests fail.

Yay-- that's what we wanted to happen.

And the cool part is, we get a little bit

of output in the middle there.

What's happening with this test is we are using a framework

to do pixel by pixel comparison of two images to say,

is this image like that previous image, like our baseline?

And if not, tell me how much the variance is.

In this case, it's 1.8%.

And actually, how many exact pixels

are different between those two images, which is pretty neat.

And so when we execute this and it fails,

we also get two more images in our codebase as well.

I'm sorry for the blurriness in that screen.

So these images this time are pretty wide,

and it's divided into three sections.

On the left is the original baseline.

That's what it should look like.

And on the right is the result of changing the green to black,

as you can see.

That's probably not what we want.

And in the middle is the diff.

The grayed-out parts are where the pixels match,

and the red would be where they didn't match.

So now me, as a human, I can go in and easily diagnose

what was going on.

And on the chance that I actually

did want to change the button to black,

I have a flow that I can take to change

the baseline to that black one, and then I

can move on from there.

I think this has been really powerful to give us

a lot of confidence as we work with our CSS codebase.

And on most of the projects I've been on with ThoughtWorks,

at least the front-end projects, that

is, the CSS has been the thing that no one wants to touch,

no one wants to change.

And God forbid you delete any lines from your CSS,

because you have no idea what's going

to happen when you do that.

And so it ends up just growing, and growing, and growing.

And the complexity gets more and more.

But with new testing strategies like this,

we can start to aggressively refactor.

And actually, you can delete lines of CSS,

and be confident that that's not going to screw up

your entire application now.

And so we helped pioneer this on the design system team

with Telus Digital.

And now, a lot of teams actually run tests

just like this on larger chunks of their application,

or even the entire thing.

And they do it in their build pipeline on every check

into the code base.

So we have a lot of confidence that the visual styles are

being maintained over time, so that customer experience

is being maintained, too.

If I go on to the last section I want

to talk about, it's about people, and more

specifically about how we incorporate culture

into the systems that we're building.

While each organization has their own culture,

at Telus Digital, the example I'll use

is that they're very highly built off

of agile principles as well as open source principles.

And so we wanted to try and embed that

into the design system.

So I want to talk about the ownership model that we used,

and how it evolved over time.

For a long time, we had a centralized ownership

model around some of the reusable components

and some of this automated tooling,

in which me and the rest of the central team,

we would produce a product and a service

to a lot of teams which would consume it.

And this is fine for simplicity and maybe speed of delivery

at times, but kind of over time, as the number of consumers

of those components grew and the number

of ways they wanted to use them changed,

it became harder and harder to deliver

that service and that product in the timely manner

that they wanted.

And the longer that team went on,

the less contacts that we had on the day-to-day

challenges that teams were facing,

and the creative ways of problem solving

in the space of design and front-end development.

So we ended up--

what we wanted to do was better leverage

the collective wisdom of all the teams using this system.

And so they've largely switched now to a federated ownership

model, where the key being that direction and contribution

to the system are largely federated to others

who want to be involved.

So this equips more people to kind of

be evangelists of the system.

It brings in new perspectives and new ideas

that we hadn't previously thought of before.

But a system such as this, you can easily

see how, as that outside circle grows,

this could get unwieldy and out of hand pretty fast.

So I think that the central team in this model

still remains very important, because this

is very similar to a lot of open source projects out there.

That central team can still provide ongoing continuity,

thought leadership, and still provide

underlying tooling for all the teams trying to use this.

So this is the model that they currently have.

All of these things-- the reusable components,

global elements, and the design system, the kind of automated

tooling and testing including visual regression

testing, and the culture of contribution and ownership--

is all part of what's called the Telus Design System.

And it's open source.

And so I invite you to check out these two links,

and you'll find everything that I've

talked about today, and a lot more into a lot more detail.

The top link is kind of the main documentation

portal that leads you to the core component catalog.

And the bottom link is the codebase.

It's under active development right now.

You can go check it out and see what's going on.

It's pretty cool.

And so I think I'll just leave you

with what is this doing at Telus Digital,

and what can it do for you?

What we've seen is designers and developers on the ground

spend less time reinventing the wheel over and over

and over again, and more time solving

the problems of the customers, which is what their job is.

So I think that is more fulfilling work

than what they may have been doing before.

Secondly, they're able to deliver products

to market much, much faster.

Because a team has all the tools necessary to get up

and running very quickly, and deploy

digital experience to production in a matter

of maybe hours or even minutes.

And then finally, the customers are getting a better

experience, because teams are better able to stay in sync.

They have reusable components to unify the end experience.

And so teams can stop optimizing for individual silos,

and they can spend more time optimizing

the overall experience.

So that's all I've got.

Thank you all very much.

Thanks for listening.

[APPLAUSE]