1
00:00:00,000 --> 00:00:04,000
이 책을 읽기 시작한 건, 우리 팀이 만든 화면 하나 때문이었습니다.

2
00:00:04,000 --> 00:00:10,000
출시 후 일주일도 안 돼서 “이 버튼이 왜 여기에 있죠?”라는 질문을 받았고, 그 순간 문득 이런 생각이

3
00:00:10,000 --> 00:00:11,000
들었습니다.

4
00:00:11,000 --> 00:00:16,000
우리가 정말로 고민한 건 사용자의 행동이었을까, 아니면 그냥 예쁘게 보이는 결과물이었을까.

5
00:00:16,000 --> 00:00:21,000
The Design of Everyday Things를 다시 펼친 이유가 거기에 있습니다.

6
00:00:21,000 --> 00:00:27,000
돈 노먼의 책은 원래 문손잡이와 스위치로 유명하지만, 이번 5회차에서 다루는 6장과 7장은 개발자에게 훨씬 더

7
00:00:27,000 --> 00:00:28,000
날카로운 질문을 던집니다.

8
00:00:28,000 --> 00:00:31,000
좋은 설계 원칙이 실제 제품 조직에서는 왜 자꾸 밀려나는가.

9
00:00:31,000 --> 00:00:38,000
디자인은 한 번의 멋진 해결이 아니라, 관찰하고 문제를 다시 정의하고 실험하는 과정을 조직이 반복할 수 있느냐의

10
00:00:38,000 --> 00:00:40,000
문제라는 점을 이번 회차는 분명히 보여줍니다.

11
00:00:40,000 --> 00:00:44,000
읽기 전에 나는 UX를 디자이너가 건네주는 산출물 정도로 생각하고 있었습니다.

12
00:00:44,000 --> 00:00:46,000
개발자는 그걸 구현만 하면 된다고.

13
00:00:46,000 --> 00:00:48,000
그런데 이 책은 그 가정을 흔들었습니다.

14
00:00:48,000 --> 00:00:55,000
디자인 사고는 발산하고 수렴하는 반복 구조이고, double diamond라는 말로 표현되기도 하지만, 결국 중요한

15
00:00:55,000 --> 00:00:58,000
건 처음에 정의한 문제가 거의 항상 틀렸거나 너무 좁다는 사실입니다.

16
00:00:58,000 --> 00:01:03,000
그래서 좋은 팀은 요구사항을 바로 티켓으로 만들기 전에, 관찰과 재정의를 먼저 합니다.

17
00:01:03,000 --> 00:01:04,000
문제는 현실입니다.

18
00:01:04,000 --> 00:01:07,000
일정, 예산, 레거시 코드, 마케팅 요구, 이해관계자.

19
00:01:07,000 --> 00:01:10,000
이 제약들은 UX 원칙을 구호로 만들어버립니다.

20
00:01:10,000 --> 00:01:16,000
그래서 책이 말하는 핵심은, 좋은 UX는 예쁜 화면이 아니라 제약 속에서도 반복 가능한 판단 시스템이라는 점입니다.

21
00:01:16,000 --> 00:01:23,000
디자인 시스템이 단순히 컴포넌트 공장이 아니라, “왜 이렇게 만들었고 언제 쓰면 안 되는지”를 기록하는 조직의 기억

22
00:01:23,000 --> 00:01:25,000
장치가 되어야 하는 이유도 여기에 있습니다.

23
00:01:25,000 --> 00:01:30,000
읽으면서 가장 불편했던 부분은, 결국 개발자도 이 시스템의 일부라는 사실이었습니다.

24
00:01:30,000 --> 00:01:36,000
상태 모델을 어떻게 설계할지, 에러를 어떻게 보여줄지, 접근성을 어디까지 고려할지는 더 이상 디자이너만의 영역이

25
00:01:36,000 --> 00:01:37,000
아닙니다.

26
00:01:37,000 --> 00:01:41,000
우리가 늦게 참여하면 사용성 문제는 코드가 거의 굳은 뒤에야 발견됩니다.

27
00:01:41,000 --> 00:01:45,000
좋은 팀은 디자인과 개발을 순서가 아니라 루프로 연결한다고 책은 말합니다.

28
00:01:45,000 --> 00:01:47,000
그 말이 유난히 오래 남았습니다.

29
00:01:47,000 --> 00:01:49,000
그래서 실제로 바꾸기로 한 것이 하나 있습니다.

30
00:01:49,000 --> 00:01:51,000
기능 티켓을 받을 때마다

31
00:01:51,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:05,000
스토리북 문서에도 “이 컴포넌트를 쓰면 안 되는 상황”을 함께 남기기 시작했습니다.

35
00:02:05,000 --> 00:02:10,000
출시 후 일주일 안에 로그와 피드백을 모아 UX 회고를 하는 것도 이번에 새로 정한 규칙입니다.

36
00:02:10,000 --> 00:02:13,000
이 책은 특히 두 부류의 사람에게 권하고 싶습니다.

37
00:02:13,000 --> 00:02:19,000
하나는 디자인 시스템을 만들고 있는데, 점점 컴포넌트만 늘어나고 판단의 품질은 쌓이지 않는다고 느끼는 개발자.

38
00:02:19,000 --> 00:02:24,000
다른 하나는 좋은 원칙을 알고 있지만, 매번 비즈니스 압력 앞에서 무기력해지는 기획자와 개발자입니다.

39
00:02:24,000 --> 00:02:30,000
예쁜 결과물을 만드는 일과, 팀이 계속 더 나은 판단을 하게 만드는 시스템을 만드는 일은 다릅니다.

40
00:02:30,000 --> 00:02:36,000
한 문장으로 정리하면, 좋은 UX는 한 번의 멋진 화면이 아니라, 팀이 계속 더 나은 판단을 하게 만드는 반복

41
00:02:36,000 --> 00:02:37,000
가능한 시스템입니다.

42
00:02:37,000 --> 00:02:40,000
우리 제품에서 사용자가 가장 자주 멈추는 화면은 어디일까.

43
00:02:40,000 --> 00:02:45,000
그 문제를 교육과 문서로 해결할 것인가, 아니면 화면의 단서와 피드백 자체를 고칠 것인가.

44
00:02:45,000 --> 00:02:47,000
다음에 읽을 책을 고를 때도 이 질문을 들고 가려고 합니다.