이 책을 읽기 시작한 건, 우리 팀이 만든 화면 하나 때문이었습니다.
출시 후 일주일도 안 돼서 “이 버튼이 왜 여기에 있죠?”라는 질문을 받았고, 그 순간 문득 이런 생각이
들었습니다.
우리가 정말로 고민한 건 사용자의 행동이었을까, 아니면 그냥 예쁘게 보이는 결과물이었을까.
The Design of Everyday Things를 다시 펼친 이유가 거기에 있습니다.
돈 노먼의 책은 원래 문손잡이와 스위치로 유명하지만, 이번 5회차에서 다루는 6장과 7장은 개발자에게 훨씬 더
날카로운 질문을 던집니다.
좋은 설계 원칙이 실제 제품 조직에서는 왜 자꾸 밀려나는가.
디자인은 한 번의 멋진 해결이 아니라, 관찰하고 문제를 다시 정의하고 실험하는 과정을 조직이 반복할 수 있느냐의
문제라는 점을 이번 회차는 분명히 보여줍니다.
읽기 전에 나는 UX를 디자이너가 건네주는 산출물 정도로 생각하고 있었습니다.
개발자는 그걸 구현만 하면 된다고.
그런데 이 책은 그 가정을 흔들었습니다.
디자인 사고는 발산하고 수렴하는 반복 구조이고, double diamond라는 말로 표현되기도 하지만, 결국 중요한
건 처음에 정의한 문제가 거의 항상 틀렸거나 너무 좁다는 사실입니다.
그래서 좋은 팀은 요구사항을 바로 티켓으로 만들기 전에, 관찰과 재정의를 먼저 합니다.
문제는 현실입니다.
일정, 예산, 레거시 코드, 마케팅 요구, 이해관계자.
이 제약들은 UX 원칙을 구호로 만들어버립니다.
그래서 책이 말하는 핵심은, 좋은 UX는 예쁜 화면이 아니라 제약 속에서도 반복 가능한 판단 시스템이라는 점입니다.
디자인 시스템이 단순히 컴포넌트 공장이 아니라, “왜 이렇게 만들었고 언제 쓰면 안 되는지”를 기록하는 조직의 기억
장치가 되어야 하는 이유도 여기에 있습니다.
읽으면서 가장 불편했던 부분은, 결국 개발자도 이 시스템의 일부라는 사실이었습니다.
상태 모델을 어떻게 설계할지, 에러를 어떻게 보여줄지, 접근성을 어디까지 고려할지는 더 이상 디자이너만의 영역이
아닙니다.
우리가 늦게 참여하면 사용성 문제는 코드가 거의 굳은 뒤에야 발견됩니다.
좋은 팀은 디자인과 개발을 순서가 아니라 루프로 연결한다고 책은 말합니다.
그 말이 유난히 오래 남았습니다.
그래서 실제로 바꾸기로 한 것이 하나 있습니다.
기능 티켓을 받을 때마다
네 가지를 짧게 적는 습관입니다.
사용자가 겪는 문제는 무엇인지, 성공 기준은 무엇인지, 실패할 가능성은 어디에 있는지, 그리고 그것을 어떻게 측정할
것인지.
스토리북 문서에도 “이 컴포넌트를 쓰면 안 되는 상황”을 함께 남기기 시작했습니다.
출시 후 일주일 안에 로그와 피드백을 모아 UX 회고를 하는 것도 이번에 새로 정한 규칙입니다.
이 책은 특히 두 부류의 사람에게 권하고 싶습니다.
하나는 디자인 시스템을 만들고 있는데, 점점 컴포넌트만 늘어나고 판단의 품질은 쌓이지 않는다고 느끼는 개발자.
다른 하나는 좋은 원칙을 알고 있지만, 매번 비즈니스 압력 앞에서 무기력해지는 기획자와 개발자입니다.
예쁜 결과물을 만드는 일과, 팀이 계속 더 나은 판단을 하게 만드는 시스템을 만드는 일은 다릅니다.
한 문장으로 정리하면, 좋은 UX는 한 번의 멋진 화면이 아니라, 팀이 계속 더 나은 판단을 하게 만드는 반복
가능한 시스템입니다.
우리 제품에서 사용자가 가장 자주 멈추는 화면은 어디일까.
그 문제를 교육과 문서로 해결할 것인가, 아니면 화면의 단서와 피드백 자체를 고칠 것인가.
다음에 읽을 책을 고를 때도 이 질문을 들고 가려고 합니다.