설치가 성공하는 예제만 있는 기술 도구 설명서를 생각해 보자. 실패 이후의 안내가 없다면 사용자는 어느 단계가 막혔는지부터 추측해야 한다. 명령을 순서대로 복사하는 데까지는 친절했는데, 결과가 예제와 달라지자 설명이 끝난다. 실패한 사용자에게 성공 화면을 다시 보여줘도 다음 동작을 알려줄 수는 없다.
가령 설정 조회 명령이 값을 찾지 못했다고 하자. 설정을 아직 저장하지 않았을 수도 있고, 다른 이름으로 조회했을 수도 있다. 접근 권한이 없는 경우에도 같은 메시지가 나오는 도구라면 구분은 더 어렵다. 여기에 다시 실행하라는 말만 붙이면 사용자는 같은 질문을 반복한다. 무엇을 확인하면 원인을 가릴 수 있는지부터 적어야 한다.
이 가상의 도구에 실패 안내를 쓴다면 조회에 쓴 이름과 저장된 설정을 대조하는 방법을 먼저 보여줄 수 있다. 이름이 다를 때와 저장된 값이 없을 때의 다음 동작도 나눈다. 접근 거부라면 사용자에게 권한을 바꾸라고 하기 전에 담당자에게 확인할 내용을 적는다. 실제 제품에 이 절차를 그대로 적용하자는 뜻은 아니다. 문서 작성자가 실제 출력과 상태를 대조해 갈림길을 만들고 확인해야 한다.
그 안내에는 어디까지 실행됐는지도 들어가야 한다. 값을 읽는 명령과 값을 바꾸는 명령에 똑같이 다시 시도하라고 쓰면, 변경 결과를 확인할 책임이 사용자에게 넘어간다. 변경 명령이라면 오류 메시지 뒤에 실제 설정을 확인하는 방법을 붙인다. 성공 화면과 오류 화면 사이에서 끝나버린 설명을 그다음 상태 확인까지 이어 쓰는 것이다.
모든 오류를 나열하자는 말은 아니다. 대표적인 실패부터 사용자가 확인할 수 있는 범위와 더 진행하지 말아야 할 조건을 정하면 된다. 원인을 구분할 방법이 없다면 미확인이라고 쓰고, 문의할 때 필요한 출력과 상태를 적는다. 다음 동작이나 담당자에게 넘기는 조건 없이 오류 이름만 길게 모으면 사용자는 긴 목록 앞에서도 무엇을 할지 골라야 한다.
실패 시나리오를 넣었다는 사실만으로 설명서의 효용이 입증되지는 않는다. 도구가 바뀌면 예전 오류 문구와 복구 방법이 맞지 않을 수 있고, 안내를 따라가도 같은 지점에서 막힐 수 있다. 수정한 문서를 실제로 따라가며 갈림길이 맞는지 확인해야 한다. 설명서가 성공한 사용자에게만 친절하다면 실패를 처리하는 일은 여전히 독자에게 남는다.