스프링노트의 UX작업들에 대해, 디자인 과정에서 발생한 여러가지 이슈들에 대해 공유해 보겠습니다. ^^
어떤 부분을 포스팅할 수 있을까 잠깐 고민해 보다가 기억을 더듬어 스프링노트의 최초부터 현재의 모습까지 변천사를 살펴보고, 각 이슈들에 대해 간략히 기술해보고자 합니다.
특히, 우리가 겪었던 디자인 개선 히스토리 및 끊임없는 시행착오들의 모습들을 공유해 보겠습니다.
편의상 이하는 존칭생략하고 편하게 쓰겠습니다.
-
시작.
최초의 작동하는 프로토타입(Working Prototype)으로 기본적인, 정말로 가장 기본적인 개념만으로 출발한 스프링노트 첫 프로토타입이다.
당시 프로토타입은 기본이긴 해도, 우리가 생각했던 핵심 기능은 모두 갖추고 있었다.
- 항상 편집 모드로 자동저장되는 에디터
: 온라인 연습장이라는 컨셉을 가장 잘 설명해주는 기능
- Ctrl+Space라는 단축키를 통해 링크를 추천
: 간단한 네비게이션
- 페이지목록과 허브페이지 목록 (지금은 없는), 그리고 페이지 이름 입력으로 바로 가기
이 3가지가 우리가 생각한 킬러 기능이었다.
최초의 프로토타입은 디자인(컬러와 레이아웃을 포함한)을 제외하고, 말그대로 기능에 대한 동작여부를 확인할 수 있는 개발이 선행된, 프로토타입으로 시작되었다. 하지만 자세히 보면 (놀랍게도) 현재의 구조나 핵심기능에 대해서 크게 벗어나지 않음을 알 수 있다. 만약 최초의 프레임으로 시작된 이 프로토타입이 위의 모습과는 전혀 다른 모습의 출발하였다면 현재의 스프링노트는 어떻게 바뀌었을까? 궁금하다. :)
-
오픈.
2007년 3월 31일 처음 오픈했을 때의 모습이다.현재와의 가장 큰 차이는 본문의 스크롤 범위에 대한 부분이다. 현재는 우측의 본문에만 내부 스크롤이 잡히지만, 당시에는 브라우저 스크롤에 의존하는 방식으로 글을 쓰면 쓸수록 본문의 길이만큼 브라우저의 스크롤바가 늘어났다.
이 경우의 문제점은 본문이 길어지면 길어질수록 좌측의 페이지 네비게이션을 하기 위해 다시 스크롤을 올려야하는 수고가 있다는 점이었다. 이는 스프링노트 핵심 컨셉 중 '빨리 쓰기'와 '빨리 찾기'를 해치는 사용자 경험이었다.
마찬가지로 본문 하단의 편집 히스토리 및 부가 기능(첨부파일, 엮인페이지, 수정일자..) 역시 본문의 길이만큼 아래로 내리지 않으면 볼 수가 없다는 문제가 있었다.
항상 편집 모드로 자동 저장되기 때문에 페이지를 열고 바로 원하는 곳을 클릭하여 고치고 다시 쉽게 떠날 수 있도록 했지만, 스크롤 때문에 본문의 길이에 의존적으로 페이지 네비게이션이 불편해지는 경험을 주고 있었던 것이다.
본문의 길이와 관계없이 언제나 원하는 페이지로 쉽게 이동할 수 있게 만들기 위해, 우린 원점에서 다시 시작할 필요가 있다고 판단했다.
결국 2주 단위로 약속했던 기능 추가를 잠시 멈추고, 전체 팀원이 새로운 UI구성에 참여하게 되었다.
-
전체 팀원이 모두 UI개선에 참여하여, 각 멤버가 나름 사용자 시각에서의 개선 아이디어를 페이퍼로 프로토타이핑하고, 다시 이를 취합하여 각 안을 검토하고, 이를 적용하는 과정을 여러 번 반복하였다.
기존에 이 작업을 디자인/기획 파트에서 주도하여 진행했을 때와는 매우 다른, 신선한 경험이었다.
이때 개발자들의 insight에서 많은 도움을 얻었고, 팀이 하나의 목표로 단결하여 한걸음 나아가는 작은 성공이라는 열매를 얻어냈다.
일단, 이렇게 모든 직능을 포함한 전체 팀이 UI개선에 참여하면서 얻는 소득은 여러 가지인 것 같다.
첫째, 속도가 굉장히 단축되었다. 모든 단계별 화면까지 진행하게 되면서 각 직군별 멤버들의 이해도가 매우 높아졌고, 병목이 없이 미리 최종 그림을 염두에 두고 작업을 진행할 수 있었다.
둘째, 팀웍이 좋아졌다. 모든 멤버가 참여하여, 내가 만들고 내가 낸 의견으로 발전된 스프링노트의 새 UI는 볼 때마다 뿌듯한 그런 녀석이었다.
그리고.9월 2차 개편이후이후 결과물에 대해 팀내 만족도도 좋았고 유저리서치등을 통한 사용자 반응도 비교적 좋았다.하지만 인터페이스의 기능적인 개선사항들은 여전히 존재했고, 또한 해결해야될 부분들이 많이 존재했다.
또 다른 문제.
그중 우리팀에서 가장 논란이 많았고, 가장 어려웠고, 깨끗하게 해결되지 않고 있는 문제는 당연히 공유/공개에 대한 문제였다. 2차 개편당시 UI개선의 또 중요한 목표중 하나가 공유 및 공개를 쉽게 하자라는 것이었다.
기존의 공유/공개의 액션의 분리는 각 레이블링의 난해함 뿐만 아니라 상태와 결과가 직관적으로 이해되지 않는 어려움이 있었다.
여러가지 아이디어들이 나왔고, 최종적으로 우리는 이를 해결하기 위한 액션으로 공유/공개를 합친 형태의 'X명이 쓰고, X명이 읽을 수 있습니다. (아래그림 참조)' 로 개선하기로 하였다.
최초 아이디어가 도출되고 프로토타입으로 선행작업이 될때만 해도 팀내 반응은 열광적(!)이었다. 우리는 굉장히 쉬운 UI로 공유/공개의 구분또한 사용자가 생각하지 않아도 될거라 생각할 정도였다.
하지만...결론부터 얘기하자면 결과가 사용자에게 그렇게 쉽게 와닿지 않았던것 같다. ;
프로토타입으로서의 내부 테스트나 팀내/외의 만족으로 문제가 해결되었다고 생각하는건, 스스로 함정에 빠질 수 있는 위험한 생각이었다.
물론 일부 유저들에게는 열광적인 환호(!)를 받았지만, 이후 여러번의 사용성 테스트를 통해 드러난 결과에서는 여전히 '어렵다' 라는 것이었다.
결국, 그림과 같이 현재는 다시 공유와 공개가 분리되었고(^^;) 개선작업을 통해 기존의 라이트웨이트(Lightweight) 형태의 다이얼로그가 아닌 모달다이얼로그로서의 인지적으로 좀더 명확함을 주기 위한 비쥬얼 개선작업이 진행되었다. 덧붙여, 사용자의 동선도 최대한 Depth를 줄여나가는 형태로 접근하였다.
우리가 이 개선작업을 통해 배운것은 주관적인 팀내 시각은 여러가지 레거시(Legacy)를 갖고 있어서 잘못하면 내부 만족으로 그칠 수 있지만, 보다 현명한 개선작업을 위해서는 철저히 사용자 테스트를 통한 근거를 마련하는 것이라고 생각한다.
이후 우리는 최근까지 개선되는 작업에서 보다 명확한 결과를 얻기 위해 유저 리서치 파트(User Research Part)의 도움을 얻어 기능을 개선해 왔다.
물론 현재도 공유 및 공개의 사용자 경험은 정답이 아님을 잘 알고 있고, 현재도 진행형으로 계속적으로 발전시켜야할 인터페이스/기능임에는 틀림없다.
계속해서.
우리는 내부적으로도 스프링노트를 Perpetual Beta 서비스라고 부른다.
지금도 스프링노트는 지속적으로 기능 개선을 하고 있다. 해결해야될 과제들이 여전히(!) 많이 존재하고 좀더 쉬어져야 하기 때문이다.
+ 스프링노트는 이제서야 새싹에서 한살이 되었을뿐이다.
시간이 지남에 따라 UI역시 성숙해지길 소원하고, 사용자의 입장에서도 스프링노트가 나이를 먹어감에 따라(^^) 더욱더 성장하는 서비스가 되길 바란다.
덧붙여, 개인적으로도 스프링노트를 통해 UX에 대한 다양한 접근법/시도등 많은 경험을 익힐 수 있는 프로젝트라고 생각한다.
by jfactory
