왜 라벨을 고치기 전에 '문제'부터 다시 정의했을까
1/ 단순한 태그처럼 보이지만, 작업을 이해하는 방식입니다
뤼이도에서 라벨은 작업 옆에 붙는 단순한 입력 값이 아닙니다.
어떤 팀에게 라벨은
- 우선순위(P0,P1)이고
- 어떤 팀에게는 작업의 성격(디자인, 프론트엔드, 백엔드)이며
- 또 다른 팀에게는 배포 단위나 이슈의 맥락이 되기도 합니다.
즉, 라벨은 각 팀이 작업을 어떻게 분류하고, 무엇을 중요하게 보고, 어떤 기준으로 프로젝트를 운영하는지를 드러내는 장치입니다.
사용자는 라벨을 통해 작업을 찾고, 필터링하고, 우선순위를 정합니다.
이 과정이 반복될수록 라벨을 단순한 편의 기능이 아니라 프로젝트를 운영하는 기준에 가까워집니다.
그래서 이 문제를 '작은 기능'이 아니라 프로젝트가 지연되는 구조와 연결된 문제로 바라보기 시작했습니다.
2/ 같은 라벨이 여러 개 생긴 이유는, 라벨 자체에 있지 않았습니다
뤼이도에서는 프로젝트가 지연되는 주요 원인을 네 가지로 정의해왔습니다.
- 갑작스러운 요청, 작업, 회의로 계획이 틀어지는 문제
- 기준 없이 운영되는 프로젝트 관리 체계
- 업데이트 누락과 지연으로 팀 현황을 파악하기 어려운 문제
- 흩어져 있는 문서와 작업, 관리되지 않은 업무 히스토리
라벨 문제는 이 중 2번 '기준 없이 운영되는 프로젝트 관리 체계', 4번 '관리되지 않은 업무 히스토리'에 직접 연결되어 있었습니다.
같은 의미의 작업이 서로 다른 라벨로 흩어지면
팀은 어떤 작업이 진행 중인지, 어떤 작업이 이미 끝났는지 한눈에 파악하기 어려워집니다.
이는 단순히 라벨이 많아지는 문제가 아니라,
작업을 바라보는 기준이 흐려지고 업무 히스토리가 분절되는 문제로 이어집니다.
여기서 한 단계 더 들어가 "왜 이런 현상이 반복되는가"를 다시 살펴보았습니다.
3/ 라벨을 점검할 수 있는 시점과 공간이 없었습니다
문제를 더 들여다 보니,
같은 의미의 라벨이 계속해서 생기는 이유는 명확해졌습니다.
뤼이도 안에는
라벨을 점검하고, 조정하고, 팀의 언어를 맞출 수 있는 시점과 공간이 존재하지 않았습니다.
라벨은 작업을 생성하는 흐름 속에서 개별 사용자가 필요에 따라 쉽게 추가할 수 있었지만,
- 지금 사용 중인 라벨이 무엇인지
- 비슷한 의미의 라벨이 이미 존재하는지
- 이 라벨이 어떤 작업들에 쓰이고 있는지
를 한 번에 확인할 수 있는 곳은 없었습니다.
그 결과 라벨은 각자의 작업 맥락 속에서 조용히 쌓였고,
중복과 분산은 자연스럽게 반복될 수밖에 없었습니다.
4/ 문제를 이렇게 정의했습니다
문제를 '같은 의미의 라벨이 여러 개 존재한다'로 정의하지 않았습니다.
대신 이렇게 정의했습니다.
공통의 기준과 언어를 정리할 수 있는 구조가 부족하다.
라벨은 각자 작업을 할 때 붙이는 개인적인 선택에 가까웠고,
그 결과 라벨을 "함께 정리해야 할 대상"으로 인식하기 어려웠습니다.
각자가 다른 라벨을 붙이고 있으니 정리해야겠다는 계기 자체가 쌓이지 않았고, 같은 의미의 라벨은 계속 쌓이게 됩니다.
또한 라벨은 개별 항목으로만 존재했기 때문에
이를 삭제하거나 정리할 때 어떤 작업에 어떤 영향을 미칠지 가늠하기 어려웠습니다.
이 구조에서는 라벨을 정리하는 행위 자체가 자연스럽게 뒤로 밀릴 수밖에 없었습니다.
5/ 그래서 '정리할 수 있는 흐름'을 설계했습니다
문제 정의를 바탕으로
해결책을 기능 목록이 아니라 문제에서 출발해 다시 정리했습니다.
1) 라벨이 쌓이기 전에 점검하려면
→ 라벨을 한 곳에서 바라볼 수 있어야 합니다.
작업 입력 과정이 아니라 라벨 자체를 관리하고 점검할 수 있는 전용 공간을 만들었습니다. 라벨을 기준으로 대화를 시작할 수 있도록 하기 위함입니다.
2) 라벨을 정리하는 것이 부담스럽지 않으려면
→ 영향 범위를 먼저 알 수 있어야 합니다.
라벨을 삭제하거나 병합할 때 어떤 작업에 사용되고 있는지 바로 확인할 수 있도록 설계했습니다. 정리가 '위험한 선택'이 되지 않도록 하기 위함입니다.
3) 각자의 언어가 아니라 팀의 언어가 되려면
→ 라벨을 묶고 정리할 수 있어야 합니다.
비슷한 의미의 라벨을 그룹화할 수 있도록 설계해 팀이 사용하는 기준을 점차 하나로 맞춰갈 수 있도록 했습니다.
6/ 문제를 대하는 뤼이도의 기준
이 글은 라벨 관리 기능을 소개하기 위한 글이 아닙니다.
프로젝트가 지연되는 원인을 어디에서 문제로 정의했고, 그 문제를 어떻게 UX 구조로 풀어냈는지를 보여주고자 했습니다.
뤼이도는 사용자의 프로젝트가 지연되지 않도록
눈에 잘 보이는 불편보다 그 불편이 반복되는 구조에 더 집중합니다.
라벨처럼 작아보이는 요소도
작업의 기준이 되고, 팀의 언어가 되며, 결국 프로젝트의 속도에 영향을 준다고 믿기 때문입니다.
그래서 우리는 현상을 빠르게 고치기보다
왜 이런 현상이 계속 만들어지고 있는지를 먼저 정의합니다.
그리고 사용자가 의식하지 않아도 자연스럽게 정리할 수 있는 흐름을 설계합니다.
이 글은 그렇게 문제를 바라보고 풀어가는 뤼이도의 한 장면입니다.
Riido Product Designer 김채원