나쁜 유저 인터페이스를 고치는 법

이 글은 The blog of Scott Hurff에 올라온 How to fix a bad user interface라는 제목의 아티클을 한국어로 번역한 글입니다. 이 글에 관련된 모든 권리는 원작자에게 있습니다.

나쁜 유저 인터페이스를 고치는 방법

이 내용은 2016년 1월 O’Reilly 에서 출판된 제 책 Designing Products People Love에서 발췌한 내용입니다. 책을 통해 페이스북, 트위터, 슬랙 등에 다니는 20명 이상의 제품 디자이너의 일하는 방식에 대한 인터뷰를 알아보세요!

생기 없는 것처럼 느껴지는 유저 인터페이스를 경험한 적 있으신가요? 무언가가 빠져 있는 듯 보이는 UI를 만들어보신 적은요?

만약 그런 적이 있다면, 아마 어색한 UI의 한 경우를 경험하셨던 것일 듯 합니다.

어색한 UI의 예로 빠트린 로딩 인디케이터를 들 수 있습니다. 또는 무언가 잘못되었을 때 어디가 문제였는지 알려주지 않는 일이라던지요. 무서운 에러 메시지와 함께라면 금상첨화죠. 데이터가 몇 없을 때에 이상하게 보이는 그래프도 그렇구요. 새로운 데이터를 보여줄 때의 Linear snap(역: 무슨 뜻인지 모르겠네요) 입니다.

아직 어색한 UI가 뭔지 감이 잘 안 오시나요? 실제 예를 하나 들어보겠습니다. 저는 Apple TV를 씁니다. 아주 자주요. (사실, 이 글을 쓰면서도 Star Wars: Rebels의 최신 에피소드를 틀어놓은 상태입니다.) 제가 저의 최신 구매 영화 목록을 보려고 할 때마다, 저는 아래 화면을 보게 됩니다.

일 초 정도, 저는 공포에 빠집니다. 항상 말이죠. 그리고 저는 이 화면을 꽤 자주 보거든요. 왜 무서워하냐고요? 어떤 로딩 인디케이터도 볼 수 없기 때문입니다.

어떤 일이 일어나고 있다고 나타내는 것이 아무것도 없어요. 몇 초 동안, 제 머리속엔 무서운 질문들이 뛰어다닙니다. 내 영화들이 다 어디갔지? 사라진건가? 지워졌나? 누가 훔쳐가기라도 했나?

그리고, 빠른 심장 박동이 멈추고 나면, 제가 가진 영화들이 갑자기, 어떤 예고도 없이 화면에 나타나죠.

아주 거슬리는 일이죠.

이를 영화를 재생할 때랑 한 번 비교해봅시다. 애플 리모콘에서 “재생” 버튼을 누르고 나면, <백 투 더 퓨처>가 재생 될 준비를 하고 있다는 친절한 안내가 나옵니다.

차이가 느껴지시나요?

사람이 쉽게 이해할 수 있는 인터페이스를 만들고자 할 때, 우리 제품 디자이너들은 슬픈 사실을 맞닥뜨리게 됩니다. 컴퓨터가 게으르다는 사실 말이죠. 컴퓨터는 사람들이 무엇이 새롭고, 다음엔 무엇을 해야 하고, 문제가 생겼을 때 어떻게 해야할 지 이해하는 일을 돕는데에 별 관심이 없습니다.

컴퓨터가 사는 이상적인 세상에서, 예기치 못한 일이 일어났을 때 컴퓨터는 그저 무슨 뜻인지 모를 에러 코드와 무시무시한 알림을 던지면 그만이죠. 아니 그것보다도, 그냥 이진수로 말을 거는게 더 나을지도요.

하지만 이진수는 우리의 언어가 아닙니다. 우리는 물리적 세계와 연속적 흐름에 익숙해져 있죠. 문이 열릴 때, 문은 호(arc)를 그립니다. 무언가 나아갈 때면 그게 움직이는 모습을 실제로 볼 수 있고, 떨어진 물체는 튀어오르죠.

어색한 UI는 제품 디자이너가 이러한 물리적 세계의 면모를 고려하지 않을 때 발생합니다. 어디에선가 몇 몇 규칙이 지켜지지 않았다는 것을 의미하죠.

대체 어떤 규칙이냐구요?

UI 스택의 규칙입니다. 좀 더 자세히 이야기해보죠.

UI 스택

모든 상호작용이 가능한 디지털 제품의 화면은 여러 성격을 지니고 있습니다.

정확하게 말하자면, 다섯 가지 상태죠.

상황에 따라, 이러한 성격을 당신의 고객에게 드러나게 됩니다. 디자이너로서 우리는 이런 성격을 상태라고 부릅니다. 그리고 당신은 당신이 만드는 모든 화면에 대해 이 상태들을 고려할 필요가 있어요. UI 스택과 다섯 상태의 규칙에 따르는 것이 너그럽고, 도움이 되고, 사람처럼 느껴지는 응집력 있는 인터페이스를 만드는데에 도움이 되기 때문입니다.

가슴에 손을 얹고 생각해보세요. 가장 마지막으로 단 하나의 상태만으로 충분한 화면을 만들었던게 언제인가요? 날씨 앱을 만들 때조차 하나의 상태만으론 부족합니다. 실제로는, 우리가 살고 있는 세상은 완벽하지 않고 일은 예상처럼 풀리지 않습니다. 서버는 응답하기까지 시간이 필요하죠. 그리고 고객들은 항상 당신이 예상했던 대로 당신의 제품을 사용하지 않을 겁니다.

