UI 사용성 평가, 쉽고 간편하게 하는 방법
린스타트업, 린 소프트웨어 개발 방법론에게!
최근 몇 년 새 린스타트업, 린 소프트웨어 개발 등 '린' 이야기를 많이 접하게 되었었다.
학교 다닐 때만 해도 린스타트업이라는 단어는 잘 알지도 못했고 린 제조라는 단어가 훨씬 친숙했었는데 이제는 오히려 린 제조라는 말이 더 어색하게 들릴 정도다. 하여간 린스타트업이란 단어는 린 제조라는 에서 유래가 된 것이며 Lean(군더더기 없는) + Startup(자신들의 가설을 증명해가는 단계의 조직) 이 합쳐진 말인데, 바로 이 린스타트업에서 사용하는 소프트웨어 개발 프로세스가 린 소프트웨어 개발 방법론이고 기존 전통적인 워터폴 방법론과는 큰 차이점을 보인다. 이 두 가지 방법론을 비교하자면 아래 그림과 같다.
워터폴과 린스타트업을 잘비교 설명하는 그림위 그림처럼, 워터폴 방법론 프로세스 에서는 바퀴, 차대, 카울 등의 단계를 차근차근 순차적으로 진행하여 완벽한 최종 제품 or 서비스인 자동차를 만들어 시장에 내놓는 방식이었고, 린스타트업의 프로세스는 보드, 킥보드, 자전거, 오토바이 등의 작은 단계마다 고객에게 가치를 제공할 수 있는 결과물로 시장에 내놓고 반응을 살펴가며 최종 결과물로 만들어가는 방식이라 할 수 있다. 기껏 자동차를 만들어 놨어도 팔리지 않으면 허사니까 작은 단계마다 시장을 즉시 접하고 파악하여 리스크를 줄이는데 목적이 있다.
린스타트업 프로세스를 들여다보면 위 그림처럼 Build, Learn, Measure 과정을 계속 끊임없이 반복하며 원을 그리게 되는데, 이렇게 수 많은 원을 그리며 점차 완벽한 원 (=완벽한 제품 or서비스)를 만들어 나가게 된다. 그래서 린스타트업 책의 표지도 수많은 원이 그려져 있는 것이다.
[린 스타트업 The Lean Startup] 책 표지이처럼 린스타트업 프로세스에서는 필연적으로 테스트 과정을 계속 반복하게 되는데, 어떻게 하면 이 테스트 과정에 투입되는 자원과 비용을 줄일 수 있을까? 이러한 질문의 좋은 해답이 [사용자를 생각하게 하지 마 Don't make me think]라는 책에 잘 설명되어 있어서 소개하고자 한다.
(소개할 내용은 BM을 검증하기에는 무리이며, 오직 UI의 사용성에 관한 부분이다.)
사용성 평가 소개
사용성 평가란?
사용성 평가란 한 사람이 어떤 물건을 가지고 일반적인 과제를 수행하는 과정을 지켜보는 것이다 대상은 웹사이트, 애플리케이션, 제품 프로토타입, 새 디자인을 담은 스케치 등이 될 수 있다. 그 과정에서 사용자가 혼란스럽다거나 답답하다는 느낌이 드는 지점을 찾아서 고치는 것이 사용성 평가의 목표다. FGI와의 큰 차이점은 그 물건에 대해 나누는 대화를 듣는데 그치는 것이 아닌 실제 사용하는 모습을 보는 것에 있다.
개인적으로 단 한 명을 하더라도 꼭 해야 한다고 생각하는데, 왜냐하면 만든 사람은 조금만 지나도 너무나 많은 것을 알고 있기 때문에 새로운 관점으로 볼 수 없게 된다 그럴 때 평가를 해보면 전혀 다르게 이용하는 사람들을 보며 새로운 시각이 열리게 된다.
소개하는 사용성 평가는 전통적인 평가 방법이 아닌 'DIY 평가’라는 이름으로 시간과 예산, 전문지식과 공간에 제약받지 않고 누구나 쉽고 간편하게 진행할 수 있다. 전통적 평가방법이 많은 자원을 투입하여 가능한 모든 문제를 찾기 위해서였다면 DIY 평가방법은 적은 자원으로 당장 개선할 문제를 찾기 위한 목적이다.
DIY 평가 방법
평가 주기&시간
한 달에 한번 오전 시간 정도면 충분하다. 그 정도의 주기와 시간이면 단순하므로 지키기가 쉽고, 평가로 얻은 결과만으로도 다음 평가까지 개설시킬 충분한 업무량이 생길 것이다.
참여자
적정 참여자 수는 3명이다. 전통적인 방법에 비해 3명은 표본으로 삼기엔 너무나 적은 수이며 따라서 모든 문제를 밝혀내기엔 부족한 인원수라는 것은 사실이다. 하지만 전혀 문제 되지 않는다. 왜냐하면 DIY 평가는 정량평가가 아닌 정성평가로써 데이터를 만들어 내기 위한 목적이 아니다. 또 모든 문제를 찾아낼 필요가 없다 단 1회의 평가만으로도 찾아낼 수 있는 문제의 수는 고칠 수 있는 양을 채우고도 남는다. 또 3명을 넘겨 평가를 거듭해 보아도 점점 이미 알고 있는 중복되는 문제들만을 재확인하게 될 뿐이다.
모집
테스트에 참여할 사용자는 페르소나와 꼭 일치하는 사람을 고집할 필요는 없다. 그런 사용자를 찾기 위해서 노력하는 시간에 차라리 그냥 사전 지식이 없는 사용자로 조건을 완화하고 진행하여도 만족할 만큼 충분한 문제점을 발견할 수 있다. 또 조건을 완화할 경우 참여자를 쉽게 모집할 수 있게 된다. 우리는 서비스를 만들며 페이스북 그룹 몇 곳에다가 모집글을 올렸었는데 수 많은 참여자를 모집할 수 있었다. (그것도 자원봉사자로!)
진행자
참여자 옆에 1:1로 나란히 앉아서 평가 진행을 돕는 진행자 1명만 있으면 충분하다 전문가가 아니라도 상관없다. 평가 용지와 스크립트를 보며 조금만 연습해도 충분히 잘 할 수 있다.
평가 장소&도구
캠코더와 마이크가 준비된 매직미러 딸린 조용한 방일 필요 없다. 편한 카페 같은 공간에서 노트북과 마우스, 화면 녹화 소프트웨어 정도면 충분하다.
(도구 소개는 먼저 작성하였던 '스타트업 UI 프로젝트에서 사용한 10가지 도구’에서 좀 더 자세히 볼 수 있다)
평가대상
프로젝트 초반에 가까울수록 좋고 극단적으로는 디자인이나 개발 등이 전혀 이루어지지 않은 상태에서 자신의 서비스가 아닌 경쟁사의 서비스나 유사한 서비스를 사용하게 해봐도 된다. 서비스 와이어프레임 때 실시해봤고 프로토타입 때 실시해봤다 그리고 오픈 베타 중인 지금도 하고 있다.
과제
각 평가대상의 단계마다 평가하고 싶은 부분이 달라 과제가 달라지게 되는데 예를 들자면 만약 로그인 프로세스를 평가하는 목적이라면 계정 가입하기, 계정 로그인하기, 아이디 찾기, 비밀번호 찾기 같은 과제일 것이다.
좋은 질문에서 좋은 해답을 찾는다고 한다 좋은 과제를 준비하자.
진행순서&방법
1. 인사(4분)
참여자가 진행과정을 이해한 상태에서 평가에 임할 수 있도록 진행방법을 설명한다
2. 배경 질문(2분)
참여자에 대해 몇 가지 질문을 던지다. 참가자의 긴장을 풀어주며 사전 지식을 가늠할 수 있다
3. 둘러보기(3분)
서비스 첫 화면의 첫인상으로 서비스가 제대로 이해를 전달하는지 파악한다.
4. 과제(35분)
평가의 핵심적인 부분으로 참여자가 일련의 과정을 수행하는 모습을 관찰하는 부분이다 여기서 중요한 것은 참여자가 과제에 집중하되 본인이 생각하는 내용을 소리 내어 말하게 해야 한다. 말을 안 한다면 말하게끔 유도하는 질문을 던져야 한다. 예를 들면 “지금 어떤 생각이 드나요?”, “어디를 보고 계시죠?”, “이제 무엇을 할 건가요?” 등인데 질문할 때는 유도 질문하지 않도록 조심하여야 한다 참여자 스스로 과제를 수행해야 하는데 “가입 버튼을 찾고 계신가요?”라고 질문한다면 참여자에게 가입을 유도시키게 되기 때문이다.
5. 심층질문(5분)
과제 간에 행동을 유도할까 봐 미처 하지 못했던 질문을 할 수 있다.
6. 마무리(5분)
감사인사와 함께 마친다.
(진행순서&방법에 대해 간략하게 소개하였는데 가장 중요한 부분인데도 불구하고 이 글에 함께 쓰기엔 어려워 따로 분리하여 자세히 써야 할 것 같다. 다음 글 쓸 때 소개할 예정인데 아마 12월 말에 소개할 예정이다.)
평가 진행 후
평가 후 일반적으로 파악할 수 있는 문제들이 3가지 있는데 소개한다.
1. 콘셉을 이해하지 못하는 경우
무엇을 할 수 있는지 모르거나 또는 할 수 있을 거라 짐작했던 내용을 할 수 없게 된 것이다.
2. UI 텍스트가 문제인 경우
사용자가 사용하는 단어와 여러분이 사용하는 단어가 다른 경우다.
3. 찾는 내용을 찾지 못하는 경우
사용자가 원하는 것을 찾지 못하는 경우로써 더 눈에 띄도록 해야 하는 경우이다.
문제들을 보다 보면 진짜 중요한 문제도 있고 덜 중요한 문제도 있을 테고 문제뿐 아니라 사용자들이 제안한 내용도 있을 거다 "이런이런 기능 있으면 좋겠어요"하고 말이다. 이러한 문제들은 아마 다 고치기 어려울 수 있다.
때문에 팀원들이 모여서 관찰한 내용을 공유하고 고칠 문제와 고칠 방법을 정해야 할 텐데 어떻게 고칠 우선순위를 정해야 할까?
1. 공동목록을 만든다
평가 중에 목격한 문제들로만 가장 심각하다고 생각하는 문제를 3개씩 말하고 화이트보드 같은 곳에 적는다
새로운 문제를 더하려는 충동을 자제하고 새로운 기능에 대한 요청은 꼭 필요한 게 아니라면 배제한다.
2. 가장 심각한 문제 10개 뽑는다
공동목록을 만들며 중복되는 문제든 투표를 하든 10개만 뽑는다.
3. 순위를 매긴다
심각한 순서로 1~10위까지 순위를 매긴다.
4. 목록을 정돈한다
1위부터 차례대로 다음 평가전 한 달간 누가 어떻게 고칠 것인지 정한다 완벽하게 고치지 못하더라도 조치를 취한다는 것이 중요하다.
5. 매우 쉽게 고칠 수 있는 목록은 따로 둔다
심각하지 않고 매우 간단한 문제들은 별도로 모아 두어서 짧은 시간에 고칠 수 있을 때 고친다.
지금까지 쉽고 간단하게 UI 사용성 평가하는 방법에 대해 글을 작성하였는데 본문에서 먼저 언급했던 것처럼 진행방법에 대해한 자세한 내용은 다음 글쓰기 때 따로 더 심층적으로 다루도록 하겠다.
다음글: https://brunch.co.kr/@sapu0000/5
참조 : [사용자를 생각하게 하지 마 Don't make me think], 구글 이미지 검색
