도널드 노먼의 디자인 원칙, 기획자가 쓰는 법

 

UX 이야기를 하다 보면 도널드 노먼이라는 이름이 자주 나옵니다.
일상 속 물건이 왜 쓰기 어려운지를 풀어낸 책으로 유명한 분이라, 디자이너뿐 아니라 기획자도 한 번쯤 읽어 볼 만하다고 생각해요.
다만 원칙을 아는 것과 기획 문서에 쓰는 것은 다른 일이었습니다.
그래서 이 글은 그의 대표 개념들을 제 말로 풀고, 기획자가 화면을 점검할 때 어떻게 쓰는지를 정리한 노트입니다.
세부 용어는 번역서마다 조금씩 다르게 쓰일 수 있다는 점은 감안해 주세요.

 

개념 모델은 사용자가 "이 서비스는 이렇게 동작할 것이다"라고 마음속에 그리는 그림입니다.
서비스를 만든 사람의 머릿속 그림과 사용자의 그림이 어긋나면 사용성 문제가 생겨요.

가정 예시로, 장바구니와 위시리스트를 같이 둔 쇼핑 앱을 생각해 볼게요.
운영 팀은 위시리스트를 "나중에 볼 상품 보관함"으로 설계했는데, 사용자는 "가격이 내려가면 알려 주는 기능"으로 기대할 수 있습니다.
이런 어긋남은 화면 이름과 안내 문구에서 시작되는 경우가 많습니다.
기획 단계에서 "사용자는 이걸 무엇이라고 이해할까"를 한 문장으로 적어 보면 차이가 보이기 시작해요.

개념 모델을 확인하는 가장 쉬운 방법은 화면을 처음 보는 사람에게 "이 서비스가 뭘 해 줄 것 같아요"라고 묻는 것입니다.
대답이 기획 의도와 다르면 이름, 아이콘, 첫 안내 문구 중 어딘가에 원인이 있는 경우가 많았어요.

 

어포던스는 어떤 대상이 사용자에게 제공하는 행동의 가능성을 말합니다.
시그니파이어는 그 가능성이 어디에 있는지 알려 주는 신호입니다.
이 둘은 구분해서 보면 이해가 쉬워요.
문이 열리는 구조라는 것이 어포던스라면, 손잡이 모양이나 "밀기" 표시가 시그니파이어입니다.

화면에서는 이렇게 적용됩니다.
버튼이 눌러질 것처럼 보이는가, 입력 칸이 입력 칸처럼 보이는가를 확인합니다.
눌러지지 않는 요소가 눌러질 것처럼 보이면 사용자는 헛클릭을 하고, 눌러지는 요소가 일반 글자처럼 보이면 아예 못 찾습니다.
기획서에 "이 요소는 클릭 가능"이라고만 적지 말고, 사용자가 그것을 어떻게 알아챌지도 함께 적는 습관이 도움이 되었습니다.

 

매핑은 조작과 그 결과 사이의 대응 관계입니다.
버튼 배치가 조작 대상의 배치와 비슷하면 자연스럽고, 그렇지 않으면 외워야 합니다.

예를 들어 여러 구역의 알림을 켜고 끄는 화면을 가정해 볼게요.
구역 이름이 왼쪽에 있고 스위치가 화면 맨 오른쪽 끝에 멀리 떨어져 있으면, 어느 줄의 스위치인지 눈으로 따라가야 합니다.
이름 바로 옆에 스위치를 두면 매핑이 가까워져서 실수가 줄어요.
목록형 화면이라면 줄 간격과 정렬만 바꿔도 체감이 달라지더라고요.

 

피드백은 사용자가 한 행동에 대해 시스템이 돌려주는 반응입니다.
눌렀는데 아무 반응이 없으면 사용자는 다시 누르고, 그러면 중복 결제나 중복 신청 같은 문제가 생길 수 있어요.

점검 질문은 간단합니다.
누르면 즉시 눌렸다는 표시가 있는가.
시간이 걸리는 작업에는 진행 중이라는 표시가 있는가.
끝났을 때 성공했는지 실패했는지 분명한가.
특히 실패했을 때 "오류가 발생했습니다"만 보이면 다음 행동을 알 수 없으니, 무엇을 하면 되는지까지 적어야 합니다.

가정 예시로 예약 확정 버튼을 생각해 보겠습니다.
누르는 순간 버튼이 비활성으로 바뀌고 작은 진행 표시가 돌며, 끝나면 예약 번호와 함께 완료 화면으로 넘어가는 흐름이면 사용자는 불안해하지 않아요.
같은 기능이라도 아무 변화 없이 몇 초 뒤에 갑자기 화면이 바뀌면 이미 두 번 눌러 버린 뒤일 수 있습니다.

 

제약은 사용자가 할 수 있는 행동의 범위를 좁혀서 잘못된 사용을 막는 장치입니다.
날짜 입력 칸에 직접 글자를 쓰게 하는 대신 달력에서 고르게 하는 것이 대표적인 예입니다.
지난 날짜는 아예 선택되지 않도록 비활성으로 두면 오류 메시지를 보여 줄 필요 자체가 줄어요.

가정 예시로 인원 선택 칸을 보죠.
자유 입력으로 두면 0이나 음수, 터무니없이 큰 숫자가 들어올 수 있습니다.
증감 버튼으로 바꾸고 최소 한 명, 최대 여덟 명으로 범위를 정해 주면 오류 처리 화면을 따로 만들 필요가 없어져요.
여기서 최대 인원 같은 값은 설명을 위한 가정이고, 실제로는 서비스 정책에 맞춰 정해야 합니다.

다만 제약을 너무 강하게 걸면 사용자는 답답해합니다.
되돌리기와 확인 단계를 적절히 두어서, 막는 것과 돕는 것 사이의 균형을 잡는 것이 기획자의 몫이라고 느꼈습니다.

 

저는 화면 기획을 마치고 이 다섯 가지를 한 줄씩 점검합니다.
사용자는 이 화면을 어떻게 이해할까(개념 모델).
무엇을 할 수 있는지 보이는가(어포던스, 시그니파이어).
조작과 결과가 가까이 있는가(매핑).
행동에 반응이 있는가(피드백).
실수가 나기 어려운가(제약).
이 점검만 해도 화면 리뷰 때 받는 지적이 달라집니다.

원칙은 정답을 알려 주기보다 질문을 던지게 해 주는 도구라고 생각합니다.
화면을 보며 "이건 어포던스가 약한가, 피드백이 없나" 하고 이름을 붙여 보면, 막연했던 불편함이 구체적인 개선 항목으로 바뀌어요.

아직 남은 질문은 이런 것입니다.

원칙끼리 부딪힐 때, 예를 들어 단순함과 충분한 피드백이 충돌할 때 무엇을 우선할지가 어렵습니다.
이 부분은 실제 사용자 반응을 보면서 더 배워 가야 할 것 같아요.