버튼을 누르고 나서도 화면이 그대로 멈춰 있으면, 저는 가끔 불안해집니다.
과연 제대로 됐는지, 아니면 뭔가 잘못된 건지 알 수가 없어서입니다.
돈 노먼의 『The Design of Everyday Things』 2장을 읽으면서, 그 불안이 단순한 버그가
아니라 설계가 놓친 부분이라는 걸 깨닫게 됐습니다.
개발을 하다
보면 클릭 이벤트 하나만으로 일이 끝난다고 생각하기 쉽습니다.
기능이 호출됐으니
사용자는 만족할 거라고.
그런데 이 책은 그 생각이 얼마나 얕은지 보여줍니다.
사용자는 목표를 세우고, 어떻게 할지 계획하고, 실제로 조작한 뒤에야 비로소 결과를 해석합니다.
그 전체 과정을 놓치면, 버튼을 눌렀는데도 여전히 헤매는 일이 생깁니다.
읽기 전에는 실행 단계, 그러니까 클릭이나 API 호출에만 집중하면 된다고 봤습니다.
그런데 실행의 간극과 평가의 간극이라는 개념을 접하면서 생각이 바뀌었습니다.
사용자가 ‘무엇을 해야 하지?’ 하고 멈추는 순간, 그리고 ‘이게 된 건가?’ 하고 불안해하는 순간이 모두 우리가
설계해야 할 대상이라는 걸 알게 됐습니다.
코드로 해결할 수 있는 문제였는데, 그동안 너무 좁게 보고 있었던 셈입니다.
특히 인상 깊었던 건, 피드백이 단순한 장식이 아니라 신뢰를 쌓는 기반이라는 점이었습니다.
시스템이 아무 말도 하지 않으면 사용자는 같은 행동을 반복하거나, 중도에 떠나버립니다.
반대로 상태를 명확히 보여주면 사용자는 다음에 무엇을 해야 할지 스스로 판단할 수 있게 됩니다.
그 부분을 읽고 나니, 제가 만든 화면들에서 어디가 비어 있었는지 조금씩 보이기 시작했습니다.
그래서 최근에 작업한 화면 하나를 다시 들여다보기로 했습니다.
모든 비동기 동작에 idle, loading, success, error, retry 상태를 분명히 드러내고, 성공
후에는 사용자가 이어서 해야 할 행동까지 연결해주는 식으로 바꿔볼 생각입니다.
폼 제출 후 중복 클릭 방지나 되돌리기 정책도 기능별로 정리해서 문서화할 예정입니다.
작은 변화지만, 사용자가 ‘이게 된 건가?’ 하는 불안을 조금이라도 줄일 수 있지 않을까 기대합니다.
이 책은 인터페이스를 만드는 개발자, 특히 버튼이 동작하면 일이 끝난다고 생각하는 사람에게 특히 의미가 있을 것
같습니다.
디자인 시스템을 다루는 팀이라면, 컴포넌트 하나하나가 행동의 어느 지점을 책임지는지 다시 점검해보는 계기가 될
겁니다.
클릭은 사용자의 행동이 끝나는 지점이 아니라, 시스템이 사용자의 신뢰를 얻기 시작하는 지점입니다.
그렇다면 우리 제품에서 사용자가 가장 자주 멈추는 화면은 어디일까요.