제품 디자이너는 이러한 현실을 고려해야 합니다. 그리고 바로 그게 당신 제품의 모든 화면이 다음과 같은 최대 다섯 상태를 가질 수 있는 이유죠.

  • 이상적인 상태(Ideal State)
  • 비어있는 상태(Empty State)
  • 오류 상태(Error State)
  • 부분적인 상태(Partial State)
  • 로딩 상태(Loading State)

고객이 당신 제품의 사용 흐름을 따라 움직이면서, 고객은 이러한 상태와 상태 사이를 자연스레 오가게 됩니다.

실제 메시지 앱에서의 UI 스택. 각 화면 간의 전환은 자연스럽게 일어납니다.

만약 UI 스택에 실제 예시를 보고 싶다면, 지금 바로 글의 해당 부분으로 건너뛰셔도 됩니다.

UI 스택 프로토타입으로 건너뛰기

짜잔! 예상 못 했겠지만, 막간을 이용해 인터넷 역사에 대해 잠깐 얘기 해 보겠습니다. 2004년, 이전에 37signals 라는 이름을 쓰던 Basecamp라는 회사에서 “Three State Solution”라는 제목으로, 적어도 저에게 있어서는 신세계를 개척하는 듯한 글을 썼습니다. (물론 여기서의 Three State Solution은 이스라엘-팔레스타인 문제에서의 삼국 방안을 이야기하는 건 아닙니다.) 그 글의 저자는 모든 화면이 세 가지 가능한 상태 — 보통 상태, 빈 상태, 그리고 오류 상태 — 를 고려해야 한다고 이야기했습니다. 그 글을 읽고 저는 큰 충격을 받았고, 그 이후로 웹을 위한 디자인에 대해 생각하는 방식이 바뀌어버렸습니다.

하지만 인터넷 상에선 여러 것들이 변하기 마련이죠. 처음엔 AJAX 혁명이 있었고, 모바일 앱들이 나타났습니다. 그 후엔 기술의 거대한 소비가 있었구요. UI를 향한 요구와 기대는 변했습니다. 이 글은 십년이 넘게 지난 아이디어를 현 시대에 맞게 개량한 결과물입니다.

이 점을 밝혔으니, 이제 먼저 이상적인 상태에 대해 이야기해보죠.

이상적인 상태(IDEAL STATE)

저는 항상 이 상태를 가장 먼저 만듭니다. 이 상태야말로 사용자가 가장 자주 보기를 바라는 상태이기 때문이죠. 이름에 걸맞게, 이상적인 상태는 제품의 잠재력의 극치를 내재하고 있습니다. 제품이 유용하고 상호작용이 가능한 컨텐츠로 가득찬, 최대의 가치를 제공하는 상태 말이죠. 어떤 화면의 이상적인 상태는 그 화면의 다른 모든 상태를 나타내는 화면의 기반에 해당합니다. 전형적인 마케팅 페이지나 모바일 어플리케이션의 앱 스토어 스크린샷을 떠올려 보세요.

이 상태가 다른 모든 상태의 톤을 정하도록 하세요. 코어 인터페이스를 만들기 위해 반복하면서, 이 UI는 시간이 지남에 따라 엄청나게 변할 수 있기 때문입니다. 반복에는 아름다움과 리스크가 모두 존재하지요.

그리고 이 점은 다른 모든 화면에 지대한 영향을 끼칩니다.

모든 UI 상태는 결국 이상적인 상태를 향합니다. 그러므로 이상적인 상태로부터 시작하고, 제품의 디자인이 고객의 문제를 더 잘 풀 수 있게 되는 과정에서 자연스럽게 다른 상태들이 나타나도록 하세요.

아직 이상적인 상태라는게 정확히 무슨 뜻인지 모르시겠나요? 보다 명확히 하기 위해 몇 가지 예를 살펴봅시다.

얼마나 그림같은가요. 데이터도 많고, 사진도 많고.
틴더는 시장에서 가장 훌륭한 이상적인 상태를 가진 제품 중 하나입니다.

비어있는 상태(EMPTY STATE)

비어있는 상태는 하나의 화면 이상의 의미를 가집니다. 비어있는 상태를 통해 당신은 고객에게 당신의 제품을 소개하면서 훌륭한 첫 인상을 줄 수 있습니다. 관심을 유지하도록 하고, 행동을 하도록 이끌고, 제품이 제공할 가치를 떠올리게 하는거죠.

비어있는 상태는 크게 세 가지 버전으로 나눌 수 있습니다. 첫째는 고객이 제품을 맨 처음으로 사용할 때입니다. 두 번째는 그 유명한 “안 읽은 메일 없음“ 상태와 같이, 고객이 자의적으로 화면에 이미 존재하는 데이터를 모두 치웠을 때입니다. 마지막으로, 검색 결과가 비어 있을 때처럼 보여줄 게 아무 것도 없는 경우도 이 상태에 해당합니다.

대략 말하자면, 비어있는 상태를 대할 때의 리스크는 보통 이 상태는 제품을 일단 만들고 난 뒤에 추가적으로 덧붙이게 되는 경우가 많다는 것입니다. 많은 경우, 이는 너무 과한 경험 또는 냉정하고 비인간적인 경험 둘 중 하나로 끝나게 됩니다.

