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

한 줄 요약

사용자 중심 설계(UCD)는 실제 사용자와 그들의 과업·환경을 먼저 이해하고, 설계안을 사용자로 평가해 고치는 일을 반복하는 개발 방식이다. 핵심은 “추측 대신 관찰”이다.

왜 필요한가

개발자는 자기가 만든 시스템을 가장 잘 아는 사람이다. 그래서 오히려 최악의 사용성 평가자가 되기 쉽다. 내부 구조를 알기 때문에 어디를 눌러야 할지 이미 안다. 처음 쓰는 사람이 무엇을 헷갈리는지는 보이지 않는다.

기능은 다 동작하는데 아무도 쓰지 않는 사내 도구, 문의가 끊이지 않는 결제 화면, 매뉴얼 없이는 못 쓰는 관리 콘솔은 대개 같은 원인에서 나온다. 사용자를 확인하지 않고 만든 것이다. 출시 뒤에 고치면 비싸다. 화면 스케치 단계에서 사용자 다섯 명에게 보여 주는 것이 훨씬 싸다.

핵심 개념

ISO 9241-210 의 정의와 원칙

인간-시스템 상호작용의 국제 표준인 ISO 9241-210:2019 는 “인간 중심 설계(human-centred design)”를 다음 원칙으로 정리한다.

  1. 사용자, 과업, 환경에 대한 명시적인 이해에 기반해 설계한다.
  2. 설계와 개발 전반에 사용자를 참여시킨다.
  3. 사용자 중심 평가로 설계를 이끌고 다듬는다.
  4. 과정은 반복적이다.
  5. 사용자 경험 전체를 다룬다.
  6. 설계 팀에 여러 분야의 기술과 관점이 포함된다.

네 가지 활동의 반복

표준이 제시하는 활동은 네 가지이고, 평가 결과가 요구사항을 만족할 때까지 돈다.

  +--> [1] 사용 맥락 이해·명세 ----> [2] 사용자 요구사항 명세
  |                                        |
  |                                        v
  +---- [4] 요구사항 대비 평가 <---- [3] 설계안 제작
             |
             +--> 만족하면 종료(출시), 아니면 필요한 단계로 되돌아감
활동 묻는 질문 대표 방법
사용 맥락 이해 누가, 어디서, 무엇을 하려고, 어떤 제약 속에서 인터뷰, 현장 관찰(맥락 질문), 로그 분석
요구사항 명세 무엇이 되면 성공인가 과업 시나리오, 측정 가능한 사용성 목표
설계안 제작 어떻게 보이고 동작하나 스케치, 와이어프레임, 프로토타입
평가 실제로 되나 사용성 테스트, 전문가 평가, A/B 시험

사용 맥락

“사용자”는 하나가 아니다. 같은 서비스라도 처음 온 사람과 매일 쓰는 사람, 휴대폰으로 지하철에서 쓰는 사람과 사무실 큰 모니터로 쓰는 사람, 화면 낭독기를 쓰는 사람은 다르다. 맥락은 보통 다음을 포함한다.

  • 사용자 특성: 경험, 지식, 언어, 신체·인지 특성
  • 과업: 목표, 빈도, 소요 시간, 실수했을 때의 결과
  • 환경: 기기, 네트워크, 소음·조명, 방해 요인, 조직 규칙

정성과 정량을 함께 쓴다

구분 알려 주는 것 예
정성 조사 왜 그런가 인터뷰, 사용성 테스트 관찰
정량 조사 얼마나, 어디서 이탈률, 완료 시간, 오류율, 설문 점수

로그는 “결제 단계에서 40% 가 떠난다”를 알려 주지만, 이유는 알려 주지 않는다. 다섯 명을 앉혀 놓고 해 보게 하면 “주소 검색 버튼을 못 찾는다”가 보인다. 정량이 어디를 볼지 정하고, 정성이 왜인지 설명한다.

페르소나와 시나리오

페르소나는 조사 결과로 만든 대표 사용자 묘사다. 조사 없이 상상으로 만든 페르소나는 팀의 편견을 정당화하는 도구가 될 수 있다. 시나리오는 그 사용자가 목표를 이루는 구체적 흐름이다. “사용자는 편리하게 결제한다” 대신 “점심시간 10분 안에 휴대폰으로, 저장된 카드로 재주문한다”처럼 쓴다. 이렇게 써야 설계와 평가 기준이 생긴다.

흔한 오해

  • “사용자에게 원하는 것을 물어보면 된다”: 사람은 자기 행동을 정확히 예측하지 못한다. 말보다 행동을 관찰한다.
  • “UCD 는 디자이너 일이다”: 원칙 6 이 말하듯 여러 분야가 함께 한다. 개발자가 관찰 세션에 들어가면 버그 리포트보다 많은 것을 배운다.
  • “한 번 조사하면 끝”: 원칙 4 대로 반복한다.

