검증을 위한 디자인
초기 가설을 검증하기에 충분한 정도의 디자인
과연 이 프로덕트가 잘될까...?
제품을 이용하고 있는, 혹은 이용할 고객들을 위해 우리는 지속해서 새로운 프로덕트를 기획하고 개발을 해 나아간다. 핵심 사업에 대한 본원적인 경쟁력은 기본 중에 기본이다, 그러나 더 많은 고객을 얻기 위해서는 새로운 프로덕트를 통해 성장 동력을 발굴하는 노력도 기울여야 한다.
새로운 프로덕트를 만들때 프로덕트 디자이너는 고객들이 경험하고 사용할 디지털 제품을 만든다. 정말로 고객들의 문제점을 해결해 주어 그들이 원하는 제품을 만들기 위해서 다양한 가설들을 세운다. 그러나 어느곳이든 리소스(돈 & 직원)는 한정적이기 때문에 가설을 검증할 수 있는 기회는 많지 않다. 그렇기 때문에 우리는 최소한의 비용으로 가설을 검증하고 리소스 낭비를 최소한으로 줄여 목적을 달성할 확률을 높여야 한다.
고객들은 매일 가늠하기 어려울 정도로 방대한 양의 정보속에서 살아간다. 그들의 눈높이는 높아졌으며, 고객들의 변화를 미리 예측해서 제품을 성공시키는 것은 더 어려워졌다. 프로덕트를 만드는 입장에서는 과거보다 시장에서 성공적인 제품을 출시하는 것이 어려워졌다.
이러한 예측을 하기 힘들다면 우리는 MVP(Minimum Viable Product)를 빠르게 출시하여 사용자의 반응에 긴밀하고 보다 발빠르게 그들의 의견을 반응하여 사랑받는 제품으로 만들어야 한다. 거창한 계획을 세워서 조금씩 해나아가는 것이 아니라 시장과 고객들의 변화에서 배운 것들을 빠르게 적용해야한다. 잘못된 것을 알지만 돌이킬 수 없는 상황에 놓여 질질 이끌고 가서 실패하는 것을 방지해야 한다. 이것이 Lean 제품 개발의 본질이다.
검증을 하기 위해서 얼마나 해야하지 그럼...?
어떠한 디자인이 그러하듯 린 UX의 디자인의 핵심도 문제 해결에 관한 것이여야 한다. 문제를 잘 정의하고 어떻게 execute할지 결정했다면, 린 UX는 원하는 결과물에 도달하기까지 일을 될 수 있으면 최소화한다. 딱 가설 검증을 위해 필요한 정도만 디자인한다는 의미이다. 어차피 완벽한 제품을 만들기란 초 천재가 아닌 이상 어렵다.
그럼으로 우리는 초기검증을 위해 지금 시점에서 가장 중요한 디자인은 어떤것이며 시간을 허비시키는 것들은 무엇인지 구별하는 요령이 필요하다. 이 최소한의 기능만으로 사용자들에게 제품을 이용을 하게 하면서, 생각한 가설을 최대한 검증해야 한다. 그러나 여기서의 핵심은 제품의 기능이 아닌 가치의 검증에 집중이 되어야한다.
린 UX에서는 가설을 검증 할 수 있는 만큼만 디자인해야 한다. 그렇다고 대충 하라는 말은 아니다. 프로덕트 디자이너의 관점에서 제품과 디자인의 균형 잡힌 시각에서 조율을 잘 해야한다. 모든 작은 가설들을 다 증명을 하려기 보다는 통합적으로 고객들과 공감하고 문제의 본질을 해결해야 한다.
검증 도구
첫번째 도구: 제대로 문제 파악하기
어떤 디자인이든 해결한 문제를 정확히 파악하는 것이 가장 우선이다. 그러나 여기서 많은 함정들이 존재한다. 고객들과 이야기를 하다보면 문제가 아닌 해결책들에 대해서 말한다. 그들의 이야기를 듣고 해결 방법을 찾기 전에 고객의 관점에서 문제를 다시 정의하여 어떤 것들을 해야 하는지 생각해보아라.
리서치를 무조건 사용자에게만 해야 하는 것은 아니다. 스타트업이라면 더욱더 빠르게 회사 내 이해 관계자의 생각도 들어볼 수 있다. 조직 내 누군가는 나보다 문제를 더 잘 알 수 있기 때문이다. 그 누군가를 찾아 그 사람의 지식을 디자인 프로세스에 포함해보자. 그러나 명심할 점은 그들이 최종 디자인을 만들거나 사람들이 정확히 무엇을 원하는지 얘기해주는 건 아니다. 비즈니스에서 가져가야 할 중점적 부분과 사용자들의 유형, 맥락과, 니즈를 파악하며 두가지를 비교하여 중심을 잃지 말아야 한다.
두번째 도구: 테스트 우선 디자인하기
린 UX는 언제나 시작 전 목표를 측정할 방법을 강구해야 한다. 그렇지 않으면 디자인이 잘 작동하는지 알 수 없다. 반드시 측정 가능하면서 비즈니스 목표와 직접적으로 관련된 지표를 찾아야 한다.
세번째 도구: 팀이 함께 실현 가능한 해결책 찾기
우리가 해결할 문제를 제대로 이해하고 있는 최소한의 사람들을 모은 그룹이란 걸 명심하자. 문제를 제대로 파악하는 과정에서 이미 내부관계자들과 의견을 나누었으니 이제 해결책에 관해서 이야기를 해야한다. 그러나 우리는 확실한 해결방법이 있지는 않을 것 이다.
또한 그 문제에 대한 해결 방안은 수집 가지가 있을 것 이다. 그렇기 때문에 브레인스토밍하는 과정에서 회의를 길게 할 필요가 없다. 15분 이면 된다. 회의를 시작하기 전 사용자가 겪는 문제와 이를 해결해야하는 이유를 명확히 언급하여라. 성공 여부를 어떻게 측정할지에 대해서도 설명을 한다. 그런 다음 참석자 모두 한 두 문장으로 아이디어를 적는다. 참석자들에게 자신의 아이디어를 공유한다. 그 다음 그 아이디어들을 카테고리로 분류를 한다. 투표를 하는 것은 좋지 않다. 새로운 아이디어를 찾고자 진행하는 단계이기 때문이지 민주적인 방법으로 엉뚱한 실험을 하려고 모인 것이 아니기 때문이다.
네번째 도구: 타당한 접근방법 고르기
의사결정 회의를 하고 난 뒤 해결책들이 정말 명확하고 확실해보이지만, 대부분의 아이디어들로부터 사용자들을 확보하는 데는 실패한다. 디자이너는 이럴때 리소스 낭비의 방지를 할 수 있게 가설을 무효화할 수 있게 최소한으로 디자인을 해보자.
새로운 제품을 선보이기 전에 사용자가 잘 볼 수 있는 곳에 버튼을 넣고 클릭 수를 측정해보자. 버튼을 눌렀을 때에 친절한 메시지로 아직 기능이 준비 중이라고 띄우면 된다. 만약 아무도 누르지 않았다면 적어도 문제나 시장 상황을 제대로 파악할 때까지는 기능 전체를 구현할 필요가 없다는 좋은 신호이기 때문이다.
그럼이제 만들어 볼까...?
스케치하기
많은 사람들이 실수를 하는 부분이다. 왜냐하면 어떤 문제점이 있는 것 같다고 이야기를 하고 바로 스케치를 도입해보고 이곳에서부터 디자인 프로세스를 시작한다. 스케치를 시작하면 디테일에 집중하게 된다. 그러나 디테일에 집중하기 이전에 앞에 도구들을 사용한 뒤 시작점으로 해야한다.
스케치를 무작정 많은 시안들을 가져가기보단 초기 리서치에서 관찰된 문제를 가장 잘 해결 할 것으로 보이는 한두 개 안을 선택하는것이 낫다. 그리고 그것을 들고 4~5회 테스팅을 진행하여 문제가 없다면 진행, 어려움을 겪었다면 어떤 것들이 문제인지 좀 더 주의 깊게 관찰한 뒤 다시 시안을 만든다.
프로토타입 제작하기
올바른 사용자 검증 대상을 선별하여 "양질의 피드백을" 받기 위해 프로토타입을 테스팅하는 것은 중요하다. 흔히 잘못된 검증 방법은 잘못된 질문으로부터 생긴다. "혹시 이런 ~~기능이 마음에 드세요?"라고 물어보기보단 직접 사용하게 해보고 과정을 관찰하는 것이 더 중요하다. 그러나 사용자 검증은 우리 제품의 검사를 받는 것이 아니다. 현재에 대한 가능성과 함께 추후의 방향을 찾아갈 수 있는 인사이트를 얻어야 한다. 맞다 아니다기보단 "왜"라는 질문으로 발생하고 있는 문제에 대해 원인을 더 파고들어야 한다.
예전과 달리 현재는 좋은 프로토타입 툴이 많아서 뭘 사용할지에 대해서 고민을 할 정도니 알아서 좋은 것을 선택하자.
어디까지 이야기를 반영해야할까...?
프로토타입을 테스팅해보는 과정에서 사용자들이 하는 이야기들을 종합하여 솔루션을 수용하려는 경향이 있다. 내재된 문제를 파악하지 않고 말이다.
사용자가 "난 X기능을 원해요"라고 하면 왜 그 기능을 원하는지 알아보지도 않고 "사용자 X 기능을 원함"이라 적고 넘어간다. 리서치를 할때 사용자가 제품을 디자인하게 만드는 건 좋은 방법이 아니다. 그들 중 디자인과 관련된 업무를 하는 사람이 아니고선 디자인에 전혀 능숙하지 않다. 그들은 솔루션을 제시하지 진짜 문제점이 무엇인지에 대해서 그들도 모를 수 있다. 사용자들은 자신에게 꼭 필요한 것보다 친숙한 걸 요구하기 때문이다.
누군가 기능을 요청하면 왜 그 기능이 필요한지 물어보자. 꼭 물어보자 우리가 이미 그 답을 알고 있다 하여도.
마무리
린 UX는 리소스 낭비 방지를 위해 빨리 만들어서 시장에 내보내고 데이터를 측정한 다음 배운 것들을 토대로 다음 제품에 반영하는 방법이다. 만들기 - 측정 - 학습을 지속적으로 반복하는 것이다. 절대 완벽한 디자인은 없을 것이니 말이다. 학습은 여기서 가장 중요한 개념인데 기존의 것과 다르다면 과감하게 수정하는 능력이 있어야 한다.
또한 사용자와의 검증단계에서 그들이 그냥 이야기하다 떠오른 방법 대신 진짜 문제가 무엇인지 알아내고 가장 효율적인 방법으로 문제를 해결 해야한다.
참고 자료
https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux
https://www.justinmind.com/blog/lean-ux/
참고 문헌: UX FOR LEAN STARTUPS