조지 타케이라면 이렇게 말하겠죠: “세상에…”

제 의견으로는 코치 마크 — 또는 지시 사항을 담은 오버레이 — 는 제품의 첫 인상을 사려깊게 디자인하지 않은 대표적 예시입니다. 코치 마크는 더 많은 인터페이스와 더 많은 외워야 할 것들로 정신적으로 여기저기 제동을 걸며, 제품에 익숙해지는 것을 소비자의 책임으로 전가합니다. 바람직하지 않죠.

아래에서 처음으로 제품을 사용할 때의 상태를 좀 더 살펴보죠.

첫 사용 / 온보딩

고객이 제품을 맨 처음으로 사용한다면, 이 상태는 데이터가 충분할 때 고객이 어떤 화면을 보게 될 지 설명할 수 있는 유일한 기회입니다. 행동을 유도하고, 제품이 제공할 가치에 대해 이해하는 것을 도울 수 있는 기회죠. 첫 인상은 한 번 뿐인 경험인데, 바로 이 상태가 훌륭한 첫 인상을 줄 수 있는 기회입니다.

저는 이 상태를 문학 세계에서의 “영웅 서사”에 빗대곤 합니다. Joseph Campbell이 그의 훌륭한 작업물 천의 얼굴을 가진 영웅에서 소개한 이 개념은 오디세이로부터 스타워즈까지 신화적 이야기들의 기반을 이루는 개념입니다. 기본적인 전제는 아래와 같습니다.

“영웅은 흔한 일상의 세계로부터 초자연적 신비의 영역으로 모험 해 나아갑니다. 그 곳에서 믿을 수 없는 힘을 마주하고 결정적인 승리를 따내죠. 영웅은 이 신비로운 여정에서 그의 평범한 사람들의 소원을 들어줄만한 힘을 가진 채 돌아옵니다.”

비어있는 상태를 통해 고객이 영웅 서사를 경험하도록 이끄세요. 그들을 모험으로 초대하고, 알려진 도전과 미궁의 유혹을 거치도록 한 뒤, 보다 강력한 개인으로 바꿔 놓으란 말입니다.

하지만 어떻게 그렇게 하냐고요? 아래에 몇 가지 아이디어가 있습니다.

  • 말을 물가로 이끄세요. 유저를 격려하고 사기를 높이는 카피라이팅을 사용하고, 다음에 무얼 해야 할지를 명백하게 말하세요. 예를 들어, “여기엔 아무 것도 볼 게 없습니다” 같은 문구는 고객이 무엇을 기대해야 할지에 대해 아무런 정보도 주지 않습니다. 처음 보게 되는 문구가 이거라면 오히려 약간 실망하게 되겠죠. 그 대신, 고객에게 눌러야 할 버튼을 정확히 알려주고, 그 버튼을 눌러야 하는 이유를 훨씬 더 도움이 되는 전망과 함께 제공하세요.
  • 고객에게 무엇을 해야할지 지시를 내리기 위해 제품의 컨텐츠를 사용하세요. 예를 들어, 메시징 제품을 만드는 중이라면, 첫 사용 경험으로 고객의 메시지 함에 자동으로 하나의 메시지를 넣어 둘 수 있겠죠. “저를 열기 위해서 제목을 탭하세요” 같은 제목을 사용하고, 메시지 내용 안에는 어떻게 메시지를 조작하고 메시지에 답장할 수 있는지 등의 정보를 담아두는 겁니다.
  • 이상적인 상태에서 화면이 어떻게 보일지 예시 스크린샷을 제공하세요. 이런 스크린샷은 고객에게 당신 제품의 잠재성을 선보이면서, 그들이 화면의 스크린샷과 비슷한 것을 성취할 것이라는 기대를 불러일으킵니다.
  • 고객의 성취를 지켜보면서 그에 알맞게 반응하세요. 예를 들어, 특정 화면에서 너무 오래 멈춰 있는 고객에게는 무언가 도움이 필요한지 라이브 채팅으로 물어볼 수 있겠죠.

제가 사랑하는 첫 사용시 비어있는 상태의 예시 몇 개를 보여드리죠.

Hipchat은 바로 드러나지 않는 유머러스한 추가 기능을 암시하며, 고객에게 무엇을 해야할지를 말해줍니다. (역: 화면의 메시지: 카일에게 인사하세요 두 분 아주 조용히 계시네요. (doge) 같은 식으로 이모티콘을 사용해 정적을 깨보는건 어떨까요?)
Facebook Paper는 고객에게 키 제스쳐를 가르쳐 주는 동시에 제품의 기능을 점진적으로 소개합니다.
Basecamp 는 보여줄 컨텐츠가 하나도 없을 때 스크린을 빈 채로 내버려두는 대신, 대체 이미지를 배치함으로서 고객이 제품의 가능성을 상상할 수 있게 합니다. 제 안의 완벽주의자는 이상적인 생산성으로 이 화면을 가득 채우기 위해 프로젝트를 만들고 싶어하게 되겠죠.
Airbnb의 위시 리스트 항목에 맨 처음 들어가면 위와 같은 스타일리쉬하고 간결한 비어있는 상태를 보게 됩니다. 이 디자인에서 제가 좋아하는 부분은 이 화면이 (Airbnb의 디자인 언어에 맞게) 너무 열심히 노력하지 않으면서도 고객이 데이터를 모으기 시작하도록 할 아주 분명한 CAT(call-to-action)을 담고 있다는 것입니다.

