brunch

매거진 UX 넋두리

You can make anything
by writing

C.S.Lewis

by Ji Dec 11. 2021

UX Design & Lean Start-up

린하게 일해야하는 스타트업에서의 UX Design 프로세스를 고민해봤어요

저는 요즘 멋쟁이사자처럼에서 (도메인) 기획자로 성장하고 싶은 팀원분들을 대상으로 교육을 진행하고 있어요. 최근에는 사용자의 관점에서 논리적으로 문제를 정의할 수 있는 가장 효과적인 방법론이라고 생각하고 있는 UX Design Process에 대해서 이야기를 나눠봤어요(정확히는 UX Research를 중심으로 한 UX Design Process겠네요). 그런데 팀원분들과 이야기를 나누면서 브런치에도 생각의 기록을 남기고 싶은 부분이 생겨서 오랜만에 글을 한번 써보려 해요. 이번 글에서는 Lean Start-Up과 UX Design Process와의 관계성에 대해 이야기를 해볼게요. 


이미지 출처: http://www.rodrigocordero.org/en/how-to-apply-the-lean-startup-methodology/

이제 스타트업 업계에서는 상식의 영역으로 받아들여지고 있는 일 하는 방식이 바로 이 Lean Start-Up이에요. (린 스타트업에 대한 소개 및 설명들은 구글에서 검색만 해도 너무 많이 잘 나와있으니 자세한 개념에 대한 설명은 넘어가 볼게요). 린 스타트업에서 강조하는 프로세스는 Build - Measure - Learn이에요. 아이디어(가설)를 도출하고, 그 가설을 검증할 수 있는 최소 경험(MVP, Minimum Viable Product)을 만들고, 또 그 경험을 측정해서 정말 비즈니스에도 유의미한 임팩트를 가지고 왔는지를 검증하는 거죠. 그리고 계속 반복합니다. 저는 이 방법론은 최소한의 리소스를 기반으로 최대한 빨리 PMF(Product Market Fit)을 찾아야 하는 스타트업에서는 당연히 납득될 수밖에 없는 업무 방식이었다고 생각해요. 그래서 스타트업에서는 일하는 방식에 있어서의 상식이 되었다고 생각하고요. (물론, 모든 문제가 저렇게 린하게 해결될 수는 없을 때도 있어요. 하지만 적어도 최소한의 시장성과 고객 경험이 검증이 되지 않은 대부분의 스타트업에게 체계적이고 논리적이고 가성비가 높은 이 문제 해결 방식은 매우 높은 공감대를 이뤘다고는 생각해요). 게다가 가면 갈수록 급변하는 시장환경에서 비즈니스를 운영하기에는 린 스타트업 방식처럼 기민하고 유연성 있게 대응할 수 있는 방법론처럼 적합한 게 또 없겠다는 생각을 하기도 해요.  


그런데 말이에요, 린스타트업에서는 실행과 검증에 굉장히 높은 초점을 맞추고 있기에 상대적으로 가장 앞에 나오는 아이디어(가설)를 설계하는 데는 그렇게 많은 고민을 하지 않는 경향이 있어요. 빠르게 검증을 하는 것에 매몰되어서 애초에 어떤 것을 왜 검증해야 하는지에 대한 고민은 소홀해진다고 하는 건데... 개인적으로는 아이러니하더라고요. 그래서 저는 이번에 도메인 기획자분들을 교육하는 자리에서도 UX Research에 대한 이야기를 많이 나눴어요. 저는 UX Design Process의 시작은 UX Research이고, 유저에 대한 깊은 공감과 이해에서부터 시작할 때 그제야 제대로 된 문제정의가 된다고 생각하거든요. 


