Case Study: Design System Management

|

Case Study

Design System Management

My job was to make my fellow designers’ jobs easier.

This happened by providing

ongoing partnership and consulting, along with
well built components and tokens, and
comprehensive documentation and usage guidelines.

With this approach, many high-value and high-return products were delivered efficiently and established

Previous Efforts

Consistency in the details builds trust with your customers, and when businesses have multiple products to juggle, they tend to not to have time or bandwidth to focus on those details.

While the company had employed other design system managers before, the effort had not always been well received.

Previously, efforts had tended to be

Too authoritarian — "you have to use these components" often rubs people the wrong way.
Too undefined — "Let the components speak for themselves" does nothing for consistency.
Too disconnected — AI-written documentation published without review can be rife with contradictions and confusing direction.
No integration with dev — The design might look great in Figma, but if every dev team has to rebuild the components from the design, then that simply multiplies the inconsistencies and transfers the problem down the pipeline.

“You have to use these components. No unapproved colors, type, or styles.”

❌

Too authoritarian

“AI can write the docs. We don’t need to worry about that.”

&

“Figma designs are good enough. Just toss ‘em over the wall to the devs.”

❌

Too disconnected

“We don’t need any documentation. The components can speak for themselves.”

❌

Too confusing

A New Approach

When I took the position, I decided to treat my coworkers as my clients. That meant allowing them the autonomy to be "wrong", or more accurately, it meant eliminating the idea that "wrong" even existed.

Provide a library of components and patterns the disparate teams can pull from. Governance can come later.

This began with the a philosophy of stocking a pantry, not enforcing a diet regimen or setting a meal plan. I provided the components and guidance for them to use. I could inform others on how the pieces were built and what they were meant for, but I held no control over the implementation of the design system in their products.

Regular working meetings with teams ensured check-ins were informal and more informative.

Design stayed open for exploration by individual teams and designers when the existing components didn't meet their needs. This allowed for speed on the product teams when deadlines constricted.

And I did lots and lots of consulting and mentoring. I ended up touching almost everything the other designers were working on in some small way, and by putting the product needs first, the designers started seeking me out for advice and help.

Further Outcomes

By choosing not to directly govern and police the design system's usage, that left time for me to refine the system itself. This meant enhancing the components what we have in Figma and connecting more with the developers on the design system team to implement those components accurately.

As time progressed, this also came to mean I was working in the code base itself, filling design gaps and erasing design debt by fixing the small details that never would have surfaced in a JIRA priority list.

Thanks!

|

Case Study

Design System Management

My job was to make my fellow designers’ jobs easier.

This happened by providing

ongoing partnership and consulting, along with
well built components and tokens, and
comprehensive documentation and usage guidelines.

With this approach, many high-value and high-return products were delivered efficiently and established

Previous Efforts

Consistency in the details builds trust with your customers, and when businesses have multiple products to juggle, they tend to not to have time or bandwidth to focus on those details.

While the company had employed other design system managers before, the effort had not always been well received.

Previously, efforts had tended to be

Too authoritarian — "you have to use these components" often rubs people the wrong way.
Too undefined — "Let the components speak for themselves" does nothing for consistency.
Too disconnected — AI-written documentation published without review can be rife with contradictions and confusing direction.
No integration with dev — The design might look great in Figma, but if every dev team has to rebuild the components from the design, then that simply multiplies the inconsistencies and transfers the problem down the pipeline.

“You have to use these components. No unapproved colors, type, or styles.”

❌

Too authoritarian

“AI can write the docs. We don’t need to worry about that.”

&

“Figma designs are good enough. Just toss ‘em over the wall to the devs.”

❌

Too disconnected

“We don’t need any documentation. The components can speak for themselves.”

❌

Too confusing

A New Approach

When I took the position, I decided to treat my coworkers as my clients. That meant allowing them the autonomy to be "wrong", or more accurately, it meant eliminating the idea that "wrong" even existed.

Provide a library of components and patterns the disparate teams can pull from. Governance can come later.

This began with the a philosophy of stocking a pantry, not enforcing a diet regimen or setting a meal plan. I provided the components and guidance for them to use. I could inform others on how the pieces were built and what they were meant for, but I held no control over the implementation of the design system in their products.

Regular working meetings with teams ensured check-ins were informal and more informative.

Design stayed open for exploration by individual teams and designers when the existing components didn't meet their needs. This allowed for speed on the product teams when deadlines constricted.

And I did lots and lots of consulting and mentoring. I ended up touching almost everything the other designers were working on in some small way, and by putting the product needs first, the designers started seeking me out for advice and help.

Further Outcomes

By choosing not to directly govern and police the design system's usage, that left time for me to refine the system itself. This meant enhancing the components what we have in Figma and connecting more with the developers on the design system team to implement those components accurately.

As time progressed, this also came to mean I was working in the code base itself, filling design gaps and erasing design debt by fixing the small details that never would have surfaced in a JIRA priority list.

Thanks!

|

Case Study

Design System Management

My job was to make my fellow designers’ jobs easier.

This happened by providing

ongoing partnership and consulting, along with
well built components and tokens, and
comprehensive documentation and usage guidelines.

With this approach, many high-value and high-return products were delivered efficiently and established

Previous Efforts

Consistency in the details builds trust with your customers, and when businesses have multiple products to juggle, they tend to not to have time or bandwidth to focus on those details.

While the company had employed other design system managers before, the effort had not always been well received.

Previously, efforts had tended to be

Too authoritarian — "you have to use these components" often rubs people the wrong way.
Too undefined — "Let the components speak for themselves" does nothing for consistency.
Too disconnected — AI-written documentation published without review can be rife with contradictions and confusing direction.
No integration with dev — The design might look great in Figma, but if every dev team has to rebuild the components from the design, then that simply multiplies the inconsistencies and transfers the problem down the pipeline.

“You have to use these components. No unapproved colors, type, or styles.”

❌

Too authoritarian

“AI can write the docs. We don’t need to worry about that.”

&

“Figma designs are good enough. Just toss ‘em over the wall to the devs.”

❌

Too disconnected

“We don’t need any documentation. The components can speak for themselves.”

❌

Too confusing

A New Approach

When I took the position, I decided to treat my coworkers as my clients. That meant allowing them the autonomy to be "wrong", or more accurately, it meant eliminating the idea that "wrong" even existed.

Provide a library of components and patterns the disparate teams can pull from. Governance can come later.

This began with the a philosophy of stocking a pantry, not enforcing a diet regimen or setting a meal plan. I provided the components and guidance for them to use. I could inform others on how the pieces were built and what they were meant for, but I held no control over the implementation of the design system in their products.

Regular working meetings with teams ensured check-ins were informal and more informative.

Design stayed open for exploration by individual teams and designers when the existing components didn't meet their needs. This allowed for speed on the product teams when deadlines constricted.

And I did lots and lots of consulting and mentoring. I ended up touching almost everything the other designers were working on in some small way, and by putting the product needs first, the designers started seeking me out for advice and help.

Further Outcomes

By choosing not to directly govern and police the design system's usage, that left time for me to refine the system itself. This meant enhancing the components what we have in Figma and connecting more with the developers on the design system team to implement those components accurately.

As time progressed, this also came to mean I was working in the code base itself, filling design gaps and erasing design debt by fixing the small details that never would have surfaced in a JIRA priority list.

Thanks!

|