AIQ 디자인 라이브러리 구축기
인공지능 서비스를 위한 디자인 라이브러리
스켈터랩스 디자인팀은 작년 하반기부터 인공지능 클라우드 서비스 AIQ(AIaaS; AI as a Service)의 디자인 커뮤니케이션 기준을 구축해왔습니다. 이번 글을 통해 디자인 라이브러리를 제작하게 된 배경과 프로세스를 공유드리고자 합니다.
효율성을 높이기 위한 방법 탐색
급변하는 현대 사회의 서비스 및 제품은 점차 복잡해지고 있습니다. 이러한 환경 속에서 디자인 라이브러리는 반복적인 개선과 고도화가 요구되는 제품 설계, 그리고 엔지니어와 디자이너의 보다 효율적인 커뮤니케이션이 필요해지면서 대두되었습니다.
제품 개선과 고도화를 위한 선순환 역할을 하는 디자인 라이브러리라이브러리에 대한 니즈가 발생하다.
스켈터랩스의 디자이너와 엔지니어는 특정 기간 동안 프로젝트에서 긴밀하게 협업 합니다. 우리는 제품을 최소 실행 가능한 형태(MVP;Minimum Viable Product)로 개발해 시장의 빠른 변화와 예상치 못한 요구를 점진적이고 애자일한 방식으로 대응합니다.
이처럼 다수의 제작자가 공동의 목표를 이루기 위하여, AIQ 브랜드의 일관성을 고려해 빠른 개발을 가능하도록 하는 ‘장치’가 필요했습니다. 즉 우리에게도 디자인 라이브러리에 대한 강한 니즈가 생긴 것입니다.
고유의 라이브러리 제작
우리에게 가장 적합한 ‘고유의 디자인 라이브러리’를 만들기 위해 아래와 같은 과정을 거쳤습니다.
고유의 디자인 라이브러리를 만들기 위한 과정1. 유용한 프레임 워크를 도입해보자
보다 효율적인 라이브러리 구축을 위해 우선적으로 고려한 것은 우리의 일하는 방식이었습니다. 무엇보다 실 제작자인 엔지니어와 디자이너가 제품을 설계하는 과정에서 소요되는 시간과 비용, 빠른 개선 등 종합적인 부분을 아우를 수 있는 프레임 워크를 도입하기로 했습니다.
프레임 워크 도입을 위해 두 가지 관점을 기준으로 두었습니다.
하나. 유연하고 확장성 있는 커스텀 설계가 가능한가?
둘. 종합적인 스타일이 적용된 다양한 테마를 제공할 수 있는가?
이에 따라 다양한 UI 컴포넌트 프레임 워크 중에서도 AIQ 커스텀 디자인 가능성과 기존 개발 환경인 리액트 사용을 고려해 Google Material Design을 도입하였습니다.
Google material design(좌)을 사용하는 React Component(우) 제공이를 통해 설계에 유연한 프레임 워크를 구축하게 되었습니다.
2. 제품 목적에 따른 라이브러리 테마(Theme)를 분리하자
AIQ의 정보 구조는 크게 정보성과 서비스성으로 구분되는 AIQ Portal과 AIQ Console로 나뉩니다. 전반적인 브랜드 톤 앤 매너는 일관성 있게 설계하지만 정보 전달이 주요 목적인 Portal과 서비스 구매와 실제 이용을 목적으로 하는 Console은 강조해야 하는 컴포넌트의 변주 정도나 폰트의 스케일과 같은 기반 스타일의 차이가 분명하게 나타납니다.
사용자의 최종 전환을 위해 CTA 역할이 강조되는 AIQ Portal(좌측)과 빠른 작업 수행을 돕고 보조 역할을 하는 버튼이 빈번하게 필요한 AIQ Console(우측)
우리는 한 가지 종류의 테마로 이 모든 것을 해결하기엔 제약이 많음을 인지하였습니다. 따라서 제품 설계 확장성을 위해 라이브러리를 AIQ Portal 과 AIQ Console 두 가지 테마로 구분하였습니다.
결론적으로 위와 같이 테마를 분명하게 나눔으로써 사용자가 마주하는 각 페이지 별 성격에 알맞은 라이브러리로 더욱 적합한 사용성 설계에 집중할 수 있게 되었습니다.
3. 명확한 소통의 기준을 마련하자
디자인 라이브러리의 근본적인 목적은 소통의 기준을 마련해 팀의 업무 생산성을 높이는 것입니다. 우리는 아래 세 과정을 통해 불필요한 소통 비용을 줄임으로써 라이브러리의 목적을 확고히 할 수 있었습니다.
하나. 아토믹 디자인(Atomic Design) 방법론 활용
먼저 팀의 동일한 언어와 이해도를 기반으로 컴포넌트의 기능적 재사용이 가능하도록 설계하기 위해 Brad Frost의 아토믹 디자인(Atomic Design) 개념을 도입하였습니다.
아토믹 디자인은 생물학적 개념으로 인터페이스 설계 시스템을 표현한 방법론입니다. 디자인 요소인 Atoms(원자들)들이 모여 Molecules(분자들)을 구성하며, 각 구성 요소로 조합된 것들이 Organism(유기체)을 생성하는 효과적인 시스템 설계 원칙으로 쉽게 말해 블록을 쌓는 방법론이라고 할 수 있습니다.
Brad Frost의 아토믹 디자인우리는 이러한 방법론을 활용해 모든 컴포넌트들의 기준을 명확히 하였습니다.
그렇게 탄생한 AIQ 아토믹 디자인을 구분하는 기준은 ‘컴포넌트’에서 출발해 그 컴포넌트가 어떠한 기능상의 역할을 한다면 ‘Organism’, 컴포넌트 안에 또 다른 컴포넌트가 포함되어 있는 지를 기준으로 ‘Molecule’과 ‘Atom’으로 구분하고 있습니다. 이러한 기준에 따라 AIQ의 모든 컴포넌트를 분류하였습니다.
Atomic Design을 기준으로 분류한 AIQ Design Library둘. 단위의 분절
다음으로 라이브러리 전체 구조의 기반이 되는 파운데이션(Foundations)과 이를 조합한 컴포넌트(Components)로 단위를 나누어 보다 명확한 두 가지의 계층으로 구조화하였습니다.
셋. 디자인 툴(Figma)과 엔지니어 툴(Storybook)의 싱크 맞추기
제품 제작 과정에서 디자이너와 엔지니어는 세세한 컴포넌트부터 전체 페이지 구조까지 짧은 시간 내 다양한 피드백을 주고받습니다. 이때 같은 컴포넌트를 두고 서로 다른 이야기를 할 수 있는 명명 의존성이 발생하게 됩니다. 때문에 더욱 매끄러운 소통을 가능하게 하는 우리만의 이름이 필요함을 확인하였습니다.
AIQ는 Figma로 디자인하며 엔지니어의 Storybook을 통해 구현됩니다. 이를 위해 두 직군이 수 차례의 회의를 거쳐 접점을 찾고자 하였고 Atom의 버튼에서부터 Molecule, Organism, 나아가 전체 페이지의 구조와 섹션 별 명명 규칙을 세웠습니다.
페이지 구조화를 위한 디자이너와 엔지니어의 소통 방법결론적으로 간결하고 명확한 명명 규칙은 매끄러운 소통을 가능하게 해주고 직관적이고 깔끔한 코드와 손쉬운 디자인 설계로 원활한 협업을 촉진하였습니다.
4. 디자인 라이브러리 제작 결과를 공유하자
우리는 장기적인 관점에서 디자인 라이브러리의 유용함을 알리고 그 영향력을 키우기 위해 AIQ 디자인 라이브러리를 내부에 공유하였습니다.
핫한 반응이었던 디자인 라이브러리 내부 공유 세션AIQ 디자인 라이브러리 구축 후 다양한 프로젝트를 진행하며 우리가 몸소 느낄 수 있었던 결과를 정리하면 아래와 같습니다.
Fast: 재사용 가능한 컴포넌트를 통해 업무 생산성을 높여 소통 비용을 줄일 수 있었다.
Consistency: 일관된 디자인 언어를 제공해 더 나은 사용자 경험을 설계할 수 있게 되었다.
Scalable: 공통 언어로 개발 시간이 줄어 원활한 협업이 가능해지고 보다 본질적인 문제를 해결하는 데에 집중할 수 있게 되었다.
무엇보다 제품 설계 과정에서 크고 작은 의사결정을 쉽고 빠르게 할 수 있음을 확인한 우리는 지속적인 유지 관리를 위해 컴포넌트 업데이트 주기와 업로드 기준을 정하기도 하였습니다. 또한 선순환이 가능한 라이브러리가 될 수 있도록 다양한 요구사항에 맞춰 진화해 나가고자 합니다.
마치며
라이브러리가 있으면 기존에 만들어진 컴포넌트가 있기에 반복 작업이 줄고, 보다 본질적인 문제를 해결하는데에 시간을 할애할 수 있습니다. 나아가 애자일 프로세스가 결합된다면 더욱 빠른 설계와 협업이 가능해집니다.
많은 장점이 있지만, 이미 만들어진 디자인이기 때문에 창의성과 유연성이 떨어진다는 오해의 소지를 주기도 합니다. 또한 한번 구축해서 끝나는 것이 아닌, 시간을 투자해 끊임없이 수정하고 개선하는 작업이 필요합니다.
그럼에도 불구하고 디자인 라이브러리는 구성원 모두가 공유하는 공통 언어로 원활한 소통을 가능하게 하는 유기적인 체계를 제공해 줍니다. 따라서 이는 장기적으로 보았을 때 업무 프로세스를 개선할 수 있는 역할을 하게 될 것입니다.
