디자인 시스템 구축으로 시작했지만,
전체 업무 시스템 개선으로 마무리 됐습니다.

사용자와 업무 환경, 팀의 반복 업무를 함께 분석해 가장 필요한 기준부터 순차적으로 구축했습니다.

ROLEDESIGN TEAM & UX LEAD

FOCUSPRODUCTIVITY · CONSISTENCY · USABILITY

SCOPERESEARCH · SYSTEM · COMPONENTS · TOKENS

PERIODAIMMO · 2022-2024

파악해 보니,
같은 일을 계속 반복하는 것이 더 큰 문제였습니다.

01.1

먼저 팀원들로부터 히스토리를 파악했습니다.

팀이 왜 시스템을 만들지 못했고 어떤 불편을 반복해왔는지부터 확인했습니다.

“시간이 없어 공통 디자인 에셋도 못 만들었어요.”RESOURCE

“UX를 조금만 바꿔도 불편함을 호소해서 손을 못 대요.”UX CHANGE

“비슷한 기능인데 서비스마다 UX가 달라 불편하다는 이야기가 많아요.”CONSISTENCY

“디자인 시스템을 만든 경험이 없어 어떻게 시작해야 하는지 모르겠어요.”STARTING POINT

“한 번에 전체 적용을 못하면 계속 화면이 달라질 것 같아요.”ADOPTION

“회사에서 왜 필요한지 공감대를 만들기 어려웠어요.”ALIGNMENT

SYNTHESIS

결국 디자인 시스템의 필요성보다 경험·시간 부족과 단계 적용의 어려움이 먼저 문제였고,
조직의 공감대 부족까지 겹치며 시작과 운영 자체가 계속 미뤄지고 있었습니다.

따라서 결과물보다 실행 가능한 방식과 운영 구조를 먼저 정리할 필요가 있었습니다.

01.2

문제는 디자인팀만이 아니었습니다.
디자인과 개발 모두 반복 작업을 계속하고 있었습니다.

같은 기능을 설계·전달·구현·확인하는 과정이 제품마다 다시 시작됐습니다.

요구사항 정리

비슷한 기능도 제품마다 다시 해석했습니다.

›

불필요한 디자인 반복

화면 설계

공통 기준 없이 화면을 다시 설계했습니다.

›

UI 재제작

기존 리소스 대신 컴포넌트를 다시 만들었습니다.

›

개발 전달

화면마다 속성과 상태를 다시 설명했습니다.

재사용 안되는 비효율적인 구조

개발 재구현

비슷한 UI도 제품별로 다시 구현했습니다.

›

예외 재확인

상태와 예외 케이스를 다시 맞췄습니다.

›

QA·수정

기준 차이로 수정과 확인이 반복됐습니다.

›

다시 시작

다음 제품에서도 같은 과정이 반복됐습니다.

01.3

그래서 목표를 디자인 시스템 제작에서,
디자인·개발 프로세스와 협업 방식 정립으로 확장했습니다.

산출물 전달부터 토큰·라이브러리 운영까지 재사용 가능한 협업 구조로 바꿨습니다.

반복되는 기준부터 정리하기로 했습니다.

컴포넌트·상태·예외처럼 반복 판단하던 항목을 공통 기준으로 묶기로 했습니다.

산출물을 재사용 가능한 구조로 만들기로 했습니다.

화면보다 컴포넌트·상태 단위로 정리해 다음 제품에서도 재사용할 수 있게 했습니다.

개발 전달 방식을 표준화하기로 했습니다.

속성·상태·예외를 같은 구조로 전달해 반복 설명을 줄이기로 했습니다.

디자인과 개발 토큰을 맞추기로 했습니다.

컬러·타이포·간격·Radius를 개발 토큰과 매핑해 같은 기준을 쓰게 했습니다.

공통 리소스를 라이브러리화하기로 했습니다.

핵심 컴포넌트와 토큰을 양쪽에서 재사용할 수 있는 라이브러리로 관리하기로 했습니다.

