📚 지식 노트

UX 라이팅: 화면의 말도 설계다

화면의 글자는 장식이 아니라 인터페이스의 일부다. 버튼 이름 하나가 사용자가 누를지 말지, 누른 뒤 놀랄지 말지를 정한다. 제품 문구를 다듬는 일을 UX 라이팅(UX writing)이라 하고, 기준은 세 가지로 줄일 수 있다. 명확하게(한 가지 뜻으로만 읽히게), 간결하게(뜻 없는 말을 덜어), 유용하게(지금 해야 할 일을 돕게)다.

가장 흔한 실패는 "확인/취소"만 있는 대화상자다. 무엇을 확인하는지 본문을 다시 읽어야 알 수 있고, "취소"가 대화상자를 닫는 것인지 주문을 취소하는 것인지도 헷갈린다. 버튼에는 동사 + 대상을 쓴다("주문 취소하기", "그대로 두기"). 제목은 사용자가 답할 질문으로 쓰고, 누르면 무슨 일이 생기는지(환불, 되돌릴 수 없음)를 본문에 먼저 적는다.

한국어 제품 팀이 공개한 원칙도 같은 방향이다. 토스는 여덟 가지 라이팅 원칙에서 다음 화면을 예상할 수 있게 하기, 뜻 없는 말 덜기, 지금 필요한 핵심만 보이기, 소리 내 읽어도 자연스러운 말 쓰기, 겁주거나 몰아붙이지 말고 제안하기 등을 꼽는다. 짧게 쓰는 것이 목표가 아니라, 의미를 더하지 않는 말을 빼는 것이 목표라는 점이 중요하다.

오류 문구의 공식

오류 문구는 무엇이 일어났나 + 어떻게 고치나를 그 자리에서 말한다. NN/g의 오류 메시지 지침은 문제가 생긴 칸 가까이에 두기, 색에만 기대지 않기, 쉬운 말로 구체적으로 말하기, 고치는 방법 알려 주기, "잘못된"·"올바르지 않은"처럼 사용자를 탓하는 말 피하기, 입력한 값을 지우지 않고 남겨 두기를 든다. 빈칸을 그냥 두었다고 바로 오류를 띄우는 것처럼 너무 이른 검증도 피한다. 입력 폼 쪽의 자세한 패턴은 폼과 입력 글에 있다.

말투와 용어는 한 벌로

한국어 화면에서 자주 어긋나는 것이 높임법이다. 한 화면에 "저장되었습니다"(합쇼체)와 "저장했어요"(해요체)가 섞이면 서로 다른 사람이 만든 제품처럼 보인다. 제품마다 하나를 정해 문구 지침에 적고, 버튼·알림·오류·이메일까지 같은 말투를 쓴다. 용어도 마찬가지다. 같은 것을 여러 이름으로 부르면 사용자는 다른 것이라고 생각한다. 용어집을 만들어 하나로 정하고, 뜻이 다른 동작은 일부러 다른 말로 나눈다.

평가 방법 고르기: 검토할까, 관찰할까, 셀까

설계가 통하는지 확인하는 방법은 두 축으로 나눌 수 있다. 하나는 누가 보나다. 전문가가 원칙에 비춰 검토하는 방법(사용성 검사, inspection)은 사용자를 모으지 않아 싸고 빠르지만, 실제 사용자가 무엇에서 막히는지는 추측이다. 사용자를 관찰하는 방법은 비싸지만 추측이 아니다. 다른 하나는 무엇을 알고 싶나다. "왜, 어디서 막히나"는 소수를 깊게 보는 질적 방법이, "얼마나, 몇 %인가"는 다수를 세는 양적 방법이 답한다.

순서는 대개 왼쪽 위에서 오른쪽 아래로 간다. 설계 초기에는 휴리스틱 평가와 워크스루로 뻔한 문제를 치우고, 프로토타입이 생기면 사용성 테스트로 사람을 보고, 출시 뒤에는 지표와 A/B 테스트로 규모를 잰다. 숫자가 "어디서" 빠지는지 알려 주면, 다시 사용성 테스트로 "왜"를 찾는다. 조사 방법 전반은 사용자 조사와 문제 정의, 사람의 지각·인지 원리는 HCI와 UX 노트에 있다.

