우리에게 Fit한 "디자인 라이브러리"를 만들면 되죠

"디자인 라이브러리(또는 시스템)는, 확장성, 변화의 여지가 고려되어야 한다고 생각해요."

Opening

Draw Hatha를 만들고 있는 그리디브 팀의 디자이너 이주연입니다! 오늘의 주제는 상당히 많은 고민을 하게 했던 Draw Hatha의 디자인 라이브러리 구축 과정입니다. 라이브러리를 구축하는 방식은 이미 너무 많은 아티클들이 존재하고 있기 때문에, 저희 만의 프로세스를 적어보았습니다.
이미 써 놓은지 오래된 메이커로그임에도, 업로드에 많은 고민을 했던 이유는-

1. 디자이너가 없는 팀의 입장에서, 컴포넌트를 일일이 개발하는 것보다 컴포넌트 라이브러리를 쓰는게 더 효율적일 수 있기 때문입니다.

2. 저희의 라이브러리는 개선의 여지가 남아있기도 하고, 지극히 저희 팀에게만 ‘Fit’ 할 수도 있는 과정이기 때문이에요. 즉, 저희에게 핏한 과정이 다른 분들에겐 아닐 수도 있거든요.

여기서 솔직한 고백을 하나 하자면, 제가 저희 드로우하타의 브랜딩을 ‘미니 브랜딩’이라고 했던 이유도 저희에게 핏한 요소들로 구성되어있기 때문에 BX 디자인의 전문성을 가지고 더 디테일하게 진행하시는 분들에게 ‘누’가 될까봐 걱정되었어요.
그럼에도 제가 용기낼 수 있었던건, 이 라이브러리 세팅이 당연하고 어쩌면 모두가 아는 것일지라도, 디자이너가 없거나 디자인에 대해 막막할 수 있는 메이커 분들도 있지 않을까하는 마음입니다.
그 분들에게 조금이라도 도움이 되고 싶었어요. 기존에 이용할 수 있는 소스가 많긴 하지만, 제품의 확장성을 고려했을 때 ‘제품다움’이 주는 디테일은 결국 좋은 사용자 경험으로 이어질 수 밖에 없다고 생각해요.
개인적으로는 이 방대한 라이브러리야말로 제품의 특성에 따라, 그리고 조직의 상황과 크기마다 달라질 수 있다고 생각합니다. 그래서 저희 만의 (완벽하지 않은) 라이브러리에 대해 이야기 함으로써, 제품의 방향과 확장성에 따라 개선해 나갈 것임을 염두하고 읽어주시면 감사할 것 같아요 :)
완벽한 단계들을 다 쓸 순 없었어요. 그저 가볍게 참고만 해주세요!
오프닝이 역대급 길었네요- 그럼 이제 한 번 보실래요?🥹

라이브러리 구축 먼저하나요? 아님 플로우 설계 먼저 하나요?

어쩌다보니, 저는 0-to-1의 경험을 회사에서도 했고, 드로우하타를 통해서도 하고 있더라고요.
그래서 0-to-1 경험을 반복해서(?) 한 디자이너로서 이 제목의 대답을 일단 말하자면,

“동시에 해야하며, 개발자와의 소통에 따라 우선 순위가 정해질 것입니다.”

라이브러리는 비즈니스 전략적으로도, 사용자를 고려하는 방향성에서도 굉장히 중요한 부분입니다. 그리고 변화에도 신속하게 대응할 수 있게 하죠.

그럼에도, 꼭 지켜야 할 것

1. 아토믹 디자인

아토믹 디자인이라고 아시나요? 화면에 들어가는 모든 요소들을 작은 단위부터 큰 단위로 구성하는 방식입니다. 아토믹 디자인에 관련한 아티클들도 굉장히 많기 때문에, 이 부분은 생략할게요!

2. 컴포넌트 네이밍 규칙 정의하기

정해진 정답은 없으나, 제품의 특성과 개발 상황에 맞게 정해주시면 될 것 같아요. 보통은 컴포넌트 네임부터 시작하고, 그림과 같이 Property를 나눕니다!

'미니 브랜딩'과 '와이어프레임' 덕에, 초반에 구축할 수 있었던건?

1. 미니 브랜딩 덕분에, Color 세팅을 먼저 할 수 있었어요.

와이어프레임(설계)이 완료되고, Key Feature의 Flow가 나오면 본격적인 제품 디자인 단계(?)로 넘어갑니다. 저희의 경우는 이전에 브랜드 디자인이 되어있었기 때문에, Primary Color나 앱 자체의 무드는 정해져있었어요.

• 그래서 가장 먼저, Primary / Accent / Greyscale과 같은 기본적으로 필요한 Color Palette는 구축할 수 있었습니다. 특히, Grey scale은, 시작점이 어느 컬러냐에 따라 미세하게 톤이 달라지기 때문에 이 부분도 나름대로 연구했어요.
  

• 그리고 하나의 스크린에 일관성있는 컬러들을 조합하기 위해서는, 단계적인 컬러들이 필요했습니다. 그래서 Primary Color를 통해, HSL 값을 피그마에서 일정한 단위로 조정하며 명도에 따른 단계를 나누었어요.

  

이렇게 컬러를 일관성있게 만들어두면, 다른 컬러를 막 믹스하지 않아도 경우의 수가 많아집니다.

2. 와이어프레임 덕분에, Typography / Grid / Primary, Secondary Button 세팅을 먼저 할 수 있었어요.

