(upbeat music) - So we're gonna have a little Q and A so the people sitting over there, but you can move more into the centre if you want to see us, but if you just wanna hear us, you stay where you are. So we're having a little Q and A.
If you have a question for anyone on the panel about design systems, please put up your hand.
Ben is going to come to you with the microphone. - [Ben] They're gonna be on stage, so just stand up and shout. - What?
- So we're told just stand up and shout, which makes it easy.
And then I will repeat the question for the video, so that we have that.
So put up your, okay, in the black T-shirt, in the middle was first and then the grey T-shirt, two rows in front and then black shirt and then grey shirt. - Oh, this is not gonna work.
- All right, done, got it. - I have no faith.
- Yes please.
- It's beautiful. - I'm Jake from Nine,
I was obviously asking as well, but I was just wondering, what's your design system and it goes out and people outside the design system's team figure out something that might be valuable for the design system, how do you accept it? What's the process of accepting that feedback? (sighing drowns out speaker) - Okay so how do you implement new ideas into the design system when they come back to you after it's gone out into the world? - I feel like you answered that question yesterday, a little bit.
Do you want me to keep going on it or do you want to? - Well in my team, we have a theoretical way that we do that.
So there's this diagram that sometimes I show in my talks, that we spend some time working on, about what steps, what should be your thought process when you wanna propose something, basically like a yes or no.
You go in different directions, but it doesn't mean that everyone follows that process, but it's a good start to have those conversations. I think it really depends on the team.
What I really like to do is to create that flowchart, that diagram in a group with a bunch of people and think about each of the different steps that you wanna, that you need to consider for your particular circumstances because it might be that each step, so the first thing that people need to do is, to go and check the documentation to see if the thing that they're thinking about already exists.
But if there isn't a documentation, well now you have a work item that you have to go and work on.
Next step, if it doesn't exist, should they create a proposal or should they just come to you and say that they would like something to exist and if they'll need to create a proposal, what should be the format? So going through all those steps, I think it's a really valuable workshop that can take an hour of a handful of people's time and it also will give you some, probably some work to do because you're not gonna have everything in place. - Lets extend from that 'cause there's a bunch of questions that comes from that, around sustainability of the design system and as you mentioned onboarding people into the company using the design system and when we talk about documentation, is there a best practise for documenting the design decisions that have gone into why we have something in a certain way that can be used to stop people wanting to override? - Well, there's a few things that I've seen like I know that Gov.UK has a research section at the bottom of the documentation pages, not all of the components have a research, but they wanna highlight that so to backup those decisions.
One thing that I've done before was to link the documentation page to the previous conversation that we had in GitHub issues where you can see basically the conversation that existed.
It's two ways, I don't know if you.
- Do you do anything? Do you do anything at Atlassian? - We do some things at Atlassian and I think it depends. We have done similar things to what we were just talking about But I think what it comes down to, is the community that you're building, right.
And I think when you do link to some research and why it's bit us in the ass a bunch of times is that like, then people feel like, oh well they've already thought about it so we're not gonna really challenge the status quo and we'll just use this thing, but bitch about it because it doesn't actually meet our UCase, but they did research.
They kind of use it against us, which is fun, so I think a different way about it is kind of having thinking about the components and really being clear about what state are they at.
Is this a component that's really hardened and this isn't up for debate right now or are these things that we're considering, like we have some used cases, but maybe we could have more. And please, yes, invite people to have those kinds of discussions. And I think when you're being really transparent and really talking about what is your design system and that's kind of an existential workshop we held recently is like what is the design system? What are we about? And we only have these things and not these things and so again I think being really specific about why you exist at that point in time and it can always change and as I kinda talked about that a little, but I think that clarity really helps people to understand, okay that stuff is pretty solid, like we could probably challenge it, the colour stuff, but maybe not a thing I want to get into, but here is a specific used case for a drop down that they haven't thought about, that's a very different conversation.
So I think kind of making sure it's not just, oh we wanna contribute a thing, it's like what's the thing and why do you want to contribute it? That helps us to make those decisions.
- Yeah, just to expand on that.
Something that we did at Adobe that I thought was really unique is, because our guidelines to get into the system are pretty strict.
You have to do a lot of things.
You have to make sure it works on a bunch of platforms, it has to have four colour themes enabled.
It has to have all the accessibility checklist checked off. It's hard to get stuff into the system and that doesn't mean that there might not, there's things out there that fit a lot of used cases, that haven't been completely validated.
So we created a beta Lator system for things that are currently being experimented on and these are things that we create and haven't finished yet, but we want to offer for people to use and test or these are things that people contribute to the system that they haven't had the time to do all the work to contribute and meet all of these requirements to get to the official cannon of the system. So we called that Precursors, it was an application that just let you upload your design files and some descriptions and that started the canonization process, so once it was in Precursors, then we'll start partnering with you on supporting you to get these colour themes and accessibility checks and cross platformness into your component. - Thanks and so we had a question from nine which means that the next question has to come from ABC. Side track rules so just pretend you're from ABC. All right, now you've got a roaming mic.
- [Gentleman In Green] Oh a mic, perfect.
Okay, got it.
Hi, so 1,001 questions, but I'll probably focus on tools because I'm one of those people spending 30 to 40% of my time trying to improve tools and 100% doing everything else.
So Alex, you mentioned moving to Figma, I know there's a lot of posts out there, why to do it, but can you kinda talk us through that experience? We're a team of probably 60 to 70 designers so it's a big leap.
If you can just talk through how that happened for your team and how it's been adopted? - And also Inayaili you use Figma at Microsoft as well? - Yeah, just moved to Figma. Yeah. - Yeah, so all of you.
- So we haven't quite moved to Figma yet.
So, we're still supporting Figma and Sketch and that's because we have, all of our tooling is already in Sketch and a lot of people are using all of that stuff, it's part of their process and designers really love their process.
And so the way we approached introducing the idea of Figma is that we got a bunch of kind of licences just to try it and we just seeded it and everybody was like we'll try it and then report back and tell us how you feel. We kind of really made it from within, we were never the ones that were gonna say you should all use Figma and that is now the thing, it was very much coming from designers, excited about it and then certain people evangelising it and then people also really being honest about how it's a bit shit in certain things, but then we'd have content designers kind of talking about it and that's really exciting because they could now really engage with the work on a level that Sketch never allowed them to do and so for us it was really making sure that it came from the people using the tool, rather than the design system dictating what the tool's going to be.
- Yeah, I mean in our case, so many people need to look at a file.
Product managers, engineers, many, many other people that also we work across platforms so we can't really, I mean somethings we use Sketch, but it's not great of we have a tool that is Mac only and Microsoft.
- It's a business need.
- It makes a lot of sense to have something that can be seen by anyone on Linux, on Windows, on Mac, it doesn't matter.
- Sarah, I'm gonna wait for you to finish your water and then how does DEV work in with Figma? - I do not have a good answer because I've never worked with Figma yet.
- Great.
- Early days, but I have heard DEV saying, I'm gonna just, they literally.
- Just speak for Sarah.
- I will.
But I'm more speaking for the team, sorry. - Go for it.
- Anecdotal things DEV seemed excited because they can just go in and see it.
There is like removing a barrier and something that I didn't mention before, it's like it really kills about four or five other products, that we're already invested in like Abstract, Emural and Keynote to some point.
There are so many other benefits to actually having this one tool.
It almost feels too good, so we're still holding onto Sketch in case they come out with surprise, but we're just going slowly. But from the anecdotes that I've heard from designers, just reporting back saying the DEV's a really, and the fidelity of the kind of, they could get into the interaction piece of the design has been really positive.
- So, nobody's using Adobe UX.
- Adobe is using.
- Well yeah, yeah, that's.
- I actually, I just remembered because I was working with Figma for the first time this week.
And I have a view only account so it's been really cool because I can go into these files and comment on things and ask questions without having to go in and edit things.
And I personally used Figma on my personal projects as a designer and I found it to align better with my developer mindset than Sketch which is more just, here's a link and do whatever, you know. - All right, black shirt.
- [Gentleman In Black] I have, it's vague question. - Excellent.
- [Gentleman In Black] Yeah, I'm gonna try to just do thinking on the spot.
So design systems are typically popularised from companies from the inside out.
I'm a designer in an agency and I guess over the past couple of years.
I'm working with my team of developers to create a shared way of working.
And we've kind of crossing very similar paths in just kind of consolidating on our approach. I don't usually see or hear anything about design systems from an agency perspective, just from a applying to different projects. How does that kind of, does that discussion come up in your spheres of knowledge, anything like that? - I only have experience with design systems from an agency perspective as building design systems for a particular client, not as a design system that is overarching for the whole agency.
- [Gentleman In Black] Yeah, it's kind of like weird things where like spacing, topography across the projects. I approach them in a similar way.
I always have the similar conventions and similar spacing, although it's different for every project, having this shared language across my team, they know what to look out for, they know that an eight-point grid exists and we can talk about it in certain ways and I guess that's something that I'd like to hear more about.
I just wanted to know if there's anyone else that's. - There's someone in the audience that literally's doing this right now and I'm gonna do that weird thing where I'm gonna get someone else to answer that question. This is Dom, he works at the Thinkmill and this is what they do.
- [Dominic] It's Dominic, oh there you go.
It's switched on there.
Hi, my name is Dominic, I work at Thinkmill and that's what I do.
(laughing) So we are actually working on a framework specifically for design systems.
I believe that design systems are very much about your specific company and it's all about collaboration within the company.
It's very contextual, so you can't really build one product that will work everywhere, but there are as you say a bunch of things that you can abstract and align on and yeah, we work on it.
We should talk.
- [Gentleman In Green] We should talk about design system for design systems.
- Oh very meta.
- Web Directions summit bringing people together and putting them in inception situations. - Community.
- There's a comment from the back.
- From behind.
- [Gentleman] You can't really see me.
- [Interviewer] Yes Hi.
- [Gentleman] Hi.
Hi, that's a bit too loud.
So a couple of years back, I remembered I was working for a digital agency as well, right, and yeah, surely, with an organisation, with the design system which you are sort of designing for different customers, right then yes you're probably have the problems where it's very contextual like Don said, but I've had some experience where like, well the approach that we had was because we were a small agency and we kinda had to get things out the door like designs for websites out the door, right.
So, what happened was, it's like, part of it came from the designers themselves, right, where it's just like, they had this whole sort of component library which they would actually adopt a lot of their layouts which had very similar content and what he would do for every single customer right, is basically he would pretty much use these designs sort of like blueprints I would say from that component library that he has.
The thing was we started realising that sooner or later, because he was using a lot of those same patterns for a lot of the content and even if it was kind of a simple content based website, right. He was able to put all these sections of pages, right. It became so systemized that we were able to sort of find those patterns and kind of then create our code library for that and from that because he was using it for different customers, different organisations using this same blueprint, we were able to get the skeleton that sort of weighed out.
Even if there were differences in colours, margins and sort of stuff, but at the very least, he had the scaffolding to be able to pull all of these things out. So I mean that's another way to do it, if cost is an issue and if it's easier to put all these cookie cutter-like way of pushing out some design system out for all your other customers to increase your efficiency then that's the way to do it, yeah.
But that's just my experience anyway.
- Just to wrap this up.
I think that with agencies, it's really interesting place to play, just because we all like to think of our ourselves as being this really unique problem and it's our company specifically, but honestly, there is way more in common than we want to admit. And there's a lot of people that, we built all these internal design systems because the tools to create a white label design system don't really work. They don't exist.
We have bootstrap, but it's not great.
- No it's not.
- Talk to Don about this, but there's interesting things that you can do now. I think, is Ryan still here? Ryan, Seddan? No, he must have docked out, Zendesk is doing this really interesting thing, where they're providing hooks so you get all the functionality of a component without any of the design logic built in.
So you could take those hooks and use all of the information they give you about this is our select, here's how it works and then skin that entirely on your own, which is really interesting.
There's a lot of places you can play.
The real unique thing about your system is the documentation, like how you use it, the guidelines for how you use it. And if you have any specific branded elements like Yelp has a component for their rating stars, which is very specific to their brand.
- Any other last comments. I'm sorry grey shirt,
we are out of time.
- [Gentleman In Grey] No, I'm actually from the ABC. (laughing) - And scene, it's so poetic.
- Is it a quick question? Okay great. - It can be.
- [Gentleman In Grey] So you talked about adoption, but I kind of read in between the lines in your talk. I feel like it's sort of in that kind of, the middle of the journey.
I think your words were, "We just kind of hard coded some shit".
It sounded maybe it was a bit more mandate to kind of get the initial momentum going.
And you also mentioned that you had your founder in early workshops.
To what extent was it actually organic adoption or just kind of getting a bit of a push initially and sort of how important was getting buy in from the top in sort of getting that momentum? - I think it was pretty important, but I think the groundwork for that buy in has been happening for a long time. So it wasn't like now you see the value.
It's kinda why I told that whole pre-story around that. It was a mandate because it was business need. The business needed to evolve.
The products need to feel better.
They needed to actually rebrand and we needed to be about the people that we're serving and collaboration and all those other things.
So, there was definitely an attachment to, we're gonna solve a business problem with this specific rebrand which will then turn into a design system which then, we can evolve the way we do things and actually set us up to scale from that perspective. When we have acquisitions joining, that's been a big carrot, because, oh you have a design system, oh you've already thought about all of this stuff, how can we hook in? I know Sarah talked about Trello as one of those acquisitions with a very strong brand and very strong opinion and so that was very much a testament to our design system kind of robustness, when we have to bring something like that in.
Having that buy in is super important, but also it wasn't just because they thought it was a good idea. It was actually gonna solve a business problem that we had as a company and I think when you can attach that kind of importance to your design system that really helps makes sure that, that adoption does happen.
And we had to hard code stuff because there was a conference that we wanted to flick a switch and it's all now blue and it got us there, right.
And I think it wasn't pretty and it's not something that we're like, oh we are so proud of it.
We thought of it in such a systemic way, but then that really got that early investment and everybody was like yeah I see the value. Okay, yeah, you can keep going.
And I think it's kind of how do you have those wins maybe at some of the cost of it not being perfect or not being like the other design systems I see out there that it's, they seem much more systemic.
And so we're always evolving and I think a lot of the stuff that Sarah talked about is kind of the future and really the now of where we are turning ourselves into a system of tokens and scaling and all those things, which we didn't think about back then, because we had a different problem to solve. - This has been extraordinarily enlightening. - I hope so. - I've working
with design systems and looking at design systems for a number of years and I've never heard them discussed as completely as I've heard this morning.
So, thank you very much.
Inayaili de León, Sarah Federman, Alex Skougarevskaya. - Nailed it.
- Yes give them whoops. - All of you.
- It's a little bit different each time.
(audience applauding) (upbeat music)