휴리스틱 평가: 여러 명이 따로 보고 합친다

휴리스틱 평가(heuristic evaluation)는 평가자가 사용성 원칙 목록에 비춰 화면을 검토하는 방법이다. 가장 널리 쓰는 목록인 닐슨의 휴리스틱 10가지는 HCI와 UX 노트에 정리해 두었고, 여기서는 진행하는 법을 다룬다. NN/g의 진행법의 요지는 3~5명이 서로 모르게 따로 보고, 끝난 뒤에 합친다는 것이다. 한 사람은 문제를 일부만 찾고, 서로의 기록을 보면 남이 찾은 것에 끌려가기 때문이다.

범위는 좁게 잡는다. "앱 전체"가 아니라 과제 하나, 화면 묶음 하나, 사용자 집단 하나, 기기 하나로 정하고 한 번에 1~2시간으로 끊는다. 각자 두 번 훑는데, 첫 번째는 흐름을 익히기만 하고 두 번째에 위반을 적는다. 다 끝난 뒤 비슷한 문제를 한데 모으고(친화도 묶기), 합의한 것과 엇갈린 것, 더 데이터가 필요한 것, 사용성 테스트로 확인할 것을 정한다. 위반이 곧 문제는 아니다. 원칙을 어겨도 그 맥락에서는 더 나은 선택일 수 있으므로, 고칠지는 사용자 조사와 함께 판단한다.

우선순위는 심각도(severity)로 정한다. 심각도는 얼마나 자주 생기나(빈도), 겪으면 넘기기 어려운가(영향), 한 번 배우면 끝인가 계속 괴롭히나(지속성)를 합친 판단이다. 평가 세션이 끝난 뒤 발견한 문제 전체 목록을 놓고 각자 따로 매기고, 한 사람 점수는 믿기 어려우므로 세 사람 이상의 평균을 쓴다.

인지적 워크스루: 처음 쓰는 사람의 눈으로 한 걸음씩

휴리스틱 평가가 제품 전체를 원칙에 비춰 본다면, 인지적 워크스루(cognitive walkthrough)는 과제 하나를 단계별로 밟으며 처음 쓰는 사람이 배울 수 있는가(학습 용이성)만 본다. 표준 패턴이 없는 복잡한 화면, 처음 써 보는 종류의 기능에서 특히 쓸모 있다. NN/g의 설명대로 진행자가 과제를 수행하며 화면마다 멈추고, 평가자들이 단계마다 네 질문을 묻는다.

1. 사용자가 이 결과를 얻으려고 할까?(목표가 맞나)
2. 올바른 동작이 있다는 것을 알아챌까?(보이나)
3. 그 동작이 원하는 결과로 이어진다고 생각할까?(이름·모양이 이어지나)
4. 동작한 뒤 목표에 가까워졌다는 것을 알 수 있을까?(진행이 보이나)

하나라도 "아니오"면 그 단계는 실패로 적는다. 기록 담당이 따로 있어 답과 판정을 적고, 끝에 실패 지점을 모아 다음 할 일을 정한다. 사용자 없이 하지만, 과제를 미리 정하고 "이 사람은 이 화면을 처음 본다"는 가정을 끝까지 지키는 것이 핵심이다.

사용성 테스트 설계: 과제를 주고 지켜본다

사용성 테스트(usability test)는 실제 사용자와 비슷한 사람에게 현실적인 과제를 주고, 그가 하는 것을 지켜보는 방법이다. 가장 흔한 형태가 생각 소리 내기(thinking aloud)로, 참가자가 쓰면서 머릿속 생각을 말로 내놓는다. 특별한 장비 없이 하루면 몇 명을 볼 수 있고, 사용자가 무엇을 오해했는지와 그 이유까지 들린다. 대신 말하며 쓰는 것이 자연스럽지 않아 참가자가 생각을 걸러 말할 수 있고, 진행자의 질문 하나가 행동을 바꿀 수 있으며, 통계를 낼 만한 방법은 아니다.

