설명 대신 행동을 보고 가장 위험한 가정을 검증하는 법
프로토타입이 만들었으면 실제로 사용하게 해 본다. 다만 테스트는 "마음에 드나요?"를 묻는 만족도 조사가 아니다. 목표 사용자가 현실적인 과업을 수행할 때 어디에서 이해하고, 멈추고, 잘못 선택하고, 회복하는지 관찰하는 자리다.
그래서 과업을 줄 때 버튼 이름을 알려 주지 않는다. "예약 버튼을 눌러 보세요"가 아니라 "내일 오후 팀 회의를 위해 네 명이 쓸 공간을 찾아 예약해 보세요"라고 말한다. 목표와 맥락을 주고, 길은 사용자가 찾게 하는 것이다.
디스쿨은 테스트에 필요한 것을 '장면, 도구, 역할(Scenes, Props, Roles)'로 나누어 준비한다. 사용자가 원래 이 해법을 만날 장소와 상황은 무엇인지, 경험을 성립시키는 데 꼭 필요한 화면이나 물건은 무엇인지, 마지막으로 테스트의 진행자와 관찰자와 기록자는 누가 맡을지를 미리 정하는 것이다. 테스트를 진행하는 장소와 상황도 실제 사용하게 되는 상황을 염두할 수 있어야 한다. 맥락이 달라지면 사용자의 주의와 판단도 달라지기 때문이다.
앞서 살펴본 지식의 저주는 만든 것을 시험할 때도 나타난다. 만든 사람에게 당연한 화면의 구조와 사용 순서가 처음 보는 사람에게도 분명하리라는 보장은 없다. 그래서 실제로 사용하게 하고, 어디에서 막히는지 확인해야 한다.
만든 사람이 저지르기 쉬운 실수는 설명이다. "이건 이렇게 쓰는 거예요"라고 안내하는 순간 테스트는 시연이 된다. 실제 사용 환경에서는 옆에서 설명해 줄 사람이 없는 경우가 많다. 과업을 수행하는 동안은 설명을 멈추고 지켜본다. 참여자가 멈추면 정답을 가르치는 대신 "지금 무엇을 생각하고 계신가요?"라고 묻는다. 도움을 줬다면 언제 어떤 도움을 줬는지 기록한다. 그 도움이 없었다면 사용자는 스스로 통과하지 못했다는 뜻이기 때문이다. 과업이 끝난 뒤에는 필요한 배경을 설명하고 의견을 들을 수 있다.
기록할 때는 사실과 해석을 나눈다. '사용자가 답답해했다'는 해석이고, '같은 버튼을 세 번 누른 뒤 8초간 화면을 보았다'는 관찰이다. 초기 테스트에서는 적은 수의 참여자에게서 같은 문제가 반복되어도 다음에 무엇을 고칠지 단서를 얻을 수 있다. 다만 적은 참여자에게서 나온 성공률이나 평균을 전체 사용자에게 일반화해서는 안 된다.
커머스 분석가는 문제 정의와 아이디어 단계를 거쳐 필요한 대시보드를 스케치했다. 그 화면에는 아직 확인하지 않은 생각이 담겨 있었다. 온라인팀의 성과를 설명할 지표가 적절한가. 대상 매장과 비교 매장을 고르는 데 필요한 정보가 충분한가. 화면을 본 사람이 비교의 의미를 이해하고 다음 행동을 고를 수 있는가.
분석가는 스케치를 실제 판단 과업을 수행할 수 있는 프로토타입으로 다듬었다. 기존 매장 데이터로 후보를 비교할 수 있게 하고, 아직 수집되지 않은 운영 결과에는 가상의 수치를 넣어 예시임을 표시했다. 이렇게 만든 화면을 온라인팀 일부 구성원에게 건넸다. 기능을 하나씩 설명하는 대신, 평소 업무에서 다루던 질문에 화면을 보며 답해 보도록 했다. 가상 수치가 들어간 부분에서는 실제 결정을 내리기보다 결과를 해석하고 다음 행동을 논의할 수 있는지 살폈다.
분석가는 구성원들이 화면을 사용하는 모습을 관찰했다. 어떤 지표를 먼저 확인하는지, 여러 매장과 기간을 비교할 때 화면을 어떻게 해석하는지, 판단을 위해 어떤 정보를 다시 요구하는지 보았다. 화면이 보기 좋다는 반응보다, 그 화면으로 업무의 질문에 답을 찾을 수 있는지가 중요했다.
직접 사용하는 모습을 보니 만들 때 놓쳤던 부분이 드러났다. 일부 지표 이름은 온라인팀 실무자 관점으로 다르게 해석될 여지가 있었고, 비교 기간을 서로 다르게 이해하는 경우도 있었다. 전체 수치를 확인한 뒤 특정 매장의 상황을 더 살펴보려다가 흐름이 끊기기도 했다. 분석가는 그때마다 사용법을 설명해 넘기기보다, 어디에서 왜 막혔는지 기록했다.
관찰은 부족한 부분을 찾는 데서 끝나지 않았다. 구성원들은 전체 흐름을 본 뒤 차이가 큰 매장을 찾고, 그 이유를 확인하며 다음에 살펴볼 대상을 논의했다. 그 순서를 따라가자 화면을 더 유용하게 구성할 방법도 떠올랐다. 전체 현황에서 매장별 상세 정보로 자연스럽게 이어지도록 하고, 비교에 필요한 기준을 수치 가까이에 두면 질문의 흐름을 덜 끊을 수 있었다.
떠오른 아이디어를 모두 구현하지는 않았다. 중요도 순위를 정하고, 판단을 막거나 오해를 만드는 부분부터 고쳤다. 지표의 이름과 비교 기준을 명확하게 하고, 자주 오가는 화면 사이의 이동을 줄였다. 새로운 기능 제안은 본래 정의한 문제를 푸는 데 필요한지 살펴 이번에 반영할 것과 뒤로 미룰 것을 나눴다. 수정한 화면은 다시 구성원들에게 건네 같은 지점에서 막히는지 확인했다.
이후 데이터가 늘어나고, 지표가 의도한 기준으로 집계되며, 다른 시스템에서 조회하는 수치와 차이는 없는지 확인했다. 검증이 완료된 대시보드는 온라인팀 전체 미팅에서도 사용되기 시작했다. 구성원들은 같은 화면을 보며 매장별 차이를 짚고, 추가로 확인할 이유를 묻고, 다음에 무엇을 할지 논의했다. 분석가가 화면을 설명하는 시간이 줄고, 구성원들이 화면을 근거로 서로 질문하는 시간이 늘었다.
테스트가 끝나면 발견을 다음 판단에 반영해야 한다. 피드백만 수집하고 유지할지 바꿀지 판단하지 않는 테스트는 요식 행위다. 다만 발견된 모든 문제를 고치지는 않는다. 과업을 실패하게 만들었는지, 얼마나 자주 나타났는지, 사용자가 스스로 회복할 수 있는지, 사용자와 조직에 어떤 영향을 주는지 살펴 우선순위를 정한다.
반응을 놓치지 않는 간단한 방법으로 디스쿨은 '피드백 기록표(Feedback Capture Matrix)'를 제안한다. 반응을 좋았던 점, 바라는 변화, 생긴 질문, 새로 떠오른 아이디어의 네 갈래로 나누어 적는 것이다. 다만 여기에 사용자의 말만 적으면 다시 만족도 조사로 돌아간다. 각 반응 옆에 실제로 관찰한 행동과 그때의 맥락을 함께 남겨야 한다.
개선은 흔적을 남겨야 한다. 최종 화면만 보면 무엇이 달라졌는지 알기 어렵다. 테스트에서 관찰된 행동, 해석한 원인, 변경한 요소, 기대하는 결과를 연결해 기록한다. "우리는 이렇게 관찰했고, 이렇게 해석했고, 이렇게 바꿨고, 이렇게 확인했다"는 기록은 다음 판단의 근거이자 나중에 3부에서 다룰 설득의 재료가 된다.
이 기록은 이전의 판단이 지금도 유효한지 다시 물을 근거이기도 하다. 한 번 닫은 답도 환경과 사용 방식이 달라지면 다시 열어야 하기 때문이다.
답이 없는 문제를 해결하는 과정도 이러한 맥락과 크게 연관되어 있다. 질문이 멈추는 순간, 답이 없는 문제를 해결하는 사고도 멈추게 되는 것이다.
상업용 부동산 대시보드의 첫 지도 화면은 사용자의 생각을 넓혔고, 목적에 맞는 기능으로 다듬어져 실제 운영에 들어갔다. 당시의 문제에 대한 해법으로는 성공했다.
하지만 나는 이 대시보드를 결국 실패한 사례로 기억한다. 한 팀만을 위한 화면을 만들지 말고 더 많은 사용자를 위한 기능을 넣자는 방향이 더해지면서 처음의 분명했던 목적이 흐려졌다. 데이터는 시간이 지나며 낡았고, 같은 일을 더 효과적으로 수행하는 새로운 화면도 나타났다. 대시보드는 여전히 운영되고 있지만 매달 찾는 사람은 손에 꼽혔다.
초기의 프로토타입과 사용자 소통은 제 역할을 했다. 당시의 요구를 시각의 언어로 번역했고, 가능성을 넓혔으며, 목적에 맞는 기능으로 좁혀 실제로 구현했다. 문제는 범위를 넓히고 데이터와 사용 환경이 달라진 뒤에도 처음의 답을 다시 묻지 않은 데 있었다. 한 번의 테스트와 결정은 한 시점의 답을 만들 수 있지만 그 답을 영원히 유효하게 만들지는 못한다.
해결의 다이아몬드를 닫는다는 것은 완전한 정답을 확정한다는 뜻이 아니다. 현재의 근거로 다음 행동을 정하고, 그 결과를 관찰할 수 있는 상태를 만든다는 뜻이다. 환경이 달라지고 가정이 깨지면 닫힌 다이아몬드는 다시 열린다. 2장에서 보았듯 대시보드의 수명은 그것을 낳은 질문의 수명과 연결되어 있다.
지금까지 답이 없는 문제를 해결하는 방법으로 디자인 사고를 제시했다. 사람의 경험에서 문제를 찾고, 여러 해법을 펼치고, 생각을 형태로 꺼내 시험하며 현재의 답을 고르는 과정이었다. 디자인 프로젝트에만 쓰이는 절차가 아니라, 내가 실제 조직에서 문제를 풀어온 방식을 설명하는 사고의 구조이기도 했다.
답은 문제보다 먼저 존재하지 않는다. 그리고 우리가 풀어야 할 문제는 결국 우리의 문제, 더 정확히는 그 문제를 겪고 결과와 함께 살아갈 사람의 문제다. 그들의 상황과 맥락을 이해해야 무엇이 필요한지 정의할 수 있고, 그 필요에 맞는 해법을 준비할 수 있다.
이 과정은 공식을 대입해 정답을 얻는 수학 문제와 다르다. 비즈니스에서 답이 없는 문제에 내놓을 수 있는 답은 오히려 이런 문장에 가깝다.
우리는 당신의 이야기를 들었습니다(공감).
이 어려움을 함께 풀어야 할 문제로 정의했습니다(문제 정의).
이를 해결하기 위해 이런 답을 준비해 보았습니다(아이디어와 프로토타입).
이제 실제로 도움이 되는지 함께 시험하겠습니다(테스트).
이후에는 제한된 시간과 비용 안에서 얻은 근거로 결과물을 다듬는다. 이렇게 사용자의 문제를 실제로 해결하는 답에 가까워지는 과정이, 내가 말하는 '답이 없는 문제에 답을 준비하는 법'이다.
하지만 오늘날 이 과정에 참여하는 것은 사람만이 아니다. 생성형 AI도 아이디어를 펼치고 문제를 정리하며, 형태를 만들고 여러 판단을 비교하는 일을 돕고 있다.
AI는 답이 없는 문제를 해결하는 사고에 어디에서, 어떻게 참여할 수 있을까. 다음 장에서는 그 질문을 다룬다.