디자인시스템을 만드는 과정 - (1) 기획
안녕하세요!
오늘은 1년 간 진행했던 오일나우 모바일 디자인시스템 v.2 구축기를 들려드리려고 합니다.
오일나우는 2018년부터 운영해 온 서비스로 이미 웹/앱 디자인시스템이 존재했는데요.
지난 7년간 서비스가 커져가면서 새로운 화면이 늘어났고, 기존 디자인 시스템으로는 감당하기 어려운 다양한 UI가 등장했습니다. 또한, 아이콘 에셋, 컴포넌트 등을 개발자와 디자이너가 서로 다른 이름으로 부르고 있어 통합성이 크게 저하되는 문제가 있었습니다.
그래서 오일나우 제품팀에 속한 PM, iOS, 안드로이드 개발자, 디자이너가 모인 디자인시스템 TF를 결성하여 디자인 시스템을 개선하기로 했습니다.
기존 디자인시스템 현황 파악하기
기존 시스템은 어떻게 사용되어 왔고 어떤 문제가 있는지 파악하고자
개발자분들과 디자인 시스템 피드백 시간을 가졌습니다.
문제 1. 디자인 시스템 비동기화로 인한 유사 디자인의 반복적인 생성
첫 번째로 재사용할 수 없는 디자인이 반복적으로 생산되는 문제였습니다.
캡션 스타일이 모두 다른 bottomCTA사실 디자이너(Figma)의 입장에서는 대체 무슨 차이지?라는 생각이 들지만, 개발에서는 각자 다른 코드로 구현해야 하는 컴포넌트인데요.
Figma에서는 2-3번 정도 클릭하면 계속 재사용할 수 있는 UI였기 때문에 개발도 디자인과 마찬가지로 코드 재사용이 가능하다고 생각했죠. 결국 디자인과 개발 간 디자인시스템 커뮤니케이션의 부재로, 유사한 디자인을 반복적으로 커스텀해서 개발해 효율이 떨어지고 유지보수 리소스가 증가하는 문제가 생겨났어요.
문제 2. 디자인 정책 부재로 인한 OS 간 구현 불일치
두 번째로는 같은 화면에서 OS별로 구현 디테일이 다르다는 문제였습니다.
예를 들어 사용자가 '완료'버튼을 눌러 서버로 입력 정보를 보낼 때 안드로이드는 전송 로딩을 풀페이지로 표현하고, iOS는 버튼에 로딩을 띄워서 표시하고 있었어요. 디자이너가 화면설계서를 전달할 때 로딩 규칙을 정해야 하지만 빠르게 하나의 기능을 출시하는 스프린트 문화 특성상 모든 디테일을 챙기기가 어려웠어요.
문제 3. 제품 전반에 대한 디자인 가이드 부족
그리고 제가 입사한 이후로 계속해서 발생하던 문제가 있었어요. 바로 명확한 디자인 가이드라인이 없어서 디자이너마다 가이드라인을 서로 다르게 해석하고 있는 점이었어요.
예를 들면 에러케이스나 경고를 표시할 때 사용하는 색상이 red로만 정해져 있어서, 디자이너마다 사용하는 색상이 달랐어요. 이러한 문제 때문에 저는 화면을 디자인할 때마다 1-2년 전 디자인 파일에 접속해 '여기서 divider의 색은 gray300인데, 왜 다른 파일에서는 gray400을 사용했지?' 같은 고민에 빠지다가, 가장 최근 디자인을 참고해서 색상을 사용해야 했어요.
문제 4. 기존 디자인 시스템을 개선해도 개발에서 동기화하기 어려움
오일나우는 2023년 대규모 메인화면 개편을 거치면서 UI 스타일에 큰 변화가 생겼는데요.
사용되는 아이콘, 버튼 등의 스타일에 모두 변화가 있었지만 개발에서 당장 적용하기 어려웠습니다. 기존 디자인 시스템이 존재하는데도 바로 값을 바꿀 수 없었어요. 디자인 시스템 없이 커스텀으로 만들어진 레거시 화면이 많고, OS마다 구현된 디자인 시스템 범위가 달라서 수정사항의 적용 범위를 예상하는데도 문제가 발생하기 때문이었어요.
문제 정리
1. 디자인 시스템 비동기화로 인한 유사 디자인의 반복적인 생성
2. 디자인 정책 부재로 인한 OS 간 구현 불일치
3. 제품 전반에 대한 디자인 가이드 부족
4. 기존 디자인 시스템을 개선해도 개발에서 동기화하기 어려움
목표 설정 : 디자인 시스템 v.2를 만들자
4가지 문제를 살펴보니 가장 크고 포괄적인 문제를 정의할 수 있었습니다!
메이커(디자이너-디자이너), (디자이너-개발자)가 서로 다르게 생각하기 때문에
매번 비효율적으로 일해야 하고, 다른 화면을 만들어 나간다.
이 문제를 해결할 수 있는 가장 쉬운 방법은 메이커들의 생각을 지속적으로 동기화해 줄 '공통 언어'를 새롭게 개발하는 거였어요. 기존에도 디자인시스템은 있었지만, 가이드가 자세하지 않아서 일관된 디자인을 하기 어려웠고 Figma-개발에 간극이 있어서 디자이너와 개발자가 소통하기 쉽지 않았어요. 따라서 디자인시스템을 개편하는 핵심목표를 2가지로 설정했어요.
1. 모두 일관된 디자인을 할 수 있도록 디자인 가이드 보완하기
- 정책, 원칙, 디자인을 최신화하고 제품 개발을 효율적으로 수행할 수 있도록 돕기
2. 토큰 시스템과 협의를 통한 Figma 컴포넌트 <->개발 컴포넌트 동기화하기
- 디자인 가이드를 개발과 연동하여 실제 사용자 측 컴포넌트까지 정말 동기화하기
- 디자인 업데이트 시, 실제 제품 코드까지 한 번에 적용되는 시스템을 구축하기
이 두 가지 목표를 도출하기 위해 문제정의-문제원인-목표(솔루션)설정의 과정을 거쳤는데요.
디자인시스템은 답이 정해져 있지 않기 때문에 우리 팀의 방향성을 결정하는 문제정의 단계가 정말 중요하다는 걸 깨달았습니다.
문제정의를 하지 않고 무작정 다른 시스템을 레퍼런스 했다면 '우리 팀은 디자인시스템이 가이드로만 존재하니까, 개발자들과 공통으로 사용할 수 있는 디자인시스템을 만들자'라는 생각에 매몰되어 디자인시스템 v.2를 만들지 않고 기존의 것을 개선하는 걸 목표로 정했을 거예요.
하지만 개발자분들과의 피드백을 통해 서비스 내에 여러 디자인시스템과 커스텀화면이 얽혀있고 이 때문에 개선만으로는 해결할 수 없다는 걸 발견할 수 있었어요. 따라서 저희는 새로운 디자인시스템(v.2)을 만들기로 합의했죠.
우리 팀에는 어떤 형태의 디자인시스템이 적절한지 고민해 보는 시간이 필요한 것 같습니다!
저희는 두 가지 목표를 달성하기 위해 어떤 일을 진행했을까요?
다음 편에서 Design Token을 통해 디자인 가이드를 보완하고, Figma 디자인-개발코드를 동기화한 경험을 들려드리겠습니다.
읽어주셔서 감사합니다!