과제 시나리오가 테스트의 질을 정한다. 좋은 시나리오는 목표와 상황만 주고 화면의 말을 쓰지 않는다. "'쿠폰함' 메뉴를 누르세요"라고 하면 메뉴를 찾을 수 있는지는 시험할 수 없다. 끝이 분명해야 성공 여부를 판정할 수 있고("결제 직전까지"), 참가자에게 실제로 있을 법한 이유를 준다("친구가 준 할인 코드"). 진행자는 막혀도 답을 알려 주지 않고, "지금 무엇을 찾고 있나요?"처럼 중립적으로만 묻는다.

숫자로 남기기: 성공률, 완료 시간, SUS

질적 테스트에서도 몇 가지 숫자는 남긴다. 다음 차례와 비교하기 위해서다. 과제 성공률은 끝까지 해낸 사람의 비율이고, 도움을 받아 해낸 경우를 따로 셀지 미리 정한다. 완료 시간은 평균을 내는 방법에 주의한다. 시간은 오른쪽으로 꼬리가 길어서, 길을 잃은 한 사람이 산술 평균을 크게 끌어올린다. 아래 예에서 산술 평균은 68.7초인데 평균보다 오래 걸린 사람은 일곱 중 한 명뿐이다. MeasuringU는 표본이 25명보다 적으면 로그를 평균 내 되돌리는 기하 평균(58.3초)을 권한다. 표본이 작을 때 중앙값(51초)은 가운데를 높게 잡는 경향이 있고 흔들림이 크다는 것이 이유다.

만족도는 SUS(System Usability Scale)로 잰다. 1~5점으로 답하는 문장 열 개이고, 홀수 문항은 긍정 문장("자주 쓰고 싶다"), 짝수 문항은 부정 문장("불필요하게 복잡하다")이다. 점수 내는 법은 MeasuringU의 정리대로, 홀수 문항은 응답에서 1을, 짝수 문항은 5에서 응답을 빼 0~4점으로 바꾸고, 열 개를 더해 2.5를 곱한다. 0~100점이 되지만 백분율이 아니다. 약 500개 연구의 평균이 68점이어서 70점은 "70%"가 아니라 평균 근처이고, 80.3점을 넘어야 상위 10% 안팎이다.

A/B 테스트 설계: 가설, 지표, 표본 수를 먼저

A/B 테스트는 사용자를 무작위로 나눠 한쪽에 원래 설계(A), 다른 쪽에 바꾼 설계(B)를 보이고 지표를 비교한다. 개념과 통계적 유의성은 HCI와 UX 노트와 데이터 엔지니어링 노트의 통계 절에 있고, 여기서는 시작하기 전에 정할 것을 다룬다.

• 가설: "결제 버튼 위에 총액을 보이면(변경) 결제 완료율이 오른다(지표). 사용성 테스트에서 금액을 확인하려고 장바구니로 되돌아가는 사람이 많았기 때문이다(근거)." 근거가 없는 가설은 이겨도 왜 이겼는지 모른다.
• 주 지표 하나와 지켜볼 지표: 판정은 미리 정한 지표 하나로 한다. 동시에 환불률·문의 수·페이지 속도처럼 나빠지면 안 되는 지표(가드레일)를 함께 본다.
• 표본 수: 잡아내고 싶은 최소 차이를 정하면 필요한 사람 수가 나온다. Evan Miller의 경험식은 변형마다 n ≈ 16σ²/δ²이고, 전환율이면 σ² = p(1 − p)다. 16은 대략 2 × (1.96 + 0.84)²로, 유의 수준 5%(양측)와 검정력 80%에 맞춘 값이다.
• 중간에 엿보지 않기: 결과를 여러 번 들여다보다 유의해 보이는 순간 멈추면, 실제로는 차이가 없어도 "이겼다"고 판정할 확률이 명목 5%보다 훨씬 커진다. 표본 수를 미리 정하고 끝까지 돌리거나, 처음부터 중간 확인을 허락하는 순차 검정을 쓴다.

기준 전환율이 5%일 때 2%p 차이에는 변형마다 약 1,900명, 1%p 차이에는 변형마다 약 7,600명, 0.5%p 차이에는 변형마다 약 30,400명이 필요하다. 차이를 절반으로 줄이면 표본은 네 배가 된다. 그래서 하루 방문자가 적은 서비스에서 작은 문구 차이를 A/B로 가리려 하면 몇 달이 걸리고, 그럴 때는 사용성 테스트가 더 빠른 답이다.

