1
00:00:00,000 --> 00:00:01,000
개발을 하다

2
00:00:01,000 --> 00:00:03,000
보면, 같은 오류가 반복해서 뜰 때마다

3
00:00:03,000 --> 00:00:05,000
문득 이런 생각이 들었습니다.

4
00:00:05,000 --> 00:00:09,000
이 문제를 겪는 사람이 정말 사용자일까, 아니면 우리가 만든 화면일까.

5
00:00:09,000 --> 00:00:15,000
도널드 노먼의 『The Design of Everyday Things』를 4회차까지 읽으면서, 특히 5장을 중심으로

6
00:00:15,000 --> 00:00:17,000
그 질문이 조금씩 구체화됐습니다.

7
00:00:17,000 --> 00:00:22,000
UX와 UI를 다루는 개발자로서, 나는 그동안 오류를 주로 코드의 예외 상황으로만 바라보고 있었습니다.

8
00:00:22,000 --> 00:00:27,000
try-catch로 잡고, validation으로 막고, 메시지로 안내하면 된다고 생각했죠.

9
00:00:27,000 --> 00:00:30,000
그런데 이 책은 그 생각의 반을 뒤집어 놓았습니다.

10
00:00:30,000 --> 00:00:32,000
책이 말하는 핵심은 간단합니다.

11
00:00:32,000 --> 00:00:38,000
사용자가 반복해서 실수한다면, 그것은 대개 개인의 부주의가 아니라 시스템이 실수를 유도하거나, 실수한 뒤에 돌아오기

12
00:00:38,000 --> 00:00:40,000
어렵게 만든 결과라는 것입니다.

13
00:00:40,000 --> 00:00:44,000
실행 실수와 판단 실수를 구분하고, 위험한 행동에는 강제로 제어하는 장치를 두며, 무엇보다

14
00:00:44,000 --> 00:00:46,000
완벽한 예방보다

15
00:00:46,000 --> 00:00:48,000
빠른 복구를 가능하게 하라는 이야기였습니다.

16
00:00:48,000 --> 00:00:53,000
읽으면서 가장 불편했던 부분은, 에러 메시지를 우리가 얼마나 대충 써왔는지 깨닫게 된 점이었습니다.

17
00:00:53,000 --> 00:00:58,000
“오류가 발생했습니다”라는 문구는 사실 사과처럼 보이면서도 아무것도 해결해주지 않습니다.

18
00:00:58,000 --> 00:01:04,000
사용자는 무엇이 잘못됐는지, 왜 막혔는지, 지금 무엇을 할 수 있는지, 심지어 자신의 데이터가 안전한지도 알지 못한

19
00:01:04,000 --> 00:01:06,000
채로 남겨집니다.

20
00:01:06,000 --> 00:01:10,000
그 문구 하나가 결국 “사용자가 잘못했다”는 신호로 작동하고 있었던 셈이죠.

21
00:01:10,000 --> 00:01:16,000
반대로 가장 공감했던 지점은, 좋은 설계는 오류가 생기기 어려운 흐름 자체를 만드는 일이라는 생각이었습니다.

22
00:01:16,000 --> 00:01:22,000
버튼 위치, 색상, 확인 단계, 실행 취소 가능성까지 모두가 실수를 막는 장치가 될 수 있다는 점을, 나는 그동안

23
00:01:22,000 --> 00:01:24,000
너무 가볍게 여겼던 것 같습니다.

24
00:01:24,000 --> 00:01:28,000
이 회차를 읽고 나서, 지금 진행 중인 화면 하나를 다시 들여다보게 됐습니다.

25
00:01:28,000 --> 00:01:34,000
삭제 버튼 근처에 있던 확인 단계가 사실은 너무 약했고, 실행 실수와 판단 실수를 구분해서 메시지를 다르게 보여주지

26
00:01:34,000 --> 00:01:35,000
않았더군요.

27
00:01:35,000 --> 00:01:41,000
로그를 볼 때도 “버그를 고치자”는 관점에서 멈추지 않고, “이 오류가 사용자에게 어떤 단서를 주지 못했는지”까지

28
00:01:41,000 --> 00:01:43,000
보기로 했습니다.

29
00:01:43,000 --> 00:01:47,000
그리고 파괴적인 행동에는 undo나 지연 삭제를 먼저 검토하는 습관을 붙이기로 했습니다.

30
00:01:47,000 --> 00:01:49,000
이 책은 특히 화면을 만들 때마다

31
00:01:49,000 --> 00:01:53,000
사용자가 어디서 멈추는지 궁금해하는 개발자에게 의미 있을 것 같습니다.

32
00:01:53,000 --> 00:01:59,000
에러 메시지를 그저 친절하게 다듬는 데서 그치지 않고, 흐름 자체를 다시 설계하고 싶은 사람에게 더 강하게 남을

33
00:01:59,000 --> 00:02:00,000
테니까요.

34
00:02:00,000 --> 00:02:06,000
사용자가 실수하지 않게 만드는 가장 좋은 방법은 사용자를 더 조심하게 만드는 것이 아니라, 실수하기 어려운 구조를

35
00:02:06,000 --> 00:02:08,000
만드는 것이다.

36
00:02:08,000 --> 00:02:14,000
우리 제품에서 사용자가 가장 자주 멈추는 화면은 어디이고, 그 문제를 교육과 문서로 해결할 일인지, 아니면 화면의

37
00:02:14,000 --> 00:02:15,000
단서와 피드백을 고칠 일인지, 다음에 다시 물어보게 될 것 같습니다.