전통적으로 UX Design Process라고 하면 아래 그림처럼 Double Diamond 모델을 떠올리는 거 같아요. Discovery(Research), Define(Synthesis), Develop(Concepting), Deliver(Prototyping) 이렇게 총 네 단계로 구성이 되어있고요, 그중 첫 번째 다이아몬드(Discovery & Define)의 영역이 리서치부터 분석으로까지 가고 아이디어나 가설을 도출하기 전 문제를 정의하는 단계예요. 사실 저는 문제정의까지만 잘 되면 그 뒤에 나머지 영역들은 자연스럽게 이어진다고 생각하는 편이라 첫 단추(문제정의)만 잘 채워도 반은(어쩌면 그 이상) 성공이라고 생각하는 거 같아요. 문제정의가 잘 되었다고 하더라도 그 문제를 해결할 수 있는 아이디어는 정말 많이 있어요. 그런 아이디어들은 사실 직접 사용자들에게 보여주지 않고서는 검증을 할 수도 없다고 생각하고요. 그래서 문제정의가 잘 되었다는 전제하에 Lean 하게 그 문제를 해결할 수 있다고 생각하는 다양한 아이디어를 최소 단위로 도입해보고 검증해보면서 그렇게 PMF(Product Market Fit)을 찾아가는 거죠. 


이미지 출처: https://mgearon.com/ux/double-diamond-model/


스타트업에서 일하면서 느끼는 것은, Agile 하게 (Lean과 Agile은 조금 개념이 다릅니다) 프로덕트를 만들면서 병렬적으로 깊은 인사이트를 기반으로 문제를 정의하는 것은 정말 어려운 일이라고 생각해요 (제가 최근 만난 UX Researcher 분은 이제는 유저 리서치도 효율적으로 진행할 수 있는 방법들이 많아졌다고 하셔서 너무 궁금하긴 했지만요). 따라서 짧은 호흡에서도 지속적으로 인사이트를 주입해줄 수 있는 UX Researcher가 없는 조직과 환경에서 프로덕트를 만들고 있다면, 본격적으로 Agile 하게 프로덕트를 개발하고 또 린하게 서비스를 검증하는 과정을 진행하기 전에 앞서 문제정의를 함께하는 시간을 가져보기를 권해요. 그리고 그 문제 정의가 아직은 다소 모호하다거나, 문제는 정의된 것 같은데 아이디어가 쉽게 나오지 않는다거나, 아니면 동료들마다 문제정의가 아직 합의되지 않은 상황이라면 가볍게라도 UX Research를 고려해보시는 것도 추천해요. UX Research가 정확히 무엇인지 모르겠다면... 우선 내가 고민하는 문제에 대해 공감을 할만한 사람들을 만나서 그들의 경험들을 들어보고 이 사람들의 경험들을 관통하는 문제지점이 무엇인지를 고민하는 것으로 문제정의를 시작해 보시는 것을 추천해요. 


동료들과 열심히 달리다가 보면 '우리가 지금 제대로 된 문제를 해결하고 있는 것이 맞나'라는 생각이 들 때가 있어요. 아이디어(solution)에 너무 집중하다 보면 애초에 이 아이디어가 해결하려고 했던 문제(problem)가 무엇인지 모호해질 수도 있거든요. 아이디어가 점점 살이 붙으면 그럴 때도 있고, 아니면 애초에 문제에 대한 팀원들과의 공감대 형성이나 합의가 없이 시작하는 경우에는 또 그렇기도 하고요. 그럴 때 저 앞에 수집한 사용자들의 이야기들과, 그들의 이야기를 공감하면서 나왔던 문제정의가 지금 여러분들이 제대로 된 문제를 해결하고 있는 것이 맞는지에 대한 기준점을 삼아보셨으면 도움이 될 거예요. 그렇게 우리가 어떤 문제를 해결하고 있는지, 왜 이 문제를 해결하는지 고민하고 소통하는 사람이 어떤 포지션이 든 간에 그 팀에서 문제 해결의 구심점이 되는 solutionist가 되는 것 같아요. 


그런 사람이 여러분들이 되었으면 좋겠습니다 :) 



매거진의 이전글 데이터와 지표 이해하기
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari