Getting buy-in for building a design system and team of five behind it

A presentation at Design Systems Meetup in July 2019 in Brno, Czechia by Jan Toman

Getting buy-in for building a design system (and team of five 10 behind it) Design Systems Meetup, July 2019
steps that did work and were essential in my opinion - some steps that didn’t work that much - a lot of about communication – what we’ve communicated, to whom and what worked well - change management - how team grew over the course of two years, which people were hired and why

Making travel better at Jan Toman Design System Lead at Kiwi.com Previously working for & Twitter: @HonzaTmn
I do web stuff for more than 10 years, I have worked as front-end developer or product manager - almost 2 years ago I’ve joined with design system in kiwi.com - kiwi.com – travel startup (or just company) focusing on connecting flights that weren’t supposed to be connected - and that just got an huge investment from General Atlantic

A bit of context @HonzaTmn

August 2017 Hired as 5th designer. The plan 🚀 To grow to 15 designers in the next 12 months. ! 🎨 Task Prepare UI kit for growing design team. Time frame 3 – 6 months long project. ⏱ @HonzaTmn
task – situation where a lot of you can be too, with some part-time allocation

My very first challenge “How might I prove that design system is worth a full-time investment?”
I could create a palette of colors, typography, or etc, but I wouldn’t even know how to sell it to current designers. I was a newcomer, they were there for a long time. -

The first three months 🔬 - For me, it was totally new company and I knew nothing. Blank paper. - All Medium article tells you to start with styleguide – create a palette of colors, typography, or etc, -But I wouldn’t even know how to sell it to current designers. I was a newcomer, they were there for a long time. And another thing – current designers were stronger visual designers than I am. - Starting as a UX designer – with data. And to get some data, I needed research.

🔬 ✂ Interface audits „Peak into other design systems“ 👀 👀 👀 📝 ☕☕ Talking with people ! t? ha #w
And there is a lot of related research to design systems, but I would like to speak about the last one – actual talking with people. - Some people knew that I will be working on UI kit, but I framed also as „get to know each other a bit because I am new here“

http://bit.ly/ds-research @HonzaTmn
I’ve described this in the article I wrote for our design blog, with all possible questions I asked. Check it for more info. - But basically, I framed it as that I want to understand how they work, what tools they use, if there is already something existing. -And I asked about design system and if there is something there are afraid of.

Top insights from research (and how they affected future communication)
Every insight is an opportunities to solve. - So what were some insights I’ve learned 🔬

Existing styleguide 🎨 No one used it, though. 👍 👍 ✍ 👍 😨 Fear for creativity Fear that the design system will limit them and will lead to worse UX Support from devs A looot of tools They just hate coding something repeatedly. Our design files were everywhere and nowhere. 👏 🧰 @HonzaTmn
palette and typo defined – it can be used and iterated. It will help to give a feeling that you are just trying to help to make it more useful - limiting creativity – keep people closely involved in decisions, don’t push design guidelines, be open to any change and keep them playing with atomic component to discover patterns - developer support – that’s great. they are stakeholders and that can help. Also, developers mentioned „open source“ several times – note for me for future. It was important to them, we can use it. - tools – easy problem to solve usually, that’s what I’ve started with – with reasoning that we will save some money and we will have design files in place where we need them

Listen carefully. Even small details matter. 👂

Lunch talks matter too a.k.a using „silent persuasion strategy“
🍛 🍲 ☕ 🥡 But what was important that conversations started. We already started to talk about „design system“ with the team.

♿ Priming Building a case for coding Mentioning keywords like „goals“, „roadmap“ or „accessibility“ now and then. Setting the expectation that all components will be codified eventually. 🎯 5 It’s here to help Curator, not creator It’s not about limiting anyone creativity, it’s the opposite. Keeping designers in charge of decisions, be more a curator than creator. 7 - mentioning words – so it just does feel like product that we are building - it will happen in code – even that it took another 4 months before we actually started with code - help them – get rid of stuff they find boring (and I found which is it in research) - in charge – removing my ego from it, but talk more about this one 🧞 @HonzaTmn

Keeping designers in charge? What does it mean in practice?
One of my first steps on styleguide was to clear palette (and introduce some logical structure in it) 🧞

🔬 „We already have colors and text styles.“ ❓ ❓ ⁉ @HonzaTmn
As designers mentioned in research, they already had a typography and colors defined.

Task: Clear typography and colors. „This is work-in-progress.“ @HonzaTmn
One of my first steps on styleguide was to clear palette (and introduce some logical structure in it). - Where I cleared a color palette and typography, I needed to collect a feedback on it somehow. - So I took existing website and did one thing only – adopted this palette and typography – nothing else. -

„You decide if it’s enough.“ If not? Iterate, improve, let them check again. @HonzaTmn
And I gave them power to decide if it’s good enough or we need to define more styles. - The good thing? Visual style didn’t change basically, it was just tweaking details and documenting what we’ve used for it. In practice => we didn’t need product managers involved.

Palette after a year of iterations @HonzaTmn
And it wasn’t a final palette, not at all. It was never meant to be. We tweaked it a lot during last year and improve it, but situation today is different – majority of designers aren’t questioning these choices that much.

Small iterations. Often. It doesn’t need to be perfect. It never will be anyway.

The effect of this strategy People believed in styleguide, so they started to use it. #ikeaEffect

Next 3 to 6 months 🗣 - repeating the same steps with all component – just taking it from the current UI and putting it Sketch - and communication - what does it mean in practice?

@HonzaTmn
1st step – creating a channel with clear purpose.

@HonzaTmn
2nd step – be as transparent as possible. - This is my first post in that slack channel

@HonzaTmn
encourage people to break it

A lot of small changes. Often. @HonzaTmn
Designers reported issue or had request, and 15 minutes later available in Sketch. - I was very flexible. If people find bug, fix it as soon as possible – because if not, it might lead to people not using it because it is blocking them. -

Giving them control. Again. @HonzaTmn
it wasn’t important to me which component will be the next

Silent weekly updates To management. 🤫 - just to let them know that something systematic is happening in design (for now) - using existing channels -All these small steps, all this communication and flexibility was about one thing – to gain trust of designers. @HonzaTmn

🤜🤛 It’s all about gaining trust.
Because in the end, it’s all about gaining trust. -Because people trusted it (and all activity was exposed!), people used our UI kit component from the day one. They’ve felt that they can count on me if there is any request and that it can be added as soon as possible.

December 2017 … more & more requests coming. ☃ - People used UI kit on the daily basis, saying that it saves their time when designing. -That also meant that designers requested more and more components and variations, documentation of visual style needed to be written, etc.

December 2017 Me switching full-time on improving UI kit Goal: support 9 designers 🎆 🥂 „Team“: 1 UX Designer @HonzaTmn
That took 6 months of extra work, communication and selling the idea. - I was discussing with my boss a possibility of hiring a developer into design team – for coding components.

January 2018 Junior developer is joining our design team However, not for coding UI kit… @HonzaTmn
The original plan: he should focus mostly on building interactive prototypes. On components partially, when there is no prototype to build. - Design lead just didn’t see a value for hiring someone only for coding components. -What did I do wrong? Probably didn’t stress enough to design lead that we really need someone to code it and who needs to be design precise.

Current challenge “How might I get someone to code our UI components?“

🔬 Using research insights 👍 👍 👍 Support from devs They just hate coding something repeatedly. 👏 @HonzaTmn
If you remember, I’ve mentioned that developers were in from the day one – they just waited for someone to unify designers and they want to build component library that can be reused. - And now we had a UI kit with a small amount of components to code, so we finally have something to start with.

👍 👍 👍 Support from devs They just hate coding something repeatedly. 👏 Meeting with lead engineer to discuss options 🍻
@HonzaTmn If you remember, I’ve mentioned that developers were in from the day one – they just waited for someone to unify designers and they want to build component library that can be reused. - And now we had a UI kit with a small amount of components to code, so we finally have something to start with.

🤝 Our remote team will code UI components „They need it anyway for their new project.“ „Team“: 1 UX Designer + Remote team coding UI kit ‼ @HonzaTmn
What helped here? That designers created new project already with components from UI kit in Sketch, so there was a common understanding, that it can be reused. - What did it mean in the practice? That there was another product manager who was setting that team priorities.

🧟 March/April 2018 – Retrospective No time Partial coverage Not compliant Team’s priority was to deliver their project, not a library of reusable components. Not every variation was done, so it was basically unusable by other teams. Component’s weren’t pixel perfect, bad browser support, no test coverage. ⏰ - Didn’t work, we’ve lost 2 or 3 months. - But it gave me some argument for getting someone fully dedicated. Some arguments I could work with. - 🏚

🧟 No time Partial coverage Not compliant Team’s priority was to deliver their project, not a library of reusable components. Not every variation was done, so it was basically unusable by other teams. Component’s weren’t pixel perfect, bad browser support, no test coverage. ⏰ Meeting with lead engineer again
So all we met again and trying to find out why. Then we decide that we will go in other direction 🏚 💡 🤔

🤝 Our new junior developer will code UI components + that coder from design team will help too. „Team“: 1 UX Designer + 1,5 junior (but dedicated!) developers
It was pretty cheap for company. Low risk. - And both selected guys were also partially designers, so they have pretty good eye for coding pixel-perfect components. - team still was very unoﬃcial – dev team basically borrowed us one guy who just started in the company and there was plan to take him back if there are some other priorities

What else was 🎉 happening? How did we ensure that our design system won’t be forgotten?
But what was important that conversations started. We already started to talk about „design system“ with the team.

🚀New name Improving UI kit New components, new variations, a lot of UI kit improvements. Boosting the product feeling of our design system by giving it a unique name. ! 🗃 Orbit.Kiwi Improving visibility Creating a single source of truth for everything design systems related. Presenting design system on „AllDevs“ (company platform for sharing knowledge) 🎙 - new components – and of course, publishing changes on Slack channel, so people still felt engaged and we improved a visibility of the whole project - name - a lot of people started to mention it as KiwiKit (original name), UI kit, component library, design system, and it was just messy. Also, Slack channels related to design system was getting out of hand. - talk about some points little more, because two things from this were game-changing and I believe that they were the most important things that happened in kiwi.com to push design system

Creating name
So we voted for a new name (Orbit) and when announced, people started to make jokes. - Everything related to design system acticities had „orbit“ before, so it was clear what belongs to design system and what doesn’t. -

identity Creating name Connecting the unconnected
People started to see „Orbit“ word and emojis on Slack and asked „what is this project?“ - We had a logo & and we even used our company slogan „Connecting the unconnected“ as a headline

L Orbit.Kiwi Single source of truth.
orbit.kiwi = probably the most important thing that happened. we created a space where everything lived. - we use wordpress for it – which from technology POV? Not nice. But it works. And that’s another take away here – make it work, care about details later. - we introduced our principles there, we collected all documentation for visual style and published it there too. We’ve shown that this will be the place where all components will be available.

Orbit.Kiwi Roadmap Public for everyone
Most importantly – we published roadmap – high level overview of things we focus on. For more details, we had component status page.

Orbit.Kiwi Component status Public for everyone
So people knew what is planned
The results: much less questions of what is planned, stronger feeling that we know what we are doing and that we have some clear direction

@HonzaTmn
we also wanted to get some data from it: we have Google Analytics there, and people can send us feedback through Hotjar. Easy to implement but very useful data.

July 2018 Almost one year after my start 🌤 - People used UI kit on the daily basis, saying that it saves their time when designing. -That also meant that designers requested more and more components and variations, documentation of visual style needed to be written, etc.

🚀 Company sees us as „Orbit team“ 1 Product / UX + 2 React Developers + 1 UI Engineer
during those 3 months, we convinced design lead that we need full time of the second FE developer and with some reasoning and discussion (and not that many prototypes needed), we got it. - what also happened, that devs from other teams started to be interested in Orbit and wanted to help. Mostly one guy was consulting tech decisions for our junior devs. - and one of junior developers wanted to focus more on UI design, so he switched the role

Full-time focus. A few months later. October ☔ 2018

40 components ready In Sketch & coded in React, all tested and maintained. O 🕴 ⚖ Improving adoption Product teams started replacing old components in code. New users Good feedback New internal „clients“: business development, marketing, community & event team Getting a lot of good feedback from all over the company. 👏 @HonzaTmn

Motivation to continue is high From team and also the company. 🥳

