Scaling Design with Design Ops: The UX of UX, by Chris LaChance
Chris works at Pega, which has had a lot of challenges lately:
- Norman Nielsen group recommends a 1:10 design/developer ratio. Pega has a 1:70.
- It’s hard to get the designers all on the same page, particularly since they’re around the world.
- And before pandemic they were purely in-office. Remote is a new way of working.
- They were also putting in their first design system.
The design system had 155 components + patterns. Design operations was the key to their success.
What is design ops?
Design ops addresses challenges such as: growing and evolving design teams, creating efficient workflows, and improving the quality and impact of design outputs. (Also hiring, but we aren’t focused on that today.)
Start with people. First, get to know your team. Share out the pain points. For them, the key was that people wanted “quick and simple collaboration”, and people wanted to “know and find everything to do the job right.” If you can’t find the assets to do your job well then it’s hard to do your job.
Next, they looked at the reputation their team had in the larger company. Learn from the larger org how design and dev collaborate and communicate. In Chris’s case, he learned that the pain points were around collaboration and documentation.
Lastly, they learned about their resources. IT, Legal, and other stakeholders that drive what designers do. Sometimes stakeholders didn’t know enough about design (or vice versa) and needed conflicting things.
At the same time, they asked questions using anonymous surveys, so that answers could help solve conflict, rather than create it. The team looked at the tools they were using, and found that the tool itself mattered less than the goal of the tool. They needed to make sure they were using tools that accomplished the goals needed (not tools that had the perfect UI). Another thing they looked at was file etiquette.
What feedback loops are there in place? Where are there open chat spaces, what needs to come through newsletter updates or joining in meetings with larger teams? These helped keep the team aligned.
The design systems were a catalyst to accomplish a lot more.
For example, site and reference docs: how do you give official design assets to internal and external teams? The team began to understand what documents they really needed. How do they onboard people? What’s the best way to talk about the mission statement?
The team started considering what they needed to create, in addition to “mockups”. Things like Component Docs with measurements and gaps. Names of assets, etc.
Recently, a new measurement is showing that collaboration is way up. Thinking of these things has changed the way people work and what they put out into the world.
- Red tape is seen as bad, but you actually need red tape to hold you together.
- Repeat yourself. You need 6 attempts to remember.
- Transparency and clarity was really important. Docs were available, but people needed to understand what was happening and why.
- The team needed to be ready to pivot as needed. Case in point: initially the team was called “design governance” but after finding there was unfortunate stigma with that name they changed it to “design quality”.