디자인시스템의 시작은 조직적인 공감대 형성부터.
이 글을 읽으시는 분들은 디자인시스템에 대해서 적어도 한 번쯤은 들어보셨을 겁니다. 디자인시스템의 개념과 왜 필요한지에 대해서는 많은 글을 통해 읽어보셨을 거예요. 오늘은 디자인시스템 관련하여 조금은 색다른 글을 적어보려 합니다. 디자인시스템 도입에 관한 이야기예요.
여러분들은 어떤 규모의 회사에 다니시나요? 스타트업? 에이전시? 대기업? 규모와 프로덕트의 성숙도에 따라 디자인시스템에 대한 중요도가 높이 평가되는 조직에 계실 수도, 또는 인지조차 되고 있지 않은 조직에 계실 수도 있겠죠?
어떤 규모의 회사든, 프로덕트의 성숙도가 어떻든 조직 안에서 디자인시스템에 대해 가장 강력한 옹호자가 되어 시작을 알리고, 널리 퍼뜨리는 사람은 반드시 필요합니다. 궁극적으로는 조직에 꼭 필요한 사람이거든요. 어쩌면 당신이 디자인시스템을 시작해야 한다고 주장하는 유일한 사람일 수도 있어요.
디자인시스템 도입이 갑자기 ‘뿅’하고 될까요? 그럴 리가요. 디자인시스템은 혼자 시작하자고 해서 되는 게 아닙니다. ‘조직적인 공감대’가 필수적으로 따라와요. 왜 그런지 스타트업 규모의 회사를 예시로 두고 설명드려볼게요.
비즈니스 우선순위
대부분의 스타트업은 PMF(Product Market Fit)를 찾기 위해 영혼의 힘을 쏟아냅니다. 비즈니스적 가치를 우선순위에 두고, 시장에 나와 수많은 가설과 검증을 통해 처맞으면서 배우고 성장해 나가죠. 기업은 일단 뭐가 되었든 돈을 벌어야 해요. 비즈니스 임팩트가 실행할 백로그를 결정하는 중요한 기준이 되어야 한다는 것이죠.
그렇다면 아무것도 갖추어지지 않고 제로부터 시작하는 팀의 입장에서 프로덕트를 만들어냄과 동시에 디자인시스템에도 투자할 리소스가 있는지에 대해서는 결국 개인의 역량(개인기) 레벨에 따라 결정되는 문제에 직면하게 됩니다. 역량이 높은 어벤저스로 구성되었다면, 디자인부채와 기술부채 그리고 앞으로의 생산성과 확장성까지 고려해 가며 안정성 있는 프로덕트를 초기부터 빌딩하게 될 것이고요. 그렇지 않은(대부분의) 경우라면, 프로덕트의 생산과 수정의 반복에 허덕이며 시스템은 그저 그림의 떡이 될 것입니다.
여러분들은 즉시 체감 할 수 있는 비즈니스 임팩트와 지금은 보이지는 않지만 장기적으로 느껴질 부채를 어떻게 비교 분석하며 도입을 주장할 수 있을까요? 이건 정말 어려운 일이라 생각합니다. 저희 CPO님의 말씀을 빌리자면 소위 ‘아트의 영역’이라고 말씀드리고 싶네요.
기술적인 공감대
디자인 시스템 도입을 위해서 넘어야 할 산이 한 단계 더 있습니다. 그건 바로 기술적인 얼라인이에요. 디자인시스템은 적어도 디자인팀과 프론트엔드 개발팀 중 한 팀이라도 아예 공감대가 없으면 구축하고 운영하기에 정말 큰 어려움이 있습니다. 융합형 인재(챔피언)가 각 팀에 한 명씩은 존재해야 함께 구축해 나갈 수 있어요.
예를 들어 개발팀만 디자인시스템에 대한 이해도가 높고, 디자인팀은 재사용에 대한 개념과 일관성의 중요성을 깨우치지 못하는 크리에이티브한 사람들로만 구성되었다면 프로덕트를 만들기보다 디자인시스템에 드는 온보딩과 작업 리소스가 훨씬 많이 들 것입니다. 오히려 같이 논의하지 않고 개발팀끼리만 따로 공유하는 디자인 컨벤션을 만드는 게 속이 편하다고 느낄 거예요.
반대의 경우도 한번 볼까요? (낮은 확률로) 디자인팀이 오히려 디자인시스템에 대한 이해도가 높고, 개발팀에서는 디자인토큰이 무엇인지, 컴포넌트는 어떤 방식으로 구조화하는지에 대한 개념이 낮다면, 아무리 피그마로 개발 뺨치는 구조로 라이브러리를 구성한들 프로덕션까지는 만들어지지 않는 종이 쪼가리가 되어버리는 셈이 되는 것이죠.
어렵다! 어려워!
맞아요. 디자인시스템은 도입부터 어려워요 ㅎㅎ..하지만 여러분들은 해낼 수 있을 거예요. 적어도 제가 이 글을 통해 말씀드리면서 필요한 것들을 챙겨드릴 수 있을 테니까요. 저도 디자인시스템 도입과 관련된 이야기에 관하여 처음 알게 된 건, 해외 글들이었어요. ‘How to get buy-in for design system’ 비스무리한 타이틀의 글들이 긴 시간에 걸쳐 꾸준히 올라오는 것을 보면서 ‘해외에서는 디자인시스템 도입과 관련된 이슈에 있어 많은 설득의 시간을 필요로 하고 노력하고 있구나’를 많이 느끼다가, 직접 스타트업에서 2년 동안의 시간을 몸 담아보니 왜 저런 글들이 쓰이게 되는지 좀 알겠더라고요.
디자인시스템은 구축을 위해 도입부터 큰 노력이 필요하다는 것을 말씀드리기만 하면 너무 아쉬우니까요, 설득을 위해서는 어떤 것들이 필요한지와 제가 생각하는 팀의 건강한 워크플로우는 어떤 것인지 적어보고 마무리짓겠습니다.
디자인시스템 도입을 위해 필요한 설득의 과정
아래 항목들은 아래 첨부된 링크를 토대로 만들었으니, 참고만 부탁드려요. 꼭 이렇게까지 하지 않아도 돼요.
다양한 영역에서 UI 요소의 불일치(또는 가능성) 확인
위(1번) 항목이 소프트웨어 개발에 부정적인 영향을 끼치는 부분 가시화
디자인시스템 구축 제시 (개념과 기대효과)
디자인시스템이 포함하는 요소
디자인시스템을 구축하는 데 있어 필요한 리소스
애자일 팀 워크플로우
제가 생각하는 프로덕트를 구성하는 건강한 조직은 두 가지로 분류할 수 있을 것 같아요. 디자인시스템만 전담으로 하는 팀이 있느냐, 프로덕트 팀 내에서 일부 인원끼리 길드를 이뤄 디자인시스템 구축에 Responsibility를 가져가느냐.
전자의 경우는 적어도 PM, PD, FE 최소 한 명씩은 구성된 별도의 팀이 구성되어 그들끼리 디자인시스템 로드맵을 짜고 스프린트를 진행하면 될 것 같고요. 다만, 중요한 건 디자인시스템 컨슈머(Product Team 1, 2, 3)와의 긴밀한 의사소통이 관건이 될 것 같습니다. 뭐 중/대규모 회사정도되어야 디자인시스템만 전담하는 팀이 있겠죠?
후자의 경우, 스프린트를 진행함에 있어 높은 공감대를 갖고 협의하에 일정 비율의 업무형태로 운영하는 것입니다. 다만 이 부분은 현실적으로 디자인시스템만 다루는 비율이라기보다는 기술부채를 덜어낼 티켓들로 프레이밍해나가면서 PM을 포함한 C레벨까지의 공감대를 형성해야합니다. 개인적으로는 디자인시스템이 아무리 날고 기어봤자 결국 고객을 위한 프로덕트가 우선이라고 생각하여 8:2, 9:1 정도로 점진적으로 시작하는 방법이 좋지 않을까라는 생각이 들고요.
또 다른 방법으로는 스프린트를 타입별로 나눠서 스프린트 1, 2, 3 동안에는 프로덕트에 집중을 하고 매 4번째 오는 스프린트에는 각종 기술부채와 다른 이슈 등을 해소하는 스프린트로 병행하는 방법으로 진행하게 된다면 나름 괜찮지 않을까라는 생각도 하게 됩니다.
오늘은 여기까지고요! 다음에도 디자인시스템, 프로덕트디자인 등 다양한 이야기를 가져올테니 기대해 주세요. 읽어주셔서 감사해요. 참고자료도 도움되는 자료가 많으니 한번쯤 읽어보세요ㅎㅎ. 그럼 안녕~!
참고자료
Creating a Design System: Organizational Buy In, UXPin
[https://www.uxpin.com/create-design-system-guide/get-organizational-buy-in-for-design-system]
Design Systems Buy-In Deck, Dan Mall
[https://danmallteaches.gumroad.com/l/design-systems-deck]
Design without the ‘system’: Why design system adoptions fail, Rangle
[https://rangle.io/blog/design-without-the-system-why-design-system-adoptions-fail]
5 Design System Fails - And Their Fixes, Rangle
[https://rangle.io/blog/5-design-system-fails-and-their-fixes]
The 2022 design systems survey, Sparkbox
