How to Democratize Design Systems

or ‘How to set up a bicameral practice’ or ‘How I learnt to balance power to run a stable form of governance’ or ‘How my idealism failed me at first and then saved me later’.

A confession before I start. When I started setting up the governance I had no idea that it was headed towards a form of bicameralism. It was an emergent phenomenon based on the push and pull of competing powers and priorities within the organization and that is why I think it is beautiful.

When I first started setting up the governance model, I had simple idea. A very simple idea. Not values. Not principles. Not laws. Not rules.

Just a simple idea(and a little idealistic) that people will work together if they have to accomplish big things that cannot be done alone. I just need to set up checks and balances so that the power is distributed and there is no room for autocracy (including myself as the leader)

I started to build a governance model based on this idea.

There were 50+ designers spread across 4 major groups. Each group was led by a lead designer and they worked with their product and dev lead counterparts. These design leads reported to the head of design to whom I also reported.

Product Leads sent requests to Design Leads who in turn assigned them to designers based on priority and capacity. The finished work is then handed off to the Dev leads. Not a very complicated structure. (Simple waterfall operating in a quasi agile aka Dual Sprints like anywhere else. I am oversimplifying it for the benefit of this conversation)

Starting trouble

I thought it would not be very difficult to set up the basics like colour, typography and iconography because they were driven by brand. I was wrong. The first indication of the storm to come started with the decision for error colour. For most companies it would be an easy decision. Any accessible shade of red would work but for companies with red as their primary brand colour, it was not that simple. Here is (almost) how the first meeting between the senior designers went:

A: Are we sending wrong signals by associating error with our brand colour?

B: No! The context is different. People don’t make that kind of connections. Look at brand X and brand Y. They are also red

A: Can we explore?

C: How about orange?

D: We are overthinking this

A: Lets come up with some options

Me: I am leaning towards with what B said. It is the norm in all digital ecosystems. People are smarter than to make that association. However it is only my opinion. It may be a good idea for us to explore. Can we come up with some accessible options in the next two days? If all fails, we can go ahead with this shade of red.

Dev Lead: What should we do now?

Me: Let’s go ahead with this one for now. We can replace it if we find a better option.

A: We should get the feedback from all designers. Let’s conduct a poll.

Me: Erm. I would rather not have a poll. Majoritarianism does not mean good decision. There is at least 75+ years of design experience in this room. We should be able to decide what colour the error message should be.

A: I still think we should ask everyone.

Me: Sure. Lets give it a shot.

First mistakes

That right there was my first mistake. I was too afraid to put down my foot on basic decisions. I wanted to involve everyone that I ‘thought’ was a stakeholder in the decision making process. I wanted consensus.

After three weeks of back and forth and polling, the consensus was to use (a colour close to) #ee6b24 as the error colour. Technically, there was nothing wrong with it but it did not ‘feel right’. We still went ahead with it but deep inside I knew that something was not right with this way of making decisions. (We later updated it to #ca3e00. It was a deep orange bordering red)

More mistakes followed as things got more complex with typescale and buttons. Someone thought H1 was too big and some thought it was too small. Someone thought the buttons were too big. Some thought it was too small.

Every tiny decision was bandied around and dragged along because there were too many people involved.

A hot mess

The next few months was a hot mess. I organized ‘Alignment sessions’ every Thursday. We would all meet on Thursdays to look at the rough draft of the solution for a design element (e.g :accordions) sketched by me and critique it, add use cases etc. We would refine the element as a group on the whiteboard (not pixel perfect mock)and agree on some basic ground rules for usage. We would also decide on the next element that needs to be addressed before the end of the session. I would then refine the element per our discussion and present it next week for sign off and also present a rough sketch for the next element.

The idea was to add elements week after week till all the basic elements were done.

Where it started falling apart is when some leads could not be present or had no context for feedback during the refinement but would offer all feedback after seeing the final mock. This would slow us down. So I changed the format and started presenting final mocks instead of sketches. But that did not help. We could never reach a total consensus and there was never a perfect ‘sign off’.