변경과 리뷰 방식도 운영 규칙으로 정리하기로 했습니다.

버전·리뷰·변경 공유 규칙을 정해 실제 업무에서 지속될 수 있게 했습니다.

만들기 전에,
실제 사용자들의 업무 방식과 환경부터 분석했습니다.

02.1

같은 사무실의 사용자에게 묻고,
옆에서 실제 업무를 따라가며 확인했습니다.

사용 환경·조도·작업 시간을 인터뷰하고 Shadow Tracking으로 실제 서비스 이용 과정을 확인했습니다.

AIMMO 사용자 인터뷰와 작업 환경 관찰 장면 — 01작업 환경과 시간, 장비와 불편을 직접 듣고 기록했습니다.

AIMMO 실제 서비스 이용 과정을 옆에서 관찰하는 장면 — 02옆에서 실제 서비스를 쓰는 순서와 반복 행동을 따라가며 확인했습니다.

AIMMO 관찰 결과와 개선 포인트를 정리하는 장면 — 03관찰 결과를 모아 오래 보는 구간과 즉시 판단해야 하는 지점을 분리했습니다.

02.2

관찰해 보니 시스템 제작의 핵심은,
빠르고 정확한 판단과 실행, 그리고 최적화였습니다.

Crowd Worker 특성상 탐색·판단·실행 시간을 줄이는 것이 생산성과 직결됐습니다.

저녁 · 밤에 주로 작업

낮은 조도의 저녁·밤에 작업이 집중됐고, 한 번 시작하면 장시간 이어졌습니다.

05–12시

27%

12–18시

52%

18–22시

62%

22–05시

30%

SOURCE · AIMMO Cloudworker 100명을 대상으로 한 설문 · 복수 시간대 선택

주로 집에서 장시간 작업

업무시간의 78.7%를 재택으로 진행한다고 답했습니다.

78.7%HOME

집에서 작업78.7%

회사 · 기타 장소21.3%

SOURCE · AIMMO Cloudworker 100명을 대상으로 한 설문

빠른 상태 판단이 매우 중요

상태와 다음 행동을 즉시 구분할수록 재확인 시간이 줄었습니다.

상태 즉시 파악

88%

다음 행동 결정

84%

재확인 감소

78%

오류 예방

74%

SOURCE · AIMMO Cloudworker 100명을 대상으로 한 설문

최우선은 생산성

탐색·판단 시간을 줄이는 것이 처리량과 보상에 직접 연결됐습니다.

생산성을 최우선 가치로 봤습니다.

매우 중요

58%

중요

31%

보통

낮음

빠른 탐색과 선택이 처리량을 좌우했습니다.

매우 큼

54%

큼

34%

보통

10%

낮음

처리량 증가는 보상과 직접 연결됐습니다.

매우 직접적

61%

직접적

27%

보통

낮음

SOURCE · AIMMO Cloudworker 100명을 대상으로 한 설문

02.3

환경과 사용 패턴을 분석해 보니,
주요한 개선 포인트들을 발견했습니다.

다크 모드를 정답으로 두지 않고, 저조도·장시간 사용 환경과 관련 연구를 함께 검토했습니다.

AIMMO 다크 모드 개선 화면 — 01저조도·장시간 작업 환경을 고려해 전체 화면을
다크 모드로 전환했습니다.

AIMMO 컬러 시스템 개선 화면 — 02행동·상태 대비를 명확히 하고 실제 장비 기준으로
컬러를 다시 조정했습니다.

AIMMO 컴포넌트 스케일 개선 화면 — 03주요 사용 장비를 기준으로 컴포넌트 크기와
간격을 다시 설정했습니다.

AIMMO 그래픽과 브랜딩 개선 화면 — 04그래픽 표현과 활용 규칙을 통일하고 해외 적용을 위한
영문 가이드까지 만들었습니다.

