(번역)디자인 시스템은 무엇인가? -1부-

 

원문 링크:https://medium.com/@rangleio/what-is-a-design-system-7a3d63edfcf7

What is a Design System?

다지인 시스템의 정의와 의미를 해석하는 건 조직마다 차이가 있을 수 있습니다. 이 포스트에서는 디자인 시스템의 과거인 스타일 가이드와 컴포넌트 라이브러리를 이야기하고, 개발과 디자인과의 격차를 줄이는데 도움이 될 것입니다.

 

By: Varun Vachhar and Catherine Maritan

 

 

손을 떠난 문제

경험상 대부분의 조직은 웹사이트를 페이지의 집합으로 취급합니다. 페이지는 디자인에 대해 전체적인 관점을 제공합니다. 특정 컨텐츠를 어떻게 보여줄지, 목적은 무엇이며 사용자들과 어떻게 상호작용 할지입니다. 이런 이데올로기가 현재의 디자인과 개발 프로세스를 주도하고 있습니다. 디자이너는 각각의 페이지를 디자인하고 디자이너의 손을 떠난 디자인은 개발자에게 전달되어 프로덕트 매니저와 협력하에 태스크로 분리하여 개발에 들어가게 됩니다.

 

페이지 기반의 디자인은 대중적이지만 현재는 많은 어려움을 야기시킵니다. 어플리케이션은 점점 역동적으로 변하고 있으며, 그에 따라 인터페이스는 다양한 사용환경과 반응형에 대응해야 합니다. 고정된 하나의 목업에서 모든 상황을 설명하는 건 시대를 역행하는 행위입니다. 또한 개발이 진행되면 수정이 필요할 수도 있으며 예상치 못한 상황이 발생하거나 새로운 기능을 포함할 때 굉장히 어려울 수도 있습니다. 반면에 디자인의 요소는 계속 개선됩니다. 디자인과 개발이 서로 고립되어있는 동안에는 양쪽에서의 문제 해결이 어렵습니다. 시간이 지날수록 팀은 아래의 몇 가지 증상을 겪기도 합니다.

 

디자인 때문에 개발자의 손이 묶이다

디자인상에 새로운 요구사항이나 문제점이 발생하면 디자이너는 이전에 작업했던 페이지의 대부분을 수정해야 합니다. 이때 두 가지 시나리오가 있습니다. 개발자가 디자인의 개선안이 나올 때까지 손이 묶이든지 아니면 개발자가 디자인 없이 개발을 밀어붙여서 브랜드의 가치를 훼손하는 사용자 경험을 제공할지입니다.

 

프로덕트의 방향이 엉망이 되다

전통적으로 디자이너는 프로덕트의 경험을 전체적인 관점에서 생각합니다. 반면에 개발자는 디자인을 작게 나누어 구현하는데 집중합니다.

 

개발자가 디자인을 어떻게 구현하느냐에 따라 이미 구현된 디자인과 앞으로 구현될 디자인에 영향을 끼치게 됩니다. 개발자는 프로덕트의 전체적인 구조를 디자이너의 의도대로 구현할 수도 있고 하지 않을 수도 있습니다. 그러므로 결과적으로 프로덕트가 외부환경에 능동적으로 대처하지 못할 수도 있습니다.  

 

사이트 디자인이 일관성이 없습니다

사람들은 버튼 하나에만 36가지의 다른 스타일이 있는 사이트를 보고 스스로에게 이렇게 질문합니다. "누가 이딴 식으로 했지?"

 

이런 현상은 생각보다 많습니다. 우리가 페이지를 디자인하거나 개선할 때, 똑같은 UI 요소가 최소한 한번 이상은 사용됩니다. 페이지 기반의 디자인 내에서는 일관성을 해칠 수도 있고, 향후 업데이트에서는 버튼의 인스턴스를 누락시킬 가능성도 높아집니다.

 

같은 문제를 해결하는데 시간을 낭비합니다

새로운 요청사항이 생기면, 주로 디자이너는 새로운 파일을 만들어 새로운 디자인으로 작업합니다. 작업의 대부분의 시간은 디자인의 디테일을 결정하는데 들어갑니다. 이 드롭다운에 호버 했을 때 어떻게 보일까? 이 버튼은 어때? 이런 문제는 시간을 잡아먹는 경우가 많습니다.

 

디자인의 디테일이 중요한 건 사실입니다. 하지만 팀의 다른 디자이너가 이미 작업했을 수도 있으며, 같은 요소가 다른 페이지에서 이미 사용되었을 수도 있습니다. 드롭다운의 호버 상태가 이미 정의된 경우에는 다시 생각할 필요가 없습니다.

 

유지보수가 절망적이다

프로덕트의 각각의 페이지를 문서화하는 것은 절대 유지보수라고 할 수 없습니다. 이 방식은 디자이너가 이전에 내린 결정을 쉽게 되돌아보지 못하게 합니다. 갑작스럽게 조그만 하나의 변경점으로 12개의 디자인 파일과 6개의 문서, 그리고 22줄의 코드를 수정해야 한다고 가정해봅시다. 분명히 누군가는 문서를 업데이트하는 걸 까먹을 테고, 개발자는 일관성 없는 상황에 맞닥뜨려 어디서부터 잘못되었는지 머리채를 쥐어뜯으며 고민하게 될 겁니다.

 

시간이 지날수록 프로덕트와 문서의 덩치는 커질 것이고, 유지하는 비용도 커질 겁니다. 디자인과 개발의 부채가 쌓이고, 3년 후에는 아무도 프로덕트를 건들고 싶지 않을 겁니다.