Airbnb의 디자인 시스템 만들기
원문: Building a Visual Language: Behind the scenes of our new design system.
이 글은 Airbnb가 앱을 만드는 방식 (번역본) 시리즈의 일부이다. 저자인 Karri는 최근 “무엇이든 물어보세요.” 디자이너 뉴스 인터뷰에서 이 주제와 관련한 질문들에 답했으며, 여기서 볼 수 있다.
소프트웨어 개발과 디자인을 할 때 우리에게 종종 요구되는 것은 일회성(one-off) 솔루션이다. 우리는 종종 시간 제약 하에 일하고 어떻게 나아갈지 합의되지 않은 상태로 일하기도 한다. 일회성 솔루션이 나쁜 것은 아니다. 그렇지만 그것이 튼튼한 기초 위에 세워지지 않는다면 우리는 결국 기술 및 디자인 부채를 지고 말 것이다. 시각적 언어는 다른 일반적인 언어와 다를게 없다. 언어가 잘 전달되지 않거나 제대로 이해되지 않는다면 오해가 생긴다. 제품이나 팀이 커지면서 이러한 현상은 더 심해진다.
디자인은 항상 시스템에 관한 것이었다. 어떻게 확장 가능하고 반복적으로 활용할 수 있는 시스템을 만드는가에 대한 고민이었다. 팬톤 색상부터 필립스 나사까지 이러한 시스템들은 복잡한 상황을 다루고 더 나은 제품을 만들 수 있게 해준다. 이런 시스템을 적용하기 가장 좋은 영역은 디지털 제품이라고 생각하지만, 많은 경우 우선순위에서 밀려난다.
통합된 디자인 시스템은 더 빠르고 좋은 제품을 만들기에 필수적이다. 공통의 언어로 작업하기 때문에 빠르고, 잘 짜여진 경험은 사용자가 제품을 사용하기 더 쉽게 만들기 때문에 좋다.
왜 디자인 시스템이 필요한가
Airbnb는 지난 수년간 매우 빨리 성장했다. 현재 우리 디자인 부서는 거의 12개의 기능 팀으로 구성되어 있다. 이 팀들의 노력과 작업을 관리할 수 있는 체계적인 방법이 필요하다는 사실은 너무도 뻔했다. 이 문제를 인식하면서 이것이 우리 회사 뿐만 아니라 업계 전반에 걸친 더 큰 문제라는 것을 알았다.
너무 적은 제한사항
소프트웨어 디자인은 다른 디자인 분야와 비교해서 훨씬 적은 물리적 한계를 가진다. 이것은 어떻게 보면 결과물의 자유도가 높다는 것이지만, 반대로 부자연스러운 사용자 경험을 야기하기도 한다. 우리는 디자이너로서, 그리고 제품의 주인으로서 우리만의 제한 사항을 만들고 준수해야 한다.
다양한 디자이너, 관련된 사람들 (stakeholders)
소프트웨어는 보통 팀에 의해 만들어진다. 매우 큰 규모의 팀일 경우도 있다. 사람이 많아질 수록 잘 짜여진 경험을 만들어내기는 훨씬 더 어려우진다. 그리고 팀의 크기와 상관 없이 시간이 지나면서 여러 사람들이 새로운 솔루션과 스타일을 제시하게 된다. 이 또한 사용자 경험이 수렴되지 않고 발산하게 되는 요인이다.
다양한 플랫폼
우리는 제품을 다양한 기기와 플랫폼을 통해 제공한다. 기능과 디자인을 싱크하기 위해서는 엄청난 노력이 수반된다. 종종 플랫폼마다 같은 작업을 반복해야 하는 경우도 있다.
연속성 (continuum)
소프트웨어의 고유한 특징 중에 하나는 전통적인 소비자 제품처럼 닳거나 교체되지 않는다는 것이다. 그러면서도 여전히 하나의 제품으로 여겨진다. 수년 전에 생성된 코드와 디자인은 아직도 많은 곳에 존재한다. 회사의 규모가 커지고 제품도 크게 변했는데도 말이다. 그렇기에 지속적인 관리와 업그레이드를 필요로 한다.
시작하기 (Getting to work)
이러한 과제들을 해결하고 문제 해결 과정을 빠르게 처리하기 위해서 우리는 소규모의 디자이너와 개발자로 이루어진 팀을 하나 만들었다. [1] 여기에 속한 사람들은 하던 일을 모두 멈추고 이 일에만 집중할 수 있도록 Airbnb 본사 근처의 스튜디오에서 작업했다. 그리고 모든 노력을 Design Language System (DLS) 을 만드는데 쏟았다.
DLS의 목표는 더 아름답고 접근성이 좋은 디자인 언어를 만드는 것이었다. 우리의 디자인은 잘 정의된 재사용 가능한 컴포넌트들을 통해 효율성을 제공하는 통합된 플랫폼이어야 한다고 생각했다. 이를 구체화하기 위하여 초기에는 네이티브 플랫폼(iOS & 안드로이드)에 집중하기로 했다.
우리는 여태까지 만들었던 디자인을 다 프린트했다. 보드에 사용 흐름대로 정렬하고 나서 어디에서 어떻게 사용자 경험이 깨지는지, 어디부터 변경이 필요한지 파악했다. 문제를 해결하기 위한 가장 좋은 방법은 정면으로 부딪히는 방법밖에 없었다. 우리 각자는 화면이나 제품 영역에 초점을 맞추어 다시 디자인을 했다. 그리고 우리의 디자인을 가이드해줄 몇 개의 원칙을 세웠다.
통일성 (Unified)
포괄성 (Universal)
독창성 (Iconic)
소통성 (Conversational)
기초 마련하기 (Laying the foundation)
디자인 스프린트를 하기에 앞서, 우리는 기본적인 스타일 가이드를 만들었다. 그리고 그것을 기초 가이드 (foundation) 라 불렀다. 우리는 거기에 타이포그라피, 색상, 아이콘, 간격, 정보구조(IA)를 간략히 정리했다. 그 기초 가이드 덕분에 우리는 같은 언어로 생각하며 일할 수 있었다. 매일 일과가 끝나기 전에 우리는 모두의 디자인을 리뷰했고, 점점 특정 패턴이 형성되는 것을 볼 수 있었다. 우리는 필요한 경우 방향을 수정했으며, 표준 컴포넌트를 정의하기 시작했다.
컴포넌트 만들기
전통적으로 많은 스타일 가이드는 컴포넌트를 아토믹 디자인 형식에 따라 만들었다. 원자 컴포넌트를 만들고 그것들이 모여 더 복잡한 분자가 되는 식으로 말이다. 이 방식은 이론적으로는 일관되면서 유연한 시스템을 만들기 적합하다. 그러나 현실적으로 재사용 가능한 원자 컴포넌트들이 다양한 방식으로 사용될 가능성이 높다. 결과적으로 많은 종류의 분자 컴포넌트를 만들어낸다. 따라서 이 방식은 부자연스러운 사용자 경험을 만들어낼 가능성이 높으며 시스템을 관리하기 어렵게 만든다.
원자 컴포넌트에 의존하는 대신, 우리는 컴포넌트를 살아있는 장기의 한 부분 (elements) 으로 생각했다. 그것들은 일련의 속성(properties)들에 의해 정의되는데, 각각 기능과 개성(personality)이 있으며 다른 컴포넌트들과 공존하지만 개별적으로 진화할 수 있다. 통합된 디자인 언어는 단지 정적인 규칙이나 개별 원자에만 의존하는 것이 아니라, 진화하는 생태계여야 한다.
통합된 디자인 언어는 단지 정적인 규칙이나 개별 원자에만 의존하는 것이 아니라, 진화하는 생태계여야 한다.
예를 들어서 사용자 아바타는 처음에 스타일 가이드에 의해 정의될 수 있다. 하지만 결국 플랫폼에서 사용되는 경우의 수는 다양할 수 있다. 이는 추후에 아바타를 성공적으로 업데이트하기 어렵게 만든다. “만약 이것들 중에 하나를 바꾸기 원한다면 다른 스크린에 영향을 미쳐서는 안 된다.”
각 컴포넌트는 필요한 요소들로 정의된다. 타이틀, 텍스트, 아이콘, 그림과 같은 것들 말이다. 그리고 추가적인 요소를 포함할 수도 있다. 이 요소들은 스케치 뿐만 아니라 코드로도 정의되어 있다. 구분자(divider)를 개별 컴포넌트로 보기 보다는 각 컴포넌트가 구분자를 포함하도록 했다. 그리고 나서 뷰 로직에 따라 숨기거나 보여주었다.
라이브러리 컴파일하기
이러한 컴포넌트들을 만들면서 우리는 그것들을 마스터 파일에 모아서 ‘라이브러리’라고 불렀다. 디자인 프로세스 내내 참고할 수 있었다. 한두 주 정도가 지나자 디자인 이터레이션을 할 때마다 라이브러리가 매우 큰 도움이 된다는 것을 알았다. 어느 날, 마지막 프로토타입을 정리하고 있을 동안, 우리는 라이브러리 덕분에 단지 몇 시간만에 거의 50개의 화면을 만들 수 있었다.
라이브러리가 계속 확장되는 동시에, 우리는 각 컴포넌트를 비슷한 오브젝트가 있는 아트보드에 옮기기 시작했다. 그리고 이 아트보드들은 네비게이션, 마퀴(Marquees), 컨텐츠, 이미지, 기타 케이스(Speciality)의 카테코리별로 구분했다.
먼저 모바일의 컴포넌트를 만들고 (iOS와 안드로이드), 그 후에 이를 활용하여 태블릿용 컴포넌트를 만들었다. 태블릿용 컴포넌트는 모바일과 유사했고, 하나의 코드로 두 가지 스타일을 관리할 수 있었다. 이 시스템에서 컴포넌트는 각기 다른 형태와 위치를 가지고 있었다. 반응형 웹과 마찬가지로 말이다. 그런 후에 디자이너들은 공통의 컴포넌트를 가지고 화면을 디자인했다. 이것은 iOS와 안드로이드를 포함하여 여러 다른 화면 크기에 쉽게 적용될 수 있었다.
우리는 몇 개의 태블릿용 레이아웃 컨셉을 만들었다. 예를 들어 아래의 Focus View같은 것인데, 페이지의 컨텐츠, 모달(modal), 그리고 2-column 그리드 레이아웃에 포커스를 맞추는 뷰이다.
모든 컴포넌트와 뷰는 스타일, 상태, 반응형(adaptivity)을 다루는 우리가 만든 코드기반 뷰 프레임워크에 의해 만들어졌다. [2]
배운 것 (Lessons Learned)
이 프로젝트는 꽤 도전적이었다. 우리는 앱의 대부분을 다시 디자인하고 다시 만들었다. 디자인 시스템을 적립하고 새로운 앱을 2016년 4월 17일에 출시할 수 있었다. 하지만 모든 프로젝트가 그렇듯 이 프로젝트에서도 몇 가지 아쉬운 부분들이 있었다.
컴포넌트의 불일치. 대부분의 앱은 컴포넌트들을 반복해서 사용한다. 우리의 경우 이러한 컴포넌트들이 열 (row) 혹은 테이블셀 (table-cell) 이었다. 조금 더 시간이 있었다면 열에 대해서 더 신중하게 생각하고 난 후 더 강한 패턴과 컴포넌트를 만들 수 있었을 것 같다. 결국 많은 종류의 불일치가 생기고 말았다.
스케치. 원래 컴포넌트를 스케치의 심벌로 만들었는데 결과적으로 더 복잡하게 되었다. 가끔 스케치 파일은 아직도 관리하기가 어렵다. 앞으로는 컴포넌트를 생성하고 관리하기 더 나은 방법을 찾기를 희망한다. [3]
문서화. 이 프로젝트는 짧은 시간 안에 수행되었다. 그래서 일부 문서화 작업을 미루게 되었다. 철저한 문서화가 되지 않았기 때문에 우리가 피하고 싶었던 혼란을 야기했다. 코딩과 마찬가지로 디자인 과정에서 문서화는 것은 매우 중요하다 디자인 작업을 하면서 문서화 하는 것은 의사 결정을 더 매끄럽게 하는데도 도움이 된다.
결론
이 프로젝트는 많은 제품 팀들의 노력이 들어간 기념비적인 일이지만, 디자인 시스템 (Design Language System) 을 만드는 것은 앞으로 크게 도약하기 위해 반드시 필요한 과정이었다.
이제 디자인 언어와 코드가 공유되기 때문에, 기능을 만들고 거의 동시에 모든 플랫폼에 릴리즈할 수 있게 되었다. 개발자는 뷰 코드를 작성하기보다 기능의 로직을 짜는데 더 시간을 보낼 수 있게 되었기 때문에 개발 프로세스도 더 빨라졌다. 그 뿐 아니라 이제 개발자와 디자이너는 한 언어로 소통할 수 있다.
개발자들 뿐만 아니라 디자이너들도 이 시스템에 많은 관심을 보였다. 제품을 리뷰하는데 있어 패딩, 색상, 폰트 선택 등에 시간을 보내기보다 실제 컨셉과 경험에 더 집중할 수 있게 되었기 때문이다. DLS는 시각 스타일에 대한 공감대를 형성하였으며, 모든 작업(contributions)을 하나의 시스템으로 모이도록 만들었다. 이 시스템은 또한 새로운 아이디어를 high fidelity로 빠르게 프로토타이핑하고 테스트할 수 있게 해주었다.
나는 우리가 이 시스템을 통해 실제 사용자 경험과 앞으로 만들고자 하는 컨셉에 더 집중할 수 있다고 믿는다.
Karri Saarinen은 Airbnb의 Principal Designer이며, 수제 커피, 사진 촬영, 그리고 요리하는 것을 좋아한다. 트위터 @karrisaarinen으로 연락할 수 있다.
주석
[1] 많은 성공적인 프로젝트는 팀으로부터 나오며 항상 감사할 사람들이 너무 많다. 여기서는 이 프로젝트가 잘 마무리될 수 있도록 공헌한 몇 명만 언급하고자 한다. Bek Stone, Adam Michela, Amber Cartwright, Alex Schleifer, Michael Bachand, Paul Kompfner, Sean Abraham, Salih Abdul-Karim, Michael Sui 그리고 많은 디자이너와 개발자들에게 감사한다. 또한 이 아티클의 초안을 검토해준 Josh Leong, Sola Biu, Catherine Waite에게 감사한다.
[2] DLS의 기술적인 부분은 개발자가 쓰도록 남겨두겠다.
[3] 우리는 심벌 크기를 변경할 수 있기 바랬다. (예를 들어 헤더에 더 많은 컨텐츠를 넣어야 한다든지..) 버전 3.5 이상의 스케치에서는 만약 심벌의 크기를 변경한다면 자동으로 그 심벌의 모든 인스턴스의 크기도 변경해버린다. 이것은 스케치 파일을 아주 엉만으로 만들어버릴 수 있다. (가끔은 undo도 되지 않는다.) 우리는 결국 컴포넌트를 Layer Group에 넣고 사람들이 복붙하게 만들었다.
우리는 또한 git을 사용하여 파일을 업데이트 했다. 우리는 일일이 새로운 컴포넌트를 만들고 마스터 라이브러리 스케치 파일에 추가했고, 변경 사항을 기록하여 pull request를 submit 했으며,* png 파일을 export했다. 그 후에 그 스케치 파일은 공유된 클라우드 폴더에 보관되고, 새로운 컴포넌트에 바로 접근할 수 있도록 스케치 템플릿에 연결되었다.
*역자주 - 일반적인 git 업데이트 프로세스