UX 지표: HEART, 퍼널, 그리고 NPS의 함정

출시한 제품의 경험을 숫자로 따라가려면 무엇을 셀지부터 정해야 한다. Google의 Rodden·Hutchinson·Fu가 2010년에 발표한 HEART는 다섯 범주를 둔다. 행복(Happiness, 만족 같은 태도), 참여(Engagement, 얼마나 자주·깊이 쓰나), 채택(Adoption, 새로 쓰기 시작한 사람), 유지(Retention, 다시 오는 사람), 과제 성공(Task success, 효과와 효율)이다. 범주마다 목표 → 신호 → 지표(Goals-Signals-Metrics) 순서로 정한다. 무엇을 바라는지, 그것이 이뤄지면 행동이나 태도에서 무엇이 보일지, 그것을 어떻게 셀지다.

논문은 모든 범주를 다 쓸 필요는 없지만 빼는 것도 의식적으로 정하라고 한다. 업무용 도구에서는 일이라서 쓰므로 참여가 별 의미가 없을 수 있다. 참여 지표는 합계가 아니라 사용자당 평균으로 보라는 조언도 있다. 합계는 사용자가 늘어도 오르기 때문이다.

여러 단계를 거치는 과제는 퍼널(funnel)로 본다. 단계마다 남은 사람 수를 세고, 앞 단계 대비 비율을 적는다. 아래 예의 최종 전환율은 12.6%지만, 가장 많이 빠지는 곳은 상품 보기에서 장바구니로 가는 구간(32%만 넘어감)이다. 퍼널은 어디서 빠지는지만 알려 주고 왜 빠지는지는 알려 주지 않는다. 그 구간을 사용성 테스트로 들여다본다.

NPS(Net Promoter Score)는 "이 제품을 친구에게 추천할 가능성은?"을 0~10점으로 물어, 9~10점(추천) 비율에서 0~6점(비추천) 비율을 뺀 값이다(−100~100). Bain의 Fred Reichheld가 2003년 Harvard Business Review 글로 널리 알렸다. 질문 하나라 편하지만 비판도 많다. 성장을 예측한다는 주장은 연구로 엇갈리고, 7~8점은 계산에서 아예 빠지며, 무엇이 문제인지는 아무것도 알려 주지 않는다. 아래 두 집단은 전혀 다르지만 NPS는 똑같다. NPS를 쓴다면 분포와 이유를 묻는 열린 질문을 함께 본다.

다크 패턴: 지표가 속이는 쪽으로 자랄 때

사용자가 원하지 않는 일을 하도록 유도하는 설계를 다크 패턴(요즘은 기만적 설계 패턴, deceptive pattern)이라 한다. 유형 목록과 원리는 HCI와 UX 노트에 있고, deceptive.design은 어려운 해지, 사전 선택, 숨은 비용, 헷갈리는 문구, 컨펌셰이밍(거절하는 쪽에 죄책감을 주는 문구), 끈질긴 재촉 등 18가지를 든다. 평가의 관점에서 중요한 것은 다크 패턴이 A/B 테스트에서 이긴다는 점이다. 해지 단계를 늘리면 해지율이 내려가고, 미리 체크해 두면 동의율이 오른다. 그래서 단기 지표만 보는 팀에서 저절로 자란다.

규제도 생겼다. 미국 연방거래위원회(FTC)는 2022년 9월 보고서 Bringing Dark Patterns to Light를 내고 점점 정교해지는 다크 패턴을 경고했다. 한국은 개정 전자상거래법이 2025년 2월 14일부터 시행되면서 여섯 유형을 규제한다(공정거래위원회 문답 보도). 정기 결제 금액을 올리거나 무료에서 유료로 바꿀 때 따로 동의를 받지 않는 숨은 갱신, 처음에는 일부 가격만 보이는 순차 공개 가격 책정, 특정 옵션의 사전 선택, 선택지를 치우치게 보이는 잘못된 계층 구조, 취소·탈퇴를 불필요하게 복잡하게 만드는 방해, 반복 간섭이다. 위반하면 시정 조치를 받고 최대 500만 원을 물 수 있다.