온보딩과 첫 사용 시의 상태는 거대한 주제이고, 그것만으로 책 한 권을 쓸 만한 정도입니다. 사실, 너무 그런 나머지 이미 그에 대해 쓰여진 책이 있죠. 온보딩이라는 주제에 대해 좀 더 알아보고 싶다면, Samuel Hulick의 훌륭한 저서 The Elements of User Onboarding을 추천드립니다.

유저가 데이터를 지움(USER-CLEARED DATA)

비어있는 상태의 두 번째 종류는 고객이 의도적으로 화면에서 데이터를 지운 상황입니다. 이런 경우의 예시로 고객이 해야할 일 리스트의 아이템을 전부 완료 했거나, 모든 알림을 읽었거나, 모든 이메일을 보관 처리 했거나, 모든 음악을 다운로드 한 상황을 생각해 볼 수 있습니다.

이런 종류의 비어있는 상태는 고객에게 보상을 주거나 더 나아가 다른 행동을 유도하기에 아주 훌륭한 기회입니다. “받은 메일함 비어있음” 상태를 달성했다고요? 멋지네요! 이 훌륭한 사진을 보여드리죠. 모든 음악을 다운로드하셨나요? 좋아요, 이제 가서 받은 음악들을 들어보시죠. 모든 알림을 확인하셨다고요? 당신이 읽어보고 싶어할 지 모르는 다른 글들이 여기 있습니다.

데이터를 비우는 고객은 당신의 제품에 깊게 몰입한(engaged) 고객입니다. 그들이 해야 할 일을 대신 해줌으로서 그런 고객을 당신 제품의 사용 흐름 속에 계속 유지시키세요. 다음 도약을 이루어야 할 짐을 고객에게 떠넘겨서는 안 됩니다.

iOS 6의 아주 오래된 스크린샷이지만, 여전히 받은 메일함을 모두 비웠을 때의 그 미묘한 도파민의 느낌을 그려내고 있습니다. 손수 선택된 커피숍이나 석양 등의 인스타그램 사진이 보상으로 주어지고, 인터넷에 공유 할 수 있게 되죠. 공유를 통해 받은 메일함을 비웠다는 것을 축하하고, Mailbox를 광고하는 효과도 얻게 됩니다. 일석 이조죠!

결과 없음(NO RESULTS)

만약 고객이 제품 내의 특정 데이터를 찾고자 돌아다니거나 검색을 하는 경우, 그들이 찾는 결과가 하나도 없는 경우가 생길 가능성이 있습니다. 이러한 시나리오는 고객이 찾고자 했던 것을 추론하고 똑똑한 제안을 해 줄 수 있는 놀라운 기회입니다.

Amazon은 이러한 기술을 가장 잘 사용하는 예입니다.오타와 비슷한 검색 결과 덕분에, Amazon에서의 검색이 고객에게 빈 결과를 보여주는 경우는 극히 드뭅니다. 그 대신, 어떤 단어가 맞지 않았는지를 보여줌과 동시에 가장 근접한 검색 결과를 제공하죠.

마침내 제가 메탈을 사랑한다는 것을 드러내는 예시군요. 뭐, 언젠가는 밝혀지기 마련이었겠죠.

핀터레스트의 경우는, 뭐, Amazon과 그다지 비슷하진 않네요. 하지만 이건 Pinterest 아니겠습니까. 그들이 저의 질의를 어떻게 해석했는지 본 후에, 고객은 비교적 손쉽게 검색어를 손보아서 원하는 정보를 얻을 수 있을 것입니다.

여기에서의 교훈은 이겁니다. 고객을 전혀 알 수 없는 상태에 데려다 놓지 마세요. 그들이 뭐라도 시도해 볼 수 있는 것을 주던지, 대안이 될 수 있는 경로를 제시하세요.

오류 상태 (ERROR STATE)

무언가 문제가 발생할 때의 화면입니다. 보통, 이 경우는 단순히 하나의 화면보다는 좀 더 복잡한데, 오류는 온갖 놀라운 조합으로 일어날 수 있기 때문입니다. 폼 데이터에서 빠져 있거나 잘못된 값이 있는 경우, 앱이 서버에 연결할 수 없는 경우, 업로드를 마치기 전에 다음 단계로 넘어가려고 시도하는 경우, 텍스트를 제출하지 않고 페이지를 떠나는 경우를 비롯한 수많은 경우가 오류 상태에 포함됩니다.

오류가 발생했을 때, 제품은 사용자의 모든 입력값을 안전하게 보관함으로써 사용자를 안심시켜야 합니다. 제품은 오류가 발생했을 때 사용자가 입력 또는 업로드한 어떤 것도 취소하거나, 파괴하거나, 지워서는 안 됩니다.

오리지널 매킨토시와 The Humane Interface의 저자 Jef Raskin의 발언을 보는게 적절하겠네요. 그는 이렇게 적었습니다. “시스템은 모든 유저 입력값을 신성하게 여겨야 한다. 아이작 아시모프의 로봇공학 제 1원칙, ‘로봇은 인간에 해를 가하거나, 혹은 행동을 하지 않음으로써 인간에게 해가 가도록 해서는 안 된다.’를 바꾸어 말하자면, 인터페이스 디자인 제 1원칙은 다음과 같아야 합니다. ‘컴퓨터는 사용자의 작업물에 해를 가하거나, 혹은 행동을 하지 않음으로서 작업물에게 해가 가도록 해서는 안 된다.’”

