(번역) 신은 디테일 안에 있다
원문: https://medium.com/prevue-app/god-is-in-the-details-bc3a9a9a5d88 by Buzz Usborne글에 대한 모든 권리는 원 저자에게 있습니다. All rights are reserved to the original author.
“신은 디테일 안에 있다.”
Ludwig Mies van der Rohe가 1900년대 중반에 건축물들을 디자인하면서 했던 말이고, 이는 오늘날의 제품 디자인에도 여전히 옳다. 내가 건축에 대해 잘 안다고 할 순 없지만, 건축 디자인과 제품 디자인 사이의 또다른 공통점은 이러한 디테일이 아주 간과하기 쉽다는 것이다. 그러나 이 아주 사소한 디테일들이 궁극적으로 아름다운 제품을 만들고 아름다운 집을 만든다.
안타깝게도, 제품 디자인에서 내가 말하는 ‘디테일’은 명백한 디자인 결과물(색깔, 그림자, 위치 등)에 대한 게 아니다. 나는 정의하기 어려운 것들에 대해 말하고자 한다. 사용자가 어떤 인터랙션에서 더 편하게 느끼도록 하는 경험과 패턴에 대해서. 이런 디테일은 여러 형태 — 커서 모양 바꾸기, ‘눌린’ 상태의 버튼 스타일, 유용한 애니메이션 등으로 나타날 수 있다.
디테일이 어떤 형태를 취하든, 나는 그 디테일이 포토샵으로 만든 디자인이나 상세 스펙 문서에서는 볼 수 없으리라 장담한다. ‘UX’나 ‘UI’라고 칭해지는 그 무엇의 바깥쪽에 있는, 이런 인터랙션 디테일은 제품을 실제로 써보고, 또 디자인하고 구축하는 데 시간을 써야만 발견할 수 있다.
디테일을 제품에 포함시키는 일은 시간도 더 많이 들고 기술적으로도 더 어렵다. 그래서 쉽지 않고, 그래서 드물다. 나는 이러한 디테일을 추구하는데 많은 노력을 기울였다. 그리고 Prevue의 디자이너이자 개발자로서, 나는 디테일에 집착하는 게 가능하게 해주는 두 가지 호사를 누릴 수 있었다.
첫번째는 내가 제품을 사용하고 개선하는 것을 반복할 수 있는 상황이었다는 것이다. 여기서 ‘상황’이란 디테일을 기술적으로 구현할 능력뿐만 아니라 구현할 시간도 있었음을 뜻한다. 때론 하나의 인터랙션에서 0.65초동안 지속되는 애니메이션을 멋지게 만드는 데 집착하느라 50%나 더 많은 시간을 들일 때도 있다. 대부분의 제품 개발에서 이런 호사는 누리기 어렵다.
두번째는 내가 실제로 내 제품을 매일매일 사용하는 상황이었다는 것이다. 뭔가 불편한 인터랙션(불필요하게 긴 애니메이션이나 멍청한 유저 플로우 등)이 있으면 내가 그걸 발견할 확률은 아주 높았다. 이건 기능 테스트(“Z를 누르면 X가 Y대로 동작하는가?”)와 실제 삶에서의 유저 테스트(“데드라인이 가까워졌을 때 이 제품을 쓰면 내 일을 완수하는데 직관적인 도움을 주는가?”)의 차이이기도 하다.
하지만 솔직히 말하면, 하나의 제품을 계속해서 써보고, 기능을 재구축하고, 작은 디테일에 집착하는 건 아주 많은 시간이 든다. 어쩌면 Prevue 같은 사이드 프로젝트나, 돈이 너무 많은 제품이 아니라면 이런 호사를 감당하기 어려울 수 있다. 이것들은 대개 정당화하기 아주 어렵고, 분명 압박이 다가왔을 때 첫 번째로 희생해야 할 것이기도 하다. 그래서 Ludwig Mies van de Rohe은 건축물을 몇 개밖에 디자인하지 못했고, Prevue는 기능 추가가 느렸던 것이다.
지난 7년간 나의 사이드 프로젝트를 다듬어오면서, 나는 ‘디테일 중심으로 디자인된 제품’을 ‘기민하게 움직이는 상품’으로 전환하고자 할 때 어떻게 하면 빠르게 효과를 볼 수 있는지를 배웠다. 나는 당신의 제품 릴리즈 일정에 어떻게 하면 ‘디테일에 파고들 시간’을 끼워넣을지에 대한 완벽한 해결책 대신, 프로젝트에서 작은 개선을 시작할만한 몇 가지 포인트를 공유하려고 한다. 그리고 이 작은 디테일들이 어떻게 모든 변화를 이끌어내는지도.
인터랙션을 눈으로 보여주어라
대부분의 제품에 적용될 수 있는데도 쉽게 간과되는, ‘버튼의 상태’로 이야기를 시작해보자. 인터넷 속도가 아무리 빨라도, 버튼을 누르고 다음 액션(새 페이지 로드나 사진 업로드 등)이 시작될 때까지는 항상 딜레이가 있다. 그러나 그 때 뒤에서 어떤 일이 벌어지는지를 시각적으로 보여주는 제품은 드물다.
유저가 클릭했음에도 그 클릭이 잘 동작했는지를 확인시켜주지 않은 채 놔둔다면 그 유저의 여정에 불필요한 중단을 일으키게 된다. 서버가 액션을 진행하는 동안 당신의 유저는 클릭이 작동했는지 아닌지 궁금해한다. 유저가 당신 제품의 UI에 대해 생각을 하는 건 전혀 당신이 원하는 바가 아닐 것이다.
해결책은 유저가 클릭했을 때를 표시하는 버튼 스타일을 추가하고, 액션에 대한 정보가 성공적으로 전송됐을 때를 위한 추가 스타일 또는 애니메이션을 두는 것이다. 이걸 통해, 최소한 유저가 실제로 클릭했음을 보여줄 수 있다.
한발 더 나아가, 수행되는 데 시간이 좀 걸리는 액션이라면 실제로 유저에게 무엇이 벌어지고 있는지 말해주는 것을 고려해보라. 디자인 안에서 적절하게 설명을 녹여낼 수 없다면, 문자 그대로 설명하더라도 부끄러운 일은 아니다.
물론 단순히 스타일만 바꾸는 것보다 더 깊이 들어갈 여지는 얼마든지 있다. 이미지 업로드(=상당한 시간이 드는 액션)가 좋은 예다. 유저 인터랙션이 2초 이상 지속되리라 예상되는 이벤트에서는, 아직 성공하지 않았더라도 그냥 성공한 척 보여주는 게 유저가 기다리게 하는 것보다 나을지도 모른다.
섬세한 애니메이션을 사용하라
나는 애니메이션의 중요성과, 유저가 인터페이스를 이해하는 걸 돕는 데 애니메이션이 어떤 역할을 하는지에 대해 몇날 며칠이고 말할 수 있다. 다행히도 여기에 대해선 이미 수많은 자료가 있으니, 대신 섬세한, 거의 인지하기 어려운 애니메이션의 중요성에 대해 다루겠다.
다음 사진을 보라. 이미지를 폴더로 드래그하는 건 유저의 확인을 요구하지 않고 그냥 작동하지만, 유저는 그걸 모른다. 그래서 이미지가 잘 추가되었음을 뜻하는 작은 애니메이션을 추가함으로써 유저의 불안을 줄인다.
애니메이션은 뷰와 뷰 사이의 전환을 알리는 데도 쓰인다. 갑작스럽게 상태를 바꿈으로써 유저의 포커스를 잃는 대신, 애니메이션을 쓰면 무엇이 어디서 오는지 알려줄 수 있다.
로드하는 데… 시간이… 걸린다는 걸… 기억하라
내가 Skype에서 일했던 시절의 유저 테스팅 세션이 기억난다. 유저가 ‘드롭' 했을 때 저장이 되는 드래그-앤-드롭 UI를 테스트하는 세션이었다. 그 기능은 너무 잘 개발됐기 때문에, 거의 유저가 드롭하는 즉시 저장이 됐고 로딩 상태를 필요로 하지도 않았다.
사실, 이 과정이 너무 빨라서 유저가 저장이 성공적으로 됐는지 의심했고, 혼란과 불안이 가중되었다. 해결책은? 드롭 이벤트가 발생하면 로딩 스피너가 돌아가게 해서, 제품이 ‘생각하는 척'을 하게 만들었다. 실제론 아니었는데도.
이건 로딩 스피너를 잘 쓴 케이스였다. 그러나 많은 경우에, 디자이너들은 단지 스피너를 추가할 수 있기 때문에 스피너를 추가한다. 그리고 많은 경우 유저에게 무언가가 로딩되고 있다는 걸 알려줄 필요가 없다. ‘돌아가는' 그래픽은 불필요하게 많은 관심을 끈다.
다음 예시는 사진이 동적으로 로드되는 상황인데, 저 페이지에서 중요한 건 사진이 아니라 텍스트 메시지다(“I’m big fan of this type!”). 여기서는 애니메이션이 있기 때문에 로딩 딜레이도 느껴지지 않고 스피너를 둘 필요도 없다.
컨텍스트에 대해 최적화하라
제품에 데이터, 이미지, 보고서 등이 포함되어있다면 제품은 항상 다르게 보일 것이다. 그러나 디자인을 할 때 우리는 최상의 시나리오에 대해 최적화하고, 종종 데이터가 없거나, 너무 많거나, 또는 그 중간인 상태에 대해서는 잊어버리고 만다. Lorem Ipsum, 예쁜 이미지들, 완벽한 숫자들은 버려라. 대신 컨텍스트에 대해 최적화하라. 진짜 데이터는 어떻게 생겨먹었는가?
UI의 여러가지 상태에 대해 고려함으로써 당신은 각 상태에 맞는 창의력을 발휘할 수 있다. 예를 들면, Prevue에서는 한 그룹에 이미지가 몇 개 있느냐에 따라 설정이 바뀐다. 어떻게 되든 유저 이미지가 항상 예쁘게 보일 수 있도록.
컨텍스트를 인지한다는 것은 단순히 보기 좋게 만드는 것 그 이상이다. 상황적 컨텍스트(Situaltional Context)를 인지하려면, 언뜻 보기에 직관적이고 일반적인 UI에서도 언제 어디가 눈에 띄게 해야 하는지를 확인해야 한다.
신용카드 정보를 받는 입력 폼을 예시로 들어보자. 조금만 신경을 더 써도 유저가 뭘 입력해야 하는지 이해하는 데 도움을 줄 수 있고, 잠재적 오류를 방지할 수 있다.
실제 삶에서 테스트하는 것의 가치를 보여주는 또다른 예시가 있다. 유저가 소중한 카드정보를 입력하는 건 사실 아주 불안한 일이기 때문에, 실제로 해보기 전까지는 그 가치를 인정하기 어렵다. Prevue의 신용카드 입력 폼을 만들던 때에, 최상의 유저 경험을 주기 위해 라이브 버전에서 수없이 테스트를 해봤다. 테스트를 한 번 할 때마다 내 카드에서 실제로 $10가 결제되었기 때문에 아주 충분한 동기부여가 되었다.
이런 상황에서 컨텍스트는 아주 중요하고, 아주 조그마한 디테일조차 유저를 도울 수 있다. 예를 들면:
- 숫자 포맷을 실제 카드와 같은 형태로 맞추기 (4자리 4자리 4자리 4자리)
- 숫자가 아닌 입력을 막고, 숫자를 더 많이 입력하는 것도 막기
- MM/YY가 입력되면 MM/YYYY를 추측하기 (06/18 -> 06/2018)
어떤 내용이 표시될지, 어떤 환경에서 액션이 수행될지, 또는 그 순간 유저가 느끼는 감정이 어떨지 등을 고려함으로써 당신은 보기에도 예쁘고 작동도 잘 하는 밸런스를 맞출 수 있다.
고유(native) 기능을 존중하라
당신의 제품은 그 제품이 존재하는 플랫폼의 고유 기능을 존중해야 한다. 즉 스크롤바 움직이는 것을 가로채는 것처럼 고유 기능을 바꾸는 게 아니라, 기존의 유저 경험 패턴을 보완해주어야 한다.
예를 들면, 어떤 사람들은 일반적인 액션을 수행하는 데 키보드 단축키를 사용한다. 따라서 당신의 제품이 유저에게 ‘파괴적'인 액션(컨텐츠 위치를 바꾼다거나, 많은 텍스트를 지운다거나)을 허용한다면, Ctrl+Z로 ‘되돌리기'가 가능하도록 만드는 것을 강력하게 생각해봐야 한다. Ctrl+S를 눌러 저장하기, ESC를 눌러 모달 윈도우를 닫기, ‘다른 곳을 클릭'해서 열려있는 메뉴나 드롭다운을 닫는 것 등에 대해서도 같은 논리가 적용된다.
유저에게 익숙한 인터랙션을 막는 순간, 불필요한 멈춤과 망설임이 생긴다.
또한, 유저가 액션을 수행하는 여러 가지 방법이 있다는 사실을 인지해야 한다. 예를 들어 Prevue와 Email Builder에서는 ‘업로드' 버튼을 클릭해서 이미지를 올려야 하지만, 이미지를 브라우저로 바로 드래그해서 넣는 사람도 많기 때문에 이 기능도 구현해 두었다.
완전히 똑같은 액션을 수행하는 두세 가지 방법을 구현하는 것은 불필요하게 복잡성만 늘어나는 것으로 여겨진다(특히 유저에게 그런 방법이 있다는 걸 알려주지도 않을 때에는 더 그렇다). 그러나 유저가 자신이 원하는 대로 제품을 사용할 수 있게 되는 순간, 당신은 사람들에게 편안하고 끊이지 않는 (seamless) 경험을 제공할 수 있게 된다. 이는 iPad가 실제 잡지 페이지를 넘기는 것과 유사하게 디자인된 이유이기도 하다.
당신만의 말투를 만들라(Set the tone)
마지막으로, 분명 가장 쉽게 실행할 수 있을 만한 디테일은 당신만의 말투를 만드는 것이다. 어려운 UI를 디자인하고 기술 문서를 쓰는 도중에는, 당신이 실존하는 사람들을 위한 제품을 만들고 있다는 사실을 잊어버리기 십상이다. 제품의 텍스트에 사람의 손길(Human touch)을 더하지 않으면 흡사 로봇에서 출력된 에러 메시지처럼 보인다. 유저에게 가장 안내가 필요한 시점에, 얼굴 없는 기계 앞에 있는 듯한 느낌을 준다. Dave Greiner가 제품의 텍스트를 작성하는 좋은 조언을 해주었다.
당신이 쓴 문구를 소리내서 말해보고, 그걸 유저에게 직접 말하고 있다고 상상해 보세요.
이는 두 가지 이유에서 훌륭한 조언이다. 우선 당신의 메시지가 불필요하게 길거나, 인간미가 없거나, 심지어 무례하진 않은지 빠르게 인지할 수 있다. 그리고 소리내서 읽음으로써, 지나치게 개인적인 메시지 또한 적절치 않음을 알 수 있다.
다음은 적절치 않은 메시지의 예시다. 나는 에러 메시지의 톤과 컨텍스트를 완전히 잘못 설정했었다.
읽는 사람의 마음을 부드럽게 하고 인간답게 하고 싶은 마음에서, 난 서버 에러로 인해 업로드가 실패하는, 드물게 일어나는 상황에 위와 같은 메시지가 뜨게 했다(업로드가 성공하지도 실패하지도 못했습니다 — ‘업로드 나니아'의 중간에 끼어버렸거든요). 내가 간과했던 건 컨텍스트였다. 유저는 업로드가 끝나기를 인내심 있게 기다렸는데 돌아온 건 도움이 되지도 않고 사과도 하지 않는 앱이라니. 내가 만약 유저였고 클라이언트에게 발표하러 가는 길이었다면, 또는 마감을 앞둔 상황이었다면 이런 메시지는 전혀 달갑지 않았을 것이다. 다행히 이 메시지는 고쳐졌지만, 그건 고객으로부터 정당한 분노가 담긴 이메일을 받고 나서였다.
물론 유머가 담긴 메시지가 들어갈 수 있을 만한 경우도 존재하며, 약간의 인간성이 가미되면 자칫 지루할 수 있는 유저 경험에 가치를 더해줄 수 있다. Prevue의 가입 화면은 아무 것도 입력하지 않은 채 양식을 제출했을 때 이런 메시지를 내보낸다. (여기는 당신이 무언가를 써야 하는 곳입니다.)
디테일은 제품의 마지막 1%다. 디테일은 정의하기 어렵고, 범위를 정하는 건 불가능하고, 주도면밀한 연구와 훌륭한 디자인과 재치있는 엔지니어링을 절대 대체할 수 없다. 하지만 디테일은 평범한 유저 경험과 훌륭한 유저 경험의 차이가 되어줄 수는 있다.
디테일은 당신의 제품이 자연스럽고, 재미있고, 직관적으로 느껴지도록 돕고, 유저가 스스로 똑똑하다고 여기도록 해주기도 한다. 이 작은, 잊기 쉬운 1%가 사람들로 하여금 당신의 제품을 사랑하게 해주는 열쇠가 될 수 있다.
디테일 — 바로 이 안에 신이 있다.
더 읽어보기
Neglected Design — Chris Wright
Making a Difference with Animation — Steven Fabre
Transitional Interfaces — Pasquale D’Silva
