들어가며
요즘 나만의 앱 서비스를 출시하기 위해 UI/UX를 고민하고 있습니다.
UI/UX 쪽 실무는 커녕 개인적인 경험도 거의 없는 상태인데요, 정답이 없어서 그런지 볼수록 어려운 분야인 것 같아요🥲
그래서 요즘 책이나 다른 앱을 보며 힌트를 얻으려 하고 있고, 그 과정에서 클리프 쿠앙, 로버트 패브리칸트의 <유저 프렌들리>를 읽기 시작했습니다.
솔직히 초반에는 의문이 들었어요. 원자력발전소 사고, 2차 세계대전 이야기가 나오는데 이게 앱 만드는 나에게 도움이 되는 걸까? 나에게는 당장 도움이 될만한 실용서가 필요한 건 아닐까?
하지만 읽어보니 이 책은 “버튼을 어디에 놓아라” 같은 레시피북이 아니라, 사용자를 이해하는 눈을 만들어주는 책이었습니다.
구체적인 디자인 패턴은 다른 곳에서 배울 수 있지만, “사용자가 왜 헷갈리고, 왜 실수하고, 왜 떠나는가”에 대한 근본적 사고 방식은 이 책을 통해서 잡을 수 있겠더라고요☺️
그래서 저는 이 책을 “이 사례가 내 앱이라면 어떤 형태로 나타날까?”라는 관점에서 보고자 했습니다. 그리고 각 장에서 앱 설계에 적용할 수 있는 핵심 원칙을 하나씩 뽑아 정리하기로 했습니다.
💡 본 글은 책을 직접 읽고 감상을 정리한 뒤, 앱에 적용할 포인트를 고민한 내용을 바탕으로 작성했습니다. 글을 다듬고 부가적인 인사이트를 정리하는 과정에서 Claude의 도움을 받았습니다.
1장. 혼란스러운 디자인
1979년 스리마일섬 원자력발전소 사고는 UI/UX의 중요성을 극적으로 보여주는 사례다. 이 사고에서 가져갈 핵심 교훈은 세 가지다.
정보 과부하는 정보 부재와 같다
도대체 이 수많은 경고 표시가 다 무슨 뜻인가? 기계에서 수백가지 잘못을 지적해대는 이 순간, 핵심 문제 단 하나를 어떻게 찾아내야 하는가? (p.25)
사고 당시 제어실에서 수백 개의 경보가 동시에 울렸다고 한다. 우선순위 구분 없이 전부 같은 수준으로 울리니까, 운영자들은 정작 뭐가 진짜 위험한지 판단할 수 없었다. (게다가 엄청난 소음이 쏟아 졌으니 정신이 쏙 빠졌을 것 같다.)
앱에서 알림을 남발하거나, 에러 메시지를 한꺼번에 쏟아내거나, 화면에 정보를 빽빽하게 넣는 것이 같은 실수다. “많이 보여주면 친절한 것”이 아니라, 지금 사용자에게 가장 중요한 것 하나를 명확히 보여주는 것이 진짜 좋은 설계다.
피드백은 “실제 상태”를 보여줘야 한다
이 수동 방출 밸브의 표시등에는 설계 단계부터 심각한 개념상의 오류가 있었다. 이 표시등은 누군가가 밸브 제어 스위치를 작동할 때 불빛이 꺼졌다. 밸브가 실제로 닫혔을 때가 아니었다. 다시 말해, 조작한 사람의 의도를 알려줄 뿐 실제 동작은 알려주지 못했다. (p.40)
사고의 결정적 원인 중 하나는, 밸브에 “닫힘 신호를 보냈다”는 표시만 있었지 “실제로 밸브가 닫혀 있다”는 표시는 없었다는 것이다. 운영자는 닫혀 있다고 믿었지만 실제로는 열려 있었다.
앱으로 치면, “결제 요청 중…“만 보여주고 결제가 실제로 완료됐는지 실패했는지를 명확히 알려주지 않는 것과 같다. 사용자에게 보여주는 피드백이 실제 상태를 정확히 반영하고 있는지가 핵심이다.
멘탈 모델과 실제 동작이 일치해야 한다
우리는 과거에 사용한 적 있는 사물을 바탕으로 멘탈모델을 형성한다. (p.57)
사고 당시 근무자들은 당시 벌어지는 사건들이 서로 동떨어져 보였으며, 어떠한 연결 관계도 찾기 어려웠다고 한다. 시스템은 사용자들이 “이렇게 동작할 것”이라는 멘탈모델에 맞는 경험을 주어야 한다.
앱에서 뒤로가기 버튼을 눌렀을 때 사용자는 “이전 화면”을 기대하는데 실제로는 “홈”으로 이동한다면, 사용자는 앱의 동작을 예측할 수 없게 된다. 사용자의 예상과 실제 동작이 일치하도록 만드는 것이 핵심이다.
💡 1장 체크리스트
- 사용자에게 지금 가장 중요한 정보가 분명하게 전달되고 있는가?
- 지금 이 화면이 실제 상태를 정확히 보여주고 있는가?
- 사용자가 예상하는 동작과 실제 동작이 일치하는가?
2장. 산업의 기원을 찾아서
헨리 드레이퍼스라는 산업 디자이너의 이야기를 통해, “사용자 중심 디자인”이 어떻게 탄생했는지를 보여주는 장이다.
사용자를 위한 디자인 vs 좋아 보이는 디자인
극장의 반질반질한 입구에 매끈한 카펫이 목구멍의 혀처럼 늘어져 있는 모양을 돌아보니, 동네 ‘농사꾼과 일꾼’들이 얼마나 주눅이 들었을지 보였다. … 다음날, 드레이퍼스는 사람을 불러 카펫을 뜯어내고 평범한 고무 깔개를 놓았다. 그런 다음 극장으로 돌아가 기다렸다. 처음에 두 명이 오더니, 몇 명이 더 오고, 또 몇 명이 더 오고, 또 몇 명이 더 와 극장이 가득 찼다. 묘안이 효과를 발휘한 것이다. (p.74)
드레이퍼스는 극장의 고급 카펫을 과감히 뜯어냈다! 고급스러워 보이는 카펫이 실제 관객(팝콘 흘리고 음료 쏟는 일반 대중)에게는 맞지 않다는 판단이었다. “좋은 디자인”의 기준은 디자이너의 미적 판단이 아니라 실제 사용 맥락이라는 것이다.
앱에 적용하면, 핀터레스트에서 본 예쁜 UI를 그대로 가져오는 것보다, 내 앱의 사용자가 누구인지, 그들이 어떤 상황에서 어떻게 쓸지를 먼저 생각해야 한다. 출퇴근 지하철에서 한 손으로 쓰는 앱이라면? 아무리 예뻐도 양손이 필요한 인터랙션은 고급 카펫과 같은 실수다.
사소한 불편에 창의력을 쏟아라
드레이퍼스는 생활의 사소한 부분을 손쉽게 만드는 기적을 설명할 때면 항상 신이 났다. (p.89)
드레이퍼스가 인상적이었던 건, 땅콩버터 병이나 오븐 손잡이 같은 사소한 물건에도 시간을 들여 창의력을 발휘했다는 점이다. 대부분의 사람들은 “원래 그런 거지”라고 넘어갈 부분에서 “이게 왜 이렇게 불편하지?”라고 질문을 던진 것이다.
앱에서도 “원래 다 이렇게 생겼으니까”라며 관행을 따라가는 부분이 분명히 있다. 회원가입 폼, 설정 화면, 알림 목록 같은 것들. 다른 앱이 그렇게 하니까 나도 그렇게 만드는 건, 사용자의 불편을 방치하는 것과 같다. “의례 그렇게 하니까”가 아니라 “내 사용자에게 이게 정말 편한가?”를 기준으로 봐야겠다.
💡 2장 체크리스트
- 이 디자인은 내가 보기에 예쁜 건가, 사용자의 실제 맥락에 맞는 건가?
- 사용자가 느낄 사소한 불편을 개선했는가?
3장. 누가 만든 오류인가
그동안 사고를 두고 사용자에게 원인을 찾았다면, 그 시선이 시스템에게 돌아가기 시작했다. “오류의 원인이 사용자가 아니라 설계에 있다”는 관점의 전환이다.
사용자 탓에서 설계 탓으로
오히려 이런 전투기를 조종하는 일이 불가능해 보였다. ‘조종사 과실’이 아니라 처음으로 ‘설계자 과실’을 발견한 것이다. 현재 우리에게 친숙한 사용자 친화적인 세계의 시초였다. (p.107)
과거에는 비행기 추락이나 공장 사고가 나면 “조종사가 미숙했다”, “작업자가 부주의했다”로 결론 내렸다. 그런데 2차 대전 중 숙련된 조종사들마저 같은 실수를 반복하는 걸 보고, 문제가 사람이 아니라 설계에 있다는 걸 깨닫게 된다.
앱에 적용하면, 사용자가 특정 기능을 못 찾거나 잘못 누르면 “사용자가 멍청해서”가 아니라 “내 설계가 그렇게 유도한 것”이다. 사용자 탓을 하는 순간 개선 기회를 놓치게 된다!
비슷하게 생긴 것은 반드시 헷갈린다
이 두 장치는 서로 바로 옆에 붙어 있는 데다 형태도 똑같아, 조종사가 착륙을 시도할 때 날개 플랩을 들어 올리려다가 의도치 않게 착륙 장치를 집어넣는 일이 비일비재했다. (p.108)
우선 샤페이니스는 공군 사고 기록을 보면서 같은 사고가 여러 번 발생한 원인을 파악했다. 그리고 조작부를 형태별로 구별하여 조종사가 손의 감각만으로 어떤 동작을 행하는지 알 수 있도록 개선했다.
이는 앱을 사용하는 사용자도 흔히 할 수 있는 실수다. “저장”과 “삭제” 버튼이 같은 크기, 같은 스타일로 나란히 있으면 사용자는 반드시 실수한다. 중요한 동작일수록 시각적으로, 위치적으로, 확실히 구분되어야 한다.
💡 3장 체크리스트
- 사용자가 실수했을 때, “왜 그렇게 했을까”를 설계에서 원인을 찾고 있는가?
- 비슷한 기능의 버튼이나 요소가 쉽게 구분되게 되어 있는가?
4장. 신뢰받는 제품이란
이 장은 자율주행 자동차를 예시로, 사용자가 제품을 신뢰하게 되는 조건이 무엇인지를 다룬다. 자율주행은 사용자가 말 그대로 목숨을 맡기는 기술이다. 그래서인지 신뢰의 조건이 극단적으로 선명하게 드러난다. 앱은 목숨을 맡기는 시스템은 아니라 어떤 내용을 뽑을 수 있을지 고민했지만, 결국 사용자가 자기 시간과 데이터를 맡긴다는 점에서 신뢰의 구조는 동일하다고 생각했다.
현재 상태를 알려라
무엇보다 우리는 자동차가 현재 어떤 상태인지, 즉 자율주행 상태인지 아닌지를 알아야 한다. (p.134)
자율주행 자동차가 현재 자율주행 모드인지 아닌지, 앞 차나 보행자를 인식했는지 등 차가 어떤 상태인지 알아야 사용자가 안심할 수 있다.
앱에서도 마찬가지다. 데이터를 불러오고 있는 건지, 저장이 완료된 건지, 오프라인 상태인 건지…! 앱이 지금 어떤 상태인지 사용자가 알 수 없으면, 사용자는 불안해하고 결국 신뢰를 거둔다. 1장에서 다룬 “피드백”과 이어지는 이야기이기도 한데, 1장이 “정확한 피드백”이었다면 4장은 “신뢰를 위한 피드백”이다. 피드백이 정확해야 할 뿐 아니라, 그 피드백이 사용자의 불안을 해소해줘야 한다.
다음 동작을 예고하라
그 후 자동차가 차선을 변경할 때는 화면 속 타이머가 초읽기에 들어가며 무슨 동작을 할지 예고했다. (p.135)
자율주행 자동차가 갑자기 차선을 변경하면, 아무리 안전한 판단이었더라도 운전자는 깜짝 놀란다. 반면 “3초 후 좌측 차선으로 이동합니다”라고 미리 알려주면, 같은 동작이라도 받아들일 수 있다.
앱에서도 예고 없는 동작은 신뢰를 깎는다. (자동 로그아웃, 자동 업데이트, 자동 삭제 등) 사용자가 예상하지 못한 순간에 앱이 알아서 무언가를 하면, 아무리 좋은 의도여도 “이 앱이 내 뒤에서 뭘 하는 거지?”라는 의심이 생긴다. 중요한 동작일수록 미리 알리고, 사용자가 준비된 상태에서 실행되어야 한다.
통제권을 명확히 하라
운전대는 영리하고 섬세한 방법으로 조작부는 내 것이고, 운전은 이제 기계 몫이라고 신호를 보내고 있었다. (p.148)
말의 고삐에서 영감을 얻어 자율주행 모드의 온오프를 디자인한 사례가 정말 인상 깊었다. 자동차 핸들(고삐)에서 손을 놓으면 운전대가 뒤로 살짝 물러나며 자율주행 모드로 전환됨을 알리고, 조작부는 그대로 두었다고 한다. 기계와 사람의 통제권이 분명하게 인식되어야 사고가 날 확률도 줄어들 것이다.
앱에서도 자동화된 기능과 사용자 조작 사이의 경계가 모호하면 혼란이 생긴다. 예를 들어, 자동 완성이 사용자가 입력하는 도중에 내용을 덮어쓰거나, 자동 추천이 사용자의 선택을 대신해버리는 경우다. “지금 앱이 하고 있는 것”과 “사용자가 직접 해야 하는 것”의 경계가 명확해야 한다. 그리고 언제든 사용자가 통제권을 되찾을 수 있어야 한다. 되돌리기, 취소, 수동 전환 같은 장치가 그래서 중요하다.
한계를 솔직하게 알려라
새로운 기술이 출현하면, 우리는 새로운 기술이 약속하는 수준을 넘어 우리가 상상하는 수준을 달성하기를 요구한다. 하지만 정말 이렇게 되려면 기계를 설계할 때부터 우리 상상력이 기계의 성능을 너무 앞질러 가지 않도록 디자인해야 한다. 상상력이 앞질러 가는 순간, 혼란이 퍼진다. (p.155)
자율주행 기술의 초기 실패 사례들을 보면, 사용자가 기술의 한계를 과대평가한 경우가 많다. 차가 스스로 모든 걸 해줄 거라 믿고 핸들에서 손을 떼버린 것이다. 기술이 “다 할 수 있는 것처럼” 보이게 만들면, 사용자는 기술이 못 하는 순간에 대비하지 않는다.
앱도 마찬가지다. AI 기반 추천 기능이 있다면, 그 추천이 100% 정확하지 않다는 걸 사용자가 인지하고 있어야 한다. 자동 분류가 있다면, 잘못 분류될 수 있다는 걸 알고 직접 수정할 수 있어야 한다. 과장된 기대를 심어주는 것보다, 한계를 솔직히 알리고 그 안에서 확실하게 동작하는 것이 더 강한 신뢰를 만든다. “뭐든 다 됩니다”보다 “이건 확실히 해드립니다”가 낫다.
💡 4장 체크리스트
- 앱이 지금 어떤 상태인지 사용자가 알 수 있는가?
- 앱이 자동으로 수행하는 동작을 사전에 알리고 있는가?
- 앱의 자동 동작과 사용자의 직접 조작 사이의 경계가 명확한가?
- 사용자가 언제든 통제권을 되찾을 수 있는 장치(되돌리기, 취소)가 있는가?
- 앱의 한계를 솔직하게 전달하고 있는가?
5장. 은유의 사다리가 필요한 이유
4장에 이어 이 장도 앱 설계에 직접 적용할 포인트를 뽑기가 어려웠다. 내용이 아주 중요하다는 건 알았으나, 애플의 운영체제, 아이팟 휠, 터치 스크린, 다이슨 청소기, 질레트 여성 면도기 등의 다양한 사례가 대부분 하드웨어 위주라 앱과는 거리가 있게 느껴졌다. 그래도 “은유”라는 개념 자체는 앱에도 분명히 적용되는 부분이 있다고 생각했다.
은유는 “설명 없이 이해시키는 장치”다
은유를 통해 그물망처럼 수많은 추론이 가능하며, 그 추론을 활용해 특정 사물의 작동 원리를 설명하게 된다는 생각이다. (p.169)
이 장에서 다루는 은유의 핵심은, 새로운 것을 익숙한 것에 빗대어 별도의 학습 없이 사용법을 짐작하게 만드는 것이다. 초기 컴퓨터의 데스크톱, 폴더, 휴지통이 대표적이다. 사무실 책상(데스크톱) 위의 물건들을 그대로 화면에 옮겨 놓으니, 컴퓨터를 처음 보는 사람도 “이 폴더 안에 파일을 넣으면 되겠구나”라고 짐작할 수 있었다.
앱에서도 은유는 곳곳에 쓰인다. 장바구니, 북마크, 하트, 종 모양 알림 아이콘 등등 이런 것들이 전부 은유다. 좋은 은유는 사용자가 “이건 뭐지?”라고 질문하기 전에 답을 주는 것이다. 반대로 은유가 없으면, 아이콘 하나를 이해시키기 위해 온보딩 튜토리얼을 만들어야 한다.
은유로 행동을 유도하다
거칠게 운전하면 잎이 한두 장 떨어지고, 차분하게 운전하면 새로 몇 장이 자라났다. 코치에서 시작해 녹색 불빛, 그리고 또 잎사귀까지, 한 가지 은유에서 다른 은유로 넘어가는 과정이었다. 해결안이 탁월했던 이유는 간단한 이미지 하나에 엄청난 정보가 함축되어 있기 때문이었다. 사람들이 더 나은 행태를 보일 수 있도록 독려하는 피드백 작용이었다. (p.174)
이 장에서 가장 흥미로웠던 건 포드 개발자의 사례다. 운전자가 연비를 의식하며 신중하게 운전하도록, 계기판에 “나무”라는 은유를 도입했다. 연비 효율이 좋으면 넝쿨의 잎사귀가 자라고, 나쁘면 시든다. 숫자로 “연비 12.3km/L”라고 보여줬으면 무덤덤했을 텐데, 잎사귀가 시들어가는 걸 보면 자연스럽게 운전 습관을 바꾸게 된다. (심지어 이런 아기자기한 디자인을 선호하지 않을 것 같은 미국 남성도 좋아했다는 점!)
이건 앱에도 바로 적용 가능한 아이디어다. 실제로 이 원리를 쓰는 앱들이 있다. 집중 시간 동안 나무를 키우는 Forest 앱, 연속 학습 일수를 불꽃으로 보여주는 Duolingo 등. (심지어 Duolingo는 캐릭터가 화내거나 녹아 내린다ㅠ) 전부 숫자 대신 은유를 써서, 사용자가 “이걸 유지하고 싶다”는 감정을 느끼게 만드는 것이다. 만약 내 앱에서 사용자의 특정 행동을 유도하고 싶다면, 그 행동의 결과를 숫자가 아닌 은유로 보여주는 걸 고민해볼 수 있겠다.
은유에도 유통기한이 있다
이 짐을 덜기 위해서는 스마트폰 작동 방식을 대변할 새로운 은유가 필요하다. 누구든 이 은유를 발견한다면, 우리의 디지털 일상도 진화할 것이다. 만약 스마트폰 작동 방식이 바뀌어, 앱이 아니라 우리가 소중히 여기는 관계를 중심으로 작동한다면 어떨지 상상해 보자. (p.192)
이건 앱 설계에 있어서 영감을 얻었다기 보다는, “정말 새로운 은유의 발견”이 가능할까 의문과 기대가 든 구절이다. 어쩌면 AI 시대가 도래했으니 이제 앱이 격자 무늬 배경에 나열되어 그 앱을 선택하기 보다는, 관계와 소통에 따라 앱이 흘러가는(?) 구조가 가능할지 모르겠다. 이는 한번 정한 은유가 영원하지는 않다는 것을 의미할지도 모르겠다. 처음에는 효과적이었던 은유가 사용자가 익숙해지면서 오히려 제약이 될 수 있다. 내 앱의 핵심 은유가 사용자를 돕고 있는지, 혹시 가두고 있는 건 아닌지 점검해볼 필요가 있다.
💡 5장 체크리스트
- 앱의 주요 기능이 설명 없이도 짐작할 수 있는 은유를 쓰고 있는가?
- 사용자의 행동을 유도할 때, 숫자 대신 은유로 동기를 부여할 수 있는가?
- 지금 쓰고 있는 은유가 사용자를 돕고 있는가, 가두고 있는가?
정리
처음에는 스토리텔링의 성격이 강해 보여서 각 장의 핵심을 뽑기 어려웠는데, 하나씩 정리해 보니 꽤 많은 내용이 나왔네요✌️
Part 1을 한 줄로 요약하자면 사용자 관찰, 정확하고 신뢰를 주는 피드백, 쉽게 온보딩할 수 있는 멘탈모델과 은유의 중요성 정도로 할 수 있겠습니다.
내 앱에서 사용자가 헤맨다면, 그건 사용자의 문제가 아니라 나의 설계 문제다!
이 관점을 유지하면서 나머지 파트를 계속 읽어나가 보려 합니다.
참고자료
- 클리프 쿠앙, 로버트 패브리칸트, <유저 프렌들리>