Ask not what your design system can do for you...

Marcos Peebles (@MarcosPeebles) / James Nash (@c1rrus) / Matteo Pescarin (@ilpeach)

Presenters introduce themselves
Initial statements:

Why DS?
What are DS?
How to interact with DS?

Hi, I'm Marcos and this is James, a true legend. A webmaster. He's been noodling around the WWW (world wide web, remember when we still called it that?) for about 20 years now. He took some detours along the way, working on a smartphone operating system and, later, entering the realm of UX. However, he keep finding himself gravitating back towards webby things, after all, a true leopard doesn't change his spots :)

Hi, I'm James and this is Marcos (also a real webmaster) he's been around even longer then me, spreading the love amongst 4 different continents. Jumping from code to design and back while managing his way around...

We both work for the digital transformation agency Buildit @ Wipro Digital.

Today we've heard a lot of great stuff about the state of our web browsers and how we can construct nifty things for them to render.

We're now going to talk about something that can help us as we go about making those nifty things: Design Systems.

Why do we have them?
What are they?
How we can all interact with them?

Hands up if you have...

...heard of "design systems"

...worked on a design system

...a 20 second elevator pitch for design systems

Tales from the trenches

Freya the FED
Only gets designs after they were signed off
Finds lots of issues

Meet Freya the front-end developer.

Freya is working on a project to build a small microsite. By the time she gets to see actual visual designs, they have already been through numerous iterations and, at long last, signed off by the client.

Grudgingly, she begins analysing the designs. For the 5 page microsite this project is meant to deliver, she counts 4 distinct button designs, 3 modal overlay styles and 7 different font sizes.

The layout for the "desktop" design assumes a different ordering of HTML elements than the corresponding "mobile" design.

All the placeholder texts for headings, user names and product features fit perfectly on one line - how convenient!

If only she had been involved earlier. These design bugs could have been eliminated before they were "signed off", let alone got passed on to the dev team.

Dave the designer
Wants to share work but every method is blocked

Say hello to Dave the designer!

Dave has produced some visual mock-ups and needs to share them with the team. His boss, Beth, has repeatedly stressed the importance of sharing his work early and often with the rest of the team.

Unfortunately for him, access to InVision, ZeroHeight and Zeplin is blocked by the company's network.

Dropbox, OneDrive and WeTransfer are all blocked as well.

He therefore attaches his design files to an email and hits send. It bounces back - "maximum attachment size exceeded"

He tries to use a USB stick only to discover that IT has diabled removable media on his machine.

Someone tells him that there's an MS SharePoint site on the intranet he can use to share files.

He loses the will to live.

Beth the boss
Important produce launch in Nov. Marketing site must go live then.
She trims UX down
Design takes longer than needed
Bosses devs around
Site goes live but is crap

What about when you're the business stakeholder?

The company will be making a very important, flagship product launch. It's timed to hit the Christmas market. The accompanying marketing site therefore must go live in November.

Beth the boss is in charge of getting that site built. By April her UX team has done their research and produced a thoughtful and delightful UI concept. However, it is ambitious in its scope and Beth's Gannt charts tell her there's no way it will all get designed and built by November. Luckily, she has a good handle on what the customers want and she cherrypicks the elements of the UI concept that she really needs and fit her budget.

It's now August. Visual design was meant to have finished a month ago, but more design iterations than anticipated were needed. Also, that idiot Mark from marketing didn't help with his lengthy brand compliance reviews. The remaining time and budget left for build is now extremely tight. Beth knows this and is really stressing out over it.

Unsurprisingly, the devs feel the same way and give Beth a hard time. Every sprint planning session feels like a battle. Apparently there are problems in the designs. Those have been signed off though, so there's no way Beth's re-opening that particular can of worms. She soon realises that if she pushes hard enough, the developers eventually give in a build what she wanted. They grumble something about "hacks", but as far as Beth can see it looks great. Probably they're just being divas, or lazy, or both. So annoying!

A site eventually goes up on staging in October. There was a lot of haggling during the dev phase and Beth had to concede some of the features she really wanted in order to meet her milestones. It doesn't quite live up to her original vision, but it'll have to do.

The QA team soon come back with all kinds of problems. The homepage takes about 20 seconds to load. The layout and nav on some Android phones is a bit screwy.

