웹사이트를 만들 때 사용자 관점에서 점검할 것들

 

웹사이트를 만들다 보면 만드는 사람의 눈으로는 다 괜찮아 보이는데, 처음 오는 사람에게는 낯선 경우가 많았어요.
그래서 출시 전에 사용자 관점에서 한 번 훑어보는 체크 항목을 만들어 두면 좋겠다고 생각했습니다.
오늘은 목적, 탐색, 가독성, 접근성, 속도 다섯 가지로 나누어 정리해 볼게요.
정답이라기보다 제가 쓰는 점검표에 가깝습니다.

 

 

첫째, 목적이 한눈에 보이는가

 

사용자가 처음 들어와서 몇 초 안에 이곳이 무엇을 하는 곳인지 알 수 있어야 합니다.
첫 화면의 문구와 이미지가 이 질문에 답하고 있는지 봐요.

점검 방법은 간단합니다.
이 사이트를 처음 보는 사람 한 명에게 첫 화면을 5초 정도 보여 주고 닫은 뒤, 무엇을 하는 곳 같았는지 물어봅니다.
가상의 예로 어떤 사람이 "예약하는 곳인지 구경하는 곳인지 모르겠어요"라고 답했다면, 첫 화면의 문구나 버튼 우선순위를 다시 봐야 한다는 신호예요.

그리고 사용자가 해야 할 가장 중요한 행동이 눈에 띄는지도 확인합니다.
화면에 선택지가 너무 많으면 사람들은 아무것도 고르지 않고 나가기 쉬워요.

 

 

둘째, 원하는 곳을 찾아갈 수 있는가

 

탐색은 메뉴 구성과 이름이 좌우합니다.
만든 사람에게 익숙한 용어가 사용자에게는 낯선 말일 수 있어요.

저는 메뉴 이름을 내부에서 쓰는 말이 아닌, 사용자가 검색창에 쓸 법한 말로 바꿔 보는 것을 좋아합니다.
그리고 어떤 페이지에 있든 지금 내가 어디에 있는지, 어떻게 돌아가는지가 보여야 합니다.
상단 메뉴에서 현재 위치 표시를 해 주거나, 상세 페이지에서 상위 목록으로 돌아가는 길을 두는 식이에요.

점검할 때는 과제를 하나 주고 따라가 보게 합니다.
예를 들어 "이 사이트에서 환불 규정을 찾아보세요"라고 하고 몇 번 클릭해서 도착하는지 보는 거예요.
세 번 이내에 찾지 못하면 구조나 이름을 의심해 봅니다.
이때 돌아다니는 경로를 기록해 두면 어느 이름이 혼란을 주었는지 알 수 있어요.

 

 

셋째, 읽기 편한가

 

가독성은 글자 크기, 줄 간격, 대비, 한 줄의 길이 같은 것들로 만들어집니다.
디자인 시안에서 예뻐 보이는 옅은 회색 글자가 실제 화면에서는 읽기 힘든 경우가 정말 많았습니다.

저는 두 가지를 꼭 확인해요.
밝은 야외에서 휴대전화로 봐도 글자가 읽히는가.
긴 글이 한꺼번에 덩어리로 나오지 않고 소제목과 짧은 문단으로 나뉘어 있는가.

글 내용도 가독성의 일부입니다.
한 문장이 너무 길거나 업계 용어가 설명 없이 나오면 아무리 글자가 커도 읽기 어려워요.
가능하면 한 문장에 한 가지 내용만 담으려고 합니다.

 

 

넷째, 누구나 쓸 수 있는가

 

접근성은 일부 사용자만을 위한 것이 아니라 모든 사용자의 편의와 이어집니다.
시력이 낮은 사람, 색을 구별하기 어려운 사람, 마우스를 쓰기 어려운 사람, 한 손으로만 쓰는 사람 모두가 대상입니다.

기본적인 점검 항목을 정리해 봅니다.
이미지에 대체 설명이 있는가.
색만으로 정보를 구분하고 있지는 않은가.
키보드만으로 주요 기능을 쓸 수 있는가.
터치할 버튼이 손가락으로 누르기에 충분히 큰가.

예를 들어 오류 메시지를 빨간색 글자만으로 표시했다고 가정해 봅시다.
색을 구별하기 어려운 사람은 오류가 있다는 사실을 놓칠 수 있어요.
아이콘이나 "입력이 필요합니다" 같은 문구를 함께 넣으면 해결됩니다.
접근성과 관련한 세부 기준이나 의무 사항은 확인이 필요한 영역이라, 구체적인 기준 문서를 따로 찾아서 맞춰 봐야 해요.

 

 

다섯째, 빠르게 열리는가

 

속도는 사용자가 기다려 주는 시간과 직결됩니다.
느린 화면은 아무리 좋은 내용이어도 보여 주기 전에 사용자를 잃게 만들어요.

기획자가 직접 최적화를 하지는 못해도 점검은 할 수 있습니다.
첫 화면에 꼭 필요하지 않은 큰 이미지가 있는지, 영상이 자동으로 재생되는지, 광고나 외부 도구가 너무 많이 붙어 있지는 않은지 확인해 봐요.
그리고 빠른 인터넷 환경이 아닌 곳에서도 열어 봅니다.
사무실 와이파이에서는 빨랐는데 이동 중 휴대전화에서는 한참 걸리는 경우가 흔합니다.

속도 문제는 개발자와 함께 풀어야 하니, 느린 구간을 구체적으로 짚어서 전달하면 대화가 쉬워져요.

이 다섯 가지를 일정에 넣는 방법도 적어 둘게요.
점검은 마음먹은 날 한 번에 몰아서 하면 대개 흐지부지됩니다.
저는 출시 일주일 전쯤에 두 시간을 따로 잡고, 항목마다 담당자를 정하는 방식이 가장 잘 돌아갔어요.

예를 들어 가상의 팀에서 기획자는 목적과 탐색을, 디자이너는 가독성과 접근성을, 개발자는 속도를 맡는다고 해 봅시다.
각자 자기 항목을 점검하되, 결과는 한 장의 표로 모아서 심각도를 표시합니다.
심각한 것은 출시 전에 고치고, 가벼운 것은 다음 개선 목록으로 넘기는 식이에요.

이렇게 하면 점검이 비난이나 흠 찾기가 아니라 같이 품질을 올리는 일이 됩니다.
점검표는 한 번 만들어 두고 서비스가 바뀔 때마다 조금씩 고쳐 쓰면 됩니다.

 

 

다섯 가지 점검은 새로운 이야기라기보다 놓치기 쉬운 기본을 다시 상기시키는 목록이라고 생각합니다.
출시 일정에 쫓길수록 이 목록을 건너뛰게 되니, 일정표에 점검 시간을 미리 넣어 두는 것이 중요한 것 같아요.

아직 궁금한 것도 있습니다.
점검에 쓸 사용자를 팀 밖에서 구하기 어려울 때, 팀 안의 사람으로 어디까지 대신할 수 있을까요.
그리고 다섯 가지 중 시간이 부족할 때는 무엇부터 지켜야 할까요.
이 질문에 대한 저만의 우선순위를 다음 프로젝트에서 한 번 시험해 보려고 합니다.