Selling a Design System before asking for buy-in –

An “adoption first” strategy for an internal Design System at EA

Design systems are all the rage, as they should be. People like jina anne, Nathan Curtis, Charlotte Jackson, Dave Cronin, Anna, Alex Schleifer, Diana Mounter, and Andrew Couldwell are sharing wonderful information with the community at large. Teams like Salesforce, GE, AirBnb, WeWork, Google, Atlassian, and IBM are redefining how design teams are working together on Design Systems. Perform a keyword search for Design Systems on Medium and you’ll find no shortage of great articles on getting buy-in, the makeup, the management, and the operation of a Design System. This is not one of those articles.

Instead, this is an article of how we sold and gained adoption of an internal Design System at EA before we asked for buy-in. We call this system Joystick.

Why a Design System?

I’m currently leading Experience Design at Electronic Arts for the IT organization. Our design practice has a broad portfolio, but we are primarily tasked with producing compelling solutions in the areas of Customer Experience and Employee Experience. With Customer Experience, we provide design services for the global team responsible for helping customers 24 hours a day, 7 days a week to get the most from their EA games and services. For Employee Experience, we’re aiming to much the same for our colleagues, to help them get the most out of their time here as employees.

With such a broad portfolio, it’s really easy to have disjointed and disconnected experiences for users. Scale and reusability are complex beasts, especially if dealing with multiple tech stacks, a variety of skill levels, and users accessing multiple products across the globe on an every day basis. To provide efficacy while improving efficiency, it was vital we attempted to take on scale and reusability first. A Design System made sense.

When thinking of our approach, we held three hypotheses when considering a Design System:

  1. Developers and Engineers would welcome having one.
  2. Developers and Engineers are more likely to use a technology if they have a choice in using it.
  3. Getting up-front buy-in would be very difficult. User adoption would be the key to success. Do that first.

With those in mind, here’s what we did to validate those assumptions.

1. Developers and Engineers would welcome having one

I get messages daily, from developers and engineers asking to review a product or a prototype and provide feedback. Usually, those messages are sent AFTER a ton of work has gone into creating a website or an application. I want to say, “You should have come to us earlier! We could have helped you!”, but that will only deflate and invalidate their efforts to get to that point. I want to ask, “Do you have any measurable goals?” or “What outcomes are you seeking?”, but those are questions to ask of those requesting these products and prototypes.

Instead, I ask questions like, “Are you using any frameworks?”, “What kind of tech stack is involved?”, “What’s taking up most of your time?”, “What are you struggling with the most?”. In their answers lie an opportunity to have a positive impact on their work. One such answer, which has stuck with me since I heard it, was:

“I spent the last week trying to figure out how to make the best button. Ultimately, I just grabbed Bootstrap because I needed to get the work done.” — Anonymous Developer

This answer told me several things:

  • It told me that developers care. They care about what they make and they are trying their best to create things people will love. I have yet to meet a developer who has said, “I don’t care if people use this.” Despite differences in our approaches, those who do or make want the things they do and make to be useful, to be relevant, and to be used.
  • This also told me, they don’t have all the answers, don’t necessarily want to be accountable for all the answers. They are under pressure for delivering day in and day out and are willing to leverage tools available to them if it allows them to deliver on time.
  • Finally, Developers do not have an agenda to work against design teams. Timelines dictate whether pixel perfection will happen, not a desire to ignore design guidelines.

In my experience, Style Guides have always fallen short. PDF guidelines don’t really help developers or engineers because they had to do all the work of turning those guidelines into useful markup. Developers and Engineers were also responsible for creating the documentation to allow other teams to use it.

Joystick Tiny Guides

Traditional digital design assets equate to large files filled with “red line” guidance for margins, paddings, font sizes, etc. With deadlines approaching, there are only so many “red lines” a team can deal with before they just need to get stuff done.

Developers and Engineers had to be sold on the idea that Joystick would benefit them from day one. They have the ability to make and ship things every day with or without a designer and this is a factor in leveraging popular frameworks like Bootstrap or Foundation.

2. Developers and Engineers are more likely to use a technology if they have a choice in using it.

Developers are using frameworks and design systems every day (Bootstrap, Foundation, Angular, React, etc.) and they’re often free to do so. My guess is design teams aren’t telling them they have to. We had to consider this when thinking about our deliverables. Our research told us by making Joystick in the same fashion as other well known frameworks and by providing quality documentation, they’d likely adopt it because it provides them the assets they need but didn’t necessarily want to spend time building.

Developers also don’t want to be told what stack they need to implement, so a system that works for them regardless of stack is very developer friendly. We played around with many approaches, but ultimately found ourselves attracted to what teams at GE and Salesforce were doing.

In the end, we built a Sass framework, designed Sketch and Photoshop versions of the system, and wrote “tiny guides” of how we use the system ourselves so others have the guidance they need without being educated.

Simplified packages to start with our Tiny Guides

3. Getting up-front buy-in would be very difficult. User adoption would be the key to success.

I’ve learned first-hand, through my experience, friends, and the design community at large, that asking for up-front buy-in on many projects is difficult. There’s a certain amount of research and analysis needed to be done to get a good proposal together. It’s made an even more difficult if data to evaluate the potential gains on efficiency is not available.

It made sense for us to build Joystick, but when asking for commitments for money or resources, leadership teams will ask every question they can to understand the scope and ROI of their investment. When data isn’t available, the conversations soon lead to very subjective opinions on the perceived value of the ask. Those are not fun conversations to have. If we had data on usage, that would be a powerful metric to leverage in our ask for long-term buy-in, so we determined adoption was the key to our success.

Author: Ryan Rumsey

Collect by: