일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- React Native
- 머신러닝
- 모두의 네트워크
- 깃허브 로그인
- 딥러닝
- 자바
- 정리
- 백준
- SQL
- 데베
- 백준 4358 자바
- 리액트 네이티브 시작하기
- 모두를위한딥러닝
- 백준 5525번
- 지네릭스
- 백준 4358번
- 깃 연동
- HTTP
- 깃허브 토큰 인증
- 모두의네트워크
- 백준 4949번
- 팀플회고
- 리액트 네이티브
- 깃 터미널 연동
- 문자열
- 리액트 네이티브 프로젝트 생성
- 스터디
- 모두를 위한 딥러닝
- 네트워크
- 데이터베이스
- Today
- Total
솜이의 데브로그
3장 ) 사용자와 소통하는 에러 메시지 쓰기 본문
1. 에러메시지를 쓰기 전에 에러부터 없애자
친절한 404, 불친절한 404
사용자가 보는 화면은 UI/UX 디자이너가 만든 것이다. 따라서 사용자는 개발자의 산출물 그 자체를 볼 수는 없다.
사용자가 개발자의 산출물을 볼 때는 바로 에러 메시지가 뜰 때다. 대표적으로, HTTP 404 에러인 "요청하신 페이지를 찾을 수 없습니다" 페이지이다.
- 404 에러 : 클라이언트가 서버와 통신할 수는 있지만 서버가 요청한 페이지를 찾을 수 없다는 것을 가리키는 HTTP 표준 응답 코드.
- 구글에 찾아보면 여러 사이트들의 404 에러 페이지가 나온다. 해당 페이지는 그저 찾을 수 없다고 표시하기만 하거나 (구글), 사용자가 의도한 URL을 추측해 제안하거나(위키피디아), 또는 고객센터 링크를 덧붙인다(다음, YES24 등).
다양한 에러 페이지들
그러나 근본적으로 404 에러를 만나지 않도록 만드는 것이 가장 우선이다.
사용자가 404 에러 페이지를 만나는 경우는 다음 두가지가 있다.
- 사용자가 URL을 잘못 입력한 경우
- 사용자가 링크를 클릭했으나 해당 페이지가 없는 경우 → 깨진 링크, 죽은 링크, 나쁜 링크라고 한다.
깨진 링크는 개발자의 책임이다
- 사이트 안에서 링크로 연결되다 깨진 것은 깨진 링크를 찾아내는 서비스를 이용하면 확인할 수 있다.
- Ex ) 브로큰링크체크닷컴(https://www.brokenlinkcheck.com)
- 다른 사이트에서 연결된 링크가 깨진 경우 더 큰 문제이다. 특히 검색 엔진이 페이지를 수집했는데 이후 페이지 url이 바뀌거나 삭제되었는데도 연결하는 경우
- → 검색엔진마다 제공하는 도구를 사용하면 깨진 링크를 없앨 수 있다. ex) 구글 서치 콘솔
- 깨진 링크를 확인해 하나씩 수정하면 404 페이지를 줄일 수 있다.
개발자용 에러 메시지와 사용자용 에러 메시지를 분리하자
(ㅎㅎ전공에서 아주 강조하는 부분)
- 처음부터 개발자용 에러 메시지와 사용자용 에러 메시지를 분리해 작성하는 것이 좋다.
- ex) C에서 #define 전처리기를 이용해 매크로로 처리하면 쉽게 관리 할 수 있다.
2. 사용자 에러 메시지를 제대로 쓰는법
사용자가 개발자의 의도대로 프로그램을 사용하지 않는 경우, 알림창을 이용해 에러가 발생했음을 알리는 메시지를 보여줘서 사용자가 바른 행동을 하도록 유도한다.
ex) 회원가입 시 아이디를 잘못 입력하거나 입력하지 않고 넘어가는 경우.
적절한 메시지란?
- 에러 내용 : 오류로 인한 문제와 종류
- 에러의 원인 : 오류를 발생시킨 직접적이고 근본적인 원인
- 에러 해결 방법: 사용자가 오류를 해결할 가장 쉽고 빠른 방법.
3. 사용자의 에러를 줄이는 메시지 구조화
윈도우에서는 확인이 먼저 나오고 그 다음에 취소가 나온다.
macOS에서는 취소-확인 순서로 나온다.
확인이 오른쪽에 있는 이유는 행동의 연속성 때문이다.
현 시점에는 국가나 서비스마다 순서가 다르기 때문에, OS의 순서를 따르기 보다는 서비스 내에서 일관성을 가지는 것이 좋다. 그래야 사용자 경험이 어긋나지 않는다.
⇒ 서비스에 따른 UI/UX
사용자의 반복 에러를 막는 법
ex) 반복하여 로그인 실패를 하는 경우, 다섯번 째 시도에서는 에러 메시지를 다르게 출력하며 자동 입력 방지 문자를 입력할 것을 요구한다. 해킹하려는 의도일 수 있기 때문.
- 개발자는 사용자가 최소한의 시도로 로그인에 성공하도록 해야한다. → 사용자에게 앞으로 남은 로그인 횟수를 메시지로 보여준다.
4. 에러 메시지 대신 예방 메시지를 쓰자
에러를 줄이려면 개발자도 사용자의 사용 방식을 이해해야 한다.
사용자가 어떻게 사용할지를 충분히 이해하고 조사하고 분석해야 에러를 줄일 방법을 찾을 수 있다.
예시 목록
- 사용자가 선택 할 수 없는 영역은 비활성화하고 흐린 색으로 표시한다.
- 긴 숫자를 입력할 때 (신용카드 등) 4자리씩 나누어 입력하도록 한다.
- 이메일 '@' 뒷부분 부터는 사용자가 선택 할 수 있도록 한다.
- 로그인 시 Caps Lock이 켜져있는 경우 그 사실을 미리 알려준다.
- 스마트폰 디바이스에서 특정 앱이 배터리를 과다하게 사용할 경우 이 사실을 알려준다.
개발자는 에러메시지를 쓰기 전에 그 메시지가 꼭 필요한 것인지, 본래 역할을 제대로 수행하는지 고려해야 한다.
느낀점
책을 읽다보니 지금 수강하고 있는 '사용자경험과 인간중심 디자인' 수업 내용과 겹치는 부분도 어느정도 있어서 신기하다. UI/UX 를 디자인 할 때 내용과, 개발자의 입장에서 서비스를 만들 때 사용자의 경험을 이해하고 만들어야한다는 내용이 같은 베이스라서 그런 듯 하다.
어쨌든 웹이든 앱이든 서비스를 만들 때 있어서는 결국 '사용자'가 이용하기 편리한 서비스를 만들어야하므로, 사용자 입장에서 충분히 고려하고 개발자의 입장에서도 절차를 간소화 할 수 있는 방법을 선택하는 것이 베스트인 것 같다.
에러메시지 역시 전공에서 보안관련 위주로 배우기 때문에 최소한의 내용만 출력하라고 배웠는데, 사용자의 입장을 고려한 에러메시지 역시 고민해야함을 한번 더 느낀다. 서비스 개발은 참 고려해야 할 부분이 많은 것 같다.
'책을 읽자 > 개발자의 글쓰기' 카테고리의 다른 글
6장 ) 수주를 돕는 SI 제안서 쓰기 (0) | 2021.11.15 |
---|---|
5장 ) 개발 가이드 쓰기 (0) | 2021.11.04 |
4장 ) 릴리스문서와 장애보고서 쓰기 (0) | 2021.11.04 |
2장 ) 이름 짓기와 주석 쓰기 (0) | 2021.10.12 |
1장) 글쓰기 기본 (0) | 2021.10.12 |