첫 미팅시 공유했던 문제점들

2분기 system 요소들, mui 스타일을 커스텀하는 과정에서 유저에 대한 많은 고민이 필요하지는 않았던 것 같다.

눈앞에 보이는 처리해야할 많은 foundation, component를 보며 일을 쳐내고, 문서를 옮기는 것에 몰두했던지라, 디자인 시스템 킥오프 미팅에서 내가 공유했던 디자인 시스템의 문제점에 대해서 눈에 보이는 부분만 결론이 맺어지고, 근본적인 부분에 대한 논의가 이뤄지지 못했던 것 같다. 내가 공유했던 현 디자인 시스템의 문제점의 가장 큰 부분은 **‘합의된 공통의 원칙’**이 없다는 점이었다.

대략 내가 공유했던 내용은 다음과 같다.

• 모바일 팀 - 웹 팀 간 시스템 언어 사용이 다르기때문에(사용하는 기술, 패키지 기반) 언어사전이 필요하다.
  • 시스템에서 중요한 부분은 커뮤니케이션인데, 사용하는 용어가 다르면 서로 사투리를 쓰면서 의사소통하는 것과 같음.
• 유연성 ↔ 엄격함 사이 균형을 찾는 것이 중요하며, 우리는 이에 대한 합의점이 없다.
• 이전 디자인시스템의 문제에 대한 명확한 정의와, 같은 문제를 반복하지 않기위한 해결방식, 기준점 마련 필요
• 커뮤니케이션 휘발 : 논의되는 문제점이나 의사결정사항들이 잘 공유되지 못하고 휘발되고 있음

결론으로

• 모바일 디자인 시스템을 따로 만들거기 때문에 용어가 다른것은 어쩔 수 없는 것 같음.
• 유연성 ↔ 엄격함: full strict
  • MUI 컴포넌트에 대해서는 prop추가 일절하지 않고, 컴포넌트도 여기에서 사용가능한것을 최대한활용.
  • 추가적인 atom 지양
• 커뮤니케이션 문서화 틀 마련

이렇게 마무리되었으나 왠지모를 찝찝합이 남았다.

‘차근차근’보다는 ‘빨리빨리’

full strict 를 어떻게 풀어낼지에 대해서도 아리송했으나, 이미 정리된 foundation(typography, color, palette, …) 스펙을 전달받고, 이를 코드로 옮기는 작업으로 디자인 시스템 프로젝트를 시작하게 되면서 일에 치여 미처 중요한 부분에 대해서 생각하지 못하고 있었다. 이때에는 ‘만들어가는 단계에 있으니 더듬더듬 찾아가면 되겠지’라고 생각했던 것도 같다.

이렇게 우리는 우리는 어떤 가치를 기반으로 유저에게 어떠한 프로덕트를 어떤 방식으로 제공하고 싶은지에 대한 논의 없이 반 쪽 짜리 합의점(컴포넌트를 구현하는 방식에 대해서만)을 가지고 시스템을 만들고 있었다.

MUI 컴포넌트 스타일을 커스텀하고, 문서화를 하면서 같이 전달받았던 컴포넌트 가이드라인도 다른 디자인 시스템 문서들을 참고해서 작성된 내용이었지, 우리만의 기준을 바탕으로 만들어진 가이드라인이 아니었다.

‘차근차근’보다는 ‘빨리빨리’ 에 중점을 두었던 것이다.

디자인 시스템 문서화작업을 하면서, 많은 디자인 시스템 제작 과정에 대한 글을 참조하거나, 다른 디자인 시스템 문서들을 보게 되는데, 여기서 빠지지 않고 등장하는 것이 있다. 바로 **‘디자인 원칙 (Design Principle)’**이다.

그때부터 ‘왜 우리는 디자인 원칙이 없이 시스템을 만들고있나’라는 의문점이 들기 시작했다. 하지만 패턴을 정의하게 된 지금에서야 이에 대해서 문제를 제기하게 된 것은, 디자이너분께서도 매우 바삐 다른 프로젝트와 같이 일을 쳐내는 느낌으로 진행하고 있었기 때문에 당장 이에 대해 문제제기를 하고 ‘처음부터 다시 생각해야한다’는 류의 말을 하기 두려웠던 것 같다.

어디에서 사용될, 누구를 상대로한 무기인가

최근 패턴 정의를 하고, 그대로 개발했던 MR 상당수가 거의 물거품이 되고, 스펙을 재정의하게 되었다.덕분에 그 이후에 진행되어야했던 스케쥴도 같이 밀리고, 이번 분기 디자인 시스템의 계획에 차질이 생기게 되었다. 이렇게 된 경위에는 프로젝트 리뷰 프로세스가 명확하지 않고, 잘 진행되지 않았던 점이 컸다.

하지만 애초에 스펙이 잘 정의되었다면?