이 충고를 유의하기 위해 각별히 형편없는 이 규칙의 위배자를 볼 수 있겠습니다. 바로 항공사 웹사이트입니다. 예를 들어, 신용 카드의 안전 번호를 입력하는 아주 조그마한 폼 필드 하나를 빠트렸을 때, 많은 경우에는 페이지가 새로 로딩되며 한 땀 한 땀 입력한 온갖 정보는 전부 날아간 대신 아주 공격적인 빨간색으로 어떤 필드가 빠졌는지 알려주는 식의 결과가 나오곤 합니다.

그 동안 즐거웠고, 다신 만나지 맙시다.

취소! 확인! 아마도?

아, 드디어 우리가 이해할 수 있는 문맥상의 오류 메시지에 대해 이야기해보죠. 보너스로, 좀 더 인간적으로 느껴지도록 하기 위해 약간의 유머를 첨가할 수도 있습니다.

이상적인 오류 상태는 유저로부터 입력받은 어떤 데이터도 파괴하지 않고 동적으로 발생합니다. 만약 에러를 감지하기 위해 페이지 새로고침을 피할 수 없다면, 부디 친절하게 제품에 입력된 데이터를, 비록 오류가 있다 한들, 어디든 저장해두시고요. 하지만 많은 경우 오류를 감지하기 위해 새로 고침을 하는 것은 게으름을 나타내는 신호입니다. 고객을 위해서, 부디 오류를 보다 너그럽고 친절한 방식으로 다루기 위해 당신과 당신 팀의 개발자가 좀 더 많은 노력을 하도록 하세요.

추가적으로, 오류 상태는 드라마틱 해서도, 모호해서도 안 됩니다. “죽음의 파란 화면”을 기억하시나요? 맥의 “커널 패닉”은요? 아니면, 컴퓨터를 잘 다루시는 편이라면 ”종료, 재시도, 취소”도 있겠네요. 이런 오류 상태는 필연적으로 컴퓨터의 재시작 내지는 재시도를 필요로 하는 치명적인 시스템 에러를 나타냅니다. 하지만 아직까지도, 그 오류들이 최종 사용자에게 전달했던 충격, 공포, 그리고 혼란으로 인해 잘 기억되고 있죠.

마이크로소프트의 죽음의 파란 화면이 유명해진 이유는 단순합니다. 그 화면이 사람들을 소스라치게 만들었기 때문이죠. 그 파란 화면은 (빨간 색이었던 것보단 나앗겠죠) 디버깅에 유용 했을지는 몰라도, 맥락에서 벗어나서 갑자기 나타났고, 온갖 무섭고 알아 들을 수 없는 말로 가득 차 있었습니다.

오류 상태는 반드시 다음에 해야 할 일을 알려주는 간결하고, 친절하고, 교육적인 문구를 포함해야 합니다. 모호한 에러 코드, 십육진수와 혼란스러운 선택지는 이러한 오류를 경험하는 사람들을 무섭고 실망스럽게 만들기만 할 것입니다.

물론 당신 제품의 사용자가 복잡한 과학/기술을 잘 이해하는 사람 내지는 컴퓨터 엔지니어로만 구성될 수 있겠지요. 그런 경우, 이런 매우 기술적인 오류 메시지가 고객에게 알맞은 선택지일 수 있습니다. 하지만 세상의 대부분의 사람이 소프트웨어를 일상적으로 사용하고 있고, 이런 오류 메시지가 적절한 경우는 점점 줄어들고 있습니다.

간단합니다. 오류 메시지를 기술적으로가 아닌 사람처럼 느껴지게, 그리고 메시지를 들을 대상에 알맞게 만드세요. 무언가 잘못되었을 때, 당신은 어떤 것을 듣고 싶으신가요?

오류 상태는 아주 넓게 퍼져 있고, 디자인을 하는 입장에서는 고객이 가장 안 만났으면 하는 상태입니다. 하지만 제가 장담드리건데, 이 상태에 앞선 두 상태와 마찬가지로 많은 노력을 기울일수록 당신의 제품은 훨씬 더 즐겁게 사용할 수 있는 제품이 될 것입니다. 동시에, 고객이 마주칠 수 있는 흔한 문제에 대해 당신이 미리 생각하고 해결하게 될테니 더 유용한 제품이 되겠죠.

부분적인 상태(Partial State)

오류 상태와 이상적인 상태 간의 차이는 밤과 낮 간의 그것과 같습니다. 하지만 한 줄의 데이터만이 존재할 때에는 화면이 어떻게 보여야 할까요? 사진이 몇 장 밖에 없거나, 프로필이 반만 채워졌을 때에는요?

부분적인 상태는 페이지가 비어있지 않되 드문드문 채워져 있을 때 보게 되는 화면입니다. 여기서 당신의 의무는 사람들이 낙심한 나머지 당신의 제품을 사용하는 것을 포기하는 일을 막는 것입니다.

이 화면은 사용자를 영광스러운 이상적인 상태로 인도하기 위한 마이크로 인터랙션을 디자인하기 위한 훌륭한 기회입니다. 사용자가 제품의 진정한 가치를 깨닫는 것을 돕는 여정이지요. 이 상태는 (사용자가 이룩하기 위해 이미 어느 정도의 시간을 소요한) 어떤 성취를 암시합니다. 사용자가 계속 관심을 갖고 있도록 만드세요.