It's November. The site needs to launch now, so Beth gives the green light to go live. She tells her devs to work over the weekend and fix the slow homepage on the live site. As for those Android phones - who cares? Everyone's using iPhones, right?

Within a week, visitor stats to the site have dropped dramatically. A whole sub-reddit has sprung up with parodies of her site. Beth's boss calls her into his office for "a chat".

Handovers? Hangovers!
Draconian IT
Poor quality deliverables

Hangovers due to handovers
Draconian IT
Failed projects
What have we done about it?

Hand-over to Marcos (...)

Some of these stories will surely seem familiar.

Whether its hangovers caused by handovers, draconian IT policies or projects failing to deliver - everyone involved has their pain points.

There are of course plenty more examples. Ever tried to find the web-font files for the corporate typeface? Have you attempted to style the <select> element? You get the idea.

Fortunately, the web community has been busy addressing these kinds of pains over the years. Let's see what they've been up to...

Img credit: https://www.flickr.com/photos/143842337@N03/32590257662/

Modularity

Modular is NOT new. Look at what mankind has done. Example of Brasília by Lúcio Costa and Oscar Niemeyer (Inspired by Paul Robert Lloyd's article: Designing Systems, Part 1: Theory, Practice, and the Unfortunate In-between)

Templating lang, CSS tech, Design Tools, Style guide docs

Less redundancy, Better fit, scalable, less £££

We realised some time ago that our websites tend to be made up of recurring elements: Headers, footers, links, buttons, etc.

On the dev side, ever more sophisticated templating languages have allowed us to write the markup for such elements once and then re-use them many times over. Likewise, techniques and tools to better scale HTML, CSS and JS to large and complex projects have arisen.

Designers have increasingly been complementing their full-page mock-ups with styleguide documents that lay out the styles in a more modular way. Their tooling improved too. Painstakingly hand-crafted PDF documents have given way to modular vector graphics. Sending large files around has been replaced by cloud-based sharing and synchronisation services.

This modular mindset has gone a long way towards smoothing the traditional handover between the Daves and Freyas of this world.

It has also helped surface and eliminate unintentional inconsistencies in the design and implementation. That in turn improves usability.

Businesses' bottom lines have also benefitted, since there's less redundancy in the work. Less stuff to design and build is also less stuff to maintain later on!

Img credit: https://upload.wikimedia.org/wikipedia/commons/6/62/Bras%C3%ADlia_Panor%C3%A2mica.jpg

Modularity challenges

Breaking down
Organising
Showcasing
Documenting

...components

New challenges from modularity
Quote tools for UI/UX (The Best Mockup & Wireframing Design Tools & Apps for UI/UX Designers)
What is what? Little, the same, naming?
Quote styleguides examples ()

Fantastic! Everybody's happy now... right?

Well, yes. But, this modular mindset introduced a new set of challenges:

Is naming important? How far should we break down our UI components? What about UI tooling? Can code REALLY match design and vice-versa when out of context? As we implement the UI components in code, can we showcase them individually? Etc.

Img credit: https://upload.wikimedia.org/wikipedia/commons/a/ac/Lego_dublo_arto_alanenpaa_2.JPG

Once again, our methods and tools needed to evolve.

Methodologies like "Atomic Design" gave us a simple vocabulary and mental model that helped us better organise our libraries of UI components.

Style guide website generators like ,Pattern Lab, Fractal and StoryBook arrived on the scene, saving us from manually building and maintaining special websites in order showcase our UI component implementations. By automating their production, these tools have made it easy for style guide websites to always be up-to-date.

Since style guide websites contain the actual UI components rather than static design mock-ups, they let everyone involved easily see how the UI components respond to different browsers, devices or content.

Our style guides had come alive!

Instead of just improving handovers, we were blurring the boundaries between the various disciplines. Freya, Dave and even Beth could be consumers of and contributors to the living styleguide.

We began to wonder whether we could make handovers a thing of the past?

¡El trío fantástico!

Dave Olsen
Brian Muenzenmeyer
Brad Frost

Silhouette of a hero standing on a cliff looking out towards a huge monster on the horizon

Living style guides how to face
Design & dev collab critical.
UIs and Code need to be:
- Device-agnostic
- Inclusive
- Performant
- Resilient
Living style guide are facilitators

Think about it. It should go without saying that a modern web experience, and thus the UI components it is made out of, must be:

Device-agnostic: They need to work well with arbitrary viewport sizes and input mechanisms.
Inclusive: People with all kinds of impairments need to be able to interact with them, potentially with the help of assistive technologies.
Performant: We know that slow page loads and sluggish UI performance will frustrate users. Every part of our UI therefore needs to be as efficient as possible.
Resilient: Our UI components may be populated with unpredictable content from a CMS. Will they cope well with long words, lengthy runs of text or unusually proportioned images? They might not run in ideal conditions either. Do they work without JavaScript? Or offline? Or in IE8?

Figuring out how to meet all these criteria has to be a team effort. Dave the designer, Freya the front-end developer and also Ursula from UX will need to put their heads together.

And yet, a wireframe document or a static visual design can never anticipate or express all the nuances that need to go into the actual implementation. Only code can do that.

A living style guide can be the means by which developers can demonstrate their work to the other disciplines and get their feedback and input. Changes can be made to the code and previewed almost instantly so the whole team can rapidly iterate the actual UI components until they are done.

Basically, living style guides are the shit!

Img credit: https://unsplash.com/search/photos/mountains?photo=zwdlsuRa_xc and https://www.flickr.com/photos/tristanf/3034889893/

Zombie wearing a T-shirt labelled 'Style guide'

New challenges from living style guides
Sharing code with prod?
Keeping everything in sync?
Supporting multiple products?
Keeping people in the loop

Unsurprisingly, crafting well organised, beautiful, living styleguides is rapidly becoming the de-facto way we approach much of our UI work.

However, our journey does not end there!

Once you have a living styleguide, a whole slew of new questions inevitably arise...

How do we share code between our living style guide and our actual website?

How do we continually keep design artefacts, living style guides and the website built from them up-to-date and in sync?

What happens when we need to support more than a single website?

How do we cope with multiple CMSes and front-end frameworks?

How do you keep everyone who needs to be involved in the loop?

Img credit: https://unsplash.com/search/photos/forest?photo=4dRyVyXN6Lg

Don't give up, it is tough!

Discover, Design, Code, Document, Publish, Organise...

Tough challenges.
Don't give up! 6 big blocks, yes we can! Make DS great aga.. eeer sorry got carried away, but the idea is NO WALLS!
(1) Discover/Research * (2) Design & (3) Build * (4) Document * (5) Publish
Organise the former (6)

Nathan Curtis talks about the 5 steps, we added organise -with a s- as a sixth, because we can :)

