Recently, my friend shared this story over dinner. He is an iOS developer.
He had been tasked to create a core component for his company’s design system: a container view that sweeps over other views. But there was an issue with how padding was applied. The designer in charge of the component insisted there should be a fixed padding set for content. Most developers who used the component wanted to define custom padding. He was getting lots of requests by others in the company saying their designs can’t be achieved with the new container’s implementation.
Those who worked with me on frontend projects know, bad margins and padding really drives me crazy. They seem to be the trickiest thing for large companies.
My friend goes back to the design partner to change the requirements for the padding. “Let’s set it to zero and let people put things inside a layout view”. The designer explains, “design system needs to be opinionated; all views inside the container need to have the same padding set for consistency”. The tennis match was one of stamina. Conveying how practical usage is suffering didn’t really matter. My friend got tired and gave up after running around the court.
Conflicts like this happen all the time. Perhaps, it would help to think through a framework that helps both parties arrive at shared understanding and agreement.
—
Eliyahu Goldratt, in the book It’s Not LUCK, guides conflict resolution towards finding common objective. Each action in conflict is motivated by a requirement, which in turn, is motivated by an objective. If we can work back to find the common objective in a conflict, we have the opportunity to inspect underlaying assumptions and work towards resolving the conflict.
So in our story, we have…
Developer: [A. Leveraging the design system to unlock consistency]← [B. Flexible system that matches feature designs] ← [D. Remove default padding]
Designer: [A. Leveraging the design system to unlock consistency] ← [C. Consistent component behaviour through fixed values] ← [D’. Apply default padding]
My favourite thing about this framework is its invitation to show empathy. It forces us to inspect motivations on both sides. Conflicts are part of working as a diverse group of individuals. Being able to understand differences and learning to view problems from many lenses helps teams do amazing things.
—
Let’s take another piece of wisdom from (the super awesome book) Crucial Conversations by Kerry Patterson to help us.
Often, a conflict exist because each party doesn’t have the full picture. Much like a Venn diagram with two partially overlapping circles, each party has unique knowledge with some shared understanding between the two. We should approach conversations with a level of curiosity to close the gap on shared understanding (bring those circles closer together). What do you know that they don’t? More importantly, what do they know?
Going into a debate thinking you want to “win it” yields no favourable outcomes; only annoyed people having formed a poor opinion of you.
Again, this is sounding a lot like empathy.
—
A. Leveraging the design system to unlock consistency
Going back to our conflict, I played the designer and debated with my friend. We both asked “why” a whole bunch and tried to explain the differences of theoretical and practical issues.
This is where we arrived (if you care for technical details)…
Some containers describe layout patterns while others define interaction patterns. For example, a Card is a way to lay content out. A Dialog or a Split View may be more of an interaction pattern. Perhaps, we need to have an a rule in the design system on how to approach these two types of components. It make sense for layout views to pad content. How about interaction patterns? Perhaps the rule is to pair interaction components with a layout.
This seemed like a path forward to figuring out how to resolve the conflict.
—
Conflict resolution is all about empathy. Empathy builds great teamwork, which builds great products.