No accessibility And it’s starting to be a problem. 🚧 Slowing down delivery 🐢 There is just too many people using it and we don’t have time to cover all requests ❌ 📈 Missing design docs No strong metrics However, we have bigger issues. And company is starting with OKRs, so we need to figure out metrics too. L @HonzaTmn
the last one about documentation – some people asked about it but we didn’t need it that much (and it was a mistake to not solve) - the point of this is that we had very real problems to solve, so we could start conversations - The first ones – we could hire a new developer to solve it. In this point, with so many clients in the company? It was very easy to get support for it -

No accessibility And it’s starting to be a problem. 🚧 Slowing down delivery 🐢 There is just too many people using it and we don’t have time to cover all requests 🦒 Solution: hiring 3rd developer 🏀 @HonzaTmn
The first ones – we could hire a new developer to solve it. In this point, with so many clients in the company? It was very easy to get support for it.) - the last one about documentation – some people asked about it but we didn’t need it that much (and it was a mistake to not solve)

📈 ❌ No strong metrics And company is starting with OKRs, so we need to figure out our metrics too. @HonzaTmn
It’s still an issue. We are playing with some code analysis and trying to get some data from QA testing but we still didn’t crack it - Currently, we just communicate that we need one less frontend developer and one less UI designer in the team.

📈 ❌ No strong metrics And company is starting with OKRs, so we need to figure out our metrics too. At least OKRs are defined. @HonzaTmn
we use OKrs in our company, so we aligned Orbit objectives to tree structure in OKR tool.

“Nothing is invented and perfected at the same time.“ - John Ray Rychlá iterace je opravdu důležitá. Pracujte s faktem, že to nebude nikdy perfektní, ať už chceme sebevíc. - For example, before we got to our current color set, we improved it maybe 10 times. Ukončil bych tuto část prezentace souhrnem take aways.

Fast-forward to July 2019

Current situation 🕵 Hiring Content Writer & project manager as full members of Orbit team 📱 React Native implementation of our components 🦹 Publishing new documentation page with live examples & more features (working with data we’ve collected) 🔮 Internal one-day edu conference (trainings, accessibility, how to’s, …) @HonzaTmn

Current team 5 5 ! ] 3 React developers 3 React Native developers 1 UI Engineer 1 Product Manager / UX Designer
we are looking for O 1 Content Writer 🦹 1 Project Manager @HonzaTmn
React developers – all our working on components, one is focusing more on accessibility, one on theming, one on automation of processes. - RN developers – two are working on components, one is helping to set up everything - UI Engineer – taking care of UI kit and helping with coding - I do whatever is needed, currently mostly documentation

🐛 Change doesn’t happen overnight🦋
If there is one thing that you should take from this presentation… - Change takes time. And change as big as changing how people design and develop things is not an easy change. - But to be honest: we got lucky a bit. We used Kiwi culture to achieve it, it might have take at least two times longer in different company.

Thank you + reach out to me on Twitter: @HonzaTmn

Jan Toman
@honzatmn

1 / 61

Sharing how we’ve got a company buy-in for building a design system; with practical tips on communication, strategy, and gaining the trust of colleagues and management.

You’ll learn what may help you to get buy-in for building design system in your company and one way how to approach it.

Video

Buzz and feedback

Here’s what was said about this presentation on social media.

If you are persistent. It will be successful! @HonzaTmn pic.twitter.com/OFXQb91fL9
— Czech Design Systems Community (@CzechDSC) July 9, 2019
We heard “this is great, this is helping me” @HonzaTmn pic.twitter.com/9jsJS7J6mo
— Czech Design Systems Community (@CzechDSC) July 9, 2019
The story behind Orbit - @designkiwicom design system @HonzaTmn pic.twitter.com/Z6lpKLarmI
— Czech Design Systems Community (@CzechDSC) July 9, 2019
It all started with one person @HonzaTmn dedicated to build UI kit in December 2017 pic.twitter.com/8PbBVixeMn
— Czech Design Systems Community (@CzechDSC) July 9, 2019
Start small. Iterate. Often. @HonzaTmn pic.twitter.com/LtVRxHkNZo
— Czech Design Systems Community (@CzechDSC) July 9, 2019
11th edition of Czech DSC presents @HonzaTmn and how they do design systems @designkiwicom pic.twitter.com/lDQO5HlFFj
— Czech Design Systems Community (@CzechDSC) July 9, 2019