몇몇 게임 디자인 원칙이 여기에서 유용하게 쓰일 수 있습니다. 클래쉬 오브 클랜에서처럼 더 나아지기 위해선 크리스탈을 모아야 하는 괴로운 경험 같은걸 말하는 건 아니구요. 제품의 이 상태에서 소위 촉진(acceleration)을 형성하는 것 말입니다.

촉진이란, 플레이어로 하여금 자신이 미래에 얼마나 더 강력할 지 그려보도록 도와주고, 그 비전을 달성하기 위해 해내야 할 일련의 작업으로 인도하는 작업을 나타내는 게임 디자인 용어입니다. 여기서의 핵심은 플레이어가 제품의 최대 가치를 뽑아내기 위해 스스로 지루하게 느낄 수 있는 작업을 하고 있단 사실을 인지하지 못 하게 하는 것입니다.

“촉진 단계에 진입하는 플레이어는 레벨 업을 하기 위해 그들이 해야 할 싫증나는 반복에 대해 생각하지 않고, 그저 그 반복을 하면서 결과의 가속도를 즐길 뿐입니다. … 그 대신, 플레이어들은 그들의 캐릭터가 그들이 이해할 수 조차 없는 방식으로 더 강해진 미래에 사로잡히죠. 보다 기술적으로 말하자면, 그들은 플레이어 예측 지평을 넘어 사라지는, 지수적으로 증가하는 힘 구조를 유추합니다. 전통적인 흐름과 정확히 같지 않지만, 플레이어의 들뜸 자체는 아주 유사하죠.”

아래에는 야생에서 찾아볼 수 있는 부분적인 상태의 예시입니다.

LinkedIn의 유명한 “프로필 완성도” 막대입니다. 사용자에게 정확한 작업들을 수행함으로서 100%를 달성하기를 장려하죠. 완벽주의자들이 환호하는군요.
Dropbox는 장담컨데 대부분의 Dropbox 사용자에게 매우 끌리는 요인일 추가적인 저장 공간을 얻어내기까지 사용자가 얼마나 가까운지를 보여줍니다. 단순히 완성까지 얼마나 많은 단계가 남았는지 보여주는 것 뿐만이 아니라, 이러한 단계는 교육과 활성화를 통해 고객을 보다 가치있게 만드는 부수 효과 또한 갖고 있습니다.

로딩 상태(LOADING STATE)

이 상태는 경시하기 쉽고, 실제로 많은 제품 디자이너가 이 상태를 추후에 덧붙이곤 합니다. 하지만 이 상태에는 기대치를 정한다는 지극히 실존적인 짐이 존재합니다. 당신의 앱이 데이터를 불러오고 있거나, 인터넷 연결을 기다리고 있거나, 다른 화면으로 전환 중일 때, 당신은 이런 데이터를 불러오는 상황을 어떻게 드러낼지 아주 사려깊게 접근할 필요가 있습니다. 전체 페이지 가로채기, 컨텐츠 창의 레이지 로딩, 또는 예를 들어 고객이 폼 필드에서 사용자 이름이 사용 가능한지를 찾아 볼 때 사용할 법한 인라인 로딩 등이 모두 이 상태에 포함됩니다.

또한, 로딩의 인지 역시 동등하게 중요합니다. 너무 많은 경우 디자이너는 화면을 공백과 스피너로 채움으로써 그 곳에 존재하지 않는 컨텐츠에게 거대한 책임을 부과합니다. 이런 행위는 자연스럽게 고객에게 (비유적으로) 시계를 보게 만들고, 실제로 발생하고 있는 불러오는 행위 대신 무언가를 불러오고 있다는 자체에 집중이 쏠리도록 만듭니다.

eBay에서 Yahoo!, Google 등의 디자인 팀을 이끌었고 이제는 모바일 투표 스타트업 Polar에 정착한 Luke Wroblewski의 의견 역시 그러합니다.

Wroblewski과 그의 팀은 각 투표에 대한 여러 종류의 스피너를 구현한 뒤에, 고객들이 앱이 느리다고 불평하기 시작했단 것을 알아차렸습니다. 그들은 “페이지가 새로 고침 되거나 불러와지기까지 터무니 없는 양의 기다림이 필요한 것처럼 보이고, 예전 버전만큼 빠르게 느껴지지 않는다” 와 같은 말을 했죠.

Wroblewski는 깨달았습니다.

그는 “이런 인디케이터를 도입함에 따라, 우리는 사람들이 시계를 바라보도록 만든 것이나 다름 없습니다.” 라고 했다. “결과적으로, 시간은 더 느리게 흐르고 따라서 우리 앱도 느려졌다. 우리는 사용자가 그저 기다리는 것이 아닌 목표에 다가서고 있다는 것을 분명하게 만들어주는 진척이 아닌, 인디케이터에 집중했다.”

뼈대 화면 (SKELETON SCREENS)

이러한 깨달음은 그가 “뼈대 화면”이라 부르는 것의 창조를 직접적으로 야기했습니다. 뼈대화면은 이제는 핀터레스트와 페이스북의 웹과 모바일 모두에서 사용되는 테크닉입니다. 로딩 상태에 대한 혁신적인 시도인 뼈대 화면은 컨텐츠가 로딩 중이라는 사실 자체 대신 불러와지고 있는 컨텐츠에 초점 맞추도록 합니다. 이러한 작업은 일단 페이지의 기본 구조를 보여주고, 빠져 있는 내용물이 다운로드 됨에 따라 점진적으로 빈 자리를 채우는 방식으로 구현됩니다. 이 테크닉의 아름다운 점은 스피너를 아예 없앨 수 있다는 점입니다. 또한 사용자가 인지하는 성능을 증가시키죠.

