급하게 만들 때 사용성은 어디까지 챙겨야 할까?
"좋은 사용자경험"은 IT 프로덕트를 만드는 사람이라면 항상 고민할 수 밖에 없는 영역이다. 멋진 기능을 만들었다 해도 사용하기 어려우면 빛을 발하기 어렵다. 게다가 IT 프로덕트의 UX 경험이 상향 평준화되면서 웬만큼 고민해서는 탁월하게 좋은 사용자 경험을 제공하기 어려워졌다. 이런 와중 어떤 프로덕트는 다른 차별점 없이 뚜렷하게 탁월한 UX를 가장 큰 강점으로 내세워 시장을 점유하기도 한다.
그래서 UX는 디자이너도, PM도, 프론트엔드 개발자도, 함께 머리 싸매고 고민하게 되는 분야다.
그러나 때때로, 이렇게 중요한 사용자 경험은 "일단 되게 한다"는 마음으로 프로덕트를 개발할 때 뒷전으로 밀리기 일쑤다. 특히 프로덕트를 런칭해야 할 때 그렇다. 일단 작동하는 기능을 만들어놓고 사용하기 편리한지는 그 이후에 생각하자고 생각하게 된다.
그리고 의외로 많은 경우 이건 꽤 현명한 결정이다. 사용하기 편리하게 다듬는 과정은 개발 기간을 최소 1.5배 정도는 늘리는 (그냥 내 감이다) 작업이다. 아직 수요가 검증되지도 않은 기능에 이런 시간을 미리 들이는 것보다 일단 작동하게만 만들어서 사용자가 정말로 그 기능을 확인하는지 살펴보고 그 다음에 UX 최적화하는 게 효율적이다.
B2C 제품에 비해 B2B 제품에서는 이런 논리로 UX가 희생되는 경우가 꽤나 있다.
그렇지만 많은 생산성 툴들이 훌륭한 기능을 제공함에도 불구하고 채택되지 않는 가장 큰 이유 중 하나가 불편한 UX라는 점을 기억해야 한다.
생산성 툴은 어떤 결과물을 내기 위해 반복적으로 수행해야 하는 일의 효율을 높여주는 툴이다.
문서, 공식을 적용해 바로 값을 뱉어줄 수 있는 시트, 할 일의 진행상황을 업데이트하고 관리할 수 있는 프로젝트 보드 등. 생산성 툴의 유저는 이런 결과물을 반복적으로 내놓아야 하는 사람이고, 반복적인 작업을 가장 효율적으로 할 수 있는 방법을 찾다가 생산성 툴을 사용하게 된다.
따라서 생산성 툴에 불편한 UX가 있다는 것은, 유저가 매일 반복적으로 하는, 게다가 좋은 결과물을 내야 하는 일을 할 때 아쉽지만 불편함을 감수하면서 하라고 말하는 꼴이 된다.
그렇게 되면 유저에겐 이 툴을 사용하는 게 더 이상 "효율적"이라는 생각이 들지 않는다. 우리는 불편함을 곧 비효율로 인식하는 경우가 많다. 실제로 시간 대비 산출한 Output은 비슷할 지 몰라도, 불편함을 견딘 시간은 그렇지 않은 시간보다 더 길게 인식된다. 그래서 들인 시간에 별로 차이가 없더라도 유저는 이 프로덕트를 사용한 시간이 "비효율"이었다고 느낀다.
효율적으로 일하고 싶어서 툴을 썼는데, 툴이 효율적이지 않다면? 사용할 이유가 없는 프로덕트가 된다는 말이다.
게다가, 팀이 함께 도입해서 사용해야 하는 툴이라면 불편한 UX는 더더욱 치명적이다. 팀에 새로운 툴을 도입하는 것은 결국 새로운 규칙을 도입하는 것이기에, 어떤 형태로든 저항이 있을 수 밖에 없다. 이런 와중 UX가 불편하기까지 하다면, 어찌저찌 도입까지는 가더라도 결국 아무도 쓰지 않고 몇 개월 후에 구독 해지하는 프로덕트가 될 확률이 99%다.
만약 프로덕트가 위치한 시장에 1) 경쟁자가 없고 2) 앞으로도 나오기 어려우며 3) 현재로서는 대안이 없기 때문에, 불편하더라도 그 일을 할 수만 있으면 된다고 느끼는 유저가 있다면 상관 없다. 수요가 많되 기술적 장벽 역시 높은 분야에서는 UX를 희생하더라도 사랑받는 프로덕트를 만들 수 있다.
하지만, 언제든지 경쟁자가 나올 수 있는, 또는 이미 경쟁자가 있는 시장에 위치해있거나 이미 유저가 다른 방법으로 풀고 있는 문제를 더 잘 풀려고 하는 생산성 툴이라면, 편리한 UX는 런칭 때 부터 반드시 지켜야 할 원칙이다.
그러면, 런칭 때부터 완벽에 가까운 UX만 내놓으라는 말인가요?
당연히 아니다.
어쨌거나 우리에겐 기한이 있다. 시간은 곧 돈이기 때문에 (특히 스타트업에서는 더더욱) 우리는 가능한 빠른 기간 안에 많은 것을 배워야한다. 즉 빨리 내보내야 한다.
그러면 생산성 툴 만드는 사람들은 UX를 대체 어디까지 챙겨야 하는 것일까?
조직마다 답은 다르겠지만, 우리 팀이 적용하고 있는 UX 최적화 원칙이다.
프로덕트의 가치를 가장 잘 전달하는 액션 (주로 Activation 의 기준이 되는 기능이다)까지 도달하는 user flow를 그려보기
프로덕트의 가치를 가장 잘 전달하는 액션 하나는 기분 좋은 UX로 설계하기
이 액션에 도달하는 flow 상에서 “장애물"은 없게 하기
1. "프로덕트의 가치를 가장 잘 전달하는 액션" 이란 무엇일까?
유저 한 명 한 명이 이 액션을 많이 하면 할 수록 우리 프로덕트가 전달하고자 하는 가치가 잘 전달되고 있다는 증거가 되는 액션이 있는가? 바로 그 액션이 프로덕트의 가치를 가장 잘 전달하는 액션이다.
고전적인 사례지만 - 페이스북은 친구 만들기였고, 슬랙은 메시지 보내기였다.
블로그 플랫폼이라면 블로그 작성일 것이고, 콘텐츠 열람 플랫폼이라면 콘텐츠 열람 횟수일 것이다.
지금 만들고 있는 프로덕트에서 어떤 액션이 가장 활발히 일어났으면 좋겠는가?
단순히 "노트필기", "프로젝트 관리"라고 뭉뚱그리지 말고 정확히 어떤 UI를 눌러서 어떤 변화가 생기는 인터렉션을 했으면 하는지 생각해보라.
예를 들어, 캘린더 기반으로 task를 관리할 수 있는 앱을 만드는 누군가가 "할 일을 캘린더에 불러오기"를 가장 활발히 일어났으면 하는 액션으로 꼽았다.
그러면 이 "할 일을 캘린더에 불러오는" 액션은 무조건 쉬워야 한다. 뭔가 타이핑해서 보내야 한다? 에러다. 가능한 가장 직관적으로, 할 일 목록이 있고 그 목록으로부터 드래그해서 캘린더로 가져오게 해주는 액션이 가장 나아보인다.
이렇게 타협할 수 없는 단 하나의 액션에 대해서는 타협하지 않아야 한다.
2. 장애물이란 무엇일까?
다음 두 가지 상황을 발생시키는 모든 요소를 말한다.
1. 내가 하고 싶은 액션까지 도달하는 경로가 보이지 않는다.
2. 내가 하고 싶은 액션을 하기 위해 반드시 사용해야 하는 기능이 정상적으로 작동하지 않는다.
할 일을 캘린더로 옮기려면 일단 할 일을 생성해야하는데, 앱 내에서 할 일을 생성하는 경로를 찾기 어렵다거나, 생성하는 도중 계속 오류가 발생한다면? 드래그 앤 드롭으로 할 일을 가져올 수 있든 말든 짜증나서 쓰기 싫다. 이런 어려움이나 오류는 무조건 해결해야 한다.
3. 그리고, 이것 이외에는 일단 무시한다.
할 일 관리 앱인데 프로필 닉네임을 수정하는 과정에서 오류가 난다면, 일단 넘어간다.
노트 필기 앱인데 구글 닥스를 임베드하는 과정에서 오류가 난다면, 일단 넘어간다.
핵심 빼고 나머지는 일단 넘어간다.