With so many questions and challenges, you could be forgiven for throwing your hands up in despair and running back to PhotoShop's bosom.

That's why it is so important to remember how we got here. Modular designs and living style guides are better than what went before.They are solutions to their predecessors' problems.

If you didn't run back to PhotoShop and are instead busy trying to tackle these kinds of challenges, then you have unwittingly begun work on your very own design system!

It's tough!

Img credit: https://commons.wikimedia.org/wiki/File:Old_map-Bastrop-1887.jpg

Unfortunately, no one can be told what a design system is.

You have to see it for yourself.

Design system is not one thing
Covers code, designs, docs, tools & people
Should've been "design eco-system"

Hand-over to James (...)

People struggle to explain design systems succinctly because they are not one thing.

Depending on your point of view, they might be described the effort to scale up your living style guide to serve an entire organisation.

From a business person's perspective, they could be considered the means by which an organisation gets more efficient at delivering consistent, high-quality UIs.

The marketing team might simply think of them as the replacement for their old brand guidelines PDF.

Maybe they are the never-ending struggle to discover the perfect way to make interactive products. And we are all doomed to persue that holy grail for ever and ever!

The one thing everyone does agree on is that design systems must encompass code, designs, documentation, tools and people. Furthermore, they are never "done" - in order to continuously deliver value, they must themselves be maintained continuously.

Perhaps "design eco-system" would have been a more appropriate name!

But what new challenges do they bring with them?

A design system isn't a project.

It is a product, serving products.

Nathan Curtis

Product not project
Inherently bespoke
Need support form the org -->
Org change
Doing it is hard

Organisations need to think of their design systems as a product. They have no end. They need to continuously adapt, improve and evolve in order to remain useful.

