[핵심 번역] 어떻게 디자인 시스템 구축에 동의를 얻어내는가?

핵심

디자인 시스템의 부재로 느껴지는 비효율성. 이에 비롯된 자원 낭비를 피부로 느끼지만, 그 필요성을 회사 내부에서 소통하며 주장하기는 쉽지 않다. 그 이유는 평소 업무가 기능적인지, 근본적인지에 따라 나뉘기 때문이다.

평소 업무는 기능적이다. 내가 A라는 기능의 디자인 작업을 하면 눈에 보이고, 종종 비즈니스적 성과까지 얻어낼 수 있다.

반면에 디자인 시스템은 말 그대로 바닥부터 뼈대를 세워가는 근본적인 일이다. 눈에 보이지 않고, 그 속도가 느리다.

물론 둘 다 중요하지만, 우선순위에 따라 근본적인 작업은 뒤로 미뤄진다.

 

We’ve all talked about design systems enough that it seems like by now, the benefits of having one would be clear. A design system helps us build products faster, enables teams to understand shared components and processes, and creates a consistent user experience. But in practice, we often face organizational barriers to implementing said design systems. Not to mention, sometimes it’s hard to even sell other designers on the need for a design system.

 

You’re reading this post, so I know that you probably feel the costs of working without a design system every day. But it’s not always easy to communicate the downsides of not having one, and the possibilities and benefits of implementing it.

 

This challenge sits at the core tension of most companies’ two competing needs. There’s the need for functional work (e.g., to ship features), and the need for foundational work (to build infrastructure like design systems that supports operations and growth). Choosing to invest time, energy, and money in one means investing less in the other.

 

Often, functional work produces tangible, short-term results, like a new onboarding flow that increases conversion rates. But foundational work contributes intangible, long-term results, such as increasing the velocity of feature launches. And yet, both are essential components to running a long-term, sustainable business.

 

There are many unseen costs of working without a design system. Getting buy-in comes down to showing not just why it makes your life easier, but how it can make an impact at every level of your organization. Here are three practical ways to get it.

---

부서 간 장벽이 업무를 얼마나 비효율적이고 느리게 만드는지 보여주자

핵심

디자인 시스템의 효용성을 어필하려면 비효율적인 업무 흐름을 파악하자. 
단일 소스로 협업하며 의사 결정하는 것과 디자이너마다 각자 다른 파일을 가지고 작업하는 것은 협업에 큰 차이를 보인다. 

 

“Where can I find the latest version of this?”

Whether we hear the question from a new designer or engineer, it pops up when it’s not clear where or who to turn to when you need to find something.

 

One way to get buy-in for building a design system is to find inefficient workflows that highlight the need for more structure. Here are some ways other teams have approached it:

A peer-to-peer review system, recommended by designer João Araújo, can help uncover breakdowns in the work without specifically pointing fingers. Fanduel found that a design system helped them peer reviewwithin a distributed team, because they could all see the design process and provide feedback along the way.

At Everlane, annotating, exporting, and handing off files to engineers was the final, time-consuming phase of their design process. Now that their team works with a design system, all the files are in one place and can be annotated and then inspected by all team members immediately, no handoff required.

Once you’re talking about how workflow is breaking down, you can suggest how you can work together to fix it. You can demonstrate the need for a design system by highlighting where there are multiple versions of files, duplicative workflows, and a general lack of organization in the design files.

Documentation also decreases the likelihood that we’ll be duplicating work. When I worked at Instacart, each designer had their own set of files and multiple copies of said files. Sound familiar? The lack of transparency in our team’s progress created inefficient workflows, which have since been resolved by a design system (one which I had the pleasure of helping implement 😁).

By demonstrating how a design system can be that single source of truth, clarifying the collective decision, and allowing every team to work knowing they have the latest assets, you’ll be better positioned to “sell” it more broadly. You already know, but soon others will, too: when everyone can work with fewer interruptions, we all become more agile.

---

어떻게 고객이 기능들의 비일관성을 알아차리는지 강조하자

핵심

고객이 제품을 사용할 때 자신의 기대와 다르게 반응하는 이유는 인지적으로 명확하지 않기 때문이다. 

그 이유는 마치 제품 요소 마다 각각의 디자이너의 목소리가 들어가 있는 것과 같다. 즉, 일관성이 떨어지는 디자인이 반영되었기 때문이다.

 

There was a time when I worked on a small team that was releasing one feature every week. After our initial feature sprints settled down and we were no longer simply treading water, we were able to take a look around, talk to customers, and figure out how to refine the product. In conversations with customers, we noticed them saying things like:

“I don’t understand why your color palette is super different in this area, and this area.”

“I know when I click on this one feature, it works this way, not the other way.”

There were clearly points where the product didn’t feel cohesive to the customer. Each segment of the app felt like the voice of each individual designer. Because we hadn’t committed to a standardized set of principles and components, we would often rely on varying personal preferences (“I chose this color palette because it suits my individual feature”).

 

Inconsistencies in interaction and components cause cognitive strain on new users who can’t understand the logic of the UI.  Ultimately, it leads to an unintentionally diminished customer experience. A lot of this comes from shipping new features constantly, like my team was, without looking back on how the previous features have been performing.

 

We began to see clear signs of design debt, which my team had accumulated by not prioritizing foundational work as we grew. Over time, we had to refine a lot of design in order to address our customer expectations.

Our focus on shipping features is what caused our design debt to pile up in the first place. If our team is able to consider usability, the benefits of a design system become even more clear.

 

Another way to increase the likelihood that your organization will buy into the need for a design system is to use metrics and feedback to highlight how we’re negatively affecting the customer experience. Give them the hard facts! Whether it’s pulling in real customer feedback, or adoption/retention numbers.

In the absence of a design system, we put extra responsibility on the customer to figure out how to navigate a platform instead of presenting them with an intuitive and unified design throughout the product experience. Make your design system about the customer, not you.

---

동맹을 만들고 디자인 시스템에 대한 공동의 오너십을 강조하자

핵심

디자인 시스템이 디자인 팀을 떠나 많은 부서에 도움이 된다는 점을 얘기하자.

그 결과로 모든 부서가 하나의 목표를 가지고 팀으로 움직일 수 있게 될 것이다. 

 

Despite its name, the benefits of a design system expand beyond the design team. Starting a conversation about how a design system improves workflow contributes to better cross-functional collaboration, too. More importantly, it allows engineering to become a part of the conversation early, inspiring a sense of ownership throughout the entire process.

 

Mike Dick, Design Technologist at SurveyMonkey, recommends finding an engineering counterpart within your company, someone who shares your passion for closing the designer and developer gap. This ally can teach you how design systems will be used by developers and how you can best appeal to them. Julie Nergararian, Software Engineer at HubSpot, echoes this need for collaboration: “Redesigns only work when co-owned by designers and developers.”

 

To start the wider discussion, invite everyone who would be involved in or affected by a potential design system. Keeping participants updated and involved will remain an important part of your design system, post buy-in.

 

Kick off the conversation by looking for widespread issues within your company. Nick Stamas, who created WeWork’s design system, Plasma, says he started with a Google Doc, getting team members to articulate their problems and where the workflow was breaking down. If something is slowing down a designer or developer, you know it’s also affecting the product manager, who’s responsible for the features that are being shipped out. Since a design system needs to solve issues for a company as a whole, we need to first show team members that each problem is a shared pain that we need to tackle together.

 

Take those common problems and use them to examine the potential of a design system. Jordan Girman, Senior Director of User Experience at Glassdoor, had his team members look at three questions:

• What’s the need for this system?
• How is design being implemented now?
• How should it be implemented?

Posing these questions to your teammates will not only have them considering how to fix the problems we identified together, but will also how a design system can solve these problems. You can then set design goals and requirements that work for the company as a whole.

 

Getting other teams involved early means they’re far more likely to actually care when they understand the origins of the design system and the intent behind it from the onset. Seeing the design system evolve over time will also just evoke greater overall enthusiasm and investment into what it will become.

---

디자인 시스템에 대해 내부적으로 알리는 것을 잊지 말자

핵심

디자인 시스템 작업을 지속적으로 알리고, 사용해보도록 만드는 것이 중요하다. 이해관계자들을 그 작업에 관여시켜 오너십과 기여를 하도록 만들자. 결국 목표는 사람들이 함께 임팩트를 만드는 것이기 때문이다.

 

Though change requires upfront investment, our teams can’t grow sustainably without a design system.

Once you’ve gotten buy-in and your team is working on a design system (or has completed a first version of it), it’s important to socialize it. You need feedback from the people using it.

 

Continuing to keep stakeholders in the loop on system updates will ensure that you’ll all feel a sense of ownership and collectively continue to contribute to make it better. Get people together, even if you have to resort to food bribery (hey, I’ve done it). Because ultimately, a design system supports the core tenets of what it means to be part of a team: people working together to make an impact.

 

원본 글 

Make the case: How to get buy-in for building a design system - Abstract