(bubbly music) (loud applause) - Thank you, everyone.
Yes, so, my name is Dominik, I work at Thinkmill, and I am a developer.
I'm not a designer.
I'm at a design conference talking about something called design systems, and I'm a developer, so it's not crazy or scary.
Okay. (chuckles) (loud laughter) So, I did my own slides.
(loud laughter) (cheering and applause) (Dominik laughs loudly) I assume you will throw things at me now because that's what my team did.
They looked at my slides.
I'm a developer.
I can appreciate good design, but I'm not really good at creating it.
My team looked at this and said, well, this is not really good enough.
So, luckily they took over and made the slides better, and I promise you, from here on out, you will not see anymore references to Papyrus, and I fairly apologise.
But I'm trying to make a point here.
I think the most important thing that I've learned through working with design systems is that when designers and developers work together, awesome things can happen, and this is what really gets me excited about design systems in the first place.
We heard a lot of awesome things about design systems today already, but a design system is, like Jina said just now, is a fluffy term, if you will, so I wanted to make sure what I mean when I say design systems.
This is actually something that was inspired by Jina and her talk in New York City at a design system meetup, I believe, that really stuck with me and inspired me to create this illustration because it helps me explain what a design system is or what it does.
A design system makes us work smarter together.
It forces us to work closer, and it enables us to deliver faster results afterwards, which is a great couple of words that you can say and people will be like, yeah, that sounds like positive words.
Smarter means more efficiency, closer can mean less silos and better consistency, but there's a lot of things that are in design systems. They can include pattern libraries, content guides, which is an interesting one, illustrations, animations.
It doesn't really matter.
The most important thing is it is your digital brand. It encumbers the rules in your design system to deliver your digital brand that will touch your customers. It is the source of truth where all this lives and where you create a space where people can talk to you about issues with a set digital brand.
And, most importantly, it is a living and funding internal project that will probably not generate revenue directly right away.
So, these three things are basically what I mean when I talk about design systems. And there's a thing that happens a lot, specifically when you create a design system. You're super excited about it and you're sprinting forward, and you are bringing everyone on your journey, and then you deliver it, and then you go into a trap, and this trap, I call it the baby trap.
And you may ask, what do babies have to do with design systems, and you're rightly so to ask this question. The baby trap, I like to say, is we obsess about the first nine months of pregnancy and completely forget about the next 18 years we're going to have to deal with this thing. (chuckles) So, in terms of a design system, we're really excited about creating all these design systems and we are fantastic at how to place them, but then, what do we do next? The perception often happens, the internal products say, oh, well, you've built this thing, this is fantastic, you can now spread all your people back into the product teams and we're good to go, but that's not really what a design system should be. I'm going to say design system a lot today, so I should get this.
So, how can we avoid this trap, and there's another reference to Jina.
She actually just mentioned it, which is fantastic. She just published, not too recently ago, her talk in great detail about design systems are for people.
Design systems are for people, built by people. And we heard Jeff talk about this today as well, people should be the central concern for a healthy design system.
It's all about people, and if you had to tweet about my talk in a single word, that's the word that I would use. So, I will be talking today about four different pillars and a couple of things that we've done within these pillars to help us sustain a design system for the long run. So, I'll talk about community and how we can bring people together within a company. Once you have the community, we make sure that we have a sustainable way of collaboration and make sure that what we do makes sense.
We will track your success because it holds our motivation and it will make us go to the next day.
And then we talk about communication because that's really important when it comes to people.
Okay, with that, let's start with the community aspect of it. Conway's law has been stated in our industry a lot and there's lots of words, and it means a lot of different things to a lot of different people.
So, how is that relevant to us? If I had to rephrase Conway's law, 'cause I think it is really relevant to us, I would say, to make sure that we build something, build a community in us, we have to cross the organisational boundaries that we have in front of us. And that sounds a little bit clearer, but it's maybe not perfectly clear and it also doesn't really lay down what a design system is. What does it have to do with design systems? So, if I had to rephrase this again, I would say a good design system is made up of a lot of people, a lot of different people. A lot of different people is really what a community is all about, and we've heard from Jeff today about the importance of diversity in our community.
So, how do we build a community? One thing that we've done, and there's a couple of things now that I'll just talk about, the things that we've done that we found great success with.
We've gone out to all these different departments, in this case, this is the government thing, and we created an open day, a session where everyone can come, and we called it the design system love day. It's an open-door policy where everyone knows this is where we're going to meet everyone and we will welcome specifically doubters.
In fact, we will reach out to people that are in doubt about the design system efforts and will try to engage with them, engage with people's fears and try to understand them. We also created a space for research.
It was really important and it made a lot of difference to publish research or the thinking behind each of the decisions that we made in the design system.
To have this space, we were able to elevate design arguments I'm sure you all have into a completely different level.
So now, when what we call the HIPPO, the "highest paid person's opinion" in the room, comes in and says, well, this green, hmm, I like red, they can't engage with us like this anymore. They actually have to say, well, we've got research for the green.
If you want to have red, you're going to have to show us why.
And that's a really powerful thing for us as a tool to use to push back.
It also spreads empathy.
It makes sure that what we are building and what we are researching touches all the different points that we need, and by touching all these different points, we're exposing all these different points and people have to engage with it, and they see it and say, okay, I didn't have to think about this other product because I'm only in my little product, I'm in my own silo.
So, it's a really good tool to spread that empathy across your organisation.
And lastly, but not least, we're going to have to do some research.
It's really important to actually do research. I skipped over this in the beginning, but I think it's really worth saying.
Do your research, do your user research.
Make sure that you involve the design system team. As we heard before, it's all echoing, it's all connected. Use your team, and go out there and expose yourself, and understand why we're doing certain things, but don't stop there.
As a design system, you have actually lots of customers, not just the customers of your company that will use the end result of your design system. Your customers are also the designers that are using your design system.
Your customers are also your content authors, your developers, accessibility experts and people that have accessibility impairments.
(laughs) Even the legal team, dare I say.
I think they told me I have to say that.
(loud laughter) So, research is really something that is important that we can't overstate.
Now, another thing that I've seen over the years is the excitement levels, and this is something that surprised me because I'm a developer working with a lot of designers.
When I talk to a room of designers and developers equally in the room and I mention design systems and what it means, the excitement level usually looks like this, and this is something to be aware of.
There's a lot of designers that say, well, this is what we've been doing for years, what're you talking about, and I don't want you to just systemize this, and all the creativity and all these things that we just heard from Jina.
But developers love systems.
They jump on it, they're like, oh, yeah, okay, we can put rules in there, we can make it really rigid. (loud laughter)
And that is not something we should have.
We need to have rules in there, but we need to push back, it needs to be a 50/50, it needs to be an equal power dynamic between designers and developers, and this is really the exciting part of what design systems are, to me anyway.
So, make sure that if you let developers, I actually had a slide and the designers removed it.
I had a slide that said don't let developers take over, (laughs) because if developers take over your design system, you get what designers worry about when they hear design system.
That's a really good sentence.
I should have a slide on it. (loud laughter)
Okay, the next thing that we've done is frequent showcases. So, we have actually made sure that in the creation of our design system, every two weeks we talked about, to the entire company, what we've been doing, what has been working, what hasn't been working, what are we going to try next, just to take people on the journey and try to help them empathise with what we are doing, and that's great for when you create the design system. As soon as you publish the MBP, people stop doing that, and it's really important to keep up that momentum. This is exactly what you need to do in order to keep your design system alive because the truth is a lot of times you create a design system and you have a lot of things that fell out because you want to do the MBP, you want to publish something very quickly. And there are so many things that you had in mind that you wanted to do, but it drops off, and as soon as you are live, no one is going to talk about it anymore.
So, keep that up, mention it over and over again. Over-communicating is always better than the opposite. And then, one thing that I'm really passionate about is the donation model, and to frame this, we need to look at where a design system team maybe sits. So, in our case, what we often have is, we have a lot of teddy bears, and there's one robot. I don't know why, designers. (chuckles) We have all these different product teams and they are all working on their own little different silos, and usually what we have is the design system team in the middle, and there is often not that many people working on a design system. In fact, there's usually (whispers) very little money and we have to twinge it all together, but the design system team is expected to answer all these different questions of all these different concerns that all the product teams have, and that's a problem, and we feel this pressure in a design system team.
So, what we've done in Westpac, when we started this, is we actually went out to some of these product teams and asked them to give us a person.
We said, hey, can we have one person of your team to come in for a month to work in the design system team. It will be to 30% working on your product because you're using our thing anyway.
And we made sure while they were there to help them understand the concerns of the design system, really made them go through all of the different steps that we had to go through to, for instance, add in a component, or think about the research, think about other products that that person may have not been exposed to otherwise, and we used them as a fresh perspective on our own stuff. We've been working on it for years.
We needed a fresh person to look at this thing that we created and give us some feedback.
It's a great way of doing some guerrilla testing they call it, I think.
And then, after a month or two, we just send them back, and they go into their products, but now they're champions. They're champions of the design system.
They know how to raise an issue.
That is one of the most important things for us because we want to know about the issues that are being faced inside the product team so we can solve them. They now know how to do that.
They even know how to fix it, theoretically, if they had time, which is invaluable.
And, in the end, they become the champions of the growth, and they possibly wear our T-shirts in their swag, because that's definitely something we need to do. And (chuckles) we learn from nature on this model.
This is a thing (laughs loudly) that's more of a joke. So, this is how viruses work, right? (chuckles) We are actually trying to virally make people understand what we're doing and get them together, get them excited about all these different things. Okay, so, when I talk about this, people specifically ask me, how do you get to do that, how do you get to go to a product company, a product team, and ask them, hey, give me one of your resources, one of your people? And that's a fair question 'cause that's when office politics and all these different things come in. So, the first thing that I always tell them is go with the sentence of, hey, we're one team, one dream, we're all working on this together, this is one company, let's do this.
Sometimes that works, and you stop there and you're good. Often it doesn't, and then you go into framing this ask, and say, well, actually, we're going to save you time with our design system, so give us that resource in exchange for the time that you save building these assets.
Or, if that doesn't work, you say, actually, we've built code, there's a tangible thing that we created that we give you, and for that we want something in return. There is a thing when it comes to something material that allows more materialistic project managers to make these connections, and it helps.
And in the end, of course, it will up-skill these people, and it's a great story for us to say, hey, we're going to take this person and we can teach them all about the front end and all about this, how to design for the web because you've only had to design for your native application, that kind of stuff, and that's really good.
It gives you yet another tool in your assets. And in the end, it's a fantastic onboarding experience. So, when a new person starts in a product team, that's when you get in and say, well, before they start, why don't you give them to us? They'll learn all about our company, all about our culture, all about the different endpoints that we have, and then you get them in there, good to go. Okay, so, community building is not a new thing.
Community building is one of these things that the scientific community has been working on for a very long time.
If you think about it, all the inventions that we have these days are all a synergy of chemistry and physics, and computer science, and all of these different things working together. So, there's a lot of research in how to build communities within different scientific communities and how to do this prosperously, and some of these things that I've said today actually go right in there, and we'll get to more in the future. Okay, so, let's summarise community very quickly. We have design system love day to make sure that we're all coming together and it's an open-door policy.
We do research and we expose ourself to research, and we make sure that we're all coming together in understanding the constraints and the users. We do showcases, take people on the journey. We make sure that we are all equally empowered, designers and developers, trying not to tip it one way or another.
And then, the donation model is one of the things that really worked well.
I'm going to have summary slides in every single section, so I'm going to pause, you can take photos, and then we'll go onto the next. So, you don't need to, if I run, because there's a lot of small slides, okay.
Collaboration.
The next bit that I wanted to talk about was collaboration. You've got a community now.
How do you make sure that collaboration works well in your company? Nathan Curtis has actually published this article in 2015. He talked about the different ways you can manage the collaboration between lots of different teams, and he's talking about all these three different ideas, and I encourage you to read this article. It's a fantastic article.
But it doesn't matter which one you choose and which one is right for you because they all have their ups and downs.
The most important thing is curation.
When you do a collaboration thing, the scariest thing to designers I find is, ah, I'm going to let someone else design my thing and now it's going to look more greenish than bluish. And I understand this is a silly way of phrasing it, but curation is really powerful to make sure that what is being added, and you are literally taking things on from other people, will be taken on in a way that is very productive. Curation will give you consistency because now you have one person in charge of this one thing and that person has the understanding of each of the different spots. It will give confidence to your users to make sure that, okay, if we're going to grow further and there's more people coming from another thing, there's still one helms person. And then it helps with communication so people know exactly where to go and who to talk to when they have questions. Another really important thing about curation is listen, really listen.
That is a skill that we, as millennials, or whatever generation we are, really struggle with these days.
Listening is a skill that is, I think, underrated, and it's one of those soft skills that are really hard. Some notes for myself that really helped me make sure that I can listen to people and take it on is to take notes, actually write it down, and internalise it afterwards.
And then, another trick is to repeat what the other person said in your own words. It does two things, it gives a signal to the person who transmitted the information to you that you've understood them, that you're on the same page, and they don't feel like they're struggling anymore to transmit this information over and over again because they're not getting anything back.
And it also allows you, as a second thing, to internalise it, understand it, and say, oh, okay, I've said it in different words, in my own words, that makes sense now, it's more natural now. And in a design system perspective, what we try to do is we make those issues our sprint goals. We've hammered it down, we've digested it properly. Now we can make it our KPI and we can actually work towards this, and that creates authenticity and it creates a welcoming environment for people to voice their concerns.
Alphas is one of the things that helped us with creating a space within a design system that is already somewhat constrained to be really creative. It's the idea of having "in progress" components, the idea of, hey, we're going to try this thing out; we're not sure about it 100% yet and we want to learn more about this, but we're going to put it out there and you can use it; please give us feedback.
It creates the space for us to try things out, it creates time for feedback, and it test drives your assumptions because we always have assumptions.
And tools that we've used for collaboration in the long-run are like slack and discourse, two wildly different tools that do wildly different things, and it really depends on what company you're into to choose which tool is the right tool for you. This is a screenshot that I took yesterday of the discourse instance for the DTA, and I've got a couple of notifications that I should be looking at. Sorry.
Meaningful collaboration is not a solved problem. Again, the scientific community has been working on this for a long time, and there was actually a study in 2017 that looked at this and asked themselves, what can we do? They actually went through and did research and came out with five things afterwards that was really important to them.
They said, we have to make it meaningful, collaboration has to mean something to people. Yeah, we'll get into that later.
You need to engage with people upfront, they can't be surprised about the collaboration that you're doing.
That happens more often than you'd think.
We need to create fertile ground to allow them to engage if they choose to.
So, whenever it happens, and it sometimes is surprising that someone comes in and says, hey, I want to engage with you, create the space, have it in the backend and go in there.
And deal with problems head-on, really important too. When you make mistakes, and we all make mistakes, talk about it and say, hey, we're humans, we're trying our best, let's deal with this, let's fix it. And handle ownership fairly, this is one of the things that comes in with office politics and literal politics when we talk about the design system for Australia. There's a cautionary tale that I love to share. With Westpac, a while ago, we created the design system for Westpac and their bank, and they're very big on security, which makes sense 'cause they've got all the money. We found, in our research, that there's a lot of projects that didn't want to adopt any of the design system because they didn't know how it was built.
They weren't hundred percent sure what the code was that we're going to adopt.
And the way we solved this, from our perspective, is we created everything opensource. We put everything opensource in GitHub and we were super proud because it was the very first repository in the bank that went opensource. And there were lots of flags and lots of meetings, but we got there, and we were really, really happy. Two years later, the blind, angry mob on the Internet got triggered and pointed out to us that we have a design system for a bank, and you opensource it? Now I can create another website of a bank that looks like the bank and I can get all your passwords. Well, sure, but there are tools that you can use.
I didn't know about this, I learned about this afterwards. There are tools that you can use on any website where you can just change two or three things, it looks exactly the same, and it's so much easier than a design system.
So, unfortunately, this gathered steam on the Twittersphere, people got angry, and we couldn't talk them down about it. Westpac felt that it was a reputational risk and actually closed everything down, and it was a huge blow to the morale and the happiness of our team.
And the cautionary tale, or the thing that we learned here, is we should've educated our users about security. It is a primary concern of the bank that should've been front and centre of the design system. We should've talked about this.
We didn't feel like it because it's front end code and everyone gets it anyway, but you live and learn.
So, I'm tackling this head-on, that was a mistake. So, a summary of the collaboration: Make sure that you curate, regardless of what model you choose, really listen to the users and the customers that are using your design system, create space to test things out, and learn from your mistakes.
Photos? Good.
Okay, so, the next bit that I wanted to talk about was tracking your success.
Tracking your success in a design system is really not straightforward.
What does success look like? First of all, it'll make you accountable, it's really good to have.
It helps the team because they have a clear goal to head towards and everyone knows exactly what they're doing.
And, but not least, it helps your project being funded because you still have something that you can show off to the powers that be that have the money to say, hey, we're making progress, these are the things that we're doing and this is the thing that we're doing next. But what is success? What does it look like in a design system, and there's lots of different thinking around this. Is it the downloads of your sketch files? Is it the design consistency? Are you looking through all your websites and counting all the different variations of the button? Is it the time saved, how fast can you create your features for the company? Or is it the lost in translation issues, where designers and developers talk about completely different things because they don't have the same language? Or is it just the attendance of the design system love day? Any of these are fantastic.
One of the things that we've learned when we created metrics', is that the plural, for the success of a design system is we need to make it meaningful.
We need to focus on the impact of your metrics rather than the metrics itself.
For instance, if you reinvent the button less in each of the departments in the government, you have suddenly more taxpayers' money to pay for, I don't know, an NBN, (loud laughter) or education, or any of these different things. If you have more developers starring and liking your design system, you have less developers not knowing about topography and design colours and semantic colours, and all these awesome things that they should really know about. If you have more consistent interfaces, you have less users having to learn your interface over and over again while they're going through your website or your product.
So, for tracking your success, it's really important to be out there, to celebrate your wins.
We did something in Westpac where we created a design system love publication, it was all about love.
They needed more.
And we created an email that we sent out every time we made a change and we published something. We explained all the different changes, but not in technical terms.
We explained, hey, the button, there was a bug and it was getting really small, but we pumped it up; its ego is now happier and now it's being bigger, and lots of tiny little jokes.
It really engaged the audience.
We make sure that we track these metrics on our website and expose them towards the users of our design system. That could be, for instance, the adoption of strategic agencies or departments that we're really, really proud of, or it could be how many times it's been downloaded the last year, the usage statistics.
Whatever metrics make sense for you and your system, it will prolong the interest in the design system and take other people on the journey that you're on. But be fabulous as a team.
I've found the design system team can be silly. It can be this quirky team in the middle that doesn't take themselves too serious and is like an island in a company that can help you just rest and be welcomed.
All these things, keep yourself accountable. It builds trust and authenticity if you publish all your goals and your tracks. And the summary slide, look at these animations. We define our success, we need to make sure that we know what we're striving towards.
We make it meaningful so that we can identify it as humans. And we celebrate our wins so people can celebrate with us. And that leaves us with communication.
Communication is really important with humans and it's super flawed.
The first important thing that I want to drive is over-communication is always better than the opposite. Documentation, I've never seen or heard anyone say, ah, we wrote too much documentation, that was a mistake. (loud laughter)
I don't think that's ever going to happen.
Write more, and then, and then some.
And it is really helpful because it also allows you to transfer the information or your concerns. But it's also important to ask yourself, who are you documenting for? Are you separating, for instance, the documentation for designers and developers because it allows you to focus and drill into the content of this? And that might be the right answer for you. Or you combined the documentation of the designers and developers and expose them to each other's concerns, so a developer suddenly knows about these colour schemes and that there's an action colour, and it has a semantic meaning and, oh, I shouldn't be using that somewhere else. No matter what you choose there, it is really important that you only choose one. I've never seen it done well where you do both. So, try to be straightforward in your communication in your documentation.
Then ask yourself, what should we document? Should we document, and this is not a question, there's an exclamation mark, you should document your research.
You should document your alpha releases and your testing ground and what you're working next on. You should document how you collaborate and make it really easy for people to engage with you. Publish your roadmaps.
Talk about what you're doing next because there are some people that may be completely frustrated with the fact that you've not dealt with this yet whereas you're literally dealing with it now and they just don't know about it.
And the last one that is my favourite one in this one is delight your readers.
As a design system team, I always feel like there is an opportunity for us to make someone smile because they saw something from this internal team that really doesn't have any of the constraints they have to think about in all these different things. So, when we rolled out our emails, and I eluded to that earlier, we made sure that we made it really entertaining and talked about what we're trying to do, we're really just here to help you. And what we found, and that honestly surprised me, is that a lot of people signed up to the newsletter that had nothing to do with the design system. Like project managers and sales people, they just wanted this one monthly email to read through every single thing, and they read through the change logs of our components. Just think about this, someone takes their time out to eat something, probably, during lunch and read through the change logs of our design system. That is fantastic, a fantastic outcome.
Another thing that we did in the design system for the government is we made sure that all the error messages start with a movie quote.
Now, don't get me wrong, it was really important to actually get to the error message as well. So, we made sure that the message following afterwards was really productive and told you exactly what was wrong, but it was also a good opportunity to delight a person and say, hey, we've got this thing that is happening, but we also tell you where to go next.
And we always made sure that we were proud, we were proud of our design system.
There are so many banking websites that have my name in the source code.
I'm getting up in the morning feeling like I've accomplished something because I'm there, because you know banking website will never be updated in the next 50 years. (loud laughter and applause)
And one thing that we've done in the design system that may or may not be known to people in part of the design system that are currently here is if you enter a specific string anywhere on the website, you'll get some bubbles.
It means nothing, it's very little work, we copied it from somewhere else, but it makes such a big difference to the team and to the morale and their happiness.
We literally had a day where I asked everyone, we're going to sit down and we're going to create Easter eggs now, because it is this team-building exercise that really makes a difference, and you have a piece of you in the thing that is now going off to all those government departments.
And there's more, but I'm not going to tell you about them. So, communication, the summary.
Build as many docs as you can, and then try to build some more.
Ask yourself who to write for and be deliberate about it. Make sure that you document as much as possible. That's really the same point.
And delight your users, take the opportunity to put a smile on someone's face.
So now, here's the big summary of the entire talk of all the different sections.
We talked about community.
We talked about the collaboration.
Once you have your community, how can you make sure that it all works? We talked about how we make sure that people feel delighted and engaged with it, and then about the communication, how we do all this together.
You've got your design system, you've set it up for success. You are there for the long run, hopefully.
Now you go off and iterate.
You do more communication, you do more community, more collaboration, you do more tracking of your success, and you do more communication.
But the most important thing is you keep playing. You break things.
It's good to know the boundaries of your own system, but you always have to communicate it because design systems are for people.
Thank you very much. (loud applause)
(bubbly music)