Luke Wroblewski의 앱 Polar와 앱의 뼈대 화면

핀터레스트는 뼈대 화면 로딩 상태의 개념을 도입하되, 구현에 있어 독특한 변화를 줍니다. 바로 이미지의 “평균 색상”을 얻어낸 뒤 이미지의 배경을 그 색으로 채우는 것이죠. 이렇게 함으로서 이미지가 완전히 불러와지기 전에도 사용자는 마치 보게 될 이미지의 미리보기를 보는 듯한 느낌을 받게 됩니다.

페이스북은 비슷한 테크닉을 그들의 모바일 앱 Paper에 도입한 뒤, 후에는 웹 버전에서도 구현했습니다. 그들이 “어른거리는 효과(shimmer effect)”라 부르는 효과와 결합해, 페이스북은 컨텐츠와 비슷한 모양을 갖는 특정한 뼈대 효과를 보여줍니다. 그리고 컨텐츠를 불러오는 중이라는 것을 전달하기 위해, 도형들은 어른거리는 효과를 통해 고동치죠.

낙관적인 행동에 대해 성공 예측하기

그의 엔지니어링적 노력이 앱의 사용자가 느끼는 속도를 어떻게 달성했는지 설명하며, Instagram의 공동 창업자인 Mike Krieger는 2011년에 다음과 같이 말했습니다. “아무도 그들이 기다리는 동안 기다리길 원하지 않는다.”

사실 Krieger는 제품에 의해 어떤 행동이 “낙관적으로” 수행되어야 한다는 개념을 개척했습니다. 행동이 성공할 것을 가정함으로서, 행동이 훨씬 빠르게 동작하는 것처럼 보이게 하는거죠.

사진에 “좋아요”를 누르거나 댓글을 다는 경우를 생각해 보십시오. 두 경우 모두에서, 고객 관점에서는 해당 행동이 즉각적으로 접수됩니다. 그리고 백그라운드에서 제품은 실제로 행동을 완료하기 위해 서버에 요청을 보내고 있죠.

또한 낙관적인 행동은 미디어를 업로드 할 때 사용자가 느끼는 속도를 증가시키는데에도 큰 도움이 될 수 있습니다. 사용자가 사진 업로드 흐름에서 “완료” 버튼을 누르기 전까지 기다리는 대신, 인스타그램은 필터가 선택된 직후부터 사진 업로드를 시작합니다. 고객이 취소할 경우 데이터를 그냥 버려야 할 수 있다는 점에서 최적의 엔지니어링 해법은 아니더라도, 이런 접근은 업로드가 매우 빠르게 일어나는 것처럼 보이게 합니다. “아무도 보지 않고 있을 때 비트를 옮겨라”라는 정신을 따름으로서 당신 제품의 속도가 당신의 자산 중 하나가 되도록 할 수 있습니다.

지금까지 UI 스택과 다섯가지 상태 각각의 여러 예시를 보셨는데요. 그 상태들이 모두 함께 동작할 때는 어떤 모습일까요? UI는 각 상태 간의 전환을 어떻게 설명해야 할까요?

그게 바로 UI 스택의 강력한 점입니다. 이런 상태들은 진공 속에 존재하지 않습니다. 제품에 의해 어떤 때에든 호출될 수 있는 수직적 축 위에 존재하죠. 이 상태들을 처리할 뿐만 아니라 화면이 각 상태 사이에서 어떻게 이동하는지 서술하는 것이 당신의 역할입니다.

이 아이디어를 설명하기 위해, 실제로 존재하지 않는 메시징 앱을 만들어 보았습니다.

왜 메시징 앱이냐구요? 이런 상태를 갖고 놀기에 가장 먼저 떠오르는 뻔한 예시는 아니죠. 하지만 저는 이것이 메시지 인터페이스처럼 임시적인 UI 조차 UI 스택의 규칙을 따르는지 보여줄 수 있는 훌륭한 예시라고 생각합니다. 더 나아가, 한 상태에서 다른 상태로, 화면의 상태가 매끄럽게 이동하는 것을 확실히 해야 할 우리의 책임이 얼마나 큰지를 잘 보여주죠.

그래서, 메시징 앱에서 우리가 신경써야 할 것들이 뭐가 있을까요?

메시지가 하나도 없는 상태를 처리해야 합니다. 이게 우리의 비어있는 상태입니다.

우리의 부분적인 상태는 한 쪽에서만 메시지를 보냈을 때가 되겠네요.

그러고 나면, 메시지를 받기를 기다릴 때의 타이핑 인디케이터가 있습니다. 다른 말로는, 우리의 로딩 상태죠.

하지만 잠깐만요, 다른 종류의 로딩 상태 있죠. 우리가 메시지를 보내고, 그 후 메시지 전송 확인을 받을 때 말입니다.

이 흐름에서 오류가 발생할 수 있겠죠. 메시지 전송이 실패할 때라던지요.

그리고 우리가 오류로부터 복구하고, 다시 전송을 시도하는 메커니즘을 잊어선 안 됩니다. 이것도 로딩 상태의 다른 버전이 되겠네요.

