사용자를 생각하게 하지마_기본예절로서의 사용성
아 이거 왜 이따구로 만들어놨어!
우리 모두는 이런 경험을 가지고 있을 것이다.
웹사이트든 앱이든 딱 들어갔는데
내가 원하는 걸 어디서 찾아야 하는지 모르겠다던지,
큰 카테고리는 찾았는데 그 안에서 세부적인 부분에서 막힌다던지.
그럴 때 속으로 외친다. "아 이거 왜 이따구로 만들어놨어!"
스티브 크룩(애플, 렉서스 등의 사용성 컨설턴트)은 비행기를 예약했다.
근데 알고보니 비행기를 타는 날이 항공사와 노조 간 단체교섭의 마지막 날이었다. 회사와 노조가 합의가 이르렀는지 일정대로 비행기를 탈 수 있는건지 당연히 궁금했고 웹 사이트에 들어갔다. FAQ 목록을 꼼꼼히 보았지만 파업에 대한 언급 조차 없었다.
파업이 진짜 일어날 것인지, 현재 교섭 진행 상황은 어떤지, 파업이 시작되면 어떤 상황이 벌어질 것인지, 항공권을 다시 예약하려면 어떻게 해야 하는지 등 너무 궁금했지만 해결할 수 없었다.
이 과정을 겪는 동안 크룩의 호감도는 아래와 같이 바사삭된다.
스티브 크룩의 책 대부분에서는 "사용자가 보기에 명료한가?, 이해하기 어렵지 않은가?"와 같이 웹, 앱을 명료하게 만드는 방법에 대해 계속 논했다.
하지만 사용성을 구성하는 또 다른 주요 요소가 있는데 바로 "내 사이트가 예의 바르게 작동하고 있는가?"와 같이 사용자에 대한 배려심을 갖춘 행동을 하는지 여부이다. 이 부분은 웹/앱에 대한 사용자의 호감도와도 직결된다.
이번 파트에서 다룬 사용자의 호감이 줄어드는 요인들과 사용자의 호감을 키우는 요인들에 대해 공유해보려 한다. 호감을 키우는 요인을 확보하는 것도 너무 중요하지만, 효감이 줄어드는 요인을 제거하는 것도 너무 중요하다.
1. 사용자가 원하는 정보 숨겨둘 때
2. 자신이 원하는 방식대로 하지 않는다고 사용자 귀찮게 할 때
3. 필요하지도 않은 정보 물어볼 때
4. 가식적인 표현으로 사용자 기만할 때
5. 홍보용 장치로 작업 방해할 때
6. 사이트가 아마추어 수준으로 보일 때
1. 사용자가 사이트에서 가장 많이 하는 활동을 알아내어,
그 부분을 명확히 드러내고 쉽게 사용할 수 있게 할 때
2. 사용자가 알고자 하는 정보를 공개할 때
3. 사용자의 수고를 최대한 줄여줄 때
4. 노력을 쏟아부을 때
5. 궁금해할 만한 사항을 예측하고 그에 대한 답을 제시할 때
6. 인쇄용 페이지처럼 편의성을 높여주는 요소를 제공할 때
7. 오류가 발생했을 때 쉽게 회복할 수 있게 할 때
8. 해결하지 못한 문제가 있을 때는 사과할 때
최근 어떤 웹사이트를 이용하며 불편한 부분이 있었는데, 그 부분을 호감 바사삭 예시로 사용할까 하다가 올리지 않았다. 대신 호감 키우는 예시를 발견해서 덧붙인다.
지난 폭우때도 네이버가 '실시간 기상 상황'을 통해 지역별로 자신이 위치한 곳의 기상 상황을 사진 혹은 텍스트로 공유할 수 있는 판을 깔아주는 것을 보고 감탄했다.
폭우가 얼마 지나지 않아 또 태풍 소식이 있어 걱정되어 관련 기사를 찾아보기 위해 네이버에 들어갔다.
좌측 이미지는 9월 5일 월요일 새벽 1시 네이버 홈화면 우측 이미지는 9월 5일 월요일 오후 1시 네이버 홈화면의 모습이다.
호감을 키우는 요인 1-5번에 다 해당되는 기획이 아닌가 생각된다.
1. 사용자가 (특정 기간동안) 사이트에서 가장 많이 (검색) 하는 활동을 알아내어, 그 부분을 명확히 드러내고 쉽게 사용할 수 있게 할 때
2. 사용자가 알고자 하는 정보를 공개할 때 = 사용자가 알고자 하는 힌남노에 대한 정보 (비가 얼마나 오는지, 바람은 얼마나 부는지, 밖에 돌아다녀도 되는건지, 차를 끌고 나가도 되는건지)
3. 사용자의 수고를 최대한 줄여줄 때 = 실검이 없어지고 나서 이제 사용자는 궁금한 키워드를 직접 검색해봐야 한다. 저렇게 홈화면에 딱 있으면 너무 편하다 클릭만 하면 되니까.
4. 노력을 쏟아부을 때 = 불과 12시간만에 로고 디자인도 덧붙여지고 카피 라이팅도 바꼈다.
5. 궁금해할 만한 사항을 예측하고 그에 대한 답을 제시할 때 = 그렇다 궁금해할 만한 사항을 예측해 그에 대한 답을 너무 편한 위치에 떡하니 제시해줬다.
제보톡에 들어가면 지난 폭우때처럼 지역별로 실시간 채팅이 가능하다.