컴퓨터공학 300 주제 시리즈의 287번째 글이다. 전체 지도는 여기.

한 줄 요약

사용성은 “정해진 사용자가 정해진 맥락에서 목표를 효과적·효율적·만족스럽게 달성하는 정도”다. 평가는 사용자를 관찰하는 방법과 전문가가 검토하는 방법으로 나뉘고, 둘 다 측정 기준을 미리 정해야 의미가 있다.

왜 필요한가

“써 보니 괜찮던데요”는 평가가 아니다. 누가, 무엇을, 어떤 기준으로 해 봤는지 없으면 다음 버전과 비교할 수 없다. 사용성 평가를 체계적으로 하면 다음이 가능해진다.

  • 출시 전에 치명적인 사용 문제를 싸게 찾는다.
  • 두 설계안 중 어느 것이 나은지 근거를 댄다.
  • 개선 효과를 숫자로 보여 준다.
  • “취향” 논쟁을 “관찰된 사실” 논의로 바꾼다.

핵심 개념

사용성의 정의: ISO 9241-11

ISO 9241-11:2018 은 사용성을 세 요소로 정의한다.

요소 뜻 측정 예
효과성(effectiveness) 목표를 정확하고 완전하게 달성했는가 과업 성공률, 오류 수
효율성(efficiency) 들인 자원(시간·노력)은 얼마인가 과업 완료 시간, 클릭 수
만족도(satisfaction) 사용자가 어떻게 느꼈는가 설문 점수

정의에 “정해진 사용자, 목표, 사용 맥락”이 들어 있다는 점이 중요하다. 전문가에게 쉬운 시스템이 초보자에게 어려울 수 있다. 사용성은 시스템 단독의 성질이 아니다.

방법의 두 갈래

구분 방법 장점 한계
사용자 기반 사용성 테스트(관찰), 현장 연구, A/B 시험 실제 행동을 본다 모집·진행 비용
전문가 기반 휴리스틱 평가, 인지적 워크스루 빠르고 싸다 실제 사용자 문제를 놓치거나 과장

사용성 테스트

기본 형태는 단순하다. 대표 사용자에게 현실적인 과업을 주고, 진행자는 개입을 최소화하며 관찰한다.

1. 목표와 측정 지표 정하기      (예: 성공률, 시간, 오류, SUS)
2. 과업 시나리오 쓰기           "다음 주 화요일 회의실을 2시간 예약하세요"
3. 대표 사용자 모집             실제 사용자 특성과 맞게
4. 진행: 소리 내어 생각하기     사용자가 생각을 말하며 수행
5. 기록: 어디서 막혔나, 무엇을 말했나
6. 문제 목록화와 심각도 평가
7. 수정 후 다시 테스트

과업 문장에 화면의 버튼 이름을 쓰면 안 된다. “예약 버튼을 눌러 보세요”는 답을 알려 준 것이다. 사용자의 목표로 말해야 한다.

“소리 내어 생각하기(think-aloud)”는 사용자가 무엇을 기대하고 무엇에 놀랐는지 드러낸다. 진행자가 “그건 여기 있어요”라고 도와주는 순간 그 데이터는 오염된다.

몇 명이면 되나

Nielsen 과 Landauer(1993)는 n 명이 발견하는 문제의 비율을 1 - (1 - L)^n 으로 모델링했다. L 은 한 명이 어떤 문제를 발견할 확률이다. Nielsen 은 여러 프로젝트 평균으로 L 을 약 31% 로 보고, 5 명이면 약 85% 를 찾는다고 정리했다. 그래서 “한 번에 많은 사람보다, 5 명씩 여러 번 반복하라”는 조언이 나왔다.

이 숫자는 조건부다. 사용자 집단이 서로 크게 다르면 집단마다 따로 테스트해야 한다. 성공률이나 시간을 통계적으로 비교하려면 더 많은 표본이 필요하다. 5명 규칙은 “정성적으로 문제를 찾는” 목적에 한한다.

휴리스틱 평가

평가자 몇 명이 경험 법칙 목록을 기준으로 화면을 검토한다. 가장 널리 쓰이는 것은 Nielsen 의 10가지 휴리스틱이다.

  1. 시스템 상태의 가시성
  2. 시스템과 현실 세계의 일치
  3. 사용자 제어와 자유(취소·되돌리기)
  4. 일관성과 표준
  5. 오류 예방
  6. 기억보다 인식
  7. 유연성과 효율성(숙련자 단축키)
  8. 미적이고 최소한의 디자인
  9. 오류 인식·진단·복구 지원
  10. 도움말과 문서

평가자는 각자 독립적으로 검토한 뒤 결과를 합친다. 한 사람은 일부만 찾기 때문이다. 발견한 문제마다 심각도(사용 빈도, 영향, 지속성)를 매긴다.

만족도 설문: SUS

System Usability Scale(SUS)은 Brooke 가 1986년 만든 10문항 설문이다. 홀수 문항은 긍정문, 짝수 문항은 부정문이고 각각 1~5점으로 답한다. 점수 계산은 다음과 같다.

홀수 문항: (응답 - 1)
짝수 문항: (5 - 응답)
합계(0~40) x 2.5  ->  0~100 점

SUS 점수는 백분율이 아니다. 68점을 “68%”로 읽으면 안 된다. 같은 제품의 버전 간 비교나, 동일 설문을 쓴 다른 제품과의 비교에 쓴다.

직접 해 보기

SUS 점수를 계산하고, 문제 발견 모델이 n 에 따라 어떻게 포화하는지 본다.

def sus_score(answers):
    """answers: 10개 문항, 각 1(전혀 아니다)~5(매우 그렇다)"""
    assert len(answers) == 10
    total = 0
    for i, a in enumerate(answers, start=1):
        total += (a - 1) if i % 2 == 1 else (5 - a)   # 홀수=긍정문, 짝수=부정문
    return total * 2.5

participants = {
    "P1": [4, 2, 4, 1, 5, 2, 4, 2, 4, 2],
    "P2": [3, 3, 3, 2, 4, 3, 3, 3, 3, 2],
    "P3": [5, 1, 5, 1, 5, 1, 5, 1, 4, 2],
    "P4": [2, 4, 2, 3, 3, 4, 2, 4, 2, 3],
    "P5": [4, 2, 4, 2, 4, 2, 4, 2, 4, 2],
}
scores = {p: sus_score(a) for p, a in participants.items()}
for p, s in scores.items():
    print(p, s)
print("평균 SUS:", sum(scores.values()) / len(scores))

L = 0.31   # 한 명이 한 문제를 발견할 확률(Nielsen 의 평균값)
for n in (1, 3, 5, 10, 15):
    print(f"n={n:2d}: {1 - (1 - L) ** n:.1%}")

실행 결과다.

P1 80.0
P2 57.5
P3 95.0
P4 32.5
P5 75.0
평균 SUS: 68.0
n= 1: 31.0%
n= 3: 67.1%
n= 5: 84.4%
n=10: 97.6%
n=15: 99.6%

P4 의 32.5 점이 눈에 띈다. 평균만 보면 놓친다. 이 사람이 어떤 과업에서 막혔는지 관찰 기록을 다시 봐야 한다. 정량은 어디를 볼지, 정성은 왜인지 알려 준다.

문제 발견 곡선은 5명에서 84%, 10명에서 98% 다. 5명 이후 추가 인원이 찾는 새 문제는 빠르게 줄어든다. 같은 예산이면 5명 테스트 → 수정 → 5명 테스트가 10명 한 번보다 많은 문제를 고친다. 수정이 새 문제를 만들었는지도 확인할 수 있다.

현업에서는

  • 사내 도구라도 동료 두세 명에게 과업을 주고 옆에서 지켜보면 큰 문제는 대부분 드러난다. 장비도 필요 없다. 화면 공유와 메모면 된다.
  • 운영 대시보드는 “장애가 났을 때 원인 노드를 1분 안에 찾는가” 같은 과업으로 평가할 수 있다. 홈랩 k3s 를 운영하며 알림을 받았을 때 몇 번의 클릭으로 원인 파드에 도달하는지 세어 보는 것도 효율성 측정이다.
  • A/B 시험은 출시 후 정량 비교에 강하지만 “왜”를 알려 주지 않고, 트래픽이 충분해야 한다. 작은 서비스에서는 사용성 테스트가 더 많은 것을 알려 준다.
  • 휴리스틱 평가는 코드 리뷰와 비슷하게 PR 단계에 넣을 수 있다. “오류 메시지가 해결 방법을 말하는가”, “되돌리기가 있는가” 같은 체크리스트 형태가 실용적이다.

확인 문제

  1. ISO 9241-11 의 사용성 세 요소와 각각의 측정 예를 들어라.
  2. 과업 시나리오에 화면의 버튼 이름을 쓰면 안 되는 이유는?
  3. SUS 응답이 모든 문항 3점이면 점수는?
  4. “5명이면 충분하다”는 규칙이 맞지 않는 경우 두 가지를 들어라.

풀이

  1. 효과성(과업 성공률), 효율성(완료 시간), 만족도(SUS 점수).
  2. 사용자가 찾아야 할 답을 알려 주는 셈이라 실제로 그 버튼을 발견할 수 있는지 측정할 수 없다.
  3. 홀수 문항 5개 x 2점 + 짝수 문항 5개 x 2점 = 20, x 2.5 = 50점.
  4. 사용자 집단이 서로 크게 다를 때(집단별로 따로 필요), 성공률·시간 같은 지표를 통계적으로 비교하려 할 때.

더 읽을거리 (References)