디자인 시스템을 설계하면서 쌓아 올린 이해도를 바탕으로 공통 영역 개선과 리뉴얼, 제품 비전 설계에 집중했습니다. 아래는 제가 팀 안에서 주도적으로 설계하고 개선한 프로젝트 중 일부입니다.
flex는 Workday, 더존과 흡사한 HR SaaS 제품으로 B2B, Web 영역에 집중하고 있습니다. 기존 시장은 고객사 입맛에 맞추는 구축형 제품들이 주류를 차지했다면, 근래에 소프트웨어향 제품으로 사용자 경험에 신경을 많이 쓰고 있는 제품으로 주목을 받았습니다.
flex는 근태관리, 전자결재, 성과관리, 급여정산 같은 다양한 도메인으로 이뤄진 제품이며 저는 2.0 리뉴얼 시점에 팀에 합류했습니다. 첫 플랫폼 디자이너(디자인 시스템 설계를 주 업무로 담당)로 합류했지만, 이후 현재까지 다양한 도메인 기능 설계를 거쳐 현재는 디자인 시스템과 공통 영역 설계에 집중하고 있습니다.
flex는 다양한 도메인이 결합되어있는 소프트웨어 제품으로 도메인과 도메인 혹은 사용자를 연결해주는 다양한 공통 기능들이 매우 중요합니다. 개별 도메인 제품팀은 각자 필요한 기능을 만들 수도 있지만 반복되는 구현을 줄이는 효율성, 비슷한 기능들의 일관성을 지키기 위해서 제품의 공통 기능들을 적극적으로 활용하고 있습니다.
공통 영역이란 어떤 도메인과도 결합되어있지 않고, 공용으로 사용되는 검색, 할 일, 캘린더 같은 기능을 의미하며, 다양한 도메인이 활용할 수 있어서 사용자들이 자주 마주치는 기능입니다. 시점적으로 새로운 디자인 시스템 문법과 함께(물론 더 향상된 기능도 포함해서) 제품이 2.0으로 업데이트되면서 공통 영역도 새로운 경험 설계가 필요해졌습니다.
검색은 소프트웨어향 제품에서 가장 놓치기 쉬운 기능입니다. 목적에 충실하게 검색 → 검색 결과 확인 흐름에만 집중할 수도 있지만, 저는 검색이 제품 안에서 활용도가 높으면서 제품 전체를 아우르는 강력한 유틸리티 기능으로 발전시키고 싶었습니다.
검색 기능을 기반으로 하는 유틸리티에 대한 아이디어는 Mac OS의 Spotlight와 Raycast, Alfred 같은 런쳐 어플리케이션들을 오랫동안 사용하면서 익숙해진 경험에서 얻었습니다. 런쳐 어플리케이션은 Mac 안에 저장된 파일, 연락처···부터 응용 프로그램과 그 안에서 동작하는 기능들까지 검색할 수 있습니다. flex도 구성원 정보부터 전자결재 문서까지 다양한 데이터를 다루지만, 그만큼 복잡하게 개별 메뉴와 수 많은 기능을 제공하기 때문에 비슷하게 데이터를 넘어서 액션까지도 검색할 수 있는 방향성을 생각했습니다.
그래서 저는 사용자들이 원하는 기능이나 정보를 찾을 때 겪어야 하는 과정을 모두 건너뛰고 한 번에 찾을 수 있는 데이터 + 디렉토리 검색 방향으로 기능을 설계했습니다.
사용자가 어느 위치에 있던 {Cmd} + {K} 단축키로 즉시 검색 모달을 띄울 수 있습니다.
제품의 복잡하고 큰 볼륨 안에서 빠른 액션도 자연스럽게 녹이는 것도 중요했습니다. 최초의 디자인 방향은 모든 검색 결과를 전부 보여주는 방향으로 설계 되었고 엔지니어링 부하와 사용자들이 너무 많은 정보를 이해하지 못 할 것이라는 걱정이 있었습니다.
또 다른 문제는 도메인마다 제공해야 하는 주요 정보도 달랐기 때문에 모두 동일하게 표현하기 어렵고 적절하게 필요한 정보를 보여줄 수 있는 개별 검색 항목 UI도 필요했습니다.
첫 검색 단계는 모든 카테고리의 검색 결과를 4개 이하로 보여주도록 설계했습니다.
몇 차례의 디자인 테스트와 팀 안에서 엔지니어링 구조에 대한 논의를 바탕으로 방향성을 결정했습니다. 검색 인풋에 키워들르 입력하면, 도메인 검색 결과 그룹을 개별로 제공하고 {전체 보기}를 누르면 상세 결과로 이동합니다. 사용자들은 상세 결과 화면에서 필터, 정렬 같은 검색에 필요한 기능을 제공받거나 도메인 액션들을 찾아서 수행할 수 있습니다.
빠른 검색은 모달이기 때문에 뎁스 이동을 위한 네비게이션 장치도 함께 고민했습니다. 하위 뎁스에서는 빠른 검색 모달 위에 현재 위치를 알려주는 타이틀 UI를 제공하고, 검색 인풋에서도 이전으로 돌아갈 수 있는 버튼을 제공합니다.
상세 검색 결과 UI 구성
상세 검색 결과 화면에서 더 자세한 결과를 확인할 수 있습니다.
기술적인 제약도 구현된 화면에 영향을 주었지만, 오히려 이런 제약 덕분에 엔지니어와 긴밀하게 이야기하면서 더 단순해진 방향을 탐색해 볼 수 있었던 좋은 기회였습니다.
해야할 일(이하 ‘할 일’)은 flex를 사용하면서 처리해야할 ‘업무’를 관리할 수 있도록 도와주는 기능입니다. 제품 안에서 도메인 같은 특정 영역을 다루지 않지만, 오히려 제품 전체를 관통하는 기능으로 활용됩니다. 내부 제품팀에서는 사용자에게 액션을 포함한 넛지가 필요한경우 활용하며, 사용자들은 다른 사용자에게 승인, 반려, 작성 같은 업무 요청이 필요한 경우 사용합니다.
간단한 넛지와 처리 결과를 알려주는 알림과 다르게 할 일은 사용자가 실제 액션을 수행해야 ‘완료’ 또는 ‘반려’ 처리 할 수 있기 때문에 제품에 끼치는 영향 범위가 크고 중요한 기능들 중 하나입니다.
할 일은 도메인에서 사용자와 사용자간 발생하는 '업무'를 관리하는 기능입니다
할 일은 flex 제품 초창기에 만들어진 기능들 중 제품이 한 번 리뉴얼된 현재에도 그대로 사용되는 몇 안 되는 기능이었습니다. 제품이 담고 있는 도메인과 사용자에게 필요한 기능은 훨씬 많아지고 복잡했졌지만, 그걸 기능으로 제공해야 하는 할 일은 여전히 MVP에 가까운 기능만 제공하고 있었습니다.
할 일이 제공하고 있는 기능은 완료, 반려 같은 액션만 제공하며 할 일을 요청할 때에도 제목을 입력할 수 없었으며, 매우 치명적이게 한 번 발송된 할 일은 삭제가 안되기 때문에 삭제하고 싶다는 문의가 자주 인입되었습니다.
이전 버전은 단순함은 장점이었지만, 부족한 기능이 치명적이었습니다.
사용자들의 업무 패턴을 분석하면서 할 일이 도와줄 수 없는 몇 가지 중요한 문제를 찾았고 그것을 해결하고, 부족한 기능을 보강하기 위해서는 새로운 형태의 할 일이 필요하다고 판단했습니다.
할 일은 제품 안에 거의 모든 도메인이 활용하는 기능이었기 때문에 많은 맥락을 담으면서 일관성을 보장할 수 있는 디자인 아이디어가 필요했습니다. 도메인에서 쉽게 활용할 수 있는 구성을 찾기 위해서 다양한 아이디어를 테스트했습니다.
상세 검색 결과 화면에서 더 자세한 결과를 확인할 수 있습니다.
다양한 시안을 그려보면서 할 일에 필요한 프로퍼티와 기능들을 확정하는 과정도 함께 진행되었습니다. 업무 관리를 도와줄 수 있는 마감일, 진행 상태를 설계하고 협업에 필요한 참조, 댓글, 활동 내역을 추가했습니다. 새롭게 할 일을 설계하는 과정이었지만 기술적인 문제와 너무 익숙해진 사용자 경험을 유지하기 위해서 예전 기능을 여전히 유지해야 하는 문제도 있었습니다.
대표적인 예는 목록에서 마우스 호버시 노출되는 CTA 버튼입니다. 기술적으로도 복잡도를 높이는 구현이 필요했고 경험적으로도 되돌릴 수 없는 액션을 너무 쉽게 제공하는 위험이 있었습니다. 다만 사용자들이 목록에서 즉시 업무를 처리해버리는 경험이 너무 익숙해졌기 때문에 기능을 제거하지 않았습니다.
많은 아이디어 테스트와 기능에 대한 검증 과정을 거쳐서 할 일의 방향을 설계했습니다. 사용자가 해야할 일은 홈피드 첫 섹션에서 확인하거나 전달하기 CTA 버튼을 통해서 요청할 수 있고 필요하다면 어떤 화면에서든 빠른 검색을 통해서도 가능하도록 했습니다.
상세 검색 결과 화면에서 더 자세한 결과를 확인할 수 있습니다.
할 일 메뉴와 상세에서도 사용자 업무 흐름을 쉽게 파악할 수 있도록 아래와 같은 기능을 제공합니다.
할 일 메뉴에서 목록은 필터, 정렬, 그룹 같은 기능을 제공합니다.
할 일 상세 모달 구조
앞서 이야기했던 것처럼 연장 근무 승인과 구성원 리뷰 요청 같이 전혀 다른 맥락의 할 일 타입들의 일관성을 유지할 수 있는 아이디어가 필요했습니다. 승인 관련 업무 요청이 할 일 사용에 대부분을 차지하고 있어서 승인 UI를 중심으로 구성하는 것을 고려하기도 했습니다. 다만 승인 요청 안에서도 연장 근무, 증명서 발급, 문서 조회 등 전혀 다른 내용이었기에 완벽하게 동일한 UI를 제공하기에는 어려울 것 같다고 결론지었습니다.
여러 아이디어 중 할 일 모달 안에 도메인 참조 영역을 제공하는 방향으로 디자인 했습니다. 할 일 모달에서 도메인은 참조 영역을 통해 제목과 속성 하단에 도메은 타임라인이나, 문서 정보 등을 원하는 형태로 표현할 수 있습니다. 또한 공통 기능 관점에서 최소한의 일관성을 지키기 위해서 가이드 UI Kit, 예시 UI 등을 제공합니다.
할 일 상세 모달 안에서 참조 영역 구성
할 일에서 사용되는 참조 영역 UI 예시들
할 일의 진행 상태는 승인, 반려 같은 액션을 취하면 자동으로 변경되지만, 사용자도 마음대로 변경할 수 있습니다. 이것은 살짝 어색하고, 예상이 잘 안되는 것 같지만 의도한 동작입니다.
재설계된 첫 버전의 할 일은 진행 상태가 진행 예정, 진행 중, 완료됨, 반려됨, 취소됨까지 총 5개였습니다. 팀 안에서 할 일을 사용해 본 경험에 관해서 이야기하던 도중 우리 팀이 사용자들의 업무 과정을 최대한 상세하게 표현하고 싶어서 많은 상태를 만들었지만, 실제로 사용해 보니 각 상태에 대한 해석 방식이 각자 너무 다르다는 점을 깨달았습니다.
그래서 처음으로 돌아가 사용자들의 문제를 다시 탐구했고, 정석적인 업무처리도 원하지만, 시간이 지나거나 구두로 커뮤니케이션된 업무는 '화면에서 안 보이게 그냥 완료 처리하고 싶다'라는 약간 이상한 니즈도 있는 것을 확인했습니다. 제품 관점에서는 말이 안 되는 방향이지만 실제 업무 처리 과정에서는 충분히 있을 수 있는 경우라고 생각해서 진행 상태를 과감히 줄이고, 처리 여부와 상관없이 완료할 수 있도록 다시 만들었습니다.
할 일이 추구하는 방향은 제품 안에서 사용자가 확인해야 할 모든 업무를 알려주고 요청한 업무 진행 상황을 확인하기 위한 기능입니다. 릴리즈된 버전은 할 일의 최종 종착지가 아닙니다. 오히려 할 일이 담아야 할 정보를 동일한 포맷으로 정리했다는 점에서 첫 단계를 넘었다고 생각합니다.
도메인을 위해서 훨씬 유연하게 설계를 보완한 할 일의 다음 버전
일정은 flex 안에서 업무상 생기는 이벤트들을 확인할 수 있게 도와주는 기능입니다. 할 일처럼 오래된 기능이었고 크게 두 가지 문제가 있었습니다.
일정 조회시 너무 느려지는 성능 이슈
제품 내 일정 중 근무, 휴가, 기념일만 확인 가능함
일정은 확장성을 고려하기 힘든 초기 상황에서 설계되었습니다. 한 번에 모든 회사 인원의 이벤트를 조회하도록 구현되어있었고, 50명 미만 소규모 회사라면 괜찮았지만 100명, 200명 이상되는 회사라면 기능 사용이 불가능해질 정도로 성능이 느려졌습니다. 문제를 해결하기 위해서 전체 조회 방식에서 캘린더 구독 형태로 개선이 필요했고 더불어서 지원하지 않았던 채용 인터뷰 일정, 원온원 일정도 추가하는 작업을 함께 진행했습니다.
개선을 위해서는 일정 화면의 구조 변경이 필요했습니다. 첫 시도는 사용자들에게 익숙한 캘린더 앱 구조(구독을 관리하는 패널과 타임라인 조합)를 그대로 차용하는 방향이었습니다. 익숙한 구조라서 이해하기는 쉬웠지만 타임라인을 사용한다면 팀 단위 구독을 하는 우리 사용자들의 특성상 일정이 너무 많아서 제대로된 뷰를 보기 어려웠습니다. 또한 프론트엔드 기술적으로 중복, 겹치는 이벤트 분기 처리, 리사이징 등 까다로운 요소들이 많았습니다.
대강 진행했던 첫 스케치
한 번에 많은 수의 동료와 팀을 구독하고 동료 간 중복 일정이 많은 우리 사용자들을 위해서는 캘린더 앱과 다른 접근 방식이 필요했습니다. 사용자, 우리 팀의 관점으로 생각하던 와중에 시간 축으로 보여주는 방식은 '여러 명의 중복 이벤트를 제대로 전달하기 까다롭다'는 점을 착안해서 거꾸로 관심 있는 대상만 확인 할 수 있도록 사람 단위로 일정을 묶어서 보여주면 더 단순화된 뷰가 나올 수 있지 않을까 생각했습니다.
모든 일정은 시간 기준이 아니라 동료 단위로 그룹핑되어 제공됩니다.
일정 모달 UI 예시
구성원 그룹의 시인성을 위해서 구성원마다 개별 랜덤 색상을 할당받도록 설계했습니다. 이벤트 아이템들은 색상의 톤을 유지하기 위해서 배경색, 텍스트 색상, 호버 색상이 다르게 구성했으며 아이템 선택시에도 활성화 상태를 유지하기 위한 상태를 디자인했습니다.
쉽게 일정을 탐색할 수 있도록 홈 피드의 일정 위젯도 새롭게 구성했습니다.
사용자들은 홈 피드에서도 동료 일정을 탐색할 수 있습니다.
일정은 아직 이벤트 조회 플로우 밖에 없고 구글 캘린더 같은 캘린더 앱에 대한 사용자들의 경험이 많았기 때문에 경험의 수준을 맞추기 위해서 오히려 섬세한 동작 설계와 접근성을 유지하는데 더 많은 노력을 들였습니다. 개별 이벤트 타입에 대한 정의나 상세 팝오버 동작, 특히 엔지니어와 브라우저 리사이즈시 사용성 보장을 위해서 UI상 분기 처리를 가장 많이 신경 썼습니다.
가능한 수준에서 최대한 세심하게 최소 브라우저 사이즈를 대응합니다.
복잡한 제품을 빠른 속도를 유지하면서 제품을 만든다면 단편적인 기능만 개발하거나 도메인간 단절된 상태로 출시되는 등 다양한 문제가 발생할 수 있습니다. 이런 상황을 방지하기 위해서는 조금 더 넓은 시야를 갖고 장기적인 방향성과 아이디어를 탐색하는 시간이 필요합니다.
구현, 디자인 시스템 패턴, 도메인간 의존성에서 벗어나서 제품의 구체적인 미래 형태를 그려보는 작업은 빠르게 움직이는 목적 조직에서는 이해관계가 설득되지 않는다면 시도하기 어렵지만 flex는 방향성을 중요하게 생각하는 팀입니다. 운이 좋게도 저는 디자인 시스템, 제품 내 설계 이해 역량을 인정받아서 담당하는 맥락을 넘어서는 다른 도메인과 기능의 비전을 설계해 볼 수 있는 기회를 얻었습니다. 아래에 작업 중에는 비전 설계에 시작해 실제로 제품에 반영된 내용이 포함되어 있습니다.
조직과 제품 관점에서 몇 가지 고려해야 할 점이 있습니다.
HR 제품에서 프로필은 일반 구성원, 리드, 인사 담당자 모두에게 중요한 공간이면서도 모두에게 의미있는 정보를 보여주기 어려운 공간입니다. 당시 프로필은 인사 담당자 같은 모든 권한을 갖고 있는 사용자들에게만 유의미한 정보를 보여주고 있었고 그 외 사용자들에게는 필요없는 공간이었습니다. 저는 프로필이 동료와 개인에게도 활용할 수 있는 공간이 될 수 있도록 방향을 그렸습니다.
제품 구조상 급여명세서, 인사 정보, 일정과 이벤트, 리뷰 등 유저 정보 대부분이 각 도메인에서 관리되고 있었고, 이런 개인 맥락의 정보들을 프로필에서 한 번에 볼 수 있는 허브로 동작하도록 설계했습니다. 인사 담당자, 관리자 같은 역할의 사용자들은 각 도메인에서도 필요한 구성원들의 정보를 일괄 확인 할 수 있지만 동료 프로필을 통해서도 훨씬 자세한 정보를 확인할 수 있습니다. 동시에 일반 사용자들도 동료 프로필에서 기념일, 소개 문구, 할 일 요청 등 다양한 액션을 수행할 수 있도록 했습니다.
새로운 프로필에서는 파편화된 정보를 한 곳에서 확인 할 수 있습니다.
프로필에서 제공되는 모달 예시
인사 담당자 같은 사용자는 인사 정보 변경 내역을 쉽게 찾을 수 있습니다.
flex 제품이 리뉴얼된 이후 도메인과 기능이 늘어나면서 인사 담당자, 관리자 중심의 메뉴들이 늘어났고, 새로운 메뉴 위계 구성이 필요했습니다. 컨셉은 일반 메뉴와 관리 메뉴를 별도로 구성하는 방향이었고 그중에 구성원 메뉴*는 거의 모든 기능이 인사 담담자 중심이라, 메뉴 구조 개선을 진행한다면 일반 구성원들도 활용할 수 있는 새로운 아이디어가 필요했습니다.
* 구성원 목록, 입 퇴사 관리 등 기능이 포함됨
인사 담당자 중심의 구성원 메뉴에 제한된 인사 정보를 갖고 재구성하고 딱딱한 B2B SaaS 문법을 그대로 유지하는 것은 사용자들에게 아무런 가치가 없다고 생각했습니다. 저는 오히려 사용자에게 동료(유저)목록은 매우 익숙한 개념이니 부드러운 소셜향 제품들의 문법을 차용하는 게 인상적인 경험을 줄 수 있다고 생각했고 일상에서 자주 사용되는 소셜 제품들의 유저 목록을 광범위하게 조사했습니다.
조사 단계에서 우리 제품에 적용할 수 있거나 필요한 요소들을 생각보다 많이 발견할 수 있었습니다. 예를 들면 현재 접속 상태 · 기록을 보여주는 것은 우리 제품에서는 근무 상태, 휴게 상태 같은 기능을 통해서 표현해 줄 수 있었고, 상태 메시지 · 기념일 같은 요소들도 이미 제품 내 프로필에서 조금만 더 다듬는다면 충분히 제공할 수 있는 경험이었습니다. 이외에도 페이스북의 페이지 · 그룹 같은 소셜 기능에서 착안해 팀 프로필 같은 개념도 구체화할 수 있었습니다.
동료 목록 상단은 생일, 기념일 등을 보여주며 동료들의 소개 메시지도 확인할 수 있습니다.
다양한 편의 기능을 제공합니다.
조직 위계와 상관없이 수평적으로 회사 안의 모든 조직을 확인할 수 있습니다.
상태 메시지를 직접 설정하고, 저장 전에 미리 확인할 수 있도록 했습니다.
일반적으로 제품을 사용하기 위해서 사용자들에게 자세한 설정을 하도록 유도하는 것은 흔히 '단순'하지 못한 설계라고 평가받습니다. HR SaaS에도 통용되는 이야기일까요? 100개의 회사가 있다면 100개의 문화가 있다고 할 만큼 사용자들의 요구는 다양하고 쉽게 보편화할 수 없으며, 오히려 설정을 통해서 회사 문화에 맞는 제품을 만들고 싶어 합니다. 그래서 저는 flex에서 설정이 불가피한 단계라면 차라리 훨씬 유려하고 친절한 방향으로 풀어내고 싶었습니다.
flex는 결이 다른 도메인들이 많았기 때문에 설정 UI 패턴이 도메인마다 다르게 나온다면 일관성 유지와 예측 가능한 경험을 주기 어려웠습니다. 따라서 설정의 폼, 스위치, 슬라이더, 로우 같은 UI 컨트롤러 패턴을 공통화하는 데 집중하면서 UI 패턴 안에서 설정이 어떻게 사용자들이 보는 화면에 영향을 끼치는지 '미리보기' 같은 기능도 제공해서 친절한 경험과 예측 가능한 경험을 제공해 보려고 했습니다.
설정 메뉴 구조와 이해하기 쉬운 폼 패턴과 컨트롤러를 구상했습니다.
디자인 시스템 제작 이후 제품 설계에 집중했지만 중간중간 새롭게 공통 패턴을 만들거나 필요하다고 생각되는 컴포넌트를 개선, 추가하는 작업은 계속해서 진행했습니다. 디자인 시스템 Linear는 가장 자부심을 느끼는 프로젝트인 만큼 주요 업무로 담당하지 못하더라도 팀 안에서 지속해서 발전시키고 싶은 욕심이 있었습니다.
아래의 예시들은 위에 소개되지 않은 프로젝트들도 포함되어 있습니다.
정렬, 커뮤니케이션 툴킷, 드롭다운 예시
flex에서 함께 일하고 있는 제품 팀은 누구보다 뛰어난 수준의 결과물을 만드는 데 집착하면서 적극적으로 의견을 교환하고, 수용하는 문화를 갖고 있습니다. 각자의 관점을 이해하기 위해서 몇 시간 동안 토론하기도 하면서, 디자인의 중요성을 이해하고 유려한 사용자 경험과 비주얼을 위해 다양한 기술을 시도하고 있습니다. 덕분에 디자인을 바라보는 시각과 엔지니어링 기술적인 이해, 커뮤니케이션 방법 등 많은 것을 배웠고 지금도 배우고 있습니다. 정말 감사합니다.