오랜만에(처음인가?) 조금 더 실무적인 글을 써보고자 한다. UX에 대한 내용이다.
사용자 경험(UX)과 인간-컴퓨터 상호작용(HCI), 이 단어를 처음 들은 것은 아직 군인이었던 2010년이었다. 군대에서 생물학과 심리학에 큰 관심이 생겨 여러 권의 책을 읽었는데, 그 모든 학문적인 영역이 하나로 합쳐질 수 있다는 생각이 들어 매우 흥분됐던 기억이 난다. 그 이후로 지금까지 6년 동안, 사용자 경험에 대해 공부해왔고 창업을 한 이후에는 비캔버스의 사용자 경험 향상을 위해 2년째 달리고 있다.
실무적으로나 학문적으로나 아직도 부족한 것이 많지만, 비캔버스라는 툴을 2년째 서비스하며 해온 고민들을 생각해보면 툴에 대한 사용자 경험만큼은 우리 팀만큼 전문성을 가진 사람이 많이 없을 것이라 생각한다. 비캔버스는 웹에서 동작하는 애플리케이션으로 포토샵과 같은 툴이다.
TOOL이라는 서비스 특성상 사람들의 인식에서 정해진 영역이 강하지 않기 때문에, UI를 완전히 새롭게 설계하고 그것을 표준으로 만들 수 있다는장점이자 단점이 있다. 즉, 우리가 독특하게 UI와 UX를 설계하여 사용자에게 제시후, 익숙하게 만드는 '닻 내리기(Anchoring effect)식 전략'이 가능했다는 것인데 이 때문에 처음 비캔버스를 접하는 사용자들이 서비스를 어려워하는 경우도 많았다.
올 초, 우리는 이러한 한계를 효과적으로 극복할 수 있는 모형을 찾았는데, 이 것이 우리의 전체적인 개발 프로세스에 큰 영향을 미쳐오고 있다. 오늘 이것을 공개하고자 한다.
포스트잇 메모 기능을 개발한다고 가정해보겠다.
참고로, 나는 인터페이스 관점의 UX를 '기능'과, 그 기능까지 찾아가는 '내비게이션'으로 분리하여 생각한다. 가령, 내가 여행지에 고깃집을 창업하기로 결심했다면, 고깃집 자체를 어떻게 운영할 것인지에 대한 것은 '기능'차원이다. 반면, 어떻게 사람들이 거리적인 동선이나 심리적인 흐름에 의해 내 고깃집에 도달할 지에 대해서 고민하는 것은 '내비게이션'에 대한 고민이다. 이번 예시는 포스트잇 메모 기능이라는 '기능'에 대한 내용으로 국한되어 있지만 이 모델 자체는 '내비게이션' 성격의 UX에도 사용할 수 있다.
이런 UX/UI 개발에 대한 프로세스를 정립하는 일은 우리 팀의 특성상 반드시 필요한 것이었다. 비캔버스는 지금까지 2년간 디자이너 없이 순수 개발팀으로만 이뤄져 왔다. 즉, 주요 커뮤니케이션 상대인 내가 기획과 디자인뿐 아니라 마케팅 업무와 회사 대표일까지 하고 있는 상황에서 나와의 커뮤니케이션이나 토론이 아주 잦게 진행되는 것은 시간적으로 불가능했다. '이게 왜 이렇게 만들어지냐?', '이건 어떻게 만드냐'에 대한 질문이 잦을수록 내가 다른 업무를 볼 시간이 매우 적어졌고 개발팀도 수동적으로 일하는 것 같아서 매우 싫었다.
그래서 올 초부터 이 프레임(모형)을 만들어서 개발 프로세스에 적용해왔는데, 결과는 매우 효과적이다. 서론이 길었다. 본론으로 돌아와서 내가 "포스트잇 메모 기능을 개발하자!"라고 개발팀과 이야기할 때는 이런 모델을 제시한다. 물론 이건 예시다. 실제로 적용할 때는 더 복잡하게 설계될 수 있다.
기능 개발 커뮤니케이션에 활용되는 모델 1단계.
보통 '새로 생길 기능은 이렇게 생겼고, 이렇게 동작한다'는 식으로 이야기하면 개발팀으로부터 '이럴 때는 어떻게 해? 저럴 때는 어떻게 해? 이거 누르면 뭐 나와?' 등 질문이 쏟아진다. 내가 기능 설계를 0부터 100까지 정확하게 다 설명하면 이런 내용으로 회의하는데 온종일 시간을 낭비하게 되며, 개발팀의 창의성과 고객에 대한 감정이입 능력을 말살시키는 것이라 생각한다.
위 사진에서 볼 수 있듯, 포스트잇 메모 기능이 있기 전과 후가 어떻게 다른 지에 대해 먼저 설명한다. 이 기능이 사람들에게 어떻게 선물처럼 다가갈 수 있는지 말해주고, '사용자의 기능 사용 목적'을 추정하여 알려준다. 즉, '우리 팀', '내 의도'는 아직 등장도 하지 않는다. 내 이야기를 하는 것이 아니다. 내 머릿속의 기획을 이야기하는 것이 아니다. 우리 고객이 어떻게 이 기능을 사랑하게 될 것이고, 이 기능을 어떤 목적으로 활용하게 될 것인지 고객 사이드로 설명한다.
나는 개인적으로 페르소나 분석을 싫어한다. 본래 페르소나의 목적은 특정 인터페이스에 대해 각기 다른 사람들이 어떻게 다른 패턴을 보이는지 파악하여 그 패턴을 바탕으로 UX를 개선시키는 게 목적이라 보는데, 지금 사람들이 하고 있는 것은 마케팅 차원의 인류 통계학적 고객이 누군지 파악하려 하는 건지, 서비스 UX를 개선시키려는 것인지 분간이 잘 안 간다. UX/UI 개선을 위해서는 페르소나 분석이 아니라, 우리 고객이 우리 제품을 사용하는 고객들의 패턴을 세부적으로 분류하고 그 분류된 특정 패턴의 고객들이 기능에 어떻게 다르게 반응하는지 등을 파악하는 것이 중요하다 생각한다.
각설하고, 2단계로 돌입할 때가 됐다. 이제 고객에 대해 이해하고, 이 기능이 어떻게 작동하면 좋을 지에 대해 개발팀들도 머릿속에 생각과 아이디어가 생겼을 것이 분명하다. 내가 고객이라고 눈을 감고 상상하면 제품을 직접 돌려볼 수도 있는 그런 경지에 조금이라도 빠져든 것이다. 그럼 이제 2단계 논의가 가능해진다.
2단계.
이제 어떻게 움직일지 고민하는 단계다. 그전에 우리는 이미 고객이라는 상상 속에 빠져있으니, 고객 입장에서 포스트잇 기능을 사용해볼 때다. 포스트잇 기능을 사용할 때 외부적인 간섭이나 방해는 무엇이 있을까? 포스트잇이라는 게 액셀처럼 멋지게 구조화된 형태가 아니라서 상사가 내가 노는 줄 알고 눈치를 줄지도 모르겠고, 내 10년 된 17인치 모니터에서는 포스트잇 글자가 조금 작아 보일지도 모르겠다. 서비스 내부적인 간섭 요인도 이런 식으로 상상이 가능하다.
이렇게 간섭 요인까지 봤으면 드디어 '우리 이야기', '내 기획'이 나올 때다. 아까 이야기했던 고객의 목적에서 외/내부 간섭 요인을 제거하면 우리의 기능 개발 목적을 손쉽게 설정할 수 있다. 어떻게 '이 기능을 만들지'에 대해서까지 불필요한 브레인스토밍 시간 필요 없이 단기간에 빠르게 도달할 수 있다. 이렇게 한 번 우리끼리 합의를 보고 나면 불필요한 질문과 회의가 매우 줄어든다. 스스로 이 모델을 참고하면서 '고객은 이런 목적을 달성하는 것이니 버튼은 이렇게 동작해야겠지?'라는 개발팀의 상상력이 작용하기 때문이다. 그런 뒤에 논의를 시작하면 발전적이면서도 짧고 굵은 토론이 가능하다.
이렇게 목적까지 설정했으면, 이 기능을 음악으로 한 번 표현해보면 아주 재미있다. 가령, 이 기능을 쓸 때 사용자들의 머릿속에서 어떤 음악이 흘러나올 것 같은지 상상해본다. 이게 좀 어렵다면 이 기능을 사용하는 영상을 만든다면 무슨 음악이 어울릴지를 찾고 그 이유를 적어보면 된다. 그렇게 하면 단순히 논리적인 차원의 어떤 딱딱한 객체로써 기능을 보는 것이 아니라, 사용자와 우리를 호흡하게 만들어주는 살아있는 중간 매개자로서 바라볼 수 있다. 즉 서비스가 생명력을 갖는다고 생각하게 되는 순간이 찾아온다.
3단계, 마지막 단계다.
2단계에서 목적까지 다 세웠으니 이제 기획자는 기획을 하고, 디자이너는 디자인을 하면 되고 개발자는 개발을 하면 된다. 보통, 이때 커뮤니케이션에 항상 큰 문제가 생기곤 한다. 기획이 다 끝나서 개발팀에게 전달하면 싸움이 나거나, 개발자가 개발을 하다가 디자이너의 욕심을 발견하면 또 싸운다거나..
이 모델을 활용하면 그러한 일이 줄어든다. '고객의 목적 달성'외에는 모든 팀원들이 오버를 하지 않게 된다. 나도 개발을 하면서 느꼈지만, 아무리 안중요한 기능이라도 쉬울 줄 알았는데 막상 안 풀리면 거기에 엄청나게 많은 시간을 할애하게 된다. 개발자의 욕심이 작용하는 것이다. 디자이너도 마찬가지다. '적합한 사이즈의 포스트잇을 만들어주자'에 많은 고민을 해야 할 디자이너가 포스트잇 색깔에 지나치게 많은 고민을 한다던지, 폰트 생김새나 여백 같은 것에 고민하는데 큰 시간을 할애하게 된다. 그것 또한 욕심인 셈이다. 서로 욕심부려서 결과물이 좋은 꼴을 본 적이 없다.
우리가 고객의 입장에서 감정 이입하여 만들어낸 '고객의 목적'을 달성시켜주는데만 집중한다면 커뮤니케이션 시간이 월등하게 줄어들고 자기방어적인 입장으로 점철된 회의 또한 크게 줄어든다.
즉, UX라는 것은 그저 디자인팀이나 기획자의 전유물이 아니다. 전체 팀이 일하는 프로세스가 오롯이 사용자 경험에 크게 영향을 미치며 기능 딜리버리 속도에도 크게 영향을 미친다. 물론, 우리 팀에서 이것이 가능했던 이유는 고객을 진심으로 사랑하고 낮에는 고객지원을, 밤에는 개발을 하는 고된 상황 속에서도 고군분투하는 개발팀이 있기에 가능한 것이었다. 이 기회를 빌어 우리 개발팀(경병현 이사님, 심중섭 팀장님)에 감사한다.
수동적인 조직에서는 이러한 프로세스가 불가능할 수 있지만 이런 프로세스를 적용하기 위해 노력한다면 개발자가 하루 종일 코드만 보고 불평하고 있는 일은 줄일 수 있다. '이 거지 같은 걸 왜 만들어야 돼'라는 생각으로 개발을 하게 되면 개발 결과물도 후지고 일정도 늦어지며 자기 자신에게도 악영향을 미치게 된다. 그리고 그 부정적인 에너지는 고객도 무의식적으로 느낄 수 있게 된다.
마치, 음식점에 갔는데 주인장이 성질을 내며 음식을 만들면 아무리 맛있는 음식도 아무런 맛이 느껴지지 않는 것과 같은 것이다. 화가 난 어머니가 차려주신 밥상의 밥은 왠지 잘 넘어가지 않는다. 우리가 개발을 하거나 서비스를 만들 때도 똑같다. 부정의 에너지가 서비스를 덮고 있으면 그 에너지는 우리가 모르는 새에 고객의 인식 속에 들어가 서비스의 사려 깊은 에너지를 말살시키게 된다. 실컷 부정적인 에너지 다 투여해서 고객의 입맛을 다 망쳐놓고 사용자 경험이 어떻고 버튼을 어디에 배치해야 되고 고민하는 것은 매우 이상해보인다.
따라서, 우리에게는 이런 모델이 매우 중요했고 앞으로도 쭉 활용하게 될 것이다.
어떻게 보면 무식하고 후져 보이는 전략이자 모델일 수 있겠지만, 유용하다 생각하는 사람들은 이를 잘 활용해 보기를 바란다. 막상 해보면 매우 좋은데, 순서가 가장 중요하니 순서를 바꾸면 안된다.
1. 고객에게 감정 이입하기 (이 기능이 있기 전, 있고나서 고객의 행동 변화)
2. 고객을 위한 우리의 움직임을 결정하기
3. '이거 진짜 고객의 목적을 위한 길인가? 이 토론은? 이 회의는? 쓸데없는 시간낭비 아닐까?' 생각하기
가입하기
