니들이 설문의 구조 Structure를 알어?
UX는 고객 중심의 문제해결이 핵심입니다. 그러다 보면 시장조사와 더불어 유저 테스트 User Test가 자연스럽게 따라오게 돼버리곤 합니다만... 글쎄요?
저는 대부분의 경우에 UX포폴에서 유저 테스트가 꼭 들어가냐에 대해서는 약간은 회의적이긴 합니다. 이유는 두 가지입니다.
1. 주니어 레벨에서 수행할 수 있는 유저 테스트는 기대 수준이 낮기에 큰 의미가 없다.
2. 시니어 레벨에서는 이런 유저 테스트 결과는 업무 비밀유지 조항에 위배될 가능성이 높아 포폴에 직접적으로 수록하기 힘들다.
두 개를 제외하고 생각하면... '그럼 유저 테스트가 들어갈 수 있는 경우는 뭐가 있을까요?'라고 생각하면 거의 없지 않을까요?
먼저 설명이 쉬운 2번부터 자세히 설명을 드리면,
신입/주니어가 아닌 시니어 수준에서의 포폴이라면 이직을 전제로 하여 제작할 경우가 매우 높습니다. 직장 경험이 없는 시니어는 말이 안 되잖아요?
그렇다는 건 현재 제작 중인 포폴은 재직 중인 회사의 업무 내용을 담고 있을 가능성이 높으며, 이 업무에 대해서는 대외 공개 가능한 수준(결과물)에서만 포폴에 담는 게 허용됩니다. 유저 테스트 결과와 같은 시장 반응 분석 같은 자료는, 실제 우리 서비스에 대한 시장의 수렴도를 적나라하게 드러나게 해 주므로 강한 보안자료로 취급될 가능성이 높습니다.
그러니 당연히 유저 테스트 결과는 포폴에 들어갈 가능성이 매우 낮죠.
그럼 역으로 '신입/주니어 레벨에서는 가능하지 않겠어요?'라고 생각할 수도 있겠죠.
현재 재직 중인 회사의 업무가 아닌 순수 내 창작물이 포폴의 주가 되는 이 급에서는 충분히 가능한 발상입니다만, 애석하게도 여기도 함정이 있습니다.
유저 테스트는 일종의 설문조사와도 같습니다.
대개의 조사는 조사자가 검증하려는 내용을 문항에 얼마나 정교하게 설계해서 넣느냐에 따라 써먹을 수 있는 인사이트가 뽑히느냐(증명되느냐)로 그 가치가 판이하게 달라질 수 있습니다.
그렇다는 건 얼마나 의도적으로 유저 테스트를 설계하고 그 의도에 부합하는 결과물을 검증해서 가설을 확인하고 인사이트를 도출하느냐가 관건인 것인데.. 대개 주니어의 레벨에서는 이 설문의 기본 골조가 되는 가설 자체의 수립을 굉장히 어려워합니다. 또는 굉장히 어설프게 하곤 합니다.
그러니 결국엔 설문은 허공을 맴돌듯, 수박 겉핥듯 문항은 존재하지만 결과를 통해 정량적인 뭔가를 뽑아내어도 그게 뭘 의미하는지도 모르는 의미 없는 설문이 되는 경우가 많습니다. 그럼 평가관은 그걸 보고 무슨 생각을 할까요?
음 열심히는 했네,
근데 어쩌란 거지?
대체로 이 프레임을 벗어나는 경우는 매우 드뭅니다. 그렇기에 전 컨설팅을 해주다가 데스크 리서치에서 어느 정도 방향성이 뽑히는 친구들에게는 그 방향성을 확인(검증)하는 형태로 설문을 권해보기도 합니다만 대체로 주니어 레벨에서는 이 방향성을 다듬는 것조차도 버거워하기에 굳이 유저 테스트를 권하지는 않습니다.
UX의 방법론은 사용자를 이해하고 이들이 겪는 문제를 해결하기 위한 말 그대로 방법일 뿐이지, 이 방법론 자체가 결과일 수는 없습니다. 그렇기에 유저 테스트? 포폴에 꼭 들어갈 필요는 없습니다. 차라리 여기에 들일 시간이 있다면 리서치를 통해 이미 나와있는 데이터들을 좀 더 면밀히 분석해서 프로젝트의 논리적 근거를 만들어 가는 걸 권하고 싶습니다.