직접 해 보기

정량 데이터로 “어디를 볼지” 정하는 가장 단순한 도구는 퍼널(funnel) 분석이다. 단계별 도달 사용자 수를 세어 이탈이 큰 지점을 찾는다.

from collections import defaultdict

# (사용자, 단계) 이벤트 로그. 실제로는 분석 도구나 서버 로그에서 뽑는다.
events = [
    ("u1", "cart"), ("u1", "address"), ("u1", "payment"), ("u1", "done"),
    ("u2", "cart"), ("u2", "address"),
    ("u3", "cart"), ("u3", "address"), ("u3", "payment"),
    ("u4", "cart"),
    ("u5", "cart"), ("u5", "address"), ("u5", "payment"), ("u5", "done"),
    ("u6", "cart"), ("u6", "address"), ("u6", "payment"),
    ("u7", "cart"), ("u7", "address"),
    ("u8", "cart"), ("u8", "address"), ("u8", "payment"), ("u8", "done"),
]
steps = ["cart", "address", "payment", "done"]

reached = defaultdict(set)
for user, step in events:
    reached[step].add(user)

prev = None
for s in steps:
    n = len(reached[s])
    if prev is None:
        print(f"{s:8s} {n:2d}명")
    else:
        print(f"{s:8s} {n:2d}명  (이전 단계 대비 {n / prev:5.0%}, 이탈 {prev - n}명)")
    prev = n

실행 결과다.

cart      8명
address   7명  (이전 단계 대비   88%, 이탈 1명)
payment   5명  (이전 단계 대비   71%, 이탈 2명)
done      3명  (이전 단계 대비   60%, 이탈 2명)

결제(payment) 단계에서 완료로 넘어가는 비율이 가장 낮다. 여기까지가 정량이 할 수 있는 일이다. 다음 단계는 결제 화면을 실제 사용자에게 시켜 보는 것이다. 카드 입력 형식이 까다로운지, 오류 메시지가 불친절한지, 배송비가 그제야 보여서 그만두는지는 관찰해야 안다.

8명 표본으로 비율을 해석하면 안 된다는 점도 기억하자. 이 예제는 계산 방법을 보이기 위한 것이다. 실제 판단에는 충분한 표본과 기간이 필요하다.

현업에서는

  • 사내 운영 도구나 관리 콘솔도 사용자가 있다. 운영자 두세 명이 실제로 장애 대응할 때 어떤 화면을 어떤 순서로 보는지 옆에서 관찰하면 메뉴 구조가 바뀐다. 홈랩 k3s 대시보드를 혼자 쓰더라도, 새벽에 알림을 받고 휴대폰으로 볼 때의 맥락은 낮에 노트북으로 볼 때와 다르다.
  • 기획 문서에 “직관적인 UI” 같은 말 대신 측정 가능한 목표를 적는다. 예: “처음 쓰는 사용자 5명 중 4명이 도움 없이 3분 안에 비밀번호를 재설정한다.”
  • 사용자 조사에는 개인정보가 따른다. 녹화·녹음 전에 동의를 받고, 보관 기간과 접근 범위를 정한다.
  • 출시 후에도 고객 문의, 오류 로그, 이탈 지표는 UCD 의 입력이다. 같은 문의가 반복되면 사용자가 아니라 설계의 문제다.

확인 문제

  1. ISO 9241-210 이 말하는 네 가지 활동을 순서대로 적어라.
  2. 개발자가 자기 제품의 사용성을 평가하기에 불리한 이유는?
  3. 로그 분석과 사용성 테스트는 각각 무엇을 알려 주는가?
  4. “사용자는 쉽게 회원가입한다”를 측정 가능한 요구사항으로 바꿔 보라.

풀이

  1. 사용 맥락 이해·명세 → 사용자 요구사항 명세 → 설계안 제작 → 요구사항 대비 평가. 평가 결과에 따라 반복한다.
  2. 내부 구조와 의도를 이미 알아서 처음 쓰는 사람이 겪는 혼란을 경험할 수 없다.
  3. 로그는 어디서·얼마나 문제가 생기는지(정량), 사용성 테스트는 왜 생기는지(정성)를 알려 준다.
  4. 예: “모바일에서 처음 방문한 사용자의 90% 이상이 2분 안에 오류 없이 가입을 완료한다.” 대상·환경·기준·측정값이 들어가면 된다.

더 읽을거리 (References)

  • ISO 9241-210:2019, Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems.
  • W3C WAI, Notes on User Centered Design Process (UCD)
  • GOV.UK Service Manual, User research
  • D. Norman, The Design of Everyday Things, Revised and Expanded Edition, Basic Books, 2013.