Scaling design teams is the super power we all wish we had. We define processes, create tools, and invest in systems, confident that we’ll be able to replicate high quality experiences and products at scale. But it’s humans all the way down, so how can we make sure we are you looking after our humans in the process of organizing, automating, and systematizing our teams? How can we develop processes that center on the people whose day-to-day practices they affect, at the same time that we make strides toward efficiency, speed, and scalability?
- yaili on Twitter
- Microsoft Developer
- A comprehensive guide to design systems
- DesignOps Handbook
- Vanilla Framework
- THE 7 FUNDAMENTAL HUMAN NEEDS
- Maslow’s hierarchy of needs
- Microsoft Accessibility
- Vanilla Framework proposal issue
- Google Drive
- Design systems: how to foster participation – video
— Alex ✨ Webdirections Summit week (@skougs) October 31, 2019
Inayaili works at Microsoft doing DesignOps since long before it was a cool name… but it helps to have a shorthand name now!
She always understood how having some process could help deliver things, but it was really driven home when she took a year of maternity leave while working at Ubuntu. When she left they had a CSS framework in place, called Vanilla; but even with this and other things in place being short of a designer for a year was still going to be a challenge.
Having the design system in place was like having another designer on the team. It didn’t have opinions and couldn’t do new things, but the design system increased the team’s capacity to get things out the door.
There are a lot of things a robot designer can’t do (solve problems, make new components); but there are a lot of things it can do… and those things help you scale. The limitations are balanced by their value.
How can we get the benefits of systematising parts of our work, without forgetting that all of our process have an impact on the daily work of real people?
What do people want? There are lots of definitions but they have common themes – belonging, growth, significance. We should focus on these for our teams:
- Certainty and predictability – you don’t want your job to be boring, but you don’t want chaos either. It’s important for some things to be stable.
- Belonging – it’s good to know people care about you and are pleased to see you
- Growth – personal growth, not product growth
- Validation – we like to be recognised, we like it when people acknowledge our contributions, we don’t like people taking credit for our work
No matter how rational we think we are, we are emotional beings and our needs underly everything we do. Imagine working on a team with no sense of security, no consistency, you had no voice, you couldn’t question anything, you didn’t like anyone, nobody cared about you, and you were doing the same things without change……
Three principles for design success:
- think remote first – we are all remote workers at times, so make systems that support remote work. Just as a11y isn’t just for people with permanent disabilities, it’s for everyone at some point.
- have an engineering mindset – understand how developers work and see what you can take from that. Developers write code assuming someone else will need to pick up their work and continue it. They comment code, define standards, write tests, try to keep the code clean and readable. Designers often get caught up thinking or saying “only I can finish this work” – engineers would get fired if they said that.
- empower people to challenge decisions – do engineers feel equipped to ask questions about the design process? do designers ask questions about dev?
Guidelines for human friendly design at scale:
- Document everything – this gives people certainty and autonomy. Think about what you have and haven’t documented, and what people ask about. Knowledge should never be held by just one person or small group. Decide where you will keep you knowledge.
- Templates – people like templates. Ingredients aren’t as useful without recipes. Start with simple things like a small form, simple content layouts, make lots of templates you can copy and paste and re-use. Get other people involved, ask engineers what they need, build from there.
- Support asynchronous participation – are meetings the only way you currently make decisions? Can you find other ways to let people participate even if they couldn’t be in the room? Consider people working remote or in other timezones. Also make sure enough time is being spent on decisions! You shouldn’t make design system decisions fast, you should make them well so they last. If you only use meetings you are forcing remote workers into longer hours, which is really bad for work/life balance. Let them participate in their normal working hours. Choose tools and processes that enable this.
- Promote transparency – does everyone know what’s happening this week? What they’re working on and why? Developers usually do this pretty well, designers tend to resist tracking their work. A simple Trello board can be incredibly valuable for a design team. Not just to track your work, but to make it visible – and to visualise how much work is being piled onto the team! Avoid the ‘big reveal’ approach at the end of the process, share things as you go. Be open about how designers work, how ideas are tossed around, how decisions are made – make those processes visible.
- Educate, don’t dictate – you want people to understand why things are done the way they are, why things are scrutinised and tested more heavily before going into a design system than a quick mockup. Any interaction with design could be a learning moment. Many people without ‘design’ in their job title do quite a lot of it. Don’t make assumptions that everyone reading your design docs is deeply trained in design. Empower other people to understand design and grow as professionals who know how to work with design teams.
- Make contributions visible – design system work is often interesting and people often want to help. Highlight those contributions when they happen! This may be literal things like stickers and merch that only contributors get, but you should at least give shout outs to people who contribute.
- Don’t be a blocker – if you are working on design processes and systems, you can easily be seen as the UI police. Saying no and asking people to wait is part of the job; but do it in a way that doesn’t make your team a blocker to others. Remember that if your system doesn’t do what people need, it will eventually die. Make room for experimentation and flexibility. Make it possible for imperfect things to be tried quickly, without undermining the existing pieces that are robust.
- Hire generous people – you want people who can show they can be generous in their work, they are not seeking glory just for themselves, that are proud when their workmates are successful and work to help others be successful. This may be more common in more senior people, but it can be there at any level.
You need to scale because design teams are usually outnumbered; and you need systems and process to handle that. It doesn’t make our jobs less creative, it enables the team to produce exponential to their size.
Think about the needs of humans that make it all possible, because it’s humans all the way down.