This quote from Nathan, who has written tons of useful stuff about design systems, sums up that sentiment nicely.

Design Systems are also inherently bespoke. They will be geared towards supporting and improving your company's processes and needs. The UI libraries will be tailored to your choice of technologies, implement your brand's look and feel and only contain the UI components you need.

In her recent book "Design Systems", Alla Kholmatova does a great job of showcasing how broad the spectrum of design systems is.

So, while I encourage you to draw inspiration from what others have done, do not make the mistake of assuming you can simply copy their solution.

That in turn leads to the realisation that there needs to be a permanent team, perhaps even a new department, that can tend to and promote the design system. They need to be multi-disciplinary. They need to be funded. And they need to have a plan.

What began as Freya, David and Beth eliminating frustrations in their work has turned into a monster that will reshape the very organisation they work within!

Make no mistake. Establishing a design system is hard.

Really. Fucking. Hard.

Many organisations that now have effective design systems in place, only pulled them off after years of trying. Frequently they will have gone through several failed attempts before eventually succeeding.

Benefits seem obvious
Actual [ $ . £ . € ] value hard to establish though
Something boss, PM, UX, marketing, etc. can help with.
Something you, as a user, get FOR FREE.

Sharing the burden of work and the knowledge acquired from many, individual projects should be a no-brainer. But try calculating the dollar value of that. That is incredibly hard. Consequently, it can be a huge challenge to pursuade Billy the bean counter that setting up a design system will deliver a return on investment.

To all the Beths in the audience: Do you currently measure how much effort is spent across your entire organisation on UI-related work? Can you estimate what might be saved?

What about Mark from marketing? If you're here Mark, are you able to estimate the monetary value of applying the brand more consistently across products?

Ursula from UX, can you provide figures for how conversions might increase or user suport costs might drop, if the interface of your various products behaves more consistently?

Gathering the facts and figures that help justify creating a design system and keeping it alive is something you can all contribute to!

Great tools for web dev
Not so great for native
What about non-visual stuff?
Something for everyone!

We've seen a lot of great tools emerge that can help the likes of Freya the front-end dev. Tools that make it easy to generate living style guides, update visual design templates, etc. ...when working with web technologies.

What about Andy the Android developer though? If you build native apps for non-web platforms, the tooling situation is far less mature. Shouldn't there be native equivalents to Pattern Lab for Android, iOS and Windows? If you're an Andy, this is your chance to get stuck in and build one!

How about non-visual UIs? Alexa, Siri and Google Assistant are user interfaces. You probably want your services on them to also provide consistent UI behaviour. Perhaps you also want your company's brand to be recognisable via them. Shouldn't your design system encompass that too? Make it the home for earcons, jingles and tone-of-voice guidelines. Sam the sound designer, if you're here, get involved!

There's something here for everyone. We're all still figuring this whole "design system" thing out...

Img credit: https://www.flickr.com/photos/sheeppurple/3693959699/

To-Do List

Do your homework
- Component inventories
- Dev team surveys
- Evaluate tools
- Gather stats
Start small
- Share colours, fonts, icons, etc.
- Establish naming conventions

Moar To-Do List!

Communicate
- Write things down
- Make things easy to find & access
- Set up comms channels
Join us!
- Design Systems Slack
- London meet-ups
- Share things!

Communicate / tips are non exhaustive
- Write things down / Tips
- Make things easy to find & access / Tips
  - Design systems don’t start with components by Clearleft and
  - Modular Web Design
- Set up comms channels / Tips
  - Use ~~Email~~, Slack, Messenger, Whatsapp, Kik, Wechat, Skype, Hangouts, Twitter, Telegram, whatever social media suits you. Even Snapchat and Instagram for the very brave.
- Shout from the rooftops / Tips
  - Explain to as many people as possible what it is.
  - Look at their faces, understand why they do not understand.
  - Do not quit, repeat, refine, iterate.
Join us! (tips are non exhaustive :)
- Design Systems Slack / Tips
  - Design System Slack Channel
  - Design Systems Curated.co
- London meet-ups / Tips
  - Look for the London channel in the Design System Slack
- Share things! / Tips

And so, my fellow webmasters:

Ask not what your design system can do for you...

...ask what you can do for your design system.