분업과 오너십을 바탕으로,
실제 시스템으로 옮겼습니다.

03.1

역할을 나누고,
각자의 오너십으로 실행했습니다.

팀원별 오너십을 나누고, 지속적인 공유와 리뷰로 하나의 품질 기준을 유지했습니다.

지속적인 리뷰와 공유를 통한 고도화

TYPE

폰트 위계와 텍스트 규칙

COLOR

상태와 행동 컬러 체계

GRAPHIC

그래픽 스타일과 표현 기준

COMPONENT

코어 컴포넌트와 상태 정의

TOKEN

개발과 공유할 공통 값

03.2

분업으로 만든 시스템을,
실제 제품과 업무에 적용하며 함께 완성했습니다.

영역별로 병렬 구축한 뒤 리뷰·제품 적용·개발 협의를 반복해, 디자인 시스템을 실제 업무 기준으로 정착시켰습니다.

디자이너들이 타이포·컬러·컴포넌트 등 각자 맡은 영역을 분업해 디자인 시스템을 제작하는 장면 — 01
영역을 나누고 각자의 오너십으로 병렬 구축했습니다.

디자인 시스템 거버넌스와 컴포넌트 규칙이 표시된 모니터 화면 — 02
각자 만든 기준을 정기 리뷰로 하나의 시스템으로 맞췄습니다.

디자이너들이 디자인 시스템 컴포넌트를 실제 제품 화면에 적용하고 검증하는 장면 — 03
실제 제품에 적용하며 재사용성과 예외를 검증했습니다.

디자이너와 개발자가 디자인 시스템 컴포넌트·토큰·적용 우선순위를 회의하는 장면 — 04
적용을 위해 디자인과 개발이 함께 기준과 우선순위를 맞췄습니다.

결국 돌아보니,
디자인이 아닌 업무 시스템을 개선하는 작업이었습니다.

04.1

지금까지 구축한 디자인 시스템 중,
업무 방식의 변화가 가장 분명하게 나타났습니다.

디자이너·개발자·PO 인터뷰와 Asana를 통한 업무 시간 추적 비교를 통해 제작 전후의 변화를 확인했습니다.

GUI 디자인
제작 소요시간

-72%

협업 부서와의
소통 시간

-63%

Front-end 개발
소요시간

-38%

UX 설계·기획
고려시간

+45%

SOURCE - 디자이너·개발자·PO 인터뷰 및 Asana를 통한 업무 시간 추적 비교를 통한 생산성 변화 수치

04.2

팀이 체감한 변화도,
업무 방식에서 분명하게 나타났습니다.

디자이너·개발자 피드백을 통해 속도, 소통, UX 집중도의 변화를 함께 확인했습니다.

“반복해서 UI를 만드는 일이 줄어서 디자인 작업 속도가 확실히 빨라졌어요.”DESIGN SPEED

“개발팀에 같은 내용을 계속 설명하고 확인하는 시간이 많이 줄었어요.”COMMUNICATION

“화면 만드는 시간이 줄어서 UX 흐름이나 기획·설계를 더 깊게 볼 수 있게 됐어요.”UX FOCUS

“담당자가 달라도 같은 기준으로 작업하니까 결과물 맞추기가 훨씬 편해졌어요.”CONSISTENCY

“수정이 생겨도 컴포넌트 기준으로 바꾸면 돼서 대응이 훨씬 빨라졌어요.”REVISION

“새 프로젝트도 처음부터 다시 만들 필요가 없어서 시작할 때 부담이 많이 줄었어요.”REUSE

파악해 보니,같은 일을 계속 반복하는 것이 더 큰 문제였습니다.

먼저 팀원들로부터 히스토리를 파악했습니다.

결국 디자인 시스템의 필요성보다 경험·시간 부족과 단계 적용의 어려움이 먼저 문제였고,조직의 공감대 부족까지 겹치며 시작과 운영 자체가 계속 미뤄지고 있었습니다.

