Task 기반 사용성 평가

Task 기반 사용성 평가는 정지된 화면(프린트된 시안)을 보여주고 선호도만 묻는 방식 대신, 프로토타입으로 실제 Task를 수행하게 하며 사용성을 검증하는 방법이다. 이미 출시된 서비스의 문제를 파악할 때는 As-is 서비스의 UT(Usability Test)를 진행하는 경우가 많지만, 일정에 쫓기는 프로젝트에서는 To-be 시안까지 Task 평가를 진행하기 어려운 경우가 흔하다. 특히 프레임웍(Framework) 단계처럼 화면 완성도가 낮은 초기 시점에 Task 평가를 도입하면, 프린트된 화면만으로는 얻기 힘든 종류의 피드백을 확보할 수 있다.

사용자가 프린트된 시안을 볼 때는 "이 영역이 커서 좋다", "메뉴가 잘 보인다"처럼 화면에 드러난 기능·정보 위주로만 답한다. 반면 같은 화면으로 Task를 수행하게 하면 "알림 영역에서 문제를 바로 해결할 수 있으면 좋겠다", "이 Task에는 이 영역이 필요 없다"처럼 개선·불필요 기능에 대한 더 풍부하고 구체적인 의견이 나온다. 정지 화면 평가는 화면 내 기능 자체를 평가하게 만들지만, Task 수행은 Task와 화면을 연관 지어 평가하게 만든다는 점이 핵심 차이다.

프레임웍 단계의 Task 평가는 서비스가 운영되는 맥락을 고려한 의사결정에도 도움이 된다. 정보량이 적어 간략해 보이는 안(A안)이 안정적인 레이아웃을 유지하는 안(B안)보다 사용성 면에서 나아 보였지만, 실제 UT에서는 '안정성'이 중요한 서비스 특성상 화면이 변화하는 A안을 사용자들이 불안하게 느껴 B안을 더 선호했다. 설계자가 '작은 변화'로 여긴 부분이 사용자에게는 시안을 선택하지 않는 1순위 이유가 될 수 있다는 사례다. 이 외에도 Task 평가는 인터뷰에서 언급되지 않았던 신규 기능·용어를 실제 사용 맥락에서 검증하는 기회, 그리고 설계자 스스로 화면 간 이동의 어색함이나 이질감을 미리 발견하는 기회도 제공한다.

핵심 내용

• 정지 화면 평가: 화면에 보이는 기능·정보 위주의 피상적 의견 수집
• Task 기반 평가: Task와 화면을 연관 지어 더 구체적이고 실질적인 개선 의견 수집
• 프레임웍 단계의 Task 평가는 화면 완성도가 낮아도 실질적 사용자 반응을 미리 확인 가능
• 사용성·정보 간결성보다 서비스 맥락(예: 안정성)이 시안 선택의 실제 결정 요인이 될 수 있음
• 인터뷰에 없던 신규 기능·용어를 실사용 맥락에서 검증하는 기회
• 프레임웍을 프로토타입으로 연결해보면 설계자도 화면 간 이질감·누락을 사전에 발견 가능
• 한계: Low-fidelity 프로토타입의 제한된 인터랙션이 평가에 bias를 줄 수 있고, Task와 무관한 화면(2depth 메뉴 등)까지 설계하지 않으면 몰입감이 떨어짐
• 일정상 프레임웍 단계 UT가 어려우면, 최소한 설계자 스스로 플로우 전체를 프로토타입으로 만들어 자가 점검하는 것을 권장

관련 개념

• 키스크린과 인터랙션 프레임웍 — Task 평가의 대상이 되는 인터랙션 프레임웍(뼈대) 단계
• 사용성 비교 평가 — 정지 화면·전문가 평가와 사용자 평가를 병행하는 또 다른 평가 방법론
• 디자인 컨설팅 프로세스 — 래피드 UX의 프로토타입 단계와 이어지는 프레임웍 단계 검증 방법
• 프로토타이핑 툴 비교 — Low-fidelity/High-fidelity 프로토타입 제작 도구 비교

출처

• 프레임웍 단계에서 Task 평가를 하면 좋은 이유 — 2017-05-12, 알 수 없는 사용자