"웹 서비스 벤쳐 회사는, 서로 독립되어 있지만 동등하고 중요한 두 부류로 대변할 수 있다: 서비스를 제작하는 개발팀, 그리고 그것을 사용할 수 있도록 만드는 디자인팀.

이것은 그들의 이야기다."

 저는 2007년 9월 이후부터 스토리베리(STORYBERRY)라는 서비스를 기획해 온 이즈데드라고 합니다.

 UX Design Talk로 썰을 풀 수 있는 자리를 마련 해 주신 UX팩토리의 황리건님께 감사를 드리며, 스토리베리를 만들어오며 겪었던 사용성 저하 사례들과, 문제 해결을 위한 삽질과 고난의 경험을 "UX, 너마저!" 라는 제목으로 풀어나가 보겠습니다.

사례 1: 바벨탑

 앨런 쿠퍼(Alan Cooper)옹의 명저, 「정신병원에서 뛰쳐나온 디자인」(The Inmates Are Running The Asylum)을 읽다보면, 개발자와 디자이너, 아니, 개발자와 일반인이 사용하는 언어의 차이가 얼마나 심각한 문제를 초래하는지, 400페이지 내내 설명합니다.

 개발자들은 현실에서 사용하는 언어(Language)보다 규약어(Protocol)에 익숙합니다. 따라서 대부분의 개발자들은 (그럭저럭) 쉽게 서로 이야기를 나눌 수 있습니다.

 문제는 디자이너와 개발자가... 아니, 사용자와 개발자가 직접 만났을 경우입니다. 재앙이라고도 할 수 있는 이 순간이 찾아오면, 둘 중 누군가는 포기하거나 쓰러지게 됩니다. (일반적으론 사용자들이 먼저 넉다운하죠.)

 같은 주제를 다루지만 다른 언어를 사용하고, 결국에는 같은 사회에 속해있지만 다른 문화를 소비하게 됩니다. 그리고 서로를 이해하지 않게, 못하게 되지요. 소위 현대의 바벨의 탑은 개발자와 일반인이 서로의 언어를 이해하지 못하게 만들었습니다.

 하지만 문제는 그게 아니었습니다. 일반인은 결국 개발자가 만든 도구가 필요하고, 개발자는 자신들이 만든 도구를 사용할 일반인이 필요했다는 사실…

 2007년 말, 저희가 직면한 문제가 바로 그것이었습니다.

 위 스크린샷은 XML 기반의 태그를 활용해, 웹 상에서 스토리베리 컨텐츠를 만드는 툴인 고급 에디터(현재는 스토리에디터)의 2007년 10월 경 초기 버전의 모습입니다.

 초기 버전에서 가장 큰 문제이자, 오랜 시간동안 고쳐지지 않았던 부분 중 하나는, 바로 미디라는 버튼이었습니다.

 저 버튼의 정체는? 미디어의 준말(?)이지요. 사진과 동영상, 음악 파일들을 올리고 관리하는 메뉴였습니다. 하지만 어째서 미디가 된 걸까요?

 저 버튼이 만들어지기까지의 과정을 간략히 적어보겠습니다.

1. 미디어 관련 파일들이 저장되는 공간이 필요하다.
2. 메뉴와 버튼을 만들었다.
3. 어? 버튼에 “미디어”라고 적으려 했는데 글자가 너무 길다.
4. 뭐 대충 툴을 써보면 미디가 미디어인 것쯤은 눈치 채겠지?
5. 최대 2글자로 정리해두니 디자인적으로 버튼들이 깔끔하니 좋구나.

 결국 개발 과정에서 느끼는 규약어와, 사용자들이 보고 듣고 느끼는 언어간의 차이를 인지하지 못한 저 UX적인 실패는, 약 3개월 후가 되어서 간신히 고쳐졌습니다. 하지만 그 3개월 동안 신규 가입자가 꾸준히 늘어왔다는 사실이 저희의 마음을 아프게 만들었습니다. 신규 유저들이 사진 넣는 법을 몰라서, 스토리를 안 만들 줄은 몰랐거든요.

