디자인 시스템 환경의 변화
머리말
해당 글은 디자인 시스템에 소개한 앞선 글과 함께 작성하였으며, 2022년 말을 기준으로 정리되었음을 밝힌다. 2024년 현 상황에는 피그마를 중심으로 더 발전되어 왔음에 유의하자.
디자인 시스템이 어떻게 변화되어 왔고 현재에는 어떻게 적용되고 있는지에 대해 작성합니다.
Design System의 진화
디자인 시스템은 전혀 새로운 개념이 아니다. 이전부터 관리의 측면에서 디자인 시스템이 활용되어 왔고, 현재(2022)에는 대부분의 서비스에서 디자인 시스템을 적용하고 있다.
Design System 관리도구의 변화
초창기 디자인 시스템은 대체로 브랜드를 위한 문서로 작성되어 공유되었다. 브랜드 아이덴티티 가이드와 같은 스타일 가이드가 그 예 중 하나다. 시간이 흘러 점차 디지털 제품 및 서비스가 늘어나면서, 이를 관리하기 위한 도구도 점차 디지털화되어 갔다.
현재의 스타일 가이드, 컴포넌트 라이브러리, 패턴 라이브러리, 콘텐츠 가이드라인 등을 포함하는 디자인 시스템의 개념은 2010년대 전후로 사용되었다고 해도 무방하다. 오늘날의 디자인 시스템의 개념은 애플의 HIG, 구글의 MD 등이 대표적이다.
디자인 시스템 개념 정립 이후 시대?별 디자인 시스템 관리 도구
- 2010년대 이전 - 디자인 시스템을 위한 도구의 부재 - 포토샵
- 디자인 에셋 및 UI ToolKit 관리를 위한 도구로써 활용
- 2010년 전후 - 디자인 시스템 관리 도구의 등장 - 스케치
- 심볼 기능을 통해 재사용성을 높인 디자인 시스템 관리 도구로써 활용
- 디자인 시스템 혁신을 주도
- 2016년 이후 - 디자인 시스템 도구의 전성시대 - 스케치, 피그마, XD, 재플린
- UI Toolkit을 벗어나 실제 코드와 함께 유기적으로 관리되는 도구로 활용
- 다양한 디자인 시스템 도구 및 프로토타이핑 도구들의 등장으로 다양한 가능성 시도
- 2019년 이후 - 압도적인 피그마의 전성시대 - 피그마
- 더 이상은 관리 도구가 아닌 협업 도구
- 디자인 시스템 도구의 사실상의 표준화
수많은 디자인 시스템 도구와 프로토타이핑 툴이 등장하고 사라져 간 현재 최고의 디자인 시스템 관리 도구는 피그마다.
웹을 바탕으로 한 협업, 사용성, 연결성 등 무엇하나 빠질 것 없는 디자인 관리 툴이다. 또한 지속적인 업데이트를 통해 프로토타이핑 및 다양한 플러그인을 지원하며 다른 툴 없이 피그마 하나로 제품에 필요한 모든 디자인 작업을 수행할 수도 있다. 최근에는 스토리북과 같은 UI 컴포넌트(코드) 관리 툴과 함께 사용하여 실제품과 더욱 가깝게 유지하고 사용할 수 있다.
개인적인 의견으로 현 시점에서 디자인 시스템을 관리하고자 할 때 피그마를 사용하지 않는다면, 무언가 잘못된 조직이라 생각이 든다. 제한적인 무료 플랜일지라도 쓰지 않을 이유가 없기 때문이다. 가장 큰 걱정은 비용이다. 어도비가 인수했기에 향후 피그마의 행보가 어떻게 될지 걱정이 앞선다…
현재(2022)의 디자인 시스템 환경 - 디자인 시스템의 양축 피그마와 스토리북
프레임워크 내적인 UI 테스트 도구가 없는 웹을 기준으로 작성하여 스토리북에 주목하였다.
현재의 디자인 시스템은 더욱 제품과 더욱 밀접한 관계를 유지하고 있다. 이를 관리하기 위한 툴로 피그마와 스토리북이 많이 사용되고 있는데, 피그마는 제품의 전반적인, 그리고 디자인 작업에 초점이 맞춰진 디자인 시스템을 관리하고, 스토리북은 피그마와 연동하여 실제 제품에 적용될 컴포넌트를 테스트하고 관리하기 위해 사용하는 경향이 있다.
피그마(Figma)
디자인을 위한 디자인 시스템 관리 툴의 사실 상의 표준이다.
IT시장을 주도하는 수많은 글로벌 기업들이 피그마를 통해 디자인 시스템을 관리하고 있다. 디자인 시스템의 형식은 저마다 천차만별이지만, 대체로 다음의 구성을 포함하고 있다.
- 파운데이션 - 디자인 토큰 및 스타일 관리
- 컴포넌트 - 파운데이션을 조합한 구성요소
- 문서 - 파운데이션 및 컴포넌트에 대한 사용 가이드
피그마가 운영하는 DesignSystems 에서 피그마로 디자인 시스템을 작성 시 참고할 사항 및 수많은 기업의 디자인 시스템 사례를 확인할 수 있다.
장점
- 그냥 써라. (2022 기준)
단점
- 복잡한 그래픽 작업은 피그마와 어울리지 않는다.
- 복잡한 프로토타입 및 인터랙션에는 적합하지 않다.
스토리북(Storybook)
디자인 시스템의 컴포넌트 코드를 관리하기 위한 컴포넌트 라이브러리로 많이 사용한다.
피그마로 작성된 디자인시스템은 서비스(주로 웹앱의 페이지)의 디지안을 위해 사용된다. 이렇게 작성된 디자인 시스템을 그대로 개발환경에서 사용할 수 없다. 따라서 제품을 개발하는 개발자는 디자인 시스템에 맞춰 코드로 구성된 컴포넌트 라이브러리를 구성한다.
개발자들이 피그마를 참고하지만, 실질적으로는 코드를 더 많이 참고하기에, 스토리북은 디자이너를 위한 디자인 시스템 문서라기 보단 개발자를 위한 디자인 시스템 문서로 생각하면 좋다.
storybook-showcase 스토리북을 사용하는 기업들의 용례를 볼 수 있다.
장점
- 실제 제품에 사용될 컴포넌트 코드의 오류 및 테스트 용이
- 실제 제품에 사용될 컴포넌트 코드의 관리 및 문서화 용이
단점
- 러닝커브
- 관리 포인트 및 비용 증가
맺음말
2024년의 첨언
2024년 작성된 글에 개인적인 생각을 첨언해보고자 한다. (추가적인 자료 작성 및 정리는.. 지금은
불가능할듯하지만, 언젠가..) 2023년 피그마의 여러 업데이트는 디자인 시스템 관리적인 환경을 많이 바꿔놓을
거라고 생각한다. 그 중 주목할만한 점이 Variables 와 DevMode 다. 데브 모드 이후, 뭔 피그마 드리븐..같은
말장난 같은 말이 나오기도 하듯, 컴포넌트 디자인과 구현이 더 긴밀하게 연결되었다. 또한 스토리북과 같은 UI
테스트 중심의 테스트 가능한 라이브러리, 디자인 to 개발이 직접적으로 연결되는, 디자인 -> 실제 제품의 과정을
단순화 시키는 방향으로 진화해나가고 있는 것 같다.
솔직히 아직은 피그마로 생성하는 코드를 직접 쓴다는 것은 상상하긴 어렵다.. (개인적인 생각) 그렇지만 정적인 뷰 작성에 한해선 가능해질 수도 있지 않을까 생각해보긴 한다. 만약 그렇게 된다고 했을 때 피그마에 대한 이 의존성을 끊어낼 수 있을까?
참고