막는 방법은 평가 기준에 사용자의 이익을 넣는 것이다. 리뷰 점검표에 "해지가 가입만큼 쉬운가", "선택 항목이 기본으로 꺼져 있나", "거절 버튼이 승낙 버튼과 같은 무게인가", "첫 화면 가격이 결제 금액과 같은가"를 두고, A/B 테스트의 가드레일 지표에 환불·문의·해지 후 재가입 같은 신뢰 신호를 넣는다.

접근성 감사: 자동 검사는 시작일 뿐이다

접근성 감사(accessibility audit)는 제품이 WCAG 같은 기준을 얼마나 지키는지 체계적으로 확인하는 일이다. W3C의 평가 방법론 WCAG-EM은 다섯 단계를 둔다. 평가 범위 정하기, 대상 둘러보기, 대표 표본(페이지·화면·과제) 고르기, 표본 평가하기, 결과 보고하기다. 이 방법론도 대부분의 검사는 완전히 자동화할 수 없다고 적는다.

자동 도구가 얼마나 찾는지는 실험이 있다. 영국 정부 디지털 서비스 팀은 일부러 장벽 143개를 넣은 페이지에 자동 검사 도구 10개를 돌렸다(GOV.UK 접근성 블로그). 가장 잘 찾은 도구가 수동 확인 안내까지 쳐서 41%, 도구를 다 합쳐도 42개(29%)는 어느 도구도 찾지 못했다. 결론은 자동 도구가 쓸모는 있지만 그것만으로는 접근성을 확인할 수 없다는 것이다.

수동 점검에서는 마우스를 치우고 키보드만으로 주요 과제를 끝까지 해 본다(초점이 보이나, 순서가 맞나, 갇히지 않나). 화면을 200%로 확대해 글자가 잘리지 않는지 보고, 스크린 리더로 들으며 버튼 이름과 상태가 제대로 읽히는지 확인한다. 감사 결과는 사용성 문제처럼 심각도를 매기고, "누가 무엇을 못 하게 되나"로 적어야 고치는 순서가 선다.

흔한 오해

• "5명이면 문제를 다 찾는다." 5명은 한 차례의 크기다. 한 명이 문제의 31%를 찾는다는 가정에서 약 84%를 찾고, 고친 뒤에는 고친 것이 통하는지와 새로 생긴 문제를 다시 봐야 한다. 15명을 쓸 수 있다면 5명씩 세 번이 낫고, 사용자 집단이 다르면 집단마다 따로 본다.
• "SUS 70점이면 상위 30%다." SUS는 백분율이 아니다. 70점은 평균 68점 근처다.
• "휴리스틱을 어기면 무조건 고친다." 위반은 의심할 곳이지 판결이 아니다. 맥락과 대안을 따지고, 애매하면 사용자로 확인한다.
• "A/B에서 이긴 설계가 좋은 설계다." 다크 패턴도 이긴다. 주 지표와 함께 가드레일 지표를 보고, 이긴 이유를 설명할 수 있어야 한다.
• "자동 검사를 통과했으니 접근성은 됐다." 자동 도구를 다 합쳐도 장벽의 약 29%는 아무도 못 찾았다. 키보드·스크린 리더 점검과 사용자 테스트가 필요하다.
• "NPS 하나면 UX를 잰다." 분포가 전혀 다른 집단이 같은 점수가 되고, 무엇을 고칠지는 알려 주지 않는다.
• "UX 라이팅은 글을 짧게 줄이는 일이다." 목표는 뜻 없는 말을 빼는 것이다. 결과를 미리 알리는 한 줄처럼 길어져도 필요한 말은 넣는다.
• "사용자에게 어떤 게 좋은지 물어보면 된다." 선호를 묻는 답은 실제 행동과 다를 수 있고, 말하면서 생각을 걸러 내기도 한다. 묻기보다 과제를 주고 하는 것을 본다.

핵심 자료

사람의 지각·인지 원리와 휴리스틱 목록은 HCI와 UX 노트, 검정과 신뢰 구간은 데이터 엔지니어링 노트, 게임에서의 플레이테스트는 게임 UX 글에 있다.