As a follow up to our previous conversation about measuring speed with design systems, Amy, Nathan, and I recorded another chat about measuring quality.
Many thanks to Lucijan Blagonić for capturing these notes about the conversation! (Links added afterwards.)
Decision making and consistency
- It’s harder to align on consistency when you have many teams using the system — and sometimes DS team doesn’t even own that question of consistency of how something is used in a product.
- It’s important to agree on what consistency means for us internally (consistency of what with what).
- Sometimes we just need to agree on something to move things forward by making a provisional decision, as trying to solve all things up front might feel like trying to boil the ocean. Conversation can be facilitated in the direction (e.g. designing a card):
- There is no alignment on X, so let’s not have opinions or try to solve X now,
- We need to agree on X, even if we don’t have a best answer (and be open about it).
- Prepending “provisional” to the decision disarms and empowers the team and helps us agree on enough so that we can move forward (with the data we have) and revisit in a couple of weeks after we get new information.
- “Design systems need to provide certainty” is a line DS teams often tell to ourselves and get into trouble with obscuring that we are uncertain about something. It’s empowering for teams to know we don’t have the answers sometimes, and to know where the gaps are so they can fill them.
Design systems
- The most matured and effective systems are those that change at the way that is predictable: make the change visible, communicate it really well, and understand that people might not want to upgrade something (or they might want to upgrade only parts of it).
- Speed is important to people, and they often choose a lowered quality product if it’s faster (to adopt, to use). If you remove the constrain of speed, it will lead to higher quality, but will take longer for the system to evolve and erode satisfaction and trust.
- A leak in quality is multiplied in a design system.
- Design systems are more about proximity to certainty than certainty itself (moving thinking from DS as a library and more as a way of doing things). And the way of doing things always changes, design work is often culture work as opposed to just building components.
Working together
- Teams react better when there is a clear expectation. Be explicit about the decision (“this is our best guess”), sometimes we need to put things live and we don’t know the answers.
- Set a better expectation when communicating upcoming work (e.g. Upcoming Q4, 2022), that way teams can plan their own work if it doesn’t fit their timeline.
- Setting up release cadence can alleviate uncertainty, e.g. quarterly releases for non-breaking changes, yearly releases for breaking changes. This helps with planning and it addresses the uncertainty to a certain degree and helps teams plan ahead.
- PMs see a breaking change and they think it’s a complete UI refactoring, release cadence can help with planning (you might even introduce a “systems week” that can be planned in sprints).
- We are not building with them, we are building for them. They choose to depend on us, and they want to understand what is the nature of that dependency.
General takeaway: You have to build the idea into the company culture that it is OK to go back and change things, and the idea should be ingrained in the product teams.
Join 57,400+ subscribers to the weekly Dan Mall Teaches newsletter. I promise to keep my communication light and valuable!