On-boarding designers onto Design System Management
Advocating for a Design System Management platform in a large organization.
Kevin Muldoon
Image by rawpixel.com
Christmas was fast approaching and I was in an extremely Grinchy mood.
Inefficiency, inconsistency, and uncertainty ran rampant in my companies internal systems. Modal dialogs, buttons, text fields, and date pickers (to name a few) were all over the map. Modal dialogs were different sizes, buttons were different heights and color schemes, text fields were inconsistent in behavior and function and we had no less than three date pickers.
As the new Product Designer for internal systems, I was supposed to fix all of these problems. I was going to make the UI amazing and bring clarity to the interface and make everything intuitive. I was pretty excited!
However, my attempts to create pixel-perfect designs and prototypes for new features and products slowed to a crawl. Even with an engineering and design background, I wasn’t productive. Certainly, not as productive as I thought I should have been.
I didn’t have a single-source-of-truth for any of these systems and it was killing my productivity big time.
I needed a break
I went on a much needed Christmas holiday to rest and recover from my previous year’s efforts trying to understand the systems and the users I needed to support.
And, as I mulled over the challenges I was facing, something occurred to me. Maybe I wasn’t the only one experiencing these problems! Maybe what we needed is a more comprehensive solution that everybody in every department could use. Something that would allow our entire organization to design at scale!
Digital System Management Platform!
I didn’t know much about Digital System Managers, but I liked what I heard!
The more I learned, the more I was convinced our organization needed a DSM Platform very desperately!
We needed a single-source-of-truth for everybody to eliminate inefficiency, inconsistency, and uncertainty in our company and DSMs were exactly the tool to do just that.
The most well known DSM is Material Design from Google, but it’s not the only one. SalesForce, IBM, Microsoft and Shopify, and many other companies created their own Design Systems and backed them up with a Management Platform (DSM) so their organizations could design at scale. They were solving the very problems I was struggling with.
The same problems I suspected others in my organization were struggling with as well.
The first on-boarding
After the holidays, I was re-energized with a new purpose!
I created a deck identifying three villains of design who delighted in making everything slow, difficult and horrible as possible for designers, engineers, copywriters & product managers.

I drew characters representing inefficiency (Vampire), inconsistency (Frankenstein), and obscurity (Invisible Man). Each had a motto, so we could spot them when they arrive on the scene. My favorite is Frankensteins. “It’s fine.”
I invited four designers from different departments to discuss the possibility of a DSM for our organization. I asked each designer on a scale of 1 to 10 how much they knew about DSMs. They replied 2’s and 3’s. “Great!”, I thought. Let’s get the show on the road!
I ran through the deck. The villains seemed to resonate with the audience, as I had hoped. Coincidentally, two designers in different departments were already working hard to solidify their own design systems, but nobody had considered a DSM platform to support their efforts.
When we left the meeting, everyone had an assignment. Study DSM and investigate InVisions DSM, ZeroHeight and UXPin or any others to see which off-the-shelf solution you prefer as a single-source-of-truth for the design systems they were creating.
The second on-boarding
Turns out, nothing is easy.
Of the three design teams, one exclusively standardized on Adobe XD for design and developer-hand-off. Everyone else used Sketch/Zeplin or Sketch/InVision.
I’ve been working with Adobe products for years but XD is new to the product design community and currently not very well supported like Sketch. Turns out, none of the three suggested off-the-shelf DSM Platforms supported Adobe XD at all!
Near the end of the meeting, a designer discovered Zeplin supported Adobe XD and Sketch and everybody in the room breathed a huge sigh of relief.
We had found the solution! Let’s investigate! Let’s see if Zeplin met the DSM needs of the entire organization. We’ll meet again next week and share what we’ve discovered!
Something didn’t feel right
You’d think I would have been happy we found a universal DSM solution in Zeplin but something in the back of my mind said that wasn’t right.
I’ve worked with Zeplin for years. Saved my bacon on countless occasions as I was splitting time between iOS Engineering and Design as well as getting Android on the same page — before I was a full-time Product Designer.
So, why was I uncomfortable with Zeplin as a DSM solution? At the time, I couldn’t say. My spidey-sense was tingling and I just couldn’t explain it.
Obscurity almost won!
I had to think pretty hard on this. So, I went back to the basics.
A DSM is the single-source-of-truth for designers, copywriters, engineers & product managers. If it’s going to work, it needs to be effortlessly available to everyone across the organization.
I figured it out! I knew why my spidey-sense was tingling!
Our main villain, The Invisible Man (obscurity) would never be defeated with a Developer Hand-Off Platform (DHOP) alone because that is exactly where the Invisible Man lives!
Was that counter-intuitive? Allow me to explain…
A designer invites individual co-workers to a Zeplin project, each of whom receives an email. When the email arrives, each co-worker opens and accepts the invitation. Their browser launches and takes them to the website where they create their user/pass, if they haven’t already before. Once all those steps are completed, users are finally granted access to the content. Already, we have three steps of obscurity. An exclusive invitation, an email, and a signup process.
In contrast, a DSM is all-access. No email, no invitation, and no signup! It is the opposite of obscurity.
It’s a dictionary, not a novel.
Think of a DSM as the leather-bound dictionary/grammar guide – the single-source-of-truth for how words are spelled and sentences should be created.
To carry the analogy further, a DHOP is the draft of a novel — constantly changing and refined until it’s perfect. Just like a copy-editor wouldn’t use any book on the shelf to find the correct spelling, the engineer doesn’t use the DHOP as the gospel truth of the design. The engineer uses the DSM and the DHOP to discover the truth of designer intention.
The key difference between DHOPs and DSMs is access. What surprised us most as we looked deeper into these solutions is that a DSM cannot replace a DHOP nor does a DHOP replace a DSM. To fully defeat the villains of design, we needed both!
Unlike a DSM, DHOPs contain proprietary information such as new features and products which shouldn’t be accessible to the world as they are being created. Access should be small and controlled.
However, when a DHOP is supported by a DSM, new features and products naturally become more efficient, consistent, and certain just as any novel is better when the writer has access to a dictionary.
Obscurity defeated, and more!
DSMs offer a lot more than just defeating obscurity. While DHOPs and DSMs appear to share several similar features, (Defining typography, colors & automated design token generation) DSMs support a key role in showing functioning code examples, animations & most importantly hyper-links. DHOPs do none of these things.
Consider one engineer uses React and another uses Angular. If the engineers wanted to reduce their workload and share knowledge, they could create UI frameworks for their stacks, upload to github and the DSM can hyperlink to that repository so everybody can benefit from their efforts.
If a designer in one department prefers Adobe XD rather than Sketch, they can create an Adobe XD version of the Sketch library, upload to AWS, and likewise publish on the DSM so it’s useful to every designer in the organization.
It’s the ability to effortlessly share and collaborate that makes a DSM such a powerful tool.
Publishing Adobe XD DS into a DSM platform?
Got good news and bad news.
The good news is that a DSM is a single-source-of-truth for the entire organization and it doesn’t change often once it is set up.
While truth does change over the lifetime of a DS, the process is much slower. We take care to version each release for clarity. (ie: MyAwesomeDesignSystem_1.0.1).
The bad news is if you’re working in Adobe XD and you want an easy way to defeat inefficiency, inconsistency, and obscurity by leveraging DSM, you need to import those XD files into Sketch and upload it to the DSM.
Until DSM platforms provide Adobe support, there is no other way.
Lessons learned
Engineers were the easiest to onboard to DSM. They could see the benefit of creating a separation of concerns between best practices of UI code and business logic. A DSM helps maintain a sense of separation between the two.
Product managers understood that an accessible, single-source-of-truth would make new features/products more consistent and speed delivery to market, so they were on-board nearly instantly.
The big surprise was designers were most difficult to onboard!
Designers liked the idea of DSM. However, some found it difficult to understand the unique responsibilities of a DSM and how different those responsibilities were from a DHOP. After all, they’ve been successful without a DSM for years. Why would they ever consider to change their workflow if they’ve been successful?
However, thanks to their questions and participation, I found a way to communicate those differences because they forced me to really think about what I was advocating for.
The truth was, I wasn’t able to communicate the benefits of DSMs to designers from their point of view, because I didn’t fully understand DSMs myself! Their concerns/questions sent me right back to basics to study DSM all over again, and it made me a better advocate for it.
(This article was first published on medium.com)
👋 Let’s be friends! Follow me on Twitter and Dribbble and connect with me on LinkedIn. Don’t forget to follow me here on Medium as well for more design-related content.
Upvote
Kevin Muldoon

Related Articles