The timelines were fast approaching and we were not able to deliver. Leads started losing interest and they started delegating junior designers. It was a waste of their time. Soon it became a ‘free for all session’ and who ever was free on Thursday afternoon started showing up. The alignment meeting became a madhouse of ego conflicts and a hotbed for confusion with no decisions being made.

I clearly remember the meeting when I decided that I had to put an end to this. There were 14 designers instead of the 4 (that I had initially invited) and I was trying to maintain civility in the forum. I started dreading Thursdays.

Then one day, I sent a note cancelling the meeting until further notice. No one complained. I felt like an utter failure.

Breakthroughs

I had a very frustrating time for an entire year trying to resolve conflicts between people everyday. At first, I could not understand why people did not want to work with each other even thought they wanted the same things. I wanted all of them to be good friends and solve problems together.

I failed that year, but I had three valuable insights.

1. People were not able to align because they needed different design systems. One size does not fit all.
2. Aiming for perfection was a trap. I need momentum. I need to be so quick that I should be able to change things in the design system if I made a mistake instead of trying to be prefect and being scared of making a mistake.
3. No matter what I do there will be someone who is unhappy. My purpose as a Design System Leader is not to make people happy but to build a system where unhappy people had the opportunity and power to change things that made them unhappy. I was building a democracy among tribes that had learned to live with each other for many years while fiercely guarding their independence.

The minute I realized this, I developed a ton of empathy for the design leads and I realized that I was approaching it all wrong.

I decided to pivot on all three fronts.

First Light

My first light appeared when I started walking back home everyday with my Design Ops specialist. I would vent to him everyday and bounce my ideas off. He was an extremely nimble system thinker and was the only person around me who saw the beauty in these problems. Lucky for me, he was also a product thinker and started digging into this problem for me. A few days later I received a message from him “Hey Girish, You are not alone. Check this out!”

Reimagining Design Systems at Spotify

I still remember the joy that I experienced when the Spotify article validated my insights.

“This is exactly what I have been trying to explain. This is amazing!”

A few days later he sent another message, “I think I have found the solution for your momentum problem.”

Shape Up

We were already lean. We were already following an organic form of Shape Up. But Shape Up put a nice scaffolding around our organic process giving it a sense of orderliness. It was love at first sight for me.

Even though Shape up is not part of the Governance, it is important to understand that for context.

Shape Up

Over the next six months, we iterated on Shape Up with the help of the Scrum Master and the Dev Lead. They were such amazing partners. We started with a small component (a simple table) as an experiment. I sketched it on a whiteboard with a developer and co-wrote all behaviours down in a confluence document. Then we ‘designed in code’ because the foundational pieces were already available in the system. The output was nearly perfect. We knew that the idea worked. Over the next few sprints we started designing and developing simultaneously in the same format in the same sprint. We called it ‘Build and Iterate’.

Our first experiment was this:

Shape Up (requirement gathering)— Build and Iterate(sprint)

I handed over this process to my team to experiment more. They were amazing partners and they refined it further to match with the Scrum cadence.

Shape Up —Write Pitch(story writing) — Refine Pitch with Dev and QA (story refinement)— Build and Iterate

The team also created channels for each component per sprint so that they were readily available for each other and all decisions were taken immediately in channels instead of meetings. This saved enormous amount of time. This was the magic dust that propelled us rapidly because of the clarity and transparency it brought to the team during the sprint.

We knew that we had solved our momentum problem. Now it was only a matter of building muscle.

The initial days were met with some resistance from my team and my partners. Every time we hit a roadblock or a conflict, my lead designer would jokingly say, “Gym soreness. No pain. No gain. Don’t worry. We are not abandoning this. We are getting this done” I could not have asked for a better team and partners. They pulled this through and the resulting process doubled our velocity over time. You can read more about it here.

The Design Council (DC)

I abandoned our Thursday alignments after the hot mess period. It was an embarrassingly bad model for governance. Instead, I decided to create a council of experts in their chosen field instead of the design leads. This would keep the politics out and this council will truly be a neutral entity whose focus was only on ensuring that good design thrives. The council had experts from the following fields: UX, UI, UX Research, A11Y, Service Design and Front End Development.

