디자인 씽킹 워크숍 후기와 실무 적용기

지난달에 2박 3일짜리 디자인 씽킹 워크숍에 다녀왔습니다.
회사에서 팀 전체가 참여할 수 있는 기회를 줘서 개발자, 디자이너, 기획자가 섞인 조로 배정받아 워크숍을 진행했어요.
평소엔 각자 업무 시간에 쫓겨 이런 프로세스를 제대로 밟아볼 기회가 없었는데, 이번엔 억지로라도 처음부터 끝까지 다 해보게 됐습니다.

 

첫날은 가상의 페르소나를 두고 인터뷰를 연습하는 시간이었는데, 저희 조는 시작부터 애를 먹었어요.
퍼실리테이터가 "왜 그렇게 생각하세요"를 다섯 번 연속으로 물어보라고 했는데, 세 번째 질문쯤 가서 다들 말이 막혔습니다.
평소 업무에서는 "이 기능이 필요합니다"라는 말을 들으면 바로 "그럼 이렇게 만들죠"로 넘어갔는데, 이 워크숍은 그 사이의 "왜"를 계속 파고들라고 요구했어요.
불편했지만, 동시에 저희가 평소에 얼마나 표면적인 요구사항만 듣고 넘어갔는지 깨닫는 시간이었습니다.

 

둘째 날 오전에는 인터뷰 내용을 바탕으로 "문제 정의문"을 하나로 합의해야 했는데, 저희 조 안에서 이 부분이 제일 오래 걸렸습니다.
개발자 출신 조원은 "기능이 부족하다"는 쪽으로 문제를 정의하려 했고, 저는 "사용자가 신뢰를 못 느낀다"는 쪽으로 보고 있었어요.
같은 인터뷰 자료를 보고도 직군에 따라 문제를 완전히 다르게 읽는다는 걸 그때 실감했습니다.
결국 퍼실리테이터의 조언대로 "누가, 어떤 상황에서, 무엇 때문에 어려움을 겪는가"라는 형식에 억지로 끼워 맞춰보니, 두 관점이 사실 같은 문제의 다른 층위였다는 걸 알게 됐어요.

 

문제 정의만 잘 되니 그 다음부터는 속도가 붙었습니다.
포스트잇에 아이디어를 최대한 많이 쏟아내고, 그중 투표로 세 개를 골라 종이 프로토타입을 만들었어요.
저희 조는 결국 "온보딩 중 신뢰를 주는 진행 상태 표시" 아이디어로 좁혔고, A4 용지 여러 장을 이어붙여서 화면 전환을 손으로 직접 만들어봤습니다.
다른 조원이 사용자 역할을 맡아 종이 프로토타입을 "사용"해보는 장면이 재미있었고, 그 과정에서 "이 버튼 다음에 뭐가 나올지 모르겠다"는 피드백이 바로 나와서 그 자리에서 프로토타입을 수정했어요.

 

워크숍이 끝나고 회사로 복귀해서 바로 진행 중이던 온보딩 개편 프로젝트에 이 프로세스를 축소해서 적용해봤습니다.
2박 3일짜리 워크숍을 그대로 가져올 수는 없어서, 반나절짜리 미니 버전으로 줄였어요.
인터뷰 대신 기존 CS 로그와 사용자 인터뷰 녹취록을 다시 훑으며 "왜"를 다섯 번 물어보는 연습을 팀원들과 같이 해봤고, 문제 정의문을 한 문장으로 합의하는 데 워크숍에서처럼 시간을 충분히 썼습니다.

효과는 확실히 있었어요.
예전 같으면 "온보딩 이탈률이 높으니 단계를 줄이자"로 바로 결론 냈을 텐데, 이번엔 "사용자가 진행 상태를 몰라서 불안해한다"는 조금 더 구체적인 문제로 좁혀졌고, 해결책도 단계를 줄이는 게 아니라 진행 상태 표시를 강화하는 쪽으로 방향이 바뀌었습니다.
결과적으로 단계 수는 그대로 두고 진행바만 추가했는데, 온보딩 완료율이 실험 전보다 6%포인트 올랐어요.

디자인 씽킹을 워크숍 안에서만 하는 특별한 이벤트로 여기지 않고, 평소 회의 안에 조금씩이라도 녹여내는 게 중요하다는 걸 이번 경험으로 배웠습니다.

다음 프로젝트에서는 아예 킥오프 회의 자체를 미니 워크숍 형태로 짜볼 계획이에요.