사례 2: 자동 회전문

 유동인구가 많은 커다란 빌딩 중에는, 트래픽 컨트롤이나 냉/난방의 이점을 취하기 위해 회전문이 달려있는 경우가 많습니다. 하지만 가끔 ‘전자식 자동 회전문’이 달린 경우가 있지요. 손을 대면 자동으로 멈추고, 느릿느릿한 회전 속도에 맞춰서 걸어야 하고, 물건을 흘리면 대참사가 일어날 수도 있는 멋진 자동문이지요.

 스토리베리의 양대 에디터, 스토리에디터와 스토리포토에서 언급되었던 문제가, 바로 그런 문제였습니다.

 두 스크린샷에 공동적으로 보이는 여백이 눈에 띄시나요? 저런 배려는 주로 어도비 포토샵에서 볼 수 있는데요, Copy & Paste를 했을 경우, 사람들의 눈에 띄는 위치에 보여주기 위해, 눈에 보이는 화면의 (0, 0) 위치에서 상하로 약 20px 정도 떨어진 위치에 클립보드 이미지를 붙여 넣습니다.

 스토리베리 툴의 개발 과정에서도, 사용자들을 배려하여 사진이 삽입되는 위치에 여백을 주고 시작합니다. 다만 개발자들의 디자인에서 고려하지 못했던 사실은, 우리가 제공하는 화면은 사진이 항상 눈에 들어올 정도로 작았고, 게다가 우리는 사진을 (0, 0)으로 보내는 것이 결코 쉽지 않았다는 점이었습니다.

 게다가 사진을 클릭하고, 휠을 돌리면 사진의 사이즈가 조절되는 기능이 있었으나, 위에 살짝 떨어진 위치는 적잖은 드래그 & 드랍을 유도했습니다. 여백 덕분에 화면에 딱 맞게 사진 비율을 키우는게 어려웠으니까요.

 결국 사진을 보통 20장 넘게 삽입하게 되는 스토리포토의 작업 시간은 더뎌졌고, 스토리에디터에선 X, Y 좌표값을 0으로 바꾸기 위해 Tab키를 연발하거나 일일히 숫자를 바꾸는 눈물나는 상황이 연출되었지요.

 위 문제는 현재 버전에서도 여전히 존재합니다만, 곧 출시될 새로운 버전의 스토리포토와 스토리에디터에선 문제를 없애기 위해 몇가지 장치를 추가하였습니다. 하지만 역시나, 11개월 남짓한 시간 동안, 우리는 유저를 배려했던거죠.

사례 3: 브루투스

 공화정의 마지막을 불살랐던 카이사르(Caesar, 시저)의 죽음에 대한 이야기는 굳이 관심이 없더라도 많은 사람들에게 알려져 있는 일화입니다. 거의 아들이나 다름 없었던 브루투스(Brutus)의 단검에 마지막 단말마를 직면한 카이사르가, “브루투스, 너마저!”라고 외치고 숨을 멎었다는 유명한 이야기이죠.

 디자이너들에겐, 사람들이 항상 나의 우수하고 혁신적인 디자인을 애용할 것이며, 찬양하고 감탄할 것이다”라는 작고 소중한 꿈이 있습니다. 다음의 사례는, 그런 꿈을 무참히 짓밟히고, 고객들에게 배신을 당한(?) 디자인 요소에 대한 이야기입니다.

 초기 베리플레이어에 대해서는 사람들의 의견이 많이 갈리는 편입니다. 심플해서 좋다는 분들도 계시고, 너무 휑하고 필요한 기능들이 없다는 지적도 있었습니다.

 그리고 7개월에 걸친 고민과 노력 끝에, 새로운 플레이어가 등장했습니다! 다채롭고 흥미 진진한 새로운 기능들(저장, 불러오기 / 스토리 정보 보기)과 기존에 불편했던 기능들(자동 실행 / 추천하기)을 한껏 개선하고, 윈도우의 시작 버튼의 디자인을 참고한 새로운 레이아웃 또한 추가 되었습니다.

 하지만 과연 얼마나 많은 사람들이 버튼을 눌러봤을까요? 사람들이 스토리베리 컨텐츠를 보는 이유는, 저장하고 불러오기 위해서가 아니라, 일단 보기 위해서라는 점을 깨닫지 못하고, 화려한 기능들을 구석에 나열한 신세가 된 것 입니다.

결론

 UX는 순수하게 필요에 의해 태어난 장르입니다. 존재하지 않았던 것도 아니고, 모든 상황에 적용되는 통합 이론(Universal Principle)도 없습니다.

 하지만, 이것이 없으면 사용자들은 불편하고, 개발자와 디자이너들은 고객을 잃으며, 소프트웨어 비즈니스는 실패합니다. 특히 작은 시작으로 큰 꿈을 꾸는 벤쳐들은, 이런 점을 묵과하다가 쉽게 쓰러집니다.

 근 1년간의 삽질과 실패는 저와 저희 팀원들에게 큰 깨달음을 주었습니다. 얄팍한 배려와 무관심이 어떤 결과를 가져오는지, 춤추는 곰을 만들고 만족하는 행위가 얼마나 큰 피해를 주는지 말이죠.

 현재 스토리베리 팀에선, 인터렉션 디자인의 비중이 높아져, 꾸준한 토론과 비교 분석으로, 지금까지 많은 실망을 겪은 유저들에게 다시 한번 새로운 경험을 전달할 수 있도록, 새로운 리뉴얼 프로젝트에 박차를 가하고 있습니다. 물론 슬픈 경험들이 모티베이션이 되었다고 할 수도 있겠지만, 그 동안 저희가 잃은 것들은 매우 큰 것이었습니다.

 저희와 같은 실수를, 함께하는 웹 서비스 벤처들과 앞으로 탄생할 스타트업들이 번복하지 않았으면 하는 바람입니다. 어설픈 글 읽어주셔서 감사합니다.