저희는 (high-fidelity에 가까운) 와이어프레임을 통해, 플로우와 인터랙션 방식을 초반에 디테일하게 세팅하며 시작했습니다. 물론 제품 디자인 단계에서 변경된 부분도 많아요. ㅎ.ㅎ
(와이어프레임 빌드업은 상황에 따라 달라질 수 있다고 생각합니다. 해도 된다, 안해도 된다는 말씀드리기 어려울 것 같아요.)

1. 와이어프레임에 들어간 Text들을 통해, Typography를 구성했어요. 처음에는 가짓수가 많지 않았는데 점점 많아졌어요. 또 여기서 하나의 포인트가 있는데, 처음엔 Heading / Subheading을 구분했었어요. 근데 개발자 입장에서 컴포넌트 이름이 길어져서 불편하다고 하시더라구요.
   그래서 Type1,2,3…이런식으로 표기했고, 그 안에서 굵기에 따라 T3-1,2,3…이렇게 구분했어요.
   저 스스로 Type 1~3까지는 Heading이고 Type 4~5까지는 Subheading이라는 룰을 지키려고 했습니다. 그러나 이 부분은 명확성이 떨어져서 변경할 여지가 큰 것 같네요 :)

1. Grid는 Strict하게 가져가고 싶진 않았어요. Column > Margin 16px을 기본으로 잡았고, Gutter > 8px로 한다는 룰을 정했습니다.

2. 온보딩 플로우부터 필요했던 프라이머리 버튼을 세팅했어요! 그리고 color의 Greyscale 기반으로 Secondary버튼도 동시에 세팅했습니다.

   

자, 이제부터는 동시 진행입니다!

동시 진행의 기준들을 간략하게 적어볼게요. 존재하는 제품의 라이브러리 재구축이 아닌, 제품 빌드업과 동시에 라이브러리를 구축하는 것임을 잊지말아주세요.ㅠ_ㅠ

1. Key Feature에 포함되며, 많이 반복되는 중요한 컴포넌트 우선입니다.

이걸 어떤 기준으로 잡아요? → 만들고 있는 제품 설계를 보시면 알거에요! 또는 개발적으로 먼저 디자인되어야 하는 화면이 될 수도 있을 것 같아요. 저희는 메인 피쳐인 '기록하기' 화면부터 시작했습니다. 그 중에서도 상태의 분류가 되어야 하는 'Chip'부터 시작했어요. 저희의 경우는, ‘가입 후 정보설정~기록하기’까지 사용자가 칩을 통해 기록을 해야 하거든요.

2. 특정 화면에 귀속되지 않는, 템플릿을 구축합니다.

Toast / Modal Dialogue/Tooltip과 같은, 특정화면에 귀속되지 않고 어디든 등장가능한(?) 템플릿들을 구축했어요.

3. 화면 전환 인터랙션 방식을 정의했습니다.

기본적으로, 뒤로가기와 닫기 버튼이 포함된 Top bar Container 영역을 정의했다고 보시면 됩니다. 이건 문서와 함께 라이브러리에 제공했어요.

그리고, 이제부터는 위에 설명했던 모든 항목에 더 많은 것들이 추가되고 변경되는 프로세스를 반복합니다. ^^

그럼 Draw Hatha는, 앞으로 뭘 개선할건가요?

앞으로 Draw Hatha의 디자인 라이브러리가 개선되어야 할 점들은,

• 현재 라이브러리에 없는 요소들도 있어서 추가해야 합니다 ^^;

• 컴포넌트 하나하나를 일일이 다 라이브러리에 넣어두기보다는, 한 종류의 컴포넌트가 확장성있게 사용되도록 할 수 있는 방향을 고려하고 수정해야 할 것들이 있습니다.

• 각각의 컴포넌트와 템플릿에 대한 가이드를 정확하고 디테일하게 제공해야 합니다.

• 문서(정책과 같은 것들..)와 함께 제공되는 컴포넌트들은 문서 링크도 함께 연결해서 모두가 보기 편리하게 합니다.

갈길이 머네요….. 개발자분들과도 상의가 필요할 것 같고요.

혹시 모르는 컴포넌트 이름이 있다면..?(참고 사이트 링크 첨부)

그리고 저는 프로덕트 디자이너로 일해오면서 많이 느꼈던 부분인데요, 서로가 컴포넌트에 대해 지칭하는게 다르더라구요. 그리고 각 클라이언트마다 비슷한데? 다른 가이드로 사용되는 것들도 많구요. 또 제가 모르는 것도 있거든요.

그래서 그럴 때 제가 자주 참고하는 사이트를 넣어둘게요! 이걸 보면 더더욱 아실거에요. 회사마다 다르게 구성된 시스템과 또 같은 컴포넌트도 어떻게 구성되었느냐에 따라 붙인 이름이 다르다는 것을요 ㅠㅠ

사이트 링크: Designsystem surf

Closing

클로징을 하면서도 이거 맞나 싶지만 ㅎㅎ 꼭 기억하세요! 디자인 라이브러리에 답은 없습니다.
저희는 모바일 앱 사용자를 위한 디자인이기 때문에 반응형을 고려하지 않았는데요, 반응형을 고려한다면 Strict하지 않은 선에서 확장성 있는 설계를 고려해야 했을거에요.
결국 우리에게 맞는 'Fit'의 기준을 세우는게 라이브러리라고 생각합니다!
저희의 예시와 기준이, 제품을 빌드하시며 디자인에 대해 고민이 되는 분들에게 도움이 되었길 바라요 :)