개편하기 전 꼭 해야 할 일
자사 서비스 냉정하게 바라보기
어떻게든 접고 새로 만들어야 하는 서비스가 있다.
그런데 과연 그 개편은 왜, 누구를 위한 것일까?
인터넷 서핑을 하다 보면 서비스 개편 후기, 신규 구축 등 '새로움'이라는 핫한 키워드가 도배되어 있는 걸 보곤 한다. 나 또한 그런 신규 구축, 서비스 개편을 주로 해왔고 이 작업이 주는 짜릿함에 흠뻑 취해 있었다.
이직 후 나에게 주어진 첫 과제는 회사에서 꽤 오랫동안 서비스해 온 상당히 유명하고 중요한 서비스를 개편하라는 임무였다. 애초에 Job Description에도 해당 서비스를 개편하는 게 업무라고 명시되어 있어 아무런 의심 없이 (기존 서비스를 하나하나 뜯어보지도 않고) 개편 계획 일정을 세워서 보고했다.
그리고 받은 피드백은 지금 생각해보면 당연하지만 당시엔 굉장히 충격적이었다.
"지금 서비스가 얼마나 심각하게 문제인지도 모르는데 이 일정으로 개편을 하겠다고? 내가 알고 있는 바로는 사용자들은 지금도 잘 쓰고 있는 서비스인데?"
개편 일정을 세웠을 때 데스크 리서치 기간을 2달로 잡았는데 그 안에 이런 조사를 진행하려고 했다.
마음만 급해서 기존에 해오던 프로세스대로 뚱땅뚱땅 일정을 잡았는데 이런 안일함이 나에게 독이 되어 돌아왔다. 빠릿빠릿 일 잘하는 게 아니라 뭐가 문젠 지도 모르고 계획을 세우는 우를 범했다.
급히 계획을 수정해 자사 서비스를 냉정하게 분석 시간을 가졌다.
이 서비스가 대체 누구에게 얼마나 문제인지를 파악하자.
이렇게 마음먹고 CS, 스토어 리뷰에 달린 사용자 피드백을 하나하나 살펴보니 해당 서비스에 대한 사용자 만족도는 굉장히 높았다.
스토어 리뷰 참고자료해당 서비스는 end-user의 삶에 정말 크게 와닿는 서비스이고 없어선 안될 서비스이기 때문이었다.
그러다 보니 어느 정도 불편하더라도 그 불편함을 감수하고도 오히려 만들어주어 감사하다고 하며 서비스를 사용했다.
물론 사용성은 정말 떨어지는 서비스이다 보니 불편함을 호소하는 사용자도 많았다. 불편하다고 하는 사용자 의견을 1차로 취합해 어떤 부분에서 크게 어려움을 겪는지 확인했다.
확인해보니 서비스의 핵심기능이 구현되지 않는 상황을 발견했다.
그럼에도 감사하게 사용하는 사용자들, 감사하면서도 미안한 마음에 사명감을 가지고 어떻게 하면 서비스 신규 구축 당위성을 찾을 수 있을까 고민하기 시작했다.
'사용자도 어느 정도 불편함을 겪지만 이 불편함으로 서비스를 이탈하진 않는다.'는게 당시 서비스의 현실이었다.
그럼 어떤 근거로 신규 구축을 진행해야 하지?
개편에 힘을 싣기 위해 사용자 의견과 더불어 공신력 있는 전문가 인터뷰를 진행했다.
자사는 특정 분야에서 선구자 역할을 한 회사이기에 관련 인력풀이 상당했다. 이 좋은 인력풀을 사용하되 서비스의 불편한 점을 사용자 경험 관점에서 분석해 줄 UX 전문가들도 인터뷰에 추가하기로 했다.
전문가 인터뷰이는 해당 서비스 전문가 13명, UX 전문가 6명으로 구성해 총 19명으로 진행하기로 했다.
인터뷰는 설문지를 통해 일괄 배포하는 형태로 진행했다. 그 이유에 대해 설명하자면 물리적 거리가 먼 분들이 상당했고 짧은 시간에 많은 의견을 수집하고자 하기 위함이었다.
[설문평가 구성요소]
해당 설문은 평가 항목이 많아 엑셀로 구성했고 각 프로세스 별로 sheet를 구분했다. 설문은 진단평가라는 이름을 붙여 평가 설명, 개인정보 수집 동의, 작성자의 인구 통계학적인 정보와 특수 정보, 서비스 다운로드 과정에 대한 내용을 가장 첫 sheet에 담았다. 다음 평가 항목으로 넘어갈 수 있게 페이지 하단에 다음 sheet로 가는 링크를 넣었다.
서비스 다운로드 과정에 대한 내용은 평가항목이 시작되는 부분이기에 평가 척도에 대한 내용도 명시했다. 이때 평가를 설계할 때 주의할 점은 긍정적인 사용자 경험에 대한 점수와 부정적인 사용자 경험에 대한 점수에 일관성이 있어야 한다는 점이다.
예를 들어 다운로드하기 어려웠나요? (1. 매우 그렇다/2. 그렇다/3. 보통이다/4. 그렇지 않다/5. 매우 그렇지 않다)라고 구성하면 어려울수록 점수가 낮고 쉬울수록 점수가 높아진다. 다른 문항을 작성할 때도 이 점을 유의해서 작성하면 점수 토털로 수치적인 서비스 평가가 가능해진다.
그다음 sheet에선 task를 주고 그 과정을 경험하며 느낀 경험을 평가하는 항목이다. 이때 task는 서비스의 핵심 기능으로 구성하고 각 프로세스를 명확하게 기입해 처음 보는 사용자도 task 설문을 할 수 있게 작성하는 것이 좋다. 또한 task를 하며 발생하는 사용자 경험은 단순히 수치로만 표현하기 어려울 수 있기에 의견을 작성할 수 있는 영역을 제공했다.
평가지를 수령했을 때 해당 영역에 의견이 꽤 많이 달렸었다. 만일 단순히 수치적으로만 접근하기 힘들다면 꼭 의견 기입하는 영역을 배치하길 권장한다.
마지막으로 서비스 사용성 평가 항목을 나열하고 점수를 매기고 그 점수에 대한 이유를 작성하도록 구성했다. 이는 사용자 평가 시 답변의 정확성을 확인하고자 함이었다. 사용성 평가에 대한 척도는 Jackob Nielson이 만든 10개의 휴리스틱 평가 시스템 중 일부를 참고했다.
• 시스템 : 시스템 상태를 시각화하는 항목이다. 유저에게 현재 진행 상황에 대해 설명하고 있는지
• 사용자 주도 : 사용자에게 서비스 사용 권한
• 일관성과 표준화 : 시스템 내 일관성을 유지 여부
• 오류 예방 : 사용자가 실수로 원치 않는 액션을 하기 전 이를 방지하는 설계가 되어있는지
• 유연성과 효율성 : 각 그룹 군에 맞춰 그에 맞는 UI를 제공하는 설계가 되어있는지
• 융통성 : 서비스 사용방법이 불편할 경우 같은 업무를 수행할 수 있는 대안이 있는지
• 디자인 완성도 : 기능적, 심미적 디자인 완성도가 어떠한지
• 오류 해결 : 오류 발생 시 이를 해결할 수 있는지
정말 많은 양의 질문이었음에도 전문가가 모두 잘 답변을 해주어 개편 확정과 개편방향을 설정할 수 있었다.
개편을 할 때는 타사와 비교했을 때 '우린 이게 부족해요', '이건 바꿔야 해요.'라고 이야기하는 것도 논리적으로 설명할 수 있다면 충분히 설득력이 있으나 그렇지 않다면 냉정하게 자사 서비스를 바라보는 시간을 갖기를 권장한다. 냉정하게 바라보는 시간과 그 결과물이 향후 서비스의 방향성을 잡는데도 아주 중요한 근거자료가 될 수 있기 때문이다.
이 경험을 바탕으로 아래와 같은 결론을 얻었다.
기획을 하며 당연한걸 당연하게 여기지 말고
왜?라는 질문을 꼭 던지며 명확하게 답변을 해야 한다.
오늘도 더 성장하는 기획을 해야겠다고 다짐한다.
