David.Cheon
UIpac
David.Cheon
전체 방문자
오늘
어제
  • UIpac (648)
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (65)
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (34)
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352)
      • Weekly Curation (251)
      • Performing Arts (17)
      • Collection (6)
      • Books (0)
      • Life (78)

블로그 메뉴

  • 홈
  • 방명록

공지사항

인기 글

Tags

  • 가트너
  • 반응형웹
  • 기획
  • Curation
  • 2015
  • 유니티
  • 트랜드
  • Mreport
  • UX
  • UI
  • 사물인터넷
  • 다음카카오
  • 애플리케이션
  • 벤치마킹
  • 디자인
  • Gartner
  • trend
  • 분석
  • 2014
  • 웨어러블
  • 모바일
  • 인공지능
  • 세계 게임시장 규모
  • 동향
  • 디자인참고
  • daumkakao
  • 큐레이션
  • 트렌드
  • 기획참고
  • 사이트

최근 댓글

최근 글

방명록

Uipac
David.Cheon

UIpac

Planning · PM/UX · Product

디자인 시스템 도입기 - 왜 필요했나

2020. 10. 17. 16:03

 

작년 초, 저희 서비스의 버튼 색상이 몇 가지인지 세어본 적이 있습니다.
결과는 11가지였어요...
비슷한 파란색인데 헥스 코드가 조금씩 다른 버튼이 화면마다 흩어져 있었습니다.
디자이너가 3명, 프론트 개발자가 8명인 팀에서 벌어질 수 있는 아주 전형적인 일이었죠.

 

계기는 사소했습니다.
신규 입사한 디자이너가 "이 버튼이랑 저 버튼, 색이 다른데 의도된 건가요?"라고 물어봤어요.
저는 순간 대답을 못 했습니다.
의도된 게 아니라, 그냥 각자 다른 시점에 다른 사람이 만들었을 뿐이었거든요.
확인해보니 primary 버튼만 놓고도 코드값이 제각각이었고, 여백 값도 4px, 6px, 8px가 뒤섞여 있었습니다.

이 문제를 팀에 공유했을 때 반응이 재밌었어요.
디자이너들은 "그럴 줄 알았다"는 표정이었고, 개발자들은 "그게 왜 문제냐"는 표정이었습니다.
디자이너 입장에서는 일관성이 없는 UI가 브랜드 신뢰도를 깎는 문제였고, 개발자 입장에서는 "어차피 작동은 하는데"라는 생각이 있었던 거죠.
이 간극을 좁히는 데만 회의를 두 번 더 해야 했습니다.

 

진짜 심각성을 느낀 건 신규 기능 개발 중이었습니다.
새로 들어온 개발자가 모달창을 만들면서 "이거 우리 서비스에 있는 컴포넌트예요, 아니면 새로 만들어야 해요?"라고 물었는데, 아무도 바로 대답하지 못했어요.
결국 기존 화면 여기저기를 스크린샷 찍어서 비교해보고서야 "아, 있긴 한데 세 가지 버전이 있다"는 결론이 나왔습니다.
이게 반복되니까 매번 새 화면을 만들 때마다 기존 걸 찾는 시간이 오히려 새로 만드는 시간보다 길어지는 역설적인 상황이 됐어요.

이 시점부터 저는 디자인 시스템이라는 게 "예쁘게 만드는 도구"가 아니라 "같은 질문을 반복하지 않기 위한 장치"라는 걸 실감했습니다.
매번 "이 색이 맞나요", "이 컴포넌트 있나요"를 물어보는 데 쓰는 시간을 아끼는 게 진짜 목적이었던 거예요.

 

처음부터 완벽한 시스템을 만들 리소스는 없었습니다.
그래서 가장 자주 쓰이는 버튼, 인풋, 모달, 카드 네 가지부터 정리하기 시작했어요.
Figma에 컴포넌트를 만들고, 개발팀은 Storybook에 같은 이름으로 구현체를 올렸습니다.
이름을 맞추는 것부터가 첫 번째 작업이었어요.
디자이너는 "프라이머리 버튼"이라고 부르고 개발자는 "btn-main"이라고 부르던 걸 하나로 통일하는 것만으로도 커뮤니케이션이 확실히 줄었습니다.

색상 토큰도 이때 정리했습니다.
11가지였던 파란색을 primary, primary-hover, primary-disabled 세 가지로 줄였고, 나머지는 전부 폐기 대상으로 표시했어요.
기존 화면을 한꺼번에 다 바꿀 여력은 없어서, 새로 만드는 화면부터 새 토큰을 쓰기로 하고 기존 화면은 리팩터링 일정에 맞춰 천천히 교체하는 방식을 택했습니다.

 

솔직히 반발도 있었어요.
"디자인 시스템 만드는 동안 실제 기능 개발이 늦어지는 거 아니냐"는 질문을 경영진에게서 받았습니다.
저는 이걸 "지금 투자하지 않으면 매 스프린트마다 비슷한 시간을 계속 낭비하게 된다"는 식으로 설명했어요.
실제로 컴포넌트 라이브러리를 도입한 뒤 신규 화면 하나를 만드는 데 걸리는 시간이 평균 2.5일에서 1.5일로 줄었다는 걸 다음 분기에 데이터로 보여줄 수 있었고, 그제서야 반대 목소리가 줄었습니다.

디자이너들 사이에서도 처음엔 "내 스타일을 시스템에 맞춰야 하냐"는 불만이 있었어요.
이 부분은 시간이 좀 걸렸습니다.
개인의 취향보다 사용자가 느끼는 일관성이 우선이라는 걸 몇 번의 사용자 테스트 결과로 설득했던 것 같아요.
한 사용자가 "이 페이지 버튼이랑 저 페이지 버튼이 달라서 다른 서비스인 줄 알았다"고 말한 피드백이 결정적이었습니다.

디자인 시스템은 한 번 만들고 끝나는 프로젝트가 아니라 계속 관리해야 하는 자산이라는 걸 이 과정을 겪으며 깨달았어요.


지금도 매달 마지막 주 금요일에는 컴포넌트 리뷰 시간을 따로 잡아서, 새로 생긴 예외 케이스나 폐기해야 할 컴포넌트를 정리하고 있습니다.


완벽한 시스템을 만드는 게 목표가 아니라, 팀이 같은 언어로 이야기할 수 있게 만드는 게 진짜 목표라는 걸 이제는 확실히 알 것 같아요.

저작자표시 비영리 변경금지 (새창열림)

'Planning · PM > UX · Product' 카테고리의 다른 글

디자인 시스템과 기획 문서의 연결고리  (0) 2021.03.15
AI 스피커/보이스 UI 기획 시 고려사항  (0) 2020.11.10
비대면 시대 온보딩 UX 재설계  (0) 2020.08.16
이탈률을 낮추기 위한 점검 포인트  (0) 2020.08.12
웹사이트를 만들 때 사용자 관점에서 점검할 것들  (0) 2020.08.12

    티스토리툴바