(upbeat music) - So, I'm Yaili.
Hi, everyone.
Thank you for being here.
Again, I'm usually a bit nervous before speaking, especially if it's, I think it's super normal, but especially if it's a multi-track conference that makes me especially nervous that no one is gonna show up.
So, I'm happy to see each and everyone of you, so thank you for being here.
So, let me briefly tell you a little bit more about who I am, so that you know who is talking to you.
My name is Yaili.
I am a cat person who now has a dog.
I also have extremely unhealthy obsession with podcasts, and I am a European citizen living in London, which is very fun these days.
My parents are from Portugal and Panama.
I grew up and studied in Portugal, but I was born in Russia, which makes it very, very exciting to go through passport control sometimes if they notice that in the passport.
Anyway, I am a designer in the developer services division at Microsoft. We build the tooling in Azure to help DevOps teams to be more productive. My main responsibilities in the team are with design operations and design systems, so all of that fun stuff.
The design team is distributed across the world, across several timezones.
We have people in India.
We have people in Europe, and we have people in both the east coast and west coast of United States, and most people work from an office, but some people do work from home, like myself. I have worked on design operations and design systems for a bunch of different companies and different teams since way before there was a fancy name, and now I think that having a name makes it much easier to tell people what I do, instead of having to list 10, or 20, or 30 things that I do on any given week, at least it makes it easier for people in our industry. Because when other people ask me what I do, like a taxi driver or something, there's still an awkward pause and I don't know what to say, and I just end up saying I'm a web designer. I always understood the ways in which having processes, and guidelines, and good documentation, and flexible components, and code that is already robust made my job easier, and how if those things were done properly, it can also mean better quality for the products that we are doing.
But I really saw the power of these things when I went on maternity leave, which was just over five years ago.
He is much bigger now.
For reference, I don't know.
I actually had a quick look earlier how it works here. But in the UK, if you're an employee, you are entitled to take up to 52 weeks of parental leave, not all of it paid, not at all.
And I was planning on taking all of it.
So we had a person who was going to be my cover in place, but his role was actually going to be split between two teams, so he was not gonna just cover my job full time, not just my role.
When I left, we had what we called our CSS framework in place, which was a bunch of very simple, but very robust and flexible components.
We had core typography, spacing, colour palette, layouts and guidelines on how to put things together, and we also have things like copy guidelines and really strong brand guidelines.
As any other design team, we were always really pressed for time, and we were completely stretched thin trying to balance work that we knew as professionals that was important to improve our sites and products, but also trying to support many different teams that needed us.
So being one designer short for an entire year was not gonna be ideal, even with all of these things in place.
So I think you probably guess, you can probably guess how the story goes.
So the design system and the processes that we had in place ended up being like having another designer in the team, and maybe it was a designer that didn't have a lot of opinions and that couldn't create anything new, but it was definitely one that could get a lot of things out the door and done to a good level of quality.
And don't get me wrong, everyone was extremely happy to have me back when I came back.
I ended up being out for 13 months.
But the design system didn't take my job.
There's a lot of stuff that a robot designer can do, like it can't evolve the system it can't evolve the process, it can't think of new ways to solve problems, but there was a lot that it could do, and that's why we're also obsessed with this idea of scaling, design teams, and of systematised design and of processes that make us work more efficiently. I just realised that there was a baby in the audience and that was so cute.
So the idea of scaling design makes a lot of sense to me. I've seen how it helps teams reducing redundancy and automating repetitive tasks and documenting is something that other industries have done, and it's something, for instance, that engineers do, it's almost second nature, it's part of the job. And no one is saying that engineers are losing their jobs to frameworks or that engineers can't be creative in their work. There's enough difficult issues that automation can solve. There's a to of problems that a computer doesn't understand the way that a human can understand with all of the nuances, all of the grey areas. And the idea that we can't be creative as designers because there's 10 or 20 components that we have to use, it's also a bad excuse to not define processes and create these frameworks.
As long as the processes and the systems are delivering on their promise to uphold high standards and to represent the best that's being done across our teams.
But we need to consider who these processes and these systems are for, who's using them, who are they affecting, and that's us, that's the people, that's the humans. So what I wanna focus on today is how can we get those benefits of systematising parts of our work without forgetting that all of the processes, all of the moving parts of our design systems, all of that has an impact on the daily work of real people. When you think of people, there are a few things that people, that humans want. You can look up a few different definitions of what human needs are.
When you look at some of these different theories, you start to see that they have certain things in common, things like belonging, growth, significance. They should be the focus of how we define how our teams work.
And don't worry, there's no need for me to read all of these. I'm not gonna read this.
I will share the slides and all the references in the end if you wanna explore these and other theories, but there are a few ideas here that I would like us to consider.
First is the idea of certainty and predictability. So you don't want your job to be boring, but there are limits to how much unpredicted and unexpected things you want thrown at you on any given day.
It's important for some things to be stable and for them to be predictable.
Then the idea of belonging.
it feels good to know that people care about you and that people are genuinely happy to see you, that people think of you when they go out for lunch, that they care about your opinions, that you are respected, and that you are part of something. Then the idea of growth, and this is about personal growth, not about product growth.
That's a different thing.
We are in a knowledge-based industry.
We come to these conferences to learn from other people, to expand our networks, to have our curiosity sparked by a certain topic, and then we go and explore more.
So I would guess that most of us like this industry because it's somewhere where we need to keep learning and keep evolving. And then finally, the idea of validation.
We like to be recognised for what we do.
We like our efforts to be recognised.
We don't like it when people take credit for our work. We like when people acknowledge our contributions. We love badges, and stars, and upvotes, and karma points, reputation points.
There are also other needs that seem relevant, like the idea of equality and fairness, the idea of autonomy to make decisions, and the idea of being able to give back, contributing to something, and to find meaning through those contributions and through that participation.
So remember, no matter how rational we think that we are and that we are making decisions based just on facts and that we don't let emotions take over, especially not at work, these needs underlie everything that we do. They underlie our behaviour, our reactions, how happy we are, sad we are, how we feel at the end of the day, and maybe even the quality of the work that we're doing. Imagine if you are working in a team where you have no sense of security, where everything could change from one day to the next, and there was nothing that you could count on, where your voice wasn't heard and people took credit for your work, where you can never question everything, where you didn't like anyone and no one really cared much about you, and where you were still doing the same things the same way you were doing them five years ago or 10 years ago and nothing had changed and you haven't learned anything.
And actually, not exaggerating, there has been some jobs that I've had that sound a little bit like this.
And if this sounds familiar, maybe it's time to do something or leave.
If you want a design team that is doing great work, that is helping organisations many times their size, which is what scale is about, you need to remember that all of these things, all of these things that humans need to flourish and that they need to do their best work.
There are three principles that I would like you to think of when defining processes and systems that are human-friendly.
If consider these principles, if you remember them, you should be able to establish processes where people can do good work and thrive.
The first one is think remote first, above everything else.
You may think that you don't have a remote team, so you don't need to define workflows that are remote-friendly, but we can all be remote workers at any point, even if it's only for a day.
Let's say if you are snowed in, or there's road closures, or you're waiting for a delivery, or waiting for the plumber to come, or maybe you're travelling to a conference but you still have to take a call from your hotel room, or maybe you wanna visit family that live somewhere else, but you don't wanna take some time off or you can't take any time off, or your dog is sick, or maybe you're sick, you broke a leg, you're sick in a way that you can still work. So remote doesn't have a mean all the time remote, just like accessibility doesn't make things easier only for people who have a permanent disability. It also makes it easier for people that have a temporary accessibility issue.
If you make things easier for people who are not at the office all the time, you end up making things better for everyone else as well. So think about how accessible things are for someone who is not working from an office. What could you do to improve their situation? Are there are any simple things that you could put in place that could make a world of difference? The second principle is to have an engineering mindset. So how do developers work? In theory of course.
Things are not perfect all the time.
There's a few ideas that we can take from this principle. One thing that is very different between designers and developers is the ability of anyone being able to pick up someone else's work and understand why they did something and what to do next.
Of course this isn't always the case, but, in an ideal scenario, I think that's what engineering teams are trying to achieve.
You write documentation, you set up environments that can be easily replicated, you define standards and define tests, and you try to remove redundancy and repetition as much as you can.
On the other hand, I have worked with many designers who said, who kept saying all the time, "I am the only person who can finish this, "and I don't trust anyone else to finish my work." If an engineer said that a few times, I think they probably would be fired.
So don't indulge that designer, and instead think about how to create systems that allow for work and knowledge to be shared and to be distributed, and not siloed into just one person's head. And don't be scared of defining systems that remove the need for everything to be manual, for every button to be crafted from scratch, and for everything to need a mock-up.
And finally, empower people to challenge decisions. Does your team feel like they can question something before it's too late or are all of the decisions mandated from the top down and no one dares to raise any concerns or suggest alternatives? Do engineers feel equipped to ask things about the design process, and about mock-ups, and about the research, and about content? And the same for designers or for other disciplines. And do people feel like they are part of the decisions? Are they invested in what they're working on? This doesn't mean, or actually this could easily mean that things will never get done, because we know that designers and engineers can have a lot of opinions.
I'm not saying that every single thing that you do needs to be scrutinised by everyone and then nothing ever gets done.
But also, what is the point of hiring a really smart and diverse group of people with lots of experience, and different world views, and great skills, and great expertise if you're not going to let them speak up when they notice something that is not quite right? That doesn't make a lot of sense.
You can hire much faster and probably much cheaper and get the same results if you're gonna be doing that. So creating safe spaces for people to speak up, and to give feedback, and to voice concerns, and have ideas, obviously, in an environment of respect will make your team somewhere where people want to come back to.
So these were three guiding principles.
Let's look at a few specific things that you can put in place to define systems that are human friendly and establish processes where we can all thrive and produce great design at scale.
First thing is to document everything.
So again, we like a certain sense of stability and certainty.
We also like to be autonomous and to have the resources that we need to make decisions and to do our work.
The key resource is access to information.
And in our teams, that means access to documentation. Obviously, we can't really document everything, but you can document a lot, and maybe even things that you are not documenting yet. So pay attention to the times when people are asking where things are, or what happened in a certain meeting, or how is something done.
The idea that knowledge is only known by one person or by a very small group of people should be a very scary thought for anyone that is leading a team.
Because any time that that person walks out the door, and I mean walks out the door literally, not walks out the door as in leaves the team. Every time they walk out the door, the knowledge is going away with them.
And also, we forget things all the time.
I've been in many, many, many meetings where let's say we were reviewing work and making decisions, and then we didn't write things down.
And the following week, no one remembered what we have decided, or why we didn't make a decision, or why we made a certain decision.
And I'm talking about meetings with five, 10, 15 people in them, and no one remembered. So if you consider this in the context of being remote-friendly and remote first, you can't just tap on someone's shoulder at the office and ask them something, and you also can't necessarily just message someone to ask them, because they may be on the other side of the world, they may be asleep, and now you don't have an answer, and now you're blocked.
So trying to solve this situation where someone is blocked because they can't access knowledge and information should be one of the main things that you're trying to fix when you're establishing design systems and design processes of how people are working together.
One of the hardest questions to answer more than making people write things down is where, where is this all going.
Where are you going to save meeting notes, and important decisions, and next steps, and guidelines, and research? If you start documenting things, but they end up just living in someone's laptop, that's not as bad as not documenting at all, but it's also not much better.
So where do you want all of these words to live? Is it going to live in one single place for every single kind of documentation, or does it make more sense to separate things? For example, when I was at Canonical, we documented meetings notes in a private GitHub repo. It also made it easy to link issues from that meeting to other repos, so to link work items.
And we documented design system requests, and proposals, and questions in issues in a public repo, because the system was opensource, so that repo could be public.
And we use those issues to track any discussion, any decision about that specific design system question.
So try to think of ways that are easy, that meet people where they already are, and avoid introducing new tools, because that never goes down very well.
But there are many other ways to do it.
It doesn't have to be GitHub issues.
Maybe you have a Wiki, or maybe you use Google Drive, or SharePoint, or Dropbox.
There's many, many other options.
Along the same lines, just to note that templates really help, people really, really want templates.
What is the point of having a bunch of ingredients if you don't have a recipe of how to put them together, right? It's the same having a bunch of loose UI components that only live in Sketch or only live in Figma, and maybe that's gonna look really beautiful in a portfolio, but if you really wanna deliver on the idea of scaling design and maintaining quality, you need more than that.
And templates help things to, help things, makes them look okay.
It's one of the pieces of documentation that I see that people, they use design systems asking for more often. From all of the teams that I've been in, I think it's probably the most requested feature always, templates.
And they are not going to solves all of your problems. That's why you're saving time with templates, for the simple things and the common things. So think about how do you ask for someone's email address in your product, or what does a page that just have headings and text look like? What is the simplest form that you can have, or what is the most common form? So start small and add more as you can.
Identify what are the repeatable patterns and make templates that people can copy, and paste, and reuse.
But don't do this alone.
Get people that know the product, that build the pages, and also that are interested in helping and contributing to the design system.
Ask them what they need.
Ask engineers what are they usually more often asked to build, and that's how you find where you should start. To allow for asynchronous participation, support asynchronous participation.
Going back to the idea of belonging, and being part of something, and of being significant. One thing that I find a little bit funny is that we all say that we wish we didn't have so many meetings, that we have time to actually do some work. And then when someone calls a meeting with a bunch of people and you're not invited, you're really upset.
That happens to me.
We know that designers and engineers have a lot of opinions.
And as humans, we like to be consulted for decisions. And when you let people participate and know what's going on, it makes them more likely that they're invested in the next steps, even if they can't necessarily change the big picture, because they know how you got there and they understand what compromises were made. We also wanna feel part of something.
We wanna feel part of a team, whether we're working from our home office in a remote part of the world or from a super fancy office in the middle of a big city. If you're thinking remote first, you are considering different locations and timezones. So not everyone can be in every meeting, and sometimes really important stakeholders can't be in a certain meeting.
And again, it may not be because they are remote workers. It may be just because they're travelling or they're sick. So allow people to participate in conversations outside of that very small hour when you have that call. Let them add comments somewhere later, share the notes, and be a little bit more transparent, and let people continue conversations.
This is very important for design systems because you don't want to make decisions too quickly. When you're defining a new process or introducing a new component, for example, you are introducing another piece to the system and people trust that the system is robust, and it's flexible, and it's well-curated, and standards are not defined in a rush.
You can just look up the speed that the W3C publishes their final recommendations.
So it's okay to make decisions as slowly as you possibly can, and sometimes that's going to be super fast, that's as slow as you can go, and sometimes that can be a little bit slower. Slower can also mean healthier.
So, I'm in London, I work in London, and I work with people that are in San Francisco, and there are in Seattle.
When I'm finishing my day at 6:00 p.m., they're just starting their day.
It's 10:00 a.m.
If I felt that all of the decisions were made during their working hours and I couldn't participate in the conversations and have a say before it was too late, maybe I would start working late, and then that would make it really hard for me to have a healthy schedule, and to see my family, and to go out on Halloween, and I would always be worried that I would be missing something, even though I was working late.
And that's not great for your mental health, and to avoid burnout.
You may be getting a lot of extra work from people that are burning out, but obviously that's not a sustainable way to scale. So let people participate in the conversation even if they are not physically in the room, and let them participate in the conversation during their normal working hours.
Think back to the principle of giving people the tools to question decisions, and that means giving them the time and the opportunity and being transparent with how you make those decisions. Three, promote transparency.
So there's a few ways you can promote that transparency in your design teams.
Does everyone in your team know roughly what's happening that week, and who's working on what, and why? I feel that engineers do this a little bit more easily. I think there's usually, it can be some reluctance from design teams to want to track their work, but it doesn't mean that every single bit of work needs to be tracked, or that you need to follow a certain methodology of project management.
But generally, you should have a good idea of what's going on.
Once, I joined a very small distributed team that wasn't tracking their work anywhere, cross-discipline team.
We set up very quickly a very simple board in Trello, and it was like night and day for the remote team especially, the people that weren't in the office, because they had a much better sense of what was happening in the office.
And yes, it did mean extra work, especially for people that were in the same office, and they would just normally talk to people next to them about what they were doing, but I would say it was a very small price to pay to include everyone in the team and make the work visible to everyone, and to give everyone the same information and access to the same resources.
It's also the best way to show people the amount of work that a design team has on their plate, and to show that your time doesn't expand infinitely. And if you don't have a way to visualise your workload, it's going to be much harder to say no to more work and to see patterns of where things can be automated as well.
Other ways to promote transparency is to avoid the big reveal of design work.
So show and share work in progress as openly as you can. It doesn't have to be to the whole world or to the whole company, but as openly as you can, and also try to make the way that designers talk about their work and how we bounce ideas back and forth and how we decide to iterate, and try something new. Make that process and make those conversations visible if you can make them visible.
Not everyone is going to be paying attention, but it's a good opportunity to educate your organisations about design.
Fourth is to educated, don't dictate.
I'm not a big fan of saying that we need to educate people about design and how design works. I know education obviously is not a bad work in itself. Education is a good thing, but it does always sound a little bit patronising to me in this context.
But anyway, I'm gonna use it.
High standards and excellent quality is the promise of a design system and of a design process that you want people to follow. People should know that what comes out of this process is very good, and that is going to mean some sacrifices, and many times those sacrifices are to do with speed and with volume, with quantity.
You want people to understand why things are done the way they are, and why there is more careful inspection of what goes into design system.
A set of UI components and guidelines that are defined by a design system should be a lot more polished and a lot more flexible than a mock-up that was done in a few hours to just solve a very specific problem.
So review may be tougher.
Things may take a little bit longer to be defined. Maybe you need to do more variations, more testing, more revisions.
But if you don't and if you start shipping things that aren't quite right and they're a little bit buggy, then you are breaking the main promise of the system. So instead of thinking of these reviews and this scrutiny as moments of tension, think of them as learning tools.
Think any interaction that people have with design could be a learning moment.
And people can learn just by watching other people do their work, they can learn what it means to be a good designer. They can learn to understand.
They understand design processes, and learn what designers value, and how designers can be valuable.
Design and designers aren't going away any time soon, so getting better at working with design teams is a great skill for other people to have.
And many people with job titles and job descriptions that don't include design in them still have to do a lot of it.
There are many things that you can do to create these learning moments.
You can start by defining some checklist or some guidelines of how designers should conduct themselves.
For example, let's say you have office hours. So you should have at least some bullet points of how to speak with stakeholders and anyone that comes to those meetings.
So what to do if someone comes with a large project, instead of a quick question, or what should you say if you aren't able to help them, how can you still help? And talk about how you want your reviews and your critique sessions to happen and also define some ground rules for that. And don't forget your documentation.
Don't make assumptions about who's reading your design documentation. Don't use jargon that you can't define easily. Make sure you give links to help and to learn more about things.
Think about documentation as a tool that gives people a little bit of the knowledge and a little bit of the super powers that designers have. So think about how every interaction with your team can be a learning moment and how you can empower other people to understand design and to grow as professionals who know how to work with design teams and get the best from them.
Five, make contributions visible.
If you are building a design system or already have a design system, it's very likely that you're gonna be taking contributions, even if it's in the form of requests or documentation changes, proposals, or improvement to existing things. Design system work is usually interesting and people want to do it.
They wanna help if they can help.
Many times they wanna help because they are invested in something specific. They want that thing to be added to the system. Many times they wanna help because they just want to help. One time I worked with a team where the product manager, she didn't want me to add.
She asked me to not add any design system work to the engineering backlog, because she was worried that if I did, the engineers were going to pick up that work, instead of the planned work.
She said she was afraid that they were gonna think it was too interesting and they would just ignore all of the plan and they would just pick up that work.
And that's great, I think that's good news. I did as she said.
I've got another presentation, the ink is in the notes, about how to improve contributions to your system. You can watch that online.
But what I wanna make sure that you do is to highlight those contributions when they do happen. I've heard about teams that have created pins, and badges, and t-shirts that they only give to anyone that helps with their, let's say with code, or documentation, or any other contribution to their design system. Can you imagine how nice it is if you participate and then you get one of those? Obviously, you don't have to spend that kinda money. Your design system probably doesn't need a logo, but you should give shout outs as much as you can, let's say in a newsletter, or you can write blog posts or tweets if you are working in a public way. You can include a list of contributors in the documentation. I think that's something really nice that I've seen in some documentation sites.
There are so many ways.
Just make sure that people feel validated and rewarded for their effort, and then they will hopefully do it again and again. And more people that see that will also want to participate. Six, don't be a blocker.
If you're working on a design, on design process, and systems, you can easily be seen as the design police or the UI police if you're not too careful. Even if you are careful, you may be seen as that. Saying no and asking people to wait and asking people lots of questions is probably going to be part of your day-to-day. If you say yes to every request and to every proposal, you're not doing a great job of curating a design system that delivers on the promise of high quality, and flexibility, and of a strong brand, but you need to find ways to maintain those standards and still understand that people need to get on with their work.
Maybe they can't wait two weeks until they have the next design system meeting to approve a new component.
So how can you deliver on that promise? Do your job of defining a great system, but also not be a blocker, and saying no firmly but continue still to be approachable and helpful. And I think this is the difficult thing.
You want some level of control, that's why there are guidelines and there are pre-made blocks of user interface, but not everything that is being done is going to fit nicely into what's already predefined. If you aren't able to have some kind of answer for this question, eventually, people will stop following your processes and using your systems, and they will eventually die.
So think of how teams can still work autonomously, how the processes can allow for custom things, for exploration, and for experimentation.
I cannot tell you what's right because each team is different, and I know that some systems can be more flexible than others.
But as much as you can, make it possible for imperfect things to be tried quickly without tainting what's already there and what is already solid and robust, and hopefully test it.
That is the only way that a design system is going to evolve and that design evolves and doesn't become stagnant. You're always trying to improve your products and the same is true for the underlying systems that you want people to keep using.
So design systems and processes were changed isn't bad word or it isn't a bad thing.
As much as humans like that stability, we also want to know that we're evolving, and that we're learning, and that we're growing, both at work and in our personal lives.
So if someone finds a new and better way to solve for design problem, are you allowing for that to be incorporated into how you work? Finally, hire generous people.
So I wanted to include this almost like a foot note, but it's also very important.
I'm making some assumptions during this talk, a lot of assumptions about who the people in your team are, and also how you're hiring more people.
We don't have time to go into the subject of how to hire designers, but whatever hiring practises you're following, you want to be looking for people that can show that they can be generous in their work, that are not seeking recognition only for their own contributions, but for their team's work, and that are proud when their workmates are successful, and that work hard to make people around them successful. So people whose first instinct is usually to share what they know and to show their work and who can take feedback gracefully.
This type of profile can be more common in more senior practitioners, but that doesn't mean you can hire people starting their careers.
A design team, a design systems team, design ops teams can be an excellent place for learning about how things work and seeing how you do affect other people, not just people that use your products, but also people that you work with every day. And if you have leaders who are examples worth following, those who are just starting will have a really great gift of being able to observe what it means a good designer and a good leader without having to be arrogant and selfish.
So to conclude, the need of scaling design comes from the fact that design teams are usually outnumbered at the same time that good design practises are a necessity for any good product.
So it's a goal worth aiming for.
It doesn't make our jobs less creative.
It doesn't have to make them boring, but our jobs may evolve in the process.
So when you're laying the foundations that are needed to have design teams that produce an amount of work that is exponential to their size, and that is of high quality, and you're adjusting your workflows and creating design systems and establishing new processes, think first about how are they helping your people thrive, and how are you looking after people first, how you are trying to scale taking to account the needs of the humans that are going to make it possible, because it's humans all the way down.
And that's me.
(audience applauding) (upbeat music)