문제는 디자인팀만이 아니었습니다.디자인과 개발 모두 반복 작업을 계속하고 있었습니다.

요구사항 정리

화면 설계

UI 재제작

개발 전달

개발 재구현

예외 재확인

QA·수정

다시 시작

그래서 목표를 디자인 시스템 제작에서,디자인·개발 프로세스와 협업 방식 정립으로 확장했습니다.

반복되는 기준부터 정리하기로 했습니다.

산출물을 재사용 가능한 구조로 만들기로 했습니다.

개발 전달 방식을 표준화하기로 했습니다.

디자인과 개발 토큰을 맞추기로 했습니다.

공통 리소스를 라이브러리화하기로 했습니다.

변경과 리뷰 방식도 운영 규칙으로 정리하기로 했습니다.

만들기 전에,실제 사용자들의 업무 방식과 환경부터 분석했습니다.

같은 사무실의 사용자에게 묻고,옆에서 실제 업무를 따라가며 확인했습니다.

관찰해 보니 시스템 제작의 핵심은,빠르고 정확한 판단과 실행, 그리고 최적화였습니다.

저녁 · 밤에 주로 작업

주로 집에서 장시간 작업

빠른 상태 판단이 매우 중요

최우선은 생산성

환경과 사용 패턴을 분석해 보니,주요한 개선 포인트들을 발견했습니다.

분업과 오너십을 바탕으로,실제 시스템으로 옮겼습니다.

역할을 나누고,각자의 오너십으로 실행했습니다.

TYPE

COLOR

GRAPHIC

COMPONENT

TOKEN

분업으로 만든 시스템을,실제 제품과 업무에 적용하며 함께 완성했습니다.

영역을 나누고 각자의 오너십으로 병렬 구축했습니다.

각자 만든 기준을 정기 리뷰로 하나의 시스템으로 맞췄습니다.

실제 제품에 적용하며 재사용성과 예외를 검증했습니다.

적용을 위해 디자인과 개발이 함께 기준과 우선순위를 맞췄습니다.

결국 돌아보니,디자인이 아닌 업무 시스템을 개선하는 작업이었습니다.

지금까지 구축한 디자인 시스템 중,업무 방식의 변화가 가장 분명하게 나타났습니다.

팀이 체감한 변화도,업무 방식에서 분명하게 나타났습니다.

파악해 보니,
같은 일을 계속 반복하는 것이 더 큰 문제였습니다.

결국 디자인 시스템의 필요성보다 경험·시간 부족과 단계 적용의 어려움이 먼저 문제였고,
조직의 공감대 부족까지 겹치며 시작과 운영 자체가 계속 미뤄지고 있었습니다.

문제는 디자인팀만이 아니었습니다.
디자인과 개발 모두 반복 작업을 계속하고 있었습니다.

그래서 목표를 디자인 시스템 제작에서,
디자인·개발 프로세스와 협업 방식 정립으로 확장했습니다.

만들기 전에,
실제 사용자들의 업무 방식과 환경부터 분석했습니다.

같은 사무실의 사용자에게 묻고,
옆에서 실제 업무를 따라가며 확인했습니다.

관찰해 보니 시스템 제작의 핵심은,
빠르고 정확한 판단과 실행, 그리고 최적화였습니다.

환경과 사용 패턴을 분석해 보니,
주요한 개선 포인트들을 발견했습니다.

분업과 오너십을 바탕으로,
실제 시스템으로 옮겼습니다.

역할을 나누고,
각자의 오너십으로 실행했습니다.

분업으로 만든 시스템을,
실제 제품과 업무에 적용하며 함께 완성했습니다.

결국 돌아보니,
디자인이 아닌 업무 시스템을 개선하는 작업이었습니다.

지금까지 구축한 디자인 시스템 중,
업무 방식의 변화가 가장 분명하게 나타났습니다.

팀이 체감한 변화도,
업무 방식에서 분명하게 나타났습니다.