리뷰를 통해 순식간에 개선된 ui패턴이 훨씬 좋은 피드백을 받았고, 같은 기능을 하더라도 다양한 방식으로 풀어낼 수 있다는 점을 보면서 우리가 의사결정할 때 기준이 될 무언가가 필요하다는 생각이 번뜩 들었다.

계속해서 디자인 패턴을 어떻게 정의할지에 대한 고민에서 반복해서 맞닥뜨리는 질문은 ‘둘 다 괜찮은데, 어떤게 더 유저에게 좋은 UX일까’이다.

‘좋은 UX’가 무엇인지 알기위해서는 반드시 사용자가 누구인지를 알아야한다.

우리는 누구를 타깃으로 하는가. 결국 디자인팀의 근본적인(?) 무언가에 대해서 질문해야했다.

우리는 유저 페르소나 정의가 명확히 되어있지 않으며 , 디자인 시 무엇을 중요한 가치로 여길지에 대한 정의도 없다.

예시

예를 들어, 남녀노소 장애인, 비장애인 누구나 사용환경에 구애받지 않고 쉽게 사용할 수 있는 플랫폼을 지향한다!고한다면, ‘접근성, 정확성, 명료성’을 가장 중요한 가치로 둘 수 있을 것이다.

• 이에 따라 디자인 원칙을 세우고
• 각종 foundation, component 스펙을 정하고
• 컴포넌트, 디자인 가이드라인을 정할 수 잇게 된다.
  • 항상 text, bg color가 contrast AAA이상을 넘겨야한다 등..
• 어린아이나 노인들도 이해하기 쉬운 포괄적인 언어를 사용하며, tone & manner가 정리된 UX writing guideline도 정의될 수 있다.
• OOO컴포넌트를 사용할 땐 aria attribute를 꼭 사용하도록 개발 가이드라인도 작성할 수 있다.

나는 팀원들에게 디자인시스템 작업을 ‘무기를 만드는’ 중이라고 비유를 하곤했다.

foundation, atom 작업할 땐 무기 재료를 만드는 중이라며, 나중에 핵폭탄을 만들테니까 기대하라고.. (오펜하이머 생각이ㅋㅋㅋ)

비유를 더해보면, 이 무기가 상공에서 쓰일지, 육지에서 쓰일지, 적군 (유저)는 누구인지에 대해 알지 못한 상태에서 만들고 있던 것이다. 오펜하이머처럼 엄청나게 강력한 무기를 만들면 되는거 아닌가?라고 생각한다면 비유를 바꾸어보자.

시스템을 설계하는 것은 집을 설계하는 것이다.

디자인 시스템을 설계하는 것은 집을 짓기 위한 설계 도면, 재료, 규칙을 마련하는 것이고

어떤 재료로, 어떤 모양으로 집을 만들지보다, 집을 어디에 지을지(환경)와 누가 그 집에 살 것인지(유저)를 먼저 고려해야 한다.

마찬가지로 디자인 시스템도 사용자의 환경과 요구에 맞게 설계되어야 하며, 이를 고려하여 일관성 있는 디자인과 경험을 제공하기 위해 지침과 원칙이 필요하다.

가장 중요한 점, 디자인 시스템은 제품이나 서비스를 개발할 때 일관된 디자인과 사용자 경험을 제공하기 위한 일련의 지침과 원칙을 포함하는 체계라는 점이다. 단순히 디자인 요소와 패턴이 정의된다고 디자인 시스템이 아니다. 그건 패턴라이브러리에 불과하다.

결국, 디자인 시스템은 사용자의 경험과 기업의 가치를 함께 고려해야하고,

디자인의 기술 뿐만 아니라 유저에게 어떤 경험을 제공할 것이고, 제품을 어떻게 서비스하고싶은지에 대한 생각이 담겨있어야한다.

그래서 어떻게 되었나.

여기까지는 나의 생각이었고, ‘기초부터 차근차근’은 사실 받아들여지지 못했다.

당시 우리 팀과 서비스, 회사의 상황에서는 이 모든 것들을 새로 정의하고, 합의하기엔 리소스가 너무나도 부족한 상황이었던 것 같다. 한편으론, 당시 우리 팀에 필요한건 탄탄한 시스템보다는 일단 개발에서 빠르게 사용할 수 있는 컴포넌트였던 것 같다. 이를 통해 얼마만큼의 효율성을 가져왔는지에 대한 성과를 수치화하면 더 좋고.

어떤 일이든 원칙대로 차근차근하기 위해선 그만큼의 여유가 있어야 한다는 생각도 든다.

작은 규모의 스타트업에서 ‘디자인 시스템’을 제대로하기란 리소스가 많이 드는 작업이고, 최대한 효율적으로 진행해야한다는 점도 깨달은 것 같다.