------------------------------------------------------------
1. 사용성 테스팅(Massive and Rapid Usability Testing)
가. 사용성 테스팅의 정의
나. Rapid Usbility Testing
다. Massive Usability Testing vs. Rapid Usability Testing
2. 사용성 테스팅 계획(개발 수명주기에서의 사용성 테스팅)
가. 사용성 테스팅은 언제 수행하나요?
3. 참가자 선정
가. 사용성 테스팅에 얼마나 많은 참가자가 적당한가?
나. 사용성 테스팅에서 사용자란 누구인가?
4. 사용성 테스팅 수행
가. 사용자 테스팅
- 사용자 테스팅 소개
- 테스트 과제와 시나리오 작성
- 관찰실
- 테스트 진행
- 회고 그리고 보고서
- 체크리스트
- 사용자 테스팅의 장점과 단점
나. 카드 소팅
다. 소원의 나무
5. 정리(?)
------------------------------------------------------------
자 이제 사용자 테스팅의 결과를 정리할 시간입니다.
회고를 진행하기 전에 준비되어야 할 것은 이전에 얘기했던 관찰자들이 테스트를 관찰하면서 작성한 참가자들이 제품을 이용하면서 겪었던 가장 심각한 사용성 문제의 목록입니다.
그리고 회고가 끝나면 우리는 다음 달 테스트 전까지 고쳐야 할 항목의 목록을 얻게 될 것입니다.
회고는 테스트가 끝난 후 사람들이 테스트에 대한 내용을 생생하게 기억하고 있는 순간에 열려야만 합니다.
회고는 잘못하면 매우 우울하고 딱딱한 분위기속에서 진행될 수 있습니다.
그러한 분위기를 피할 수 있는 좋은 방법은 식사를 하면서 회고를 진행하는 것입니다. 어떤 사람들은 음식을 먹다보면 회고에 집중하지 못한다고 하지만 음식은 분위기를 부드럽게 만들어주는 효과가 있습니다.
만약 아침에 사용자 테스팅을 진행하셨다면 점심을 오후에 진행하셨다면 저녁을 함께 하면서 회고를 진행하면 좋습니다.
회고의 가장 큰 목적은 사용자 테스팅을 관찰하면서 발견된 사용성 문제들 중에서 우리가 해결가능한 가장 심각한 사용성 문제를 선정하는데 있습니다.
많은 사람들이 인정하고 싶지 않은 진실 중 하나가 모든 제품에는 사용성 문제가 있다는 것입니다.
그런데 모든 회사들은 사용성 문제를 고칠 수 있는 자원이 한정되어 있습니다. 그런데 대부분의 심각한 사용성 문제들은 현재 회사가 사용할 수 있는 자원 이상을 요구하는 경우가 많다는 것입니다.
때문에 많은 회사들은 항상 덜 심각한 문제들 중에 해결하기 쉬운것에 마음을 뺏깁니다. 결국 심각한 사용성 문제들은 항상 수정되지 않게 됩니다.
그러므로, 우리는 언제나 항상 반드시 가장 심각한 문제들을 우선적으로 고쳐 나가는 것에 고도로 집중해야 합니다.
회고를 진행하는 진행자는 이것을 반드시 염두해 두어야 합니다.
회고에 참석하는 모든 이해관계자들이 자신들이 관찰한 사용성 문제 중에서 수정하기 쉬운 문제에만 집중하지 않도록 해야 합니다.
사용자 테스팅의 가장 큰 강점은 심각하지 않은 문제보다 누구나 명확하게 이해할 수 있는 가장 심각한 문제들을 명확하게 보여준다는 것입니다.
그렇다면 관찰자들이 관찰한 수많은 사용성 문제들 중에서 과연 어떤것이 정말 심각한 사용성 문제일까요?
심각한 사용성 문제를 식별하는 것은 판단의 문제입니다.
심각한 사용성 문제를 식별하는데에 있어서 가장 어려운 경우는 분명하게 심각한 문제이지만 그 문제가 아주 소수의 사람들에게 영향을 주는 경우나 아니면 수많은 사람들에게 영향을 주지만 약간 귀찮은 정도의 문제인 경우입니다.
이렇게 판단을 내기기 어려운 경우에 있어서 가장 심각한 사용성 문제들은 아래와 같은 기준에 따라 식별할 수 있습니다.
1. 많은 사람들이 이 문제를 겪고 있는가?
2. 이것은 이 문제를 겪고 있는 사람들에게 심각한 문제를 초래하는가? 아니면 그저 불편한 정도인가?
어떠한 사용성 문제가 정말 심각한 사용성 문제인지를 판별하기 위해서 위 2가지 질문만으로도 충분히 심각한 사용성 문제들을 식별해 낼 수 있습니다. 사실 그만큼 심각한 사용성 문제들은 발견하기 쉽고 사실 모두가 이미 인지하고 있는 경우가 많습니다.
만약 쇼핑몰과 같은 사이트라면 가장 심각한 사용성 문제는 결제일 것입니다. 은행과 같은 사이트라면 이체일 것입니다.
이러한 심각한 사용성 문제를 결정하는 회고는 아래와 같은 순서로 진행됩니다.
1. 회고 순서 설명하기
여러분들이 테스트를 관찰하면서 작서하신 사용성 문제 목록들 중에서 가장 심각한 열가지를 고르겠습니다. 그리고 그 중 가장 중요한 것을 선별하여 다음 달까지 수정할 항목을 정하도록 하겠습니다.
2. 관찰실 모니터링 요원이 정리한 전체 사용성 문제 목록을 빔 프로젝트, 이젤 패드, 화이트 보드 등을 통해 공유합니다.(즐겨 사용하시는 도구가 있으시다면 어떤 것을 이용하셔도 좋습니다. 인쇄물을 이용하셔도 좋습니다. 다만, 모든 사용성 문제들을 관찰자들과 회고에 참여한 모든 사람이 한눈에 볼 수 있도록 하는 것이 좋습니다.)
3. 목록을 보면서 가장 심각해 보이는 문제 열 가지를 고릅니다.
원한다면 투표를 해도 됩니다. 아니면 해당 문제를 지적한 관찰자들의 수가 가장 많은 문제들 10가지를 골라도 됩니다.
4. 선정된 열 가지의 심각한 사용성 문제들을 심각도에 따라 다시 적습니다.
5. 선정된 열 가지의 심각한 사용성 문제들에 대한 해결 방법을 간단하게 논의 합니다. 수정은 최대한 간단히 할 수 있는 선으로 제한합니다.
6. 선정된 열 가지의 심각한 사용성 문제들에 대한 해결 방법을 검토하고 그 중 한달 동안 수정 가능한 문제들을 선택합니다.
일반적으로 3개 정도의 사용성 문제를 선정하는 것이 좋습니다. 하지만 더 많은 사용성 문제들을 수정 가능하다면 가능한 많은 문제들을 고르는 것이 좋습니다.
일반적으로 저는 회고를 진행할 때 목적을 한 달동안 수정 가능한 가장 심각한 사용성 문제 3가지로 제한하여 진행하는 경우가 많습니다.
이렇게 목적을 명확히 할 경우 사람들이 그 목적에 집중하여 회고가 좀 더 효율적으로 진행될 수 있습니다.
그리괴 회고는 진행자의 주도 하에 진행되는 것이 좋습니다. 토론은 좋은 것이지만 무엇인가를 선택하는 문제에 있어서 토론은 자칫 잘못하면 서로간의 책임을 회피하는 수단으로 이용될 수 있습니다.
관찰자들과 이해관계자의 의견에 귀를 귀울여야 하지만 결정에 있어서만큼은 진행자가 결정하여 통보하는 형태로 진행하는 것이 좋습니다.
회고에 참여하는 관찰자들과 이해관계자 중에서 사용성에 대하여 가장 잘 이해하고 있는 사람이 진행자이기 때문입니다.
또한 일반적으로 회고는 1시간정도 진행됩니다. 또한 식사와 함께 진행되기 때문에 자칫 잘못하면 어수선한 분위기 속에서 사람들이 잡답이나 영양가 없는 논쟁으로 시간을 소비할 수 있습니다.
진행자는 회고에서 사람들이 샛길로 가지 않도록 잡아주어야 합니다. 짧은 의견을 피력하는 것은 좋지만 이것이 어떠한 '종교 논쟁'으로 번지게 해서는 안됩니다.
사람들이 '종교 논쟁'에 빠지려 한다면 테스트 관찰 내용으로 논의를 되돌리는 것이 좋습니다.
"지금 하시는 이야기는 테스트에서 보신 내용인가요?" " 지금 이 이야기의 내용을 테스트에서 보신 분들이 계신가요?"
와 같은 질문이 효과적이며 필요하다면 테스트를 녹화했던 파일을 검토하는 것도 좋습니다.
마지막으로 주의할 사항은 열 가지의 사용성 문제들에 대한 해결 방법을 논의할 때 특정 사용성 문제들에 대하여 다름 프로젝트 또는 다음 스프린트, 다음 업데이트 등에서 해결될거라는 의견을 무시하시기 바랍니다.
그것은 진부한 회의론자들의 핑계일 뿐입니다.
그들은 이전에도 그렇게 심각한 사용성 문제들을 해결하지 않았습니다.
우리에게 중요한 것은 심각한 사용성 문제들을 영원히 사용자들로부터 사라지게 하지 못한다 하더라도 최소한 사용자들에게 그러한 문제들이 덜 심각할 수 있도록 그 문제를 작게 만드는 것이기 때문입니다.
심각한 사용성 문제를 해결하는 것은 누구도 원하지 않는 경우가 많습니다. 모두가 회피한다면 사용자 테스트를 수행한 의미가 없습니다. 테스트를 수행하고 문제가 발견되었다면 그 문제를 해결하기 위해 할 수 있는 모든 것을 시도할 필요가 있습니다.
진행자는 회고에 참여한 모든 사람들에게 이러한 사실을 일깨워줄 필요가 있습니다.
이렇게 다음 테스트 전까지 수정해야할 심각한 사용성 문제들이 정해졌다면 해당 사용성 문제들을 담당자들에게 이메일로 간단하게 통보하는 것으로 사용자 테스트는 끝을 맺게 됩니다.
일반적으로 사용자 테스트에서는 결과 보고서와 같은 무거운 문서를 만들지 않습니다. 왜냐하면 그러한 결과 보고서를 받아야 하는 사람들이 테스트에 직접 참여하여 관찰을 하였고 심각한 사용성 문제들을 선정했으며 그것을 수정하기로 동의했기 때문입니다.
때문에 무거운 문서 대신에 관련 이해관계자들이 그러한 사실을 잊지 않도록 일깨워주고 진행상황을 감시하고 제어하는 것으로 충분합니다.
하지만 만약에 정말로 필요하다면 정해진 양식에 따라 보고서를 작성하셔도 상관 없습니다.
간단하게 이메일로 결과를 통보한다면 아래와 같은 내용들을 적으시면 됩니다.
1. 테스트 대상
2. 참가자가 수행한 과제 목록
3. 관찰을 통해 다음 달까지 고치기로 결정한 문제의 목록
그리고 필요하다면 녹화 파일을 볼 수 있는 방법을 추가할 수 있습니다. 하지만 녹화 파일은 사용성 문제를 수정하는 과정에서 또다른 '종교 논쟁'을 불러일으킬수 있으므로 열람을 제한적으로 허용하는 것이 좋습니다. 저는 열람의 경우 비밀 서약과 함께 필요한 부분만을 제공하는 것으로 갈음합니다.
그리고 마지막으로 다음 테스트 진행 일정을 반드시 알려주어야 합니다.
이렇게 사용자 테스트가 막을 내립니다. 하지만 이것이 끝은 아닙니다. 사용자 테스트는 정기적으로 진행되는 것입니다. 이제 여러분은 다음 테스트를 준비하셔야 합니다.
다음에는 이러한 사용자 테스트를 준비하는 과정에 필요한 체크리스트를 소개해 드리겠습니다.
1. 사용성 테스팅(Massive and Rapid Usability Testing)
가. 사용성 테스팅의 정의
나. Rapid Usbility Testing
다. Massive Usability Testing vs. Rapid Usability Testing
2. 사용성 테스팅 계획(개발 수명주기에서의 사용성 테스팅)
가. 사용성 테스팅은 언제 수행하나요?
3. 참가자 선정
가. 사용성 테스팅에 얼마나 많은 참가자가 적당한가?
나. 사용성 테스팅에서 사용자란 누구인가?
4. 사용성 테스팅 수행
가. 사용자 테스팅
- 사용자 테스팅 소개
- 테스트 과제와 시나리오 작성
- 관찰실
- 테스트 진행
- 회고 그리고 보고서
- 체크리스트
- 사용자 테스팅의 장점과 단점
나. 카드 소팅
다. 소원의 나무
5. 정리(?)
------------------------------------------------------------
자 이제 사용자 테스팅의 결과를 정리할 시간입니다.
회고를 진행하기 전에 준비되어야 할 것은 이전에 얘기했던 관찰자들이 테스트를 관찰하면서 작성한 참가자들이 제품을 이용하면서 겪었던 가장 심각한 사용성 문제의 목록입니다.
그리고 회고가 끝나면 우리는 다음 달 테스트 전까지 고쳐야 할 항목의 목록을 얻게 될 것입니다.
회고는 테스트가 끝난 후 사람들이 테스트에 대한 내용을 생생하게 기억하고 있는 순간에 열려야만 합니다.
회고는 잘못하면 매우 우울하고 딱딱한 분위기속에서 진행될 수 있습니다.
그러한 분위기를 피할 수 있는 좋은 방법은 식사를 하면서 회고를 진행하는 것입니다. 어떤 사람들은 음식을 먹다보면 회고에 집중하지 못한다고 하지만 음식은 분위기를 부드럽게 만들어주는 효과가 있습니다.
만약 아침에 사용자 테스팅을 진행하셨다면 점심을 오후에 진행하셨다면 저녁을 함께 하면서 회고를 진행하면 좋습니다.
회고의 가장 큰 목적은 사용자 테스팅을 관찰하면서 발견된 사용성 문제들 중에서 우리가 해결가능한 가장 심각한 사용성 문제를 선정하는데 있습니다.
많은 사람들이 인정하고 싶지 않은 진실 중 하나가 모든 제품에는 사용성 문제가 있다는 것입니다.
그런데 모든 회사들은 사용성 문제를 고칠 수 있는 자원이 한정되어 있습니다. 그런데 대부분의 심각한 사용성 문제들은 현재 회사가 사용할 수 있는 자원 이상을 요구하는 경우가 많다는 것입니다.
때문에 많은 회사들은 항상 덜 심각한 문제들 중에 해결하기 쉬운것에 마음을 뺏깁니다. 결국 심각한 사용성 문제들은 항상 수정되지 않게 됩니다.
그러므로, 우리는 언제나 항상 반드시 가장 심각한 문제들을 우선적으로 고쳐 나가는 것에 고도로 집중해야 합니다.
회고를 진행하는 진행자는 이것을 반드시 염두해 두어야 합니다.
회고에 참석하는 모든 이해관계자들이 자신들이 관찰한 사용성 문제 중에서 수정하기 쉬운 문제에만 집중하지 않도록 해야 합니다.
사용자 테스팅의 가장 큰 강점은 심각하지 않은 문제보다 누구나 명확하게 이해할 수 있는 가장 심각한 문제들을 명확하게 보여준다는 것입니다.
그렇다면 관찰자들이 관찰한 수많은 사용성 문제들 중에서 과연 어떤것이 정말 심각한 사용성 문제일까요?
심각한 사용성 문제를 식별하는 것은 판단의 문제입니다.
심각한 사용성 문제를 식별하는데에 있어서 가장 어려운 경우는 분명하게 심각한 문제이지만 그 문제가 아주 소수의 사람들에게 영향을 주는 경우나 아니면 수많은 사람들에게 영향을 주지만 약간 귀찮은 정도의 문제인 경우입니다.
이렇게 판단을 내기기 어려운 경우에 있어서 가장 심각한 사용성 문제들은 아래와 같은 기준에 따라 식별할 수 있습니다.
1. 많은 사람들이 이 문제를 겪고 있는가?
2. 이것은 이 문제를 겪고 있는 사람들에게 심각한 문제를 초래하는가? 아니면 그저 불편한 정도인가?
어떠한 사용성 문제가 정말 심각한 사용성 문제인지를 판별하기 위해서 위 2가지 질문만으로도 충분히 심각한 사용성 문제들을 식별해 낼 수 있습니다. 사실 그만큼 심각한 사용성 문제들은 발견하기 쉽고 사실 모두가 이미 인지하고 있는 경우가 많습니다.
만약 쇼핑몰과 같은 사이트라면 가장 심각한 사용성 문제는 결제일 것입니다. 은행과 같은 사이트라면 이체일 것입니다.
이러한 심각한 사용성 문제를 결정하는 회고는 아래와 같은 순서로 진행됩니다.
1. 회고 순서 설명하기
여러분들이 테스트를 관찰하면서 작서하신 사용성 문제 목록들 중에서 가장 심각한 열가지를 고르겠습니다. 그리고 그 중 가장 중요한 것을 선별하여 다음 달까지 수정할 항목을 정하도록 하겠습니다.
2. 관찰실 모니터링 요원이 정리한 전체 사용성 문제 목록을 빔 프로젝트, 이젤 패드, 화이트 보드 등을 통해 공유합니다.(즐겨 사용하시는 도구가 있으시다면 어떤 것을 이용하셔도 좋습니다. 인쇄물을 이용하셔도 좋습니다. 다만, 모든 사용성 문제들을 관찰자들과 회고에 참여한 모든 사람이 한눈에 볼 수 있도록 하는 것이 좋습니다.)
3. 목록을 보면서 가장 심각해 보이는 문제 열 가지를 고릅니다.
원한다면 투표를 해도 됩니다. 아니면 해당 문제를 지적한 관찰자들의 수가 가장 많은 문제들 10가지를 골라도 됩니다.
4. 선정된 열 가지의 심각한 사용성 문제들을 심각도에 따라 다시 적습니다.
5. 선정된 열 가지의 심각한 사용성 문제들에 대한 해결 방법을 간단하게 논의 합니다. 수정은 최대한 간단히 할 수 있는 선으로 제한합니다.
6. 선정된 열 가지의 심각한 사용성 문제들에 대한 해결 방법을 검토하고 그 중 한달 동안 수정 가능한 문제들을 선택합니다.
일반적으로 3개 정도의 사용성 문제를 선정하는 것이 좋습니다. 하지만 더 많은 사용성 문제들을 수정 가능하다면 가능한 많은 문제들을 고르는 것이 좋습니다.
일반적으로 저는 회고를 진행할 때 목적을 한 달동안 수정 가능한 가장 심각한 사용성 문제 3가지로 제한하여 진행하는 경우가 많습니다.
이렇게 목적을 명확히 할 경우 사람들이 그 목적에 집중하여 회고가 좀 더 효율적으로 진행될 수 있습니다.
그리괴 회고는 진행자의 주도 하에 진행되는 것이 좋습니다. 토론은 좋은 것이지만 무엇인가를 선택하는 문제에 있어서 토론은 자칫 잘못하면 서로간의 책임을 회피하는 수단으로 이용될 수 있습니다.
관찰자들과 이해관계자의 의견에 귀를 귀울여야 하지만 결정에 있어서만큼은 진행자가 결정하여 통보하는 형태로 진행하는 것이 좋습니다.
회고에 참여하는 관찰자들과 이해관계자 중에서 사용성에 대하여 가장 잘 이해하고 있는 사람이 진행자이기 때문입니다.
또한 일반적으로 회고는 1시간정도 진행됩니다. 또한 식사와 함께 진행되기 때문에 자칫 잘못하면 어수선한 분위기 속에서 사람들이 잡답이나 영양가 없는 논쟁으로 시간을 소비할 수 있습니다.
진행자는 회고에서 사람들이 샛길로 가지 않도록 잡아주어야 합니다. 짧은 의견을 피력하는 것은 좋지만 이것이 어떠한 '종교 논쟁'으로 번지게 해서는 안됩니다.
사람들이 '종교 논쟁'에 빠지려 한다면 테스트 관찰 내용으로 논의를 되돌리는 것이 좋습니다.
"지금 하시는 이야기는 테스트에서 보신 내용인가요?" " 지금 이 이야기의 내용을 테스트에서 보신 분들이 계신가요?"
와 같은 질문이 효과적이며 필요하다면 테스트를 녹화했던 파일을 검토하는 것도 좋습니다.
마지막으로 주의할 사항은 열 가지의 사용성 문제들에 대한 해결 방법을 논의할 때 특정 사용성 문제들에 대하여 다름 프로젝트 또는 다음 스프린트, 다음 업데이트 등에서 해결될거라는 의견을 무시하시기 바랍니다.
그것은 진부한 회의론자들의 핑계일 뿐입니다.
그들은 이전에도 그렇게 심각한 사용성 문제들을 해결하지 않았습니다.
우리에게 중요한 것은 심각한 사용성 문제들을 영원히 사용자들로부터 사라지게 하지 못한다 하더라도 최소한 사용자들에게 그러한 문제들이 덜 심각할 수 있도록 그 문제를 작게 만드는 것이기 때문입니다.
심각한 사용성 문제를 해결하는 것은 누구도 원하지 않는 경우가 많습니다. 모두가 회피한다면 사용자 테스트를 수행한 의미가 없습니다. 테스트를 수행하고 문제가 발견되었다면 그 문제를 해결하기 위해 할 수 있는 모든 것을 시도할 필요가 있습니다.
진행자는 회고에 참여한 모든 사람들에게 이러한 사실을 일깨워줄 필요가 있습니다.
이렇게 다음 테스트 전까지 수정해야할 심각한 사용성 문제들이 정해졌다면 해당 사용성 문제들을 담당자들에게 이메일로 간단하게 통보하는 것으로 사용자 테스트는 끝을 맺게 됩니다.
일반적으로 사용자 테스트에서는 결과 보고서와 같은 무거운 문서를 만들지 않습니다. 왜냐하면 그러한 결과 보고서를 받아야 하는 사람들이 테스트에 직접 참여하여 관찰을 하였고 심각한 사용성 문제들을 선정했으며 그것을 수정하기로 동의했기 때문입니다.
때문에 무거운 문서 대신에 관련 이해관계자들이 그러한 사실을 잊지 않도록 일깨워주고 진행상황을 감시하고 제어하는 것으로 충분합니다.
하지만 만약에 정말로 필요하다면 정해진 양식에 따라 보고서를 작성하셔도 상관 없습니다.
간단하게 이메일로 결과를 통보한다면 아래와 같은 내용들을 적으시면 됩니다.
1. 테스트 대상
2. 참가자가 수행한 과제 목록
3. 관찰을 통해 다음 달까지 고치기로 결정한 문제의 목록
그리고 필요하다면 녹화 파일을 볼 수 있는 방법을 추가할 수 있습니다. 하지만 녹화 파일은 사용성 문제를 수정하는 과정에서 또다른 '종교 논쟁'을 불러일으킬수 있으므로 열람을 제한적으로 허용하는 것이 좋습니다. 저는 열람의 경우 비밀 서약과 함께 필요한 부분만을 제공하는 것으로 갈음합니다.
그리고 마지막으로 다음 테스트 진행 일정을 반드시 알려주어야 합니다.
이렇게 사용자 테스트가 막을 내립니다. 하지만 이것이 끝은 아닙니다. 사용자 테스트는 정기적으로 진행되는 것입니다. 이제 여러분은 다음 테스트를 준비하셔야 합니다.
다음에는 이러한 사용자 테스트를 준비하는 과정에 필요한 체크리스트를 소개해 드리겠습니다.
댓글
댓글 쓰기