마지막으로, 우리는 메시지들이 대화로 바뀌는 이상적인 상태에 이르게 됩니다.

가상의 예시

Marty와 Doc이 방금 막 번호를 교환했고, Marty가 Doc에게 방금 그가 Twin Pines Mall에서 무얼 보았는지에 대해 메시지하고 싶다고 해 보죠.

아직 아무 메시지가 없었기 때문에, 우리는 비어있는 상태를 이용해 고객이 우리가 그들이 행동하길 원하는 대로, 즉 메시지를 보내도록, 장려할 기회를 갖고 있습니다.

하지만 하나의 메시지가 보내지고 난 후에는 이 상태에 어떤 일이 일어나나요? 우리는 우아하게 빈 상태를 씻어낸 후, 부분적인 상태로 넘어가야 합니다. 이 경우에는, Marty가 딱 하나의 메시지를 보낸 때 말이죠.

(역: 아래 링크는 모두 각각 7초 분량의 짧은 동영상입니다. 미디엄이 동영상 파일의 직접 업로드를 지원하지 않으니, 링크에 들어가서 확인해보세요.)

http://scotthurff.com/images/posts/ui-stack/1.empty-to-partial.mov

Doc이 답장을 한 때로 빨리감기 해 봅십다. 그는 메시지 하나를 보냈지만, 아직 할 말이 더 남았네요. 따라서 로딩 상태의 한 형태인 타이핑 인디케이터가 필요하죠.

http://scotthurff.com/images/posts/ui-stack/2.message-incoming.mov

타이핑이 끝나고 메시지가 보내지면, 타이핑 인디케이터는 사라지고 새 메시지가 화면에 있는 다른 것들을 밀어내면서 나타납니다.

하지만 Marty가 다시 답장을 하고 싶을 땐 어떻게 하죠? 먼저, 필드에 텍스트가 있을 때에는 그 상태를 인식했다는 것을 보여줘야 합니다. “Send” 버튼이 회색(비활성화 상태)에서 파란색(활성화 상태)로 변하는 것에 주목하세요. 그러고 나서 실제로 메시지를 전송하면, 전송 과정에서 또다른 로딩 상태가 발생합니다. 이 때에는 메시지를 어둡게(dimmed) 처리하는데, 아직 성공적으로 메시지 전송이 완료되지 않았기 때문입니다. 전송이 완료된 후 고객에게 모든게 잘 처리되었다고 알려줄 “전송 됐음” 도장이 아직 없는거죠.

http://scotthurff.com/images/posts/ui-stack/3.message-send.mov

하지만 만약 메시지가 성공적으로 전송되지 않는다면요? 여기서 오류 상태가 등장합니다. 빨간 마커가 로딩 스피너를 대체하고, 우리는 “전송되지 않은” 어두운 상태의 메시지와 함께 남겨집니다. 전송되지 않은 메시지를 탭하면 재전송을 시도합니다. 이번엔 운이 좋았어서, 화난 빨간색 “!”는 사라지고, 메시지는 제 색을 찾고, 전송되었음을 알리는 인디케이터를 자리에 둘 수 있게 되었습니다.

http://scotthurff.com/images/posts/ui-stack/4.error-recovery.mov

이 곳, 실제 세상에서는…

그리고 이게 UI 스택이 실제 동작하는 모습입니다. 다섯 개의 화면 상태와 상태 간의 매끄러운 전환이죠. 이런 전환적 요소 없이는 새로운 상태가 나타나거나 사라짐에 따라 고객을 혼란스럽고 놀라게 만들 위험이 있습니다. 사람들을 불편하고 혼란스럽게 만드는 것이 우리가 해야 할 일은 아니겠죠?

마지막으로, 이러한 상태의 구현은 디자인과 개발의 강도 높은 협업을 필요로 합니다. 두 분야 모두에 시간을 투자하고, 함께 최고의, 가장 전체적인 경험을 고객에게 제공하기 위해 협업해야 하죠.

(만약 이 글을 좋게 읽으셨다면, 공유해주시면 감사하겠습니다. 클릭 한 번으로 트윗 할 수 있고 발송 전에 수정도 가능합니다.)

지금까지 읽은 흥미진진한 이야기의 플롯 요약

  • 이상적인 상태만을 디자인하고 다른 상태들을 뒤늦게 덧붙이지 마세요. 당신의 제품은 문제를 풀어야 합니다. 고객이 그 목표를 달성하는 것을 돕기 위해 각 화면의 상태가 어떤 역할을 할 수 있을까요?
  • Samuel Hulick의 The Elements of User Onboarding을 읽으세요.
  • 프로토타이핑을 할 때 로딩 상태를 포함시키세요. 로딩 상태 역시 제품의 경험의 일부이고, 나중에 가서야 추가되어서는 안 됩니다. 엔지니어링 팀과 함께 뭉쳐 사용자가 인지하는 (그리고 가능하다면 실제의) 성능을 향상시킬 수 있을만한 방법을 궁리해보세요.
  • 오류를 유발할 수 있는 여러 엣지 케이스를 하나하나 생각해보는 시간을 가지세요. 그 오류들을 어떻게 처리할 건가요? 고객에게 전할 수 있는 가장 친절한 응답이 뭔가요? 여기에는 가격과 이득 간의 트레이드오프가 있지만, 적어도 가장 고통스러울만한 오류들에 대해서는 꼭 처리하고, 고객의 데이터를 보존하기 위한 노력을 아끼지 마세요.