문제 해결보다 중요한 것, 문제의 선택
문제 우선순위 워크샵을 통해 개선 방향 찾기
프로덕트(서비스)는 끊임없는 개선을 통해 사용자에게 선택받기 위한 노력을 기울여야 합니다. 개선은 단순히 '문제'를 고친다에서 끝나지 않습니다. B2C에서는 고객 니즈를 반영하는 개선이 될 수 있고, B2B에서는 고객사의 요구사항을 충족시키야 하는 경우도 있습니다.
또한, 천천히 대응해도 되는 문제, 즉시 고쳐야하는 문제, 그리고 단순히 개선하면 좋을 것들까지 고려하면 '개선'의 고려사항은 끝이 없습니다. 이렇게 많은 고려사항 중 무엇을 먼저 들여다 보아야할지 결정하기 쉽지 않습니다. 왜냐하면 '중요도' 라는 것은 그때그때 바뀌기 마련이니까요.
그렇다고 중요도를 판단하기 어려워 개선이 지연되고 프로덕트의 변화가 늦다면, 경쟁력을 잃고 사용자에게서 잊혀질 가능성이 높아집니다.
그래서 우리는 적당한 타이밍을 찾아 개선의 목표를 정하고 나아가야 합니다. 그 길을 찾는 가장 효과적인 방법은 데이터에서 찾는 것입니다. 무엇을 개선해야 할지 선택하기 어려운 때, 제가 길을 찾는데 도움이 되었던 문제 우선순위 워크샵을 소개해보겠습니다.
데이터를 어디서 수집할까
프로덕트 개선을 위한 데이터는 크게 내부와 외부로 나누어 수집할 수 있습니다. 물론 이러한 분류가 너무 추상적이고 다양한 데이터의 범주를 모두 포괄할 수는 없지만, 대략 '이렇게 구분할 수 있다'로 참고해주세요.
조직 내부에서 수집한 데이터 (내부)
- 데스크 리서치, 경쟁사 조사, 휴리스틱 평가, 사내 테스트, QC 결과, 기능별 사용량 로그 등
실제 사용자 접점에서 수집한 데이터 (외부)
- 고객 인터뷰, 사용성 테스트, 데모 피드백, VOC, 현장 관찰 등
좋은 데이터는 고객에게서 직접 얻는 것만이 의미있다 생각하게 될 수도 있습니다. 그러나 외부에서 수집한 고객의 목소리만큼이나, 내부에서 수집할 수 있는 데이터도 중요합니다. 대표적으로 경쟁 서비스를 뜯어보는 일은 업계 표준을 파악하고, 우리가 제공하는 고유한 가치와 차별점을 확인하는 데 큰 도움이 됩니다. 또한, 기능적 오류를 발견할 수 있는 QC에서 수집하는 데이터와 사용성 전문가인 디자이너들이 자체적으로 실시하는 휴리스틱 평가도 도움이 됩니다. 이는 프로덕트를 전문적으로 다루는 디자이너, 개발자라는 전문가 집단 관점에서 상세하게 들여다보며 분석하는 결과 데이터이기 때문에 분석의 결과로 해석할 수 있기 때문입니다.
현장 관찰이나 인터뷰와 같은 외부에서 수집하는 데이터도 물론 중요합니다. 현장에서 사용자가 어떤 환경(예: 모니터 개수, 병행 사용 중인 다른 도구)에서 제품을 사용하는지 알 수 있게 해주며, 그들의 업무 프로세스와 관습, 바라는 점 등 실제 현장의 데이터는 직접 가보지 않는 이상 확인하기 힘든 데이터 입니다.
저는 사용자 리서치의 일환으로 데스크 리서치를 통해 의사들의 업무 플로우에 대한 자료를 엄청나게 수집하고 학습하여 표준 Workflow를 작성하였던 적이 있습니다. 그리고 검증을 위해 실제 현장에 방문하였을 때 이 Flow의 많은 부분이 틀렸다는 것을 알게 되었습니다. 현장에서의 업무는 예상하던 것보다 더 다양하게 바뀌고 있었습니다. 그렇다고 사용자 이해의 기반이 되는 데스크 리서치가 도움이 되지 않은 것은 아닙니다. 기반자료가 없었다면, 현장 방문 시 얻을 수 있는 지식의 수준이 낮아졌을 것입니다. 1차 Workflow 작성이 있었기 때문에 나의 생각과 다른점을 중심으로 빠르게 현장의 특이점을 발견해 나갈 수 있었죠.
따라서 내부와 외부 데이터를 병행 수집하는 것은 필수이며, 양쪽 모두 제품 개선에 중요한 인사이트를 제공하기 때문에 어떤 데이터를 어떻게 수집할지에 대한 계획을 사전에 꼼꼼히 세우는 것이 중요합니다. 그리고 수집한 데이터를 활용하기 좋게 저장하고 가공하는 것도 중요한 일입니다. 데이터는 사용하기 위해 모으는 것이니까요.
데이터를 어떻게 정리할까
데이터는 1차로 가능한 한 풍부하게 수집하는 것이 중요합니다. 다양한 출처에서 최대한 많은 피드백과 관찰 내용을 확보하고, 상세하게 기록하는 것이 좋습니다. 수집한 데이터에 대해 언제, 어디서, 어떻게 등 여러 관점에 대한 기록의 형태로 진행할 수도 있고, 수치 데이터라면 그 데이터가 어떠한 동작에 의해 수집되었는지, 기간이 어떠한지 등을 함께 정리해 두는 것이 좋습니다. 이는 이후 해석의 단계에서 어떻게 해석할지 모르기 때문에 많은 로우데이터를 보관하여 활용도를 높이기 위한 방법입니다.
그리고 수집 단계에서부터 완전한 정리를 시도하면 과도한 리소스가 들 수 있기 때문에, 이 시점에서는 정리보다는 '충분하고 구체적인 기록'에 집중하는 것이 효과적입니다. 물론 데이터를 수집하고 해석하는 전문가가 있는 조직이라면 제대로 된 데이터를 종류별로 활용하기 좋게 보관할 수 있겠지만, 리소스가 제한된 환경에서는 데이터 수집에서 현재 리소스 수준에서 할 수 있는 범위를 확실하게 인지하고 시작하는 것이 바람직합니다.
1차 수집 형태에 따른 저장 방식 예시
- QC 로그: 발견한 문제를 백로그(Task 관리 툴)에 저장
- 인터뷰 결과: 인터뷰이 정보와 함께 엑셀 기록
- Maze 테스트: 사용성 평가 결과 플랫폼 내 결과 페이지 확인
- 현장 관찰: 방문장소와 시간 흐름에 따른 관찰 포인트, 업무 환경 등 문서에 기록
빠른 문제 해결이 목적일 때는 이 수준의 정보로도 충분이 활용 가능합니다. 직관적이고 급한 문제가 발견되면 우선 개선하면 됩니다. 그러나 전체 데이터 속에서 흐름을 발견하고 우선순위를 정하기 위해선 추가적인 해석과 분류 작업이 필요합니다.
정성 데이터 해석 예시
- “방금 파일을 업로드 했는데 뭐였더라?, 저거였던거 같은데..” → 업로드한 파일의 시인성 부족
- “빠른 느낌이 드는 화면이네요.” → 화면 전환 속도나 인터랙션 응답성에 대한 긍정적인 체감
정량 데이터 해석 예시
- 3월 AI 분석 시도 200건 → 4월 100건 → AI 사용량 50% 감소
- 진단서 발급 3월 1,000건 → 4월 1,200건 → 20% 증가
정제 과정을 통해 수집한 문장 단위의 인사이트들은 하나의 매체에 모아 저장해두는 것이 좋습니다. 정제된 자료는 여러 방향으로 이용할 수 있기 때문에 Excel과 같이 데이터를 쉽게 읽고 수정할 수 있는 곳에 기록해 두는 것이 좋습니다.
이는 해석의 한 방향으로 GPT를 통한 해석이나, FigJam을 활용한 워크샵을 진행할 때 활용성이 높아지기 때문입니다.
모든 데이터의 정리 과정을 마치면 정제된 데이터 덩어리들이 준비됩니다. 그럼 이제 데이터 속에서 흐름을 찾을 시간입니다.
어피니티 다이어그램으로 문제 묶기
정제된 문장들을 기반으로 어피니티 다이어그램을 만들면, 문제 영역 간의 연관성이 보이기 시작합니다. 이 과정에서 묶는 그룹의 단위에 그룹의 추상화된 명제를 명명합니다. 이 과정을 거치면 여러개의 작은 그룹이 생기고, 이를 다시 큰 묶음으로 묶어 의미를 만들어 낼 수 있습니다.
“AI 버튼이 안 보여요” + “AI 분석 시작 위치를 모르겠어요” → AI 관련 문제 그룹
단순히 문제의 개수가 많다고 해서 그게 우선순위 1순위라는 의미는 아닙니다. 예를 들어 실제 사용자가 거의 없는 기능에서 문제가 집중된다면 해당 플로우를 과감히 제거하는 것도 전략이 될 수 있습니다.
적당한 개수로 그룹이 묶이게 되면, 크기와 다른 그룹간의 연관성에 대한 해석을 실시합니다. 아예 연관성이 없을 수도 밀접한 연관이 있을 수 있습니다. 그러한 관계에서 발생하는 특이성 또한 중요한 관찰점이기 때문에 꼭 기록을 해두어야 합니다.
그룹 A : 로그인 후 온보딩 문제
그룹 B : AI 기능의 시인성 문제
→ 시작이 불분명해서 핵심 기능(AI)까지 도달하지 못함
어피니티 다이어그램을 진행할 때 문제들만 모아 진행하는 방법 외에도 SWOT 분석이나 다양한 서비스 디자인 기법들과 함께 활용하면 더욱 유의미한 전략 도구가 됩니다. 다만 분석의 깊이는 팀의 리소스와 상황에 따라 유연하게 조정하는 것이 중요하며, 현실적인 수준에서의 적용을 권장드립니다.
이 과정을 거치면 몇 개의 그룹과 관계성이 정리됩니다. 브레인스토밍 단계에서의 아이디어 회의는 이러한 큰 그림의 발견으로도 충분히 가치가 있습니다. 그러나 생존이 걸려있는 스타트업의 제품은 한 단계 더 나아간 해석이 필요합니다.
중요한 건 우리 서비스의 생존에 가장 영향을 끼치는 문제는 무엇인가입니다. 그리고 그 판단의 기준은 결국 비즈니스 전략에서 나와야 합니다. 묶인 그룹들의 크기와 관계에 더해 우리 조직이 속한 비즈니스 상황과 사용자의 니즈 관점에서 각 그룹이 어떠한 중요도를 갖는지를 다시 한번 생각해야 합니다.
비즈니스 팀과 함께한 우선순위 정렬 워크샵
개선을 위한 방향 설정은 단순히 제품 관점에서만 이뤄질 수 없습니다. 사용성 문제뿐 아니라, 실제 고객 접점에서 어떤 문제들이 반복적으로 제기되는지를 근거로 삼아야 합니다. 특히 스타트업 환경에서는 '좋은 제품'보다 '가치를 만드는 제품'이 중요하고, 이 가치를 정의하고 우선순위를 함께 정하기 위해서는 비즈니스팀과의 협력이 필수적이라 보았습니다.
그래서 저는 제품을 넘어 비즈니스의 관점까지 아우를 수 있는 판단 기준이 필요하다고 보고, 비즈니스팀과 함께 우선순위 워크샵을 기획하고 실행하였습니다. 아래는 제가 진행하였던 워크샵의 구성입니다.
워크샵 구성
1. 1차 데이터 정제
다양한 방법을 통해 모은 모든 문제를 같은 수준의 문장 구조로 정리
2. 어피니티 다이어그램 작성
관련 문제들을 그룹핑 (최대 7개 그룹).
이는 인지적 부담을 최소화하기 위한 전략으로, 인간의 단기 기억이 처리할 수 있는 항목 수는 평균 7±2개라는 '밀러의 법칙(Miller's Law)'에 기반하여 정하였습니다.
3. 중요도 평가 (1차)
리커트 척도(예: 보통 ~ 매우 중요)를 사용하여 중요도를 평가하였습니다. 문제의 상대적 중요도를 판단하기 위한 도구로, 모든 문제를 다룰 수 없기에 가장 주목해야 할 영역을 선별하는 데 중점을 두었습니다.
이 외에도, 구성원당 3표씩 자유롭게 선택하는 투표 방식 등, 정량적 비교가 가능한 다양한 평가 방법을 활용할 수 있습니다.
4. 중요도 조정 (2차)
1차 평가 결과에 대해 팀원들이 반론을 제기하고 토론을 거치며, 비즈니스 관점과 기술적 제약, 사용자 가치 등을 종합적으로 고려해 최종 우선순위를 확정하는 단계입니다. 단순한 점수 합산이 아닌, 맥락과 전략적 타당성까지 반영해 결정을 내리는 것이 중요합니다. 중요도 평가 단계에서 주어진 점수에 대해 조정이 필요하다면 추가 점수를 부여하거나 빼는 등 조정 작업을 통해 최종 중요도를 산정합니다.
실제 효과
1. 워크샵 결과 '파일 관리 기능'이 최우선 문제로 선정되면서 리소스를 집중할 수 있었고,
2. 우선순위 기준이 명확해진 덕분에 일정 수립과 리소스 운영의 효율성이 눈에 띄게 개선되었습니다.
3. 또한 비즈니스팀과 사전에 합의된 기준 덕분에 협업 과정에서의 커뮤니케이션 비용도 자연스럽게 줄어들었습니다.
가장 중요한 점은 반복되던 우선순위 혼란이 줄어들었다는 것이었습니다. 우리가 당장 집중할 목표가 정해지면서, 들어오는 작은 의견들은 우리가 현재 세웠던 중요도와 저울질하여 우선순위를 평가하게 되었습니다. 기준점이 생기게 된 것이었습니다. 그래서 갈팡질팡 하지 않고 우선 목표를 향할 수 있었고, 개선해야하는 바도 뚜렸해 졌습니다.
이러한 개선은 논의보다 실행에 집중할 수 있는 환경에 도움이 되었습니다. 갈팡질팡하는 환경에서는 '이걸 왜 해야하지?'와 같은 의문이 자주 발생하고 질문도 많이 하였습니다. 그러나 워크샵을 통해 근거가 되는 여러 데이터들이 이미 전달되었기 때문에 목표에 대해 명확히 이해하고 나아갈 수 있게 되었습니다.
또한, 다른 팀 구성원들도 우리가 이러한 목표를 향해 간다는 것을 이해하고 협력하여 리소스 낭비가 줄어들고 더욱 효과적인 업무 프로세스를 만들 수 있었고, 실제로 효율 상승이 체감된다는 피드백을 들을 수 있었습니다.
여기까지 제가 실제로 진행했던 우선순위 워크샵 경험을 조금 풀어서 공유하였습니다. 이 과정을 통해 비즈니스팀과 함께 파일 관리 문제를 발굴하고, 구체적인 개선 기획을 거쳐 실제 솔루션으로 이어질 수 있었습니다.
워크샵 이전까지는 모든 문제를 다 해결해야 한다는 압박 속에서 우선순위가 일 단위로 바뀌는 혼란이 있었습니다. 하지만 워크샵을 통해 “우리는 당분간 이 문제에 집중하겠다”는 팀의 합의와 선언을 만들 수 있었고, 그 근거를 철저히 데이터 기반으로 확보함으로써 누구도 쉽게 흔들 수 없는 기준점을 세울 수 있었습니다.
프로덕트를 만들어가는 입장에서 ‘무엇에 집중하느냐’는 개인의 성과에도 큰 영향을 줍니다. 방향이 명확해야 임팩트 있는 개선이 가능하고, 그 결과는 팀 전체에도 유의미한 성과로 돌아옵니다. 결국 이 과정은 우리 모두와 데이터가 중요하다고 판단한 문제를 중심으로 팀이 하나의 목표를 향해 나아가는 정렬의 경험이었습니다.
이 글이 유사한 고민을 가진 프로덕트 디자이너 분들께 실질적인 도움이 되기를 바랍니다. 긴 글 읽어주셔서 감사합니다.
