AI Service, Progress Indicator
인공지능 의료 서비스 프로덕트 디자이너의 디자인 시스템 개선기
프로덕트 디자이너의 주요 업무 중 하나는 디자인 시스템의 유지 보수입니다. 사내 디자인 시스템을 탄생시킨 이후 3년 동안 함께하며 큰 변화는 없었지만, 저와 함께 꾸준히 성장해왔습니다. 규모가 크지 않은 스타트업에서는 이렇게 끌고 가는 것에 어려움이 많습니다. 회사에서 디자인 산출물에 대한 이해가 부족하거나, 우리의 정체성을 갖추기보다는 기존의 디자인 라이브러리를 활용해 제품을 빠르게 만들기를 원하기 때문입니다. 항상 우선순위에서 밀리기 마련이지요. 디자인 시스템을 구축하기 위해서는 제품 정의부터 브랜드 가이드까지 많은 고민이 필요한데, 생존이 우선인 스타트업에서는 이러한 프로젝트에 시간을 투자하기 어려운 것이 현실입니다.
그럼에도 불구하고 디자인 시스템을 시작해야 할 시점이 있습니다. 서비스하는 제품의 Component가 타사에서 사용하는 범용적인 것들로만 채워져 있을 때, 마치 G**, A**, T**와 같은 회사에서 만든 것 같은 착각을 느끼게 되면 디자이너로서 큰 고통을 겪게 됩니다. 그래서 저는 디자인 시스템을 만들기 시작했습니다. 다른 회사의 디자인으로 도배된 화면에서 벗어나 우리만의 정체성을 가지기 위해 시작했습니다.
지금까지 여러 Component를 만들고, UI에 Atomic 구조를 적용시켰고, 디자인 시스템을 적용한 여러 제품을 만들어내었습니다. 완벽하지는 않지만, 그래도 작동가능한 구조를 갖추었습니다. 만든 사람이 제일 잘 알듯 제 눈에 보이는 약점들이 너무 많지만, 그래도 이번에 릴리즈 하는 제품의 UI를 검토하며 Figma에서 ‘Go to main component’를 클릭할 때 디자인 시스템 페이지로 이동되는 것을 보며 뿌듯함을 느낍니다.
최근 진행 상태를 표시해주는 Progress Component를 개선하였습니다. 이전에 Slider Component를 개선하며 Track과 Progress Indicator 구조를 가진 형태를 제작하였고, 이를 재활용하여 Progress의 기본 구조를 만들었습니다. Slider에 대한 이야기는 다음에 기회가 되면 다시 작성해보는 것으로 하고 오늘은 Progress에 대해서 이야기 해보겠습니다.
개선을 위한 7단계 Step
1. 현재 우리 제품에서 사용하고 있는 Progress의 문제 정의
2. Progress에 대해 정의한 내용들 학습하기
3. 타사 디자인 시스템 중 Progress에 대한 Component 제작 사례 학습하기
4. 학습한 내용을 기반으로 개선 계획 세우기
5. Component 제작
6. 인터렉션 가이드 제작
7. 핸드오프
1. 현재 우리 제품에서 사용하고 있는 Progress의 문제 정의
인공지능 서비스 제공이 된다는 인식 부족
지금까지 우리 제품은 MUI에서 제공하고 있는 Progress Component를 사용하여 진행상태를 표시하고 있었습니다. 막대와 원형으로 표현하고 있고, 사용자가 진행상태를 직관적으로 파악하는데에는 큰 문제가 없었습니다. 그러나 제품 내 인공지능 서비스 확장 및 File Upload 과정의 UX 개선등을 진행하면서 Brand Color를 조금씩 제품 내에 섞기 시작했고, 특히 인공지능 서비스 진행 상태와 일반 진행 상태를 분리하여 표현해야 했습니다. 인공지능 서비스는 비용이 부과될 수 있으며, 우리의 핵심 서비스라는 인식을 주어야 했기 때문입니다.
핸드오프 내용과 다르게 표현되고 있음
과거에 인공지능 서비스 제공을 위한 제품 개선에 맞추어 약식으로 새로 정의해 둔 Progress Indicator가 있었습니다. 동작에 대한 가이드가 없었고, 정적인 형태로 만들어 두었습니다. 이 기획이 1차로 완료되고 핸드오프가 되었던 시점에 개발자들이 엄청 바빠서 자세한 가이드 지침을 줄 수 가 없어 일단 개발이 편한쪽으로 임시로 만들어 두었었습니다. 그래서 Figma에 남아있는 형태와 결과물이 다르게 표현되고 있었습니다.
2. Progress에 대해 정의한 내용들 학습하기
위 2가지 문제를 기억하며 Progress에 대해 찾아보기 시작했습니다. 다양한 글을 참고 했고, Taras Bakusevych의 Loading & progress indicators — UI Components series 글이 가장 많은 도움이 되었습니다.
Progress indicator는 Indeterminate(불확정지표)와 Determinate(확정지표)로 나뉩니다.
Indeterminate(불확정지표) : 기다리는 시간이 얼마나 걸릴 지 알 수 없는 경우에 사용됩니다. 반복적으로 움직이는 애니메이션을 통해 진행 상태를 표현합니다.
Determinate(확정지표) : 기다리는 시간이 예상 되고 진행율 값이 존재할 때 사용됩니다. 진행률 퍼센테이지를 시각적으로 표현합니다.
https://uxdesign.cc/loading-progress-indicators-ui-components-series-f4b1fc35339a그리고 8개의 대표적인 로딩 Pattern이 있습니다. 8개 모두 Indeterminate와 Determinate로 표현할 수 있으나 일부는 어색하게 보이는 것이 존재합니다. 예를들어 Skeleton의 경우 Indeterminate로 표현하기 적합하나 Skeleton 회색 박스를 일부 채우면서 진행상태를 보여주는 것은 어색해 보이게 됩니다. 진행 상태 표시가 화면의 너무 많은 곳에서 이루어지는 것처럼 보이게 되기 때문입니다.
https://uxdesign.cc/loading-progress-indicators-ui-components-series-f4b1fc35339aNielson norman group의 Progress Indicators Make a Slow System Less Insufferable 연구 사례를 근거로 이 아티클에서 Indeterminate와 Determinate를 어떤 상황에 사용해야 하는지에 대한 가이드를 간단한 그림으로 표현하고 있습니다. 1초 미만의 진행 상태를 표현하는 시각 표현물은 오히려 사용성에 방해가 되기도 합니다.
https://uxdesign.cc/loading-progress-indicators-ui-components-series-f4b1fc35339a카카오페이 기술블로그의 ‘무조건 스켈레톤 화면을 보여주는게 사용자 경험에 도움이 될까요?’는 위 연구를 기반으로 문제 해결을 시도한 사례입니다. 1초 미만으로 소요되는 작업에 대해 애니메이션을 사용하면 사용자가 불편함을 느끼기 때문에, 카카오페이에서 사용중인 UI에 표현되고 있는 Skeleton 에니메이션에 대해 개선이 필요하다는 내용을 담고 있습니다. (프론트엔드 측면에서 작성된 글이라 디자이너가 이해하기는 약간 어려울 수 가 있어요.) 간단히 이런 것도 있구나 하고 읽어보면 좋겠습니다.
마지막으로 ‘진행상태를 표시해주는 것은 실제로 사용성에 도움이 되는가?’ 에 대한 자료도 첨부되어 있습니다. 연구 결과에 따르면, 사용자는 피드백이 있는 경우, 없는 경우보다 더 오랜 시간을 기다린다고 합니다. 아래 연구 결과를 보면 Progress bar를 본 참가자 그룹의 대기 시간 중앙값은 22.6초였고, 진행률을 볼 수 없는 참가자 그룹의 대기 시간 중앙값은 9초였습니다. 적절한 시각적 표현을 제공하면 예상되는 로딩 시간 내에 사용자가 불만족을 느끼고 이탈하게 되는 것을 방지할 수 있고, 만족도가 상승되게 됩니다.
3. 타사 디자인 시스템 중 Progress에 대한 Component 제작 사례 학습하기
Progress Indicator의 정의와 구성 요소 이론과 관련된 자료를 찾아봤으니, 이번에는 실제 적용 사례를 탐구해 볼 시간입니다.
제품을 디자인하면서 가장 많이 참고하고 있는 IBM의 Carbon Design System부터 살펴보았습니다. IBM의 디자인 자산은 주로 IBM Design Language(타이포그래피, 색상 등과 같은 Atom 요소)와 Carbon Design System(버튼, 슬라이더 등의 Molecule 단위 Component)으로 나뉩니다.
이 중 Carbon Design System에서 Progress와 관련된 Component를 Inline loading, Progress bar, Progress indicator, Loading 그리고 Skeleton 으로 나누어 표현하고 있습니다. IBM 특유의 파란색으로 진행 상태를 명확히 보여주며, 각 상태에 어떤 요소와 조합하여 사용할 수 있는지, 다국어 지원, 인터렉션 가이드까지 잘 설명되어 있습니다.
또한, AI 서비스에 대한 가이드도 제공되고 있습니다. 서비스 내부에 AI 버튼이 탑재되고 사용자가 기능을 수행시켰을 때 나오는 피드백을 다른 Component와 다른 색상으로 배치하여 약간의 차별성을 부여하고 있습니다.
IBM의 디자인 자산을 가장 많이 참고하는 이유는 제가 만들고 있는 제품의 비즈니스 타겟이 의사이기 때문입니다. 아주 전문적이고 보수적인 사용자군으로, 이 사용자를 만족시키기 위해 “Safety first”, “Like a coworker”, “Be consistent and standard” 3가지를 디자인 원칙으로 삼고 있습니다. IBM의 디자인 시스템은 저희가 추구하는 방향에 적합한 디자인 요소들을 갖추고 있습니다. 명료하고 전문적인 인상을 주는 형태를 가지고 있으며, 다양한 디자인 Component와 인터랙션 가이드를 포함하고 있기 때문에 저희의 원칙과 유사한 관점을 가지고 있습니다.
https://carbondesignsystem.com/components/progress-bar/usage/
https://carbondesignsystem.com/components/inline-loading/usage/이 외에도 Material 3 Design kit, Blank v.2.5, Ant Design, Line design system, MUI 등 다양한 사례의 표현 방식에 대하여 검토 하였습니다. 일관성 기준 아래 여러 디자인 시스템들은 독특한 형태를 제공하지 않고 누구나 쉽게 알아볼 수 있는 보편적인 형태에 조금의 특별함을 넣어 표현하고 있었습니다. 이는 자사 서비스 만의 특징과 학습 용이성, 기억 가능성 측면의 사용성 확보 두가지를 모두 충족하기 위한 시도라 생각되고, 어느정도 고도화 되어가는 서비스들이 결국에 지향할 수 밖에 없는 선택지라 느껴졌습니다.
4. 학습한 내용을 기반으로 개선 계획 세우기
다양한 사례들을 통해 이론적인 부분부터 사례까지 쭉 탐구하였습니다. 처음 문제정의에서 ‘인공지능 서비스 제공이 된다는 인식 부족’과 ‘핸드오프 내용과 다름’ 이라는 두 가지 문제만을 발견하였었습니다. 그러나 데스크 리서치를 통해 Progress 표현 방식의 다양성 부족, 적절한 로딩 시간에 맞는 Progress indicator 제공 가이드 부족 등 잘 만들어진 디자인 시스템 구성에 비해 부족한 면들을 좀 더 찾을 수 있었습니다.
이를 기반으로 개선 계획을 세우기 시작했습니다.
인공지능 서비스의 진행 상태를 직관적으로 알 수 있게 하기
핸드오프 자료에 최대한 상세한 가이드 제시하기
다양한 케이스를 고려한 Progress Variant 제작하기
5. Component 제작
디자인 시스템으로 정의되어 있지 않았던 Progress Component들을 모으고 그 디자인을 베이스로 Variant를 제작하였습니다. 8개의 대표 Pattern 사례 중에서도 특히나 대표적인 원형과 선형 Indicator만을 우선하여 지원하는 것으로 하고 대분류의 기준으로 삼았습니다. 그 아래 크기와 인공지능 서비스 여부에 따라 분류하였고, 마지막으로 Indeterminate, Determinate 그리고 Error, Disabled 상태로 세부 구분을 하였습니다. 이렇게 분류하면 앞서 Progress Indicators Make a Slow System Less Insufferable에서 정의한 1s, 1-3s, 3-10s, 10s 상황을 대부분 대응할 수 있게됩니다. 10s 이상의 상황에서는 다른 Component를 합쳐 사용해야 하지만, 이 경우까지 디자인 시스템에 미리 정의해놓는 것은 불필요하다고 판단하였습니다.
또한, 인공지능 서비스 여부를 표현하기 위해 DeepAi-Gradation 색상만을 적용하여 Progress Indicator에 차별을 두었습니다. 확장가능성을 염두에 두어야 겠지만 현재 제공하고 있는 인공지능 서비스는 대부분 특별한 페이지를 필요로 하지 않고 아주 보조적인 성격을 띄고 있기 때문에 다른 Progress 표현 방식과 비슷하게 가는 것이 혼란을 줄이는 방식이였습니다. 조금 더 다이나믹한 인공지능 서비스가 지원된다면 Progress가 추가 될 수 있겠죠. 이런 고민들을 담아 Progress Indicator Component 구조를 설계하고 Variant에 맞는 Component들을 추가하였습니다.
Linear Progress Indicator 예시6. 인터렉션 가이드 제작
Figma에 Component를 모두 만들고 나니 다음 고민이 생겨났습니다. 머리속에 생각나는 이상적인 Component의 움직임이 있는데, 이를 표현하기에 Figma의 인터렉션은 너무 제한적이었습니다. 정확한 인터렉션 가이드를 제시하여 눈대중으로 만드는 것을 방지하고 싶었던 저는 Chat GPT의 도움을 받아 디자인 해둔 Component를 움직이는 형태로 만들고 그 안의 인터렉션 명령들을 복사하여 인터렉션 가이드를 제작하기로 하였습니다.
인터렉션을 실제로 보아야 하는 큰 이유 중 하나는 Determinate의 속도 입니다. 움직이는 모션이 너무 느리면 사용자가 서비스의 성능이 느리다고 판단할 수 있습니다. 그래서 적당한 속도의 값을 찾는게 중요하죠. 구현된 프로토타입에서 CSS와 Javascript 코드의 속도 관련 값을 수정하여 속도를 시각적으로 확인하고 결과값을 찾을 수 있었습니다. 코드 속에 적힌 인터렉션 관련 값들을 모아 영상과 함께 개발자가 보고 이해할 수 있는 수준으로 Figma의 디자인 시스템 문서에 기록하였습니다. Component 디자인 만 전달하지 않고, 인터렉션과 활용 사례까지 모두 적어서 전달해야 혼란이 줄어들게 됩니다.
사용했던 프롬프트 예
원형 인디케이터(Circular Indicator)
- Indeterminate (비결정형)의 권장하는 에니메이션 값을 보여줘
Chat GPT 활용 사례html playground에 넣어서 볼 수 있게 htmlcss 합쳐진 코드로 줘
Chat GPT 활용 사례이런 시도를 할 수 있었던 이유는 어느정도의 HTML/CSS 지식이 있어 기초적인 이해가 가능했기 때문입니다. 물론 개발자 분들이 보기에는 아주 기초적인 수준이지만, 내가 원하는 무언가를 만들 수 있을 수준이 되는지에 따라 GPT의 사용 범위가 크게 달라집니다. GPT를 사용할 때 특히 주의해야하는 점은 거짓말 입니다. 제가 입력한 내용 그대로 유지하라고 명령해도 자기 맘대로 바꿔버리고 실제로 없는 자료를 근거로 이야기 합니다. 그래서 어느정도 코드를 이해해야만 거짓을 찾아내고 GPT로 프로토타입을 만들어 활용할 수 있습니다. 어긋나려는 GPT를 잘 다독여서 계속 프롬프트를 입력하다보면 어느 순간에는 내가 원하는 결과물이 만들어집니다. 프롬프트 공부가 부족해서이겠지만 아직까지는 하나의 프로토타입을 만들기 위해 걸리는 시간이 꽤 소모가 됩니다. 그러나 그 시간만큼 유용한 결과물이기도 합니다.
Chat GPT를 HTML Playground에서 작동시킨 사례7. 핸드오프
모든 준비가 완료되면 개발자와 함께 만들어진 디자인 시스템 내용이 적절한지 검토합니다. 주로 Component 구조, 활용 사례, 인터렉션 가이드를 보고 피드백을 주고 받습니다. 제가 일하고 있는 조직은 디자이너가 많지 않아 디자이너 중심의 디자인 검토가 어려운 환경입니다. 그래서 바로 개발자가 검토하는 단계로 넘어갑니다. 이런 상황이 아쉬울때가 종종 있습니다. 개발자가 줄 수 있는 피드백과 디자이너가 주는 피드백은 엄연히 다르고 특히 인공지능 서비스의 진행상태 표시와 같은 우리만의 특별한 상황 기획 같은 경우 동료 디자이너들과 함께 많은 고민을 해야만 좋은 결과를 얻을 수 있습니다. 또한, 8 Point grid system을 기준으로 하는 Component 설계, 원과 막대의 조형성 검토 등 고민해야 하는 문제들이 참 많이 남아있습니다. 그러나 지금 할 수 있는 것에 최선을 다하여야 하기 때문에 이런 아쉬움은 뒤로하고 개발단에 넘기고 있습니다.
시간이 지나면 완성되었다 생각한 Component의 또 다른 문제를 발견하고 다시 개선하는 일이 자주 발생합니다. 얼마전 Dropdown Component의 사용에 문제가 발생하여 Dropdown에 대한 재 정의를 진행하고 Dropdown, Menu, Popover으로 Component를 분할하여 개선하였습니다. 이처럼 언제가 될지 아무도 모르지만 이번에 열심히 설계한 Progress Indicator도 다시 돌아보고 고쳐야 할 것입니다. 그리고 그 과정은 잘못에서 기인한 것이 아닌 성장을 위한 과정인 것이겠죠. 디자인 시스템은 성장하는 하나의 제품이니까요.
여기까지 사내 디자인 시스템의 Progress Indicator 개선 사례를 이야기 해보았습니다. 실제 사용하고 있는 Componet와 정의 내용을 모두 공개할 수 없어 일부 수정하여 표현하였습니다. 디자인 시스템을 끌고 가는 것은 참 어려운 과제입니다. 서두에서 이야기 했듯 지금 당장 필요한 디자인을 해내는 것이 우선일 때가 종종 있습니다. 이런 일들이 쌓이게 되면 디자인 시스템과는 거리가 멀어지고 유지보수에 시간이 더 쓰이게 되겠지요. 그래서 일부러 시간을 내어 디자인 시스템을 개선하고 최대한 정의되어 있는 Component로 디자인을 하려 노력하고 있습니다. 사내에서 협업하는 다른 디자이너 끼리 너무 다른 디자인을 하지 않도록, 내가 떠나더라도 나중에 새로운 디자이너가 디자인 방향성을 잃지 않도록. 빠름 속에서 조금씩 단단함도 추구하고 있습니다. 이 단단함이 좋은 사용성을 만들어 냅니다. 사용자에게도 디자이너, 개발자에게도. 긴 글 읽어주셔서 감사합니다. 디자인 시스템을 만들어가고 있는 많은 디자이너들 화이팅!
