(playful electronic music) - I'm here to talk to you, guys, about design systems as a service, and how to keep your customers happy.
Let's start off with a little story.
The last week of June in 2015, it was a really big week, so big that I need to put it in this talk.
I was contemplating leaving a very comfortable UX agency role, it was a little boring, to join a company I knew nothing about.
And to do a job I've never even heard of, I didn't even know that was a thing.
It was called run the ADG, the fuck is that? It was something about scaling, and it was about front end development, it was all very mysterious.
Also that week I found out I was pregnant, and later that week I also found out I was having twins. (audience laughing) I already had a three year old, so you know, talk about scale.
(audience laughing) Like the joke wasn't lost on anyone, particularly my husband.
So I'm telling you this because I had a lot at stake. Like I really needed to think about this, why Atlassian? And during my interview process, like I was interviewing them as much as they were interviewing me, I was very like I don't want this shit.
And they told me this story and I really liked it, about the value of design at Atlassian and what are they actually gonna do about it. 'Cause a lot of companies say we value design, what does that really mean? So cast your minds back, this is 2011, they hired this guy, Yogan Spankle, still there. And he, his whole job was head of design, come in and bring design to this engineering as fuck, sorry, engineering organisation, like both founders, Mike and Scott are like nerd-ass engineers, love you, love them, it's great, but we needed some design thinking here.
So Yogan came in.
And before him things like design reviews with the founders were very much like why is this colour of this button blue, and why is it over there? Like that was the depth of the kind of like design critique and conversations that were being had.
Another thing is, you know, they had this, magic number. They had all of the dropdowns.
Because back then engineers was like, we need a dropdown, let's build another another dropdown. It's a thing, I think it still happens in lots of companies today.
And we were trying to scale and I think it's the cost of scale.
We didn't have time to think about like should we really have this dropdown? We just need a dropdown, let's keep shipping value to customers.
And I think that's really important, let's keep shipping value to customers.
For a certain period of time.
And so I really kind of had a bit of an aha moment, like even back then I was like, this is kind of interesting.
When Yogan came in he sort of said, "Well, this is a bit shit".
He has a very sick Austrian accent, and, "This is a bit shit".
Terrible, terrible, and he introduced this idea of the ADG, I'm gonna talk about the ADG, I will kind of interchangeably use that as the Atlassian design system, just go with me, naming's hard.
And so he introduced this idea of the ADG, which is the Atlassian Design Guidelines back then. And so for me what that said to me, that aha moment, was really like, design systems elevate the value of design, like they actually help that shit.
And I'm gonna like dial it up a notch, it was aha for a moment, and it kind of became a truth. And there's gonna be a bunch of these truths throughout and then I'll kind of recap, so if you miss stuff, so it'll be there for you.
So I was really intrigued and kind of sold, maybe not on Atlassian, but definitely the value of design in a tech company.
So I joined, this is me, look at the hair, June sixth, July sixth, I beg your pardon, and bright-eyed, bushy tail, so full of hope, to try and figure out like what the fuck is this basically, I was really intrigued.
And I mentioned, I came from this agency land, and I'm sure a lot of you are in that land right now, and you're familiar with things like style guides, they've been around, they're always gonna be around, that's a thing. And I kind of figured that out, because style guides, I was working with big companies like Foxtail and Woolworths, and they have a style guide, and you go and look at it, and then you forget about it, and you move on, and it's out of date all the time. 'Cause it's printed, and it's terrifying.
And so what I kind of was fascinated about when I got to Atlassian was like this idea of like a design system, and we didn't call it back then, like that wasn't the hashtag, but it is now. And I love that it was designed to evolve, I love that there was this idea that because it's gonna be in code it's gonna be alive, and it can be maintained.
And I really tried to think about what does that mean. It's not just here are some assets, you do you, it's very much here it is in code documented, and all this stuff.
It seemed like euphoria.
A definition I've come back to on design systems over and over again, and I really like this, and I think it talks a little bit to some of the other talks we've had today. Design systems are a collection of rules, constraints, and principles implemented in design and code. So what does that actually mean? I showed this to my husband, he's like, "What the fuck does that mean?" I'll explain, so rules, constraints and principles, right? So when we talk about that button, and the founders, the button's getting picked on a lot, Sarah talked a lot about buttons.
When the founders were like looking at that button, and they just kept circling on this like should it be this, should it be that? If we had a design system back then, that shit would've just been solved.
Somebody sat there, did a lot of iteration, and figured out that it should be this button, it should be this colour, go and think about a different user problem, an actual user problem, like what are you trying to solve with this flow? And I think by figuring out some of those, I'm not gonna say simple, I'm gonna say common problems, because design systems don't solve simple problems, it's fucking hard to do a good button, I'm sorry, there's so much swearing in here. But it's true, I'm very passionate, and like it's hard to do a good button.
And the other part of this is implemented in design and code, it is available, it is ready, it is thought-through, it is just there for a designer, an engineer to pick up and use, and not have to worry about it if it's gonna work or not.
So when I joined our products looked like this, this is Bitbucket.
I know you thought this was 2009, right? Yeah, no, it's 2015, mm-hmm, mm-hmm, mm-hmm. And this is JIRA, and some of you may still remember this, it's not that far away.
And so we also had, because Yogan joined, and he kind of believed in the ADG, and some stuff's happened, we had a design system of sorts. And it was like this, and seems pretty legit. It was very much about thinking how we can have something. We had a bunch of interest from engineers predominantly saying, "Oh, wow, yeah, this is really great, "can you like document that?" Sure, so we did, and it was a great start.
And I think if anything it's never about the end thing of like, oh, God, you have this amazing design system, how did you do that? It's just like getting anyone interested, anyone to care, find those people.
And so that really led me to another truth around the purpose of design systems.
They're really there to solve business problems. And with that previous version I just showed you the business problem was our products were inconsistent from one another previously, they were like, "Are they even by the same company, "like what is that?" And so what we did was, ADG too before my time, was let's have them aligned, let's have JIRA look like they belong and Bitbucket together and it was nice, it was okay.
That didn't go too far, but at least it was consistency, and I think that's one of those values of design systems that people will talk about, consistency.
Something that those products didn't do, and I don't wanna bring them back on screen, but I know they're burnt in your mind, is they didn't really talk about why Atlassian, they were just like another product that did another tech thing, and they looked kind of dead inside.
And as Atlassian evolved and matured, I've said this to the founders, it's fine.
(audience laughing) As Atlassian evolved and matured we and really, you know, having design at the table really really started to think about what are we about, like we do we exist? We have these tools, but you know what, the tools are for people.
And you know what, those people come in teams, and so we really sort of needed to kind of figure out what is that expressive language, how can we express some of that stuff through our products? So what we did is we ran a workshop, amazing. We brought people together from marketing and brand, and product, and content design, my favourite. Because they're all really important to actually think about the entire product. There's Mike Cannon-Brookes in there, the founder, he was kind of brought in kicking and screaming, but he added a bunch of value, because he could see why this was important. Talk about buy-in.
This was April, 2016, we were on a bit of a journey, and everything starts with a workshop.
We came out with some really good shit.
And we agreed, that's the biggest thing, we agreed on like brand principles.
Like we're about being bold and optimistic, and being practical with a wink.
And then we could figure out what does that actually mean. But at least we agreed on a belief as an organisation between very disparate disciplines, like marketing who have opinions, and product who also have opinions.
Agreement was like a huge win.
We also came up with a single illustration style. And again, the things that we would align on, and then product designers could take this and bring this into product in a particular way, and then marketing would also take this.
And then for the end user there would be a more seamless experience.
We agreed on colour, I know, like four dots, so easy. It was really hard, you know what was even harder? Typography, fuck, that was really hard.
But we also agreed on that, right? And we agreed, and it wasn't perfect, it was always gonna evolve, but we agreed.
And I think just that, getting your design system to work, like figuring out who those partners are and who you need to agree with is kind of part of it. And I mentioned my love of content, and design systems are nothing without content. And whether you're moonlighting as a content person, you actually are a content person or you just believe in it, whatever it is, you really need to think about the writing style. Because the end user reads everything, everything is content, content is the product, don't tell anyone.
And so I think us agreeing on this single writing style, this voice and tone was like a real pivotal moment for us as a company.
And of course, why does this not work? Go.
Yeah.
Logos, you know, what's a brand refresh without logos. We had a system of logos that we came up with, and again, aligning all at once between product and marketing.
And so what we did was, you know, this is kind of where we were when I showed you those screens earlier, the 2015 screen.
Marketing doing its thing, product doing its thing, I feel like this is not uncommon.
I run a design system meetup plug, and a lot of questions I get asked is like, oh, but the marketing does this thing and like how do we do that in product.
And it's like, you've gotta talk.
And so what we did as a result of the workshop is like we came up with this agreement on foundations. We also documented everything and we up-leveled our design system.
This is atlassion.design, it is out there, it is open to the public, please check it out. And this was the kind of documentation that we ended up with.
It was all of those things that we agreed on manifested itself in documentation.
And you know, also we had the holy grail of design systems, adoption.
Because we had the founders in the room, because we had Yogan in the room, because this was like a business problem, it wasn't just like, oh, design system, it's nice. It was like our products really need to kind of ramp up. Like there was a real need.
And so we had JIRA, it's much better, we had all the other products that kind of fell in line and Confluence.
It kind of felt like we're about something, and you can really sort of feel that bold with the nav, as per Sarah's talk we've evolved past that, but this was a moment in time.
This felt like a real win.
This was Bitbucket, we had mobile.
This really felt like we were onto something, and the design system was very much part of that. And so my manager back at the time, and he used to say things to me like, "So you're done, yeah, you're good, you're done, "it's done, you're all done, "so what are you, guys, gonna do next?" I'm like, what do you mean? He just kept sort of, and I just kind of kept twitching about it. I was like, are we done? And so if we looked back on this little rollercoaster that I've been taking you on, like this little journey, started off with design.
My slides are having a great time now.
And so I joined, that was really momentous, and then we sort of thought about this ADG three project, right? This project that we started with the workshop and we created all the stuff, and then we rolled it out, and it was done.
It didn't feel done, we had adoption, that's for sure, that was a big win, and I think definitely something that we talk about a lot.
But to be honest, the team kind of felt like, no, it wasn't, there was so much more work to be done. And the reason for that is that when we just pushed it out and products kind of took it, kind of like they had to take it like medicine. Like yeah, sure, we'll adopt it, and it was hard going, and we didn't build anything flexibly.
Everything Sarah talked about for those of you who didn't hear it, like she talked about this amazing flexibility, we didn't do any of that. We were just like hard coding shit in, like it's all blue, go, go, go.
And it kind of felt like that.
And it was like, 'cause we had a business need, roll out a refresh, and we did that.
And so we were left with this thing, it felt like when we were doing this it's like we were building the engine while we were flying the plane, I don't know if you, guys, have heard of that, but that's kind of how it felt like.
And so we needed to kind of keep going, right, 'cause the design systems are alive, that was the whole promise that I kind of came into Atlassian with, they're supposed to be alive.
And how do we keep then alive? And so we were a product company, we have a bunch of products, like 15, keeps changing every day, I can't keep track. We keep buying them, so we were all about products, right? And so kind of how am I gonna frame this project, this idea that was kind of done in the minds of management to be something else? And I know this is something that has been around for a little while, but back then for me this was like a real yes, this is how we're gonna sell this.
And so we really thought about what did it mean for us to be a product for products.
The products that really wanted to actually use us rather than kind of be forced to use it.
So this is a funny photo, this is me coming back from maternity leave, this is the lead designer on the ADG three project. And I'm taking it from him, and like I'm gonna make it into a product.
And it was all gonna be magical from then on. And we came up with this really succinct definition and the ADG end-to-end design language based on our brand, personality, defined in code utopia. We had all the stuff, somebody, I was reading a blog recently and they're like, "Look at Atlassian design system, "because it's so extensive." We had a lot of stuff and that's because we have a lot of products, right? And so we kept thinking of like what does JIRA need, what does Bitbucket need, what do they all need? Like how do they kind of keep going? All this stuff is gonna work, yay, like fucking tonnes, right? And we kept doing that, and it felt kind of like exciting, 'cause we were shipping, and like Atlassian and lots of companies really think about shipping, that's a measure of success.
You've shipped a thing, it's been adopted, keep going. And so before and I said that around feeling like we were making the engine while flying the plane, now it felt like we were actually flying the plane. It felt good, and we had a 150 teams across Atlassian all like we want a thing, we need a thing, everybody needed a thing, everybody was like, we got the momentum, everybody kind of bought it. They were into it which was very exciting.
We had this amazing team and this is some of them doing fun things.
At the height of this kind of boom of the design system as a product we had like 22 people on the team. That's insane, and I have a crazy number slide for that. And it felt really good, and it also felt really hard. Because the struggle was real, right? We didn't have a repeatable process, it was time to think about a process, let's just ship shit.
And we didn't really have any documentation on like how to use the design system, we just had the design system, you just come and use it, and do a thing.
We didn't have time, because we were too busy shipping and proving our value.
And the other thing that made it like really hard was like as we were all doing this stuff Atlassian was like scaling massively.
They've always wanted to scale and they're kind of like, this is 200 some, 250 designers across three disciplines, content, research, all these designers couldn't get a bigger picture of engineers.
But there's even more engineers, there's like 900 engineers right at this point trying to use the design system.
It was really hard.
So we thought ourselves as this product, want, it was a product is something you want.
You want a design system.
People come to me and say like, "We want a design system", and I say, why? It's hard, because if you can do it in a different way maybe you should.
And so a service is something that's very much in the need space, we need a thing, we need to go and make sure that our products are consistent.
We need designers to work faster, that's a very different proposition to having a design system.
Somebody very smart who may have spoken about this in the previous talk, she's got a fabulous blog which I will link to at the end of this presentation. She said, it has the word whiskey in it, so it's a great talk, great blog that she's got. But it's really about the people on the team, right? And if they can't use it, forget the adoption, I mean that's important on one hand, but if the people who you've actually designed and built this design system for can't use it it's worthless.
And I think really coming to that realisation, going through this kind of like, we're winning, it's all amazing to this like oh, God, people. And so we really moved to this idea from a product for products, framing questions like JIRA needs this dropdown to these people need to do things better really helped us to figure out what we're about.
And so what I mean by people? We did lots of things like we stopped shipping, which was huge, I had to have that hard conversation. Oh, no, no more new things.
We have so many, we had like 60 things at the time, like 90 guidelines, we had enough shit.
But it was a culture thing, right, and I think part of it is design systems are about culture and changing culture, and changing mindset. And if your company's about shipping and value shipping it's very difficult to say we're not shipping anymore, we're gonna look at the people using the thing. So what did we do? We actually got a bunch of data and we studied people, like we studied our coworkers, we were like, these are our customers now, forget the end user, you do you, that's a product problem, we really need to figure out who the people on the ground using the design system are.
And so we like creeped on them, it was really weird. Can we watch you open sketch and do a thing? And we took notes, and we did it over and over again. And we did a bunch of times, and engineers, we had these like therapy sessions where we had a designer and an engineer come, and we would like ask them questions, and it was like marriage counselling, it was really great. 'Cause they were like, I don't know, is that what happens, I don't know, do you think that happens? And so they kind of really started to have that shared understanding and empathy for each other, like that's really what the crux of it was, this like design systems build empathy.
And we got a bunch of feedback and we learned to hold a tonne of stuff, like this. We actually have multiple sources of truth, because it's easier for our team.
And like this was just like gold, right, and like obvious.
But also we were so focused on doing things and creating more stuff for JIRA or Bitbucket to make sure they liked us, we kind of forgot about the actual people.
And so I love that, right? And right now we're actually working on a single website, Shopcora, it's really, but to get that buy-in, to get people to understand why this is the most important thing for the design system to do we needed to really kind of bring that human element to it.
And we invested in the community.
It kind of was happening for a while, like design system, designers and engineers at Atlassian are very passionate, very opinionated. And so there was already a community, but we kind of needed to invest in it, we ran things like sparring.
So we have design critique, this is us doing remote sparring, everybody has their personality.
And this is designers and engineers talking about the intricacies of round versus square avatars. And it wasn't about what they talked about, it was just having that kind of outlet and making sure that they had that community feel. And again, it's a culture thing, we needed to build a community of designers and engineers talking in the same space.
And you know what, it's really easy to measure success. We had CSET, CSET's customer's happiness.
So before we did anything it was like 32, and then we did some stuff and actually cared about the people, and then it kind of rose.
And so again, when we had to kind of advocate and talk about what is the value of the system, like we're actually making people happier at work, which is quite hard to do.
We also invested things like education, right? I talked about before, we didn't even bother with like how to use the system, we were just like some stuff.
And so, well, it started off as like a shitty keynote that I may or may not have done, turned into this like amazing kind of online resource for designers and engineers, when they join Atlassian they can just watch some videos and understand the history, and figure out what's important to them.
And so this really evolved over time, and this is like two weeks ago it became on-demand. But in terms of like figuring out our purpose is really to enable people to do better things. That's one of those things that's really important for people to do, and people to know how to do. And so again, success was really easy to report back on, because we onboarded 86 people to the Atlassian design system, to the Atlassian way of working in the past six months. Leadership kind of was like, "This is important, "this is kind of interesting", right.
So that sort of stuff.
And last, but not least, we invested in tools. So we always kind of had a guy in the corner doing things with tools and in his spare like 20% time. And by tools I mean design tools.
So when we really started to think about the people using our stuff we started to invest in what he was doing, and now we have a team of three.
And so he really did all the creeping, because he'd be like, "How do you use this thing, "and what do you need here", and et cetera, et cetera. And then he will come back with like ideas, and like this is how we can make this process for the designer more efficient, and this is how a hand over to engineering might be better, which is why we're moving to Figma.
Partly because the engineers actually will enjoy that more and designers are kind of annoyed.
But we came up with things like this.
This is still sketch, I couldn't get the Figma file for this yet, but this is what we did.
We came up with like data generators, right? So designers spend a bunch of time putting in fake data into all their prototypes, and like we just automated that for them, and they were so happy.
And also everything was so much more consistent, and everything kind of made sense, and we created this fake story.
But we would've never kind of gotten to this like lovely thing to do for people unless we actually asked them and talked to them, and actually were focusing on what they needed. If we were focused on what JIRA needed, JIRA doesn't need this.
The actual people using the design system really do. And another amazing thing when we did that is like focusing on, we could actually report back on success.
And like time saved, another one of those things about design systems, how do you measure time saved? Well, you actually measure designers working with the thing and then without a thing, and then you multiply it.
And so it was really good to kind of be able to talk to these numbers, especially when everybody talks about head count, and ratios of design to engineering. I'm like, yeah, fuck ratios, we're saving people time. And so we could actually use that as a way to get more head count, and kind of get more people to engage.
And so we got some nice feedback, and it's not to say that it's all done and it's all amazing, but it felt better, like it felt like we had a purpose and we were not just like shipping for the sake of it, we were really helping people to do a thing. And so if I was to look back on this journey that I've taken you on over this kind of 25 minutes, it was a journey, right, and I think it makes sense at different points in time for everybody to think of their design system need differently. When we were there at the beginning it was very much about necessity.
It was about we needed to have less dropdowns, 44 is bad. That's very valid, somebody can be at that point, right? And then later on, our products look kind of weird and different, that's also valid, and that's also a need.
And so how do we kind of evolve the design system as your company grows and evolves? And the fun bit is is that that it does evolve, right, and that it keeps going, I have stickers should anybody want them.
We think about ourselves now is that we, the Atlassian design system, make it easy for people to create experiences that users love.
And when we think about it in that way it really kind of helps us with that purpose. Those are the truths that I talked about and kind of sprinkled throughout, I will quickly click through them if anybody missed them. But again, we elevate the value of design with the design system.
We very much think about how does design play in the organisation.
It's not a sketch file, it's a living thing codified and documented, that is it, that is the truth right there, it is not just for one type of discipline.
It's really around aligning yourself with business problems. The companies who don't value a design system or you're struggling with getting off the ground, are you at the right company? I think if they don't kind of get it, how can you align your message to the business problem that your company's trying to solve? And when you think yourselves as a product for products, at some point potentially think of yourself as a service for people.
And so I leave you with this final truth.
If you focus on having a design system as a goal you will fail.
If you think about what is the problem you're trying to solve and how can you help people do things better you will succeed.
And I'm gonna click through these reference slides. These are like, I've gone through these a million times, I keep going to the exact same articles, it's not like I've got 1000s, it's just like these are my top favourites, and I keep going to them.
I will share the deck and you, guys, can grab those as well. And last, but not least is books.
And I think a bunch of you are familiar with some of these books.
And these are like when you are first in the design system space, start here.
These are really great and super valuable for different reasons.
And then when you kind of move on these are very fresh, that last one, the "Expressive Design Systems" is not even out yet, but it's very good.
So I really recommend you kind of immersing yourself and maybe getting into design systems as much as I have. Thanks.
(audience applauding) (playful electronic music)