This council would meet once every week to review all the pitches before it was taken up in Build and Iterate to ensure that it met best practices in all these domains. In addition to this, based on the the need, the experts would monitor the channels during Build and Iterate to ensure that the component was being built in the right way.

This was a great success as the Design Leads respected the experts and knew that everyone was equal in front of the council and no one was giving them the short end of the stick.

Phew! Things were getting better. Now the process looked like this

Shape Up — Write Pitch — Design Council Review— Refine Pitch with Dev and QA — Build and Iterate

Design System Working Group(DSWG)

All pitches were written by designers in the Design System Team. The application designers felt left out of the process. They said they did not know what was happening with the Design Systems at any given point in time. We responded by sharing our sprint calendar. It had zero effect on the problem. Thats when it hit me.

They did not want visibility. They wanted ownership. This was my second big breakthrough.

This is so fundamental to the success of any design system. For the designers have a sense of ownership and power to influence direction. It made total sense.

Currently, the Council was operating like a circle of benevolent elders of the tribe. Though the tribe respected the elders, they felt left out.

However, I was scarred by the Thursday alignment meetings. I could not bring myself up for another town hall kind of format. (I am not a fan of town halls because they only serve well for broadcasting and not for people to register their thoughts)

Instead, I requested the leads to nominate a member from their team to represent their interests in the Design System. The leads were too busy and were managing too many threads to do justice to this role. Some leads were thrilled with this idea. Some were skeptical. Some were indifferent. However, they all responded immediately and nominated their best system minds for this experiment.

I requested the DS designer and the Front End Developer (who already was a part of the council) to shepherd this fledgling group till they were ready to take over major responsibilities from the Design Council.

All pitches now went to the DSWG first, who would evaluate the merit and quality of the request and would help designers to clean up the pitches before it was sent to the council.

DSWG met every Tuesday and filtered the requests for the DC that met every Thursday. This way, designers know what was happening every week in the Design System world. They could reach out their representative on the DSWG and understand what was happening. The DSWG reps could in turn teach and train the designers on the DS processes.

Bicameral Practice

In effect, the model now resembled closely the process of creating a law in a bicameral democracy. This is how it looked now:

1. Designers submit a pitch(proposal) for a new component/to update existing component
2. First reading at DSWG
3. Second reading at DSWG (if changes were requested in first reading)
4. DSWG passes the pitch to DC with comments
5. First reading at DC
6. Second reading at DC (if changes were requested in first reading)
7. Pitch is added to the Design System backlog with comments
8. Pitch is picked up by the team during sprint planning
9. Build and Iterate
10. QA and Release

A simple idea that saved the day

This is a great case for me where intent turned into practice into theory. The resulting model closely resembles how modern states choose to govern themselves. Like everything else, it was not perfect in the beginning. But like I mentioned before, not trying to be perfect was the first major breakthrough I had. As long there is momentum in the direction of right intent, things will fall into place. It is only a matter of time.

It all started with just a simple idea(and a little idealistic) that people will work together if they have to accomplish big things that cannot be done alone. I just need to set up checks and balances so that the power is distributed and there is no room for autocracy (including myself as the leader)

I realized that persistent optimism about an idea is the only secret weapon that I need for the idea to manifest and take form.

Thanks

Like all my notes on Design System, I owe special thanks to Nathan Curtis. Also, Spotify and Basecamp for their spirit of sharing. I owe huge gratitude to these three giants on whose shoulders I stand.

Rami Dahhan, who is probably the most intelligent person I have met and whose desire to learn and the passion for problem solving is unmatched.

Amir Abura, who can hustle the team out of any tough spot with his unbridled optimism.

Cody Marshall, the design heavy lifter who possesses an unstoppable energy and infinite strength and can propel the team at a velocity that feels dangerously fast.

Anabel Leva, who has been my partner in crime since day 1 and is the rock that anchors everything in the team.

Justin Jun, Joanna Kolbe and Umair Hafeez, developers that designers can only dream of. They made it look like all of this was really easy! What amazing people!!!