안녕하세요 
지난 아티클에서는 Cochl이 어떻게 사용성 평가를 하게 되었는지 그 계기와 일련의 과정들을 소개했습니다. 이번 아티클에서는 실질적으로 우리가 각 문제를 어떻게 깊게 파헤치고, 해결했는지 그 과정을 공유해 드리려고 합니다.
지난 아티클에서는 Cochl이 어떻게 사용성 평가를 하게 되었는지 그 계기와 일련의 과정들을 소개했습니다. 이번 아티클에서는 실질적으로 우리가 각 문제를 어떻게 깊게 파헤치고, 해결했는지 그 과정을 공유해 드리려고 합니다.이전 사용성 평가에서 진행한 설문조사에서 “API 연동 시 가장 중요하게 생각하는 점”을 물었을 때 ‘상세하게 작성된 개발 문서’가 58.8%로 1위를 차지했고 뒤를 이어 손쉬운 API 연동, 활성화된 사용자 커뮤니티가 뒤따랐습니다.
위 설문 조사의 결과처럼 개발 문서가 잘 작성되어 있다면 별다른 문제 없이, 마주할 수 있는 대부분의 이슈를 커버할 수 있을 것이라고 생각하며 Cochl의 기술 문서에서 부족한 부분을 찾고 이를 보완하는 데 초점을 맞추기로 했습니다.
가장 먼저 지난 시간 살짝 공개드렸던 피드백을 바탕으로 우리가 마주한 문제를 크게 2가지 파트로 나눴습니다.
- API 설치 에러
사람들이 설치 과정에서 마주했던 문제들은 맥북 버전 호환의 문제를 제외하고는 해결이 가능한 문제들이었습니다. 하지만 설치 과정의 문제 난이도와 별개로 API가 매끄럽게 설치가 되지 않는다면 전체적인 사용자 경험은 부정적으로 바뀔 수 있습니다. 문제가 발생하지 않는 것이 가장 최상의 시나리오이지만 만약 설치 과정에서 장애가 생긴다면 사람들이 손쉽게 대처할 수 있도록 안내돼야 합니다. 물론 한정된 리소스 상 개인 별로 다른 모든 환경 설정을 맞출 수는 없으나, 자주 사람들이 궁금해하는 부분이나 공통된 환경설정 하의 에러 메시지는 충분히 선 대응할 수 있는 영역입니다.
그래서 Cochl은 단순한 API 설치뿐만 아니라, Cochl.Sense 사용과 관련하여 사람들이 궁금해하거나, 도움이 필요한 영역까지 넓게 산정하여 FAQ 페이지를 신설하는 것을 해결 방안으로 선택했습니다.
- 콘텐츠 구성
사람들이 Cochl.Sense를 더 개인화해서 사용할 수 있는 Advanced configurations 같은 경우는 페이지 트리 내 어디에 존재하는지 파악하기 어려웠고, 기능별 설명이 와닿지 않는다는 피드백이 있었습니다.
해당 피드백을 바탕으로 콘텐츠를 중심으로 기술 문서를 정리해 보았을 때, 불필요하게 중복되는 콘텐츠들도 있었고, 현재 버전과 맞지 않는 내용이라던가 설명이 부재한 경우가 있는 것을 확인했습니다. 콘텐츠들이 일정한 기준 없이 기술 문서 내 퍼져 있다 보니 내가 원하는 정보가 기술 문서 내 어디에 있는지를 찾기가 어려운 문제도 있었구요. 이는 결과적으로 우리의 사용자가 Cochl.Sense가 무엇인지는 이해하지만, 이를 바탕으로 ‘무엇’을 할 수 있는지를 파악하는 것을 어렵게 한다는 것을 알 수 있었습니다.
비록 client library의 사용성이나 각 파라미터가 어떤 기능을 하는지 명쾌하게 알려주는 높은 code level은 긍정적 평가를 받았지만, 우리의 장점이 사용자들에게 더 명확하게 느껴지기 위해서는 절대적으로 사용성 개편이 필요한 상황이었습니다.
Cochl의 장점을 더 잘 보여주기 위하여 1)정보 계층 구조를 정리, 2)사용자 관점의 UX writing을 진행, 3)다양한 유즈케이스와 샘플 코드를 보여주는 것으로 콘텐츠 구성을 바꿔보기로 했습니다.
정리된 두 가지 문제는 앞서 진행한 설문조사의 답변과 그 결을 같이 하는 게 보이시나요? 우리가 정의한 문제를 중심으로 기술 문서 사이트를 개편하면 사용자가 원하는 답에 가까워질 수 있겠다는 확신이 들었습니다. 그렇다면 Cochl이 어떻게 문제점들을 하나씩 고쳤는지 보여드리겠습니다.
1. FAQ 페이지 신설
API 설치 과정에서 자주 발견되는 문제를 정리하고, 간단한 해결 방법을 제안하는 FAQ 페이지를 만드는 것을 생각했습니다. 하지만 이에 그치지 않고 API 설치 과정뿐만 아니라 전반적인 Cochl.Sense의 사용 관점에서 나올 수 있는 질의응답을 함께 정리하는 것이 더 사용자 관점에서 유용하다고 판단되어 방향을 살짝 틀게 되었습니다.
우선은 Cochl처럼 API를 제공하는 서비스들의 기술 문서 페이지를 참고하여 크게 5가지 영역으로 카테고리를 나누어 보았습니다.
•
Account: 계정 생성과 관련된 문제
•
Payment & Billing: 요금 및 청구 관련된 문제
•
Dashboard: 대시보드 사용과 관련된 문제
•
Deployment: API, SDK 설치와 관련된 문제
•
Troubleshooting: 자주 발생하는 에러
그리고 각 카테고리 당 사람들이 궁금해할 수 있는 질문들을 일차적으로 작성 후 중복되거나 수정이 필요한 질문지들을 한 번 필터링하고 다듬었습니다. 이렇게 다듬어진 질문을 바탕으로 답변을 작성했고, 개발팀에서 답변이 필요한 부분들은 별도로 코멘트를 달아 함께 해결하였습니다. 질문과 답변을 만들어 가면서 생각지도 못한 다른 연관된 이슈들도 발견할 수 있었고, 발견된 이슈들은 유관 부서로 넘겨 수정될 수 있게끔 처리하였습니다.
이때 중요하게 고려되어야 할 부분은 1)사람들이 질문에 대한 해답을 쉽게 이해하고 따라 할 수 있는가 2)답변 중 잘못 표기되어 사용성을 떨어뜨리는 경우가 없는가로 위 두 기준을 지키면서 작성해야 합니다. 혹시 놓친 부분이 있을까 싶어 전체 팀원에게도 한 번 더 공유해 오탈자나 혹은 추가 질의를 받아가며 보완했습니다.
어쩌면 굉장히 간단한 부분이지만, 이렇게 FAQs를 작성하는 것만으로도 Cochl.Sense를 어떻게 사용할 수 있는지, 사용 과정에서 마주할 수 있는 어려움은 어떤 점들이 있을 수 있는지, 서비스 별로 어떻게 연결고리를 만들어 가야 할지를 알 수 있었습니다.
특히나 이렇게 FAQs를 만들어 두면 사후에 두 가지 측면에서 큰 도움을 받을 수 있는데요, 먼저 UX heatmap 혹은 GA를 활용하여 페이지별 방문 빈도를 파악할 수 있습니다. 어떤 항목을 사람들이 가장 많이 클릭하는지 결괏값을 확인함으로써 FAQ 내용 중 보강할 여지가 있는 부분을 관찰해 볼 수 있습니다. 또한 우리가 미리 작성하지 못한 내용이지만 접수되는 trouble shooting 내용을 바탕으로 미리 큰 에러가 발생하는 것을 방지할 수 있고, 제보자와의 신뢰 관계 형성을 통해 코어 사용자 획득으로 이어질 수도 있습니다.
2. 정보 계층구조 정리
사용자가 여러분의 기술 문서 사이트에 들어온다면 어떤 점을 보여주고 싶으신가요? 사용자가 원하는 정보를 빠르고 정확하게 보여주는 것은 매우 중요합니다. 만약 그렇지 않고 “사용자가 우리 기술 문서 사이트를 탐험했으면 좋겠어!”라는 생각으로 정보를 숨겨 놓는다면, 결국 그 사용자는 다시는 여러분의 기술 문서 사이트에 들어오지도, 여러분의 서비스를 이용하지도 않을 거니까요. 결과적으로 ‘가독성’이 좋은 웹사이트가 되어야 한다는 말입니다.
기술 문서 사이트는 보물 찾기가 아니에요!
Cochl은 Cochl.Sense란 무엇인지, 어떤 목적으로 사용할 수 있는지, 어떤 형태로 제공되는지, 어떻게 사용할 수 있는지, 어떤 기능을 가졌는지로 카테고리를 크게 나누어 보았습니다.
기존에는 Cochl.Sense API, Cochl.Sense SDK, Cochl.Sense Notification, Cochl.Sense Experience 등 크게는 프로덕트의 형태에 따라 구성 되었습니다. 다만 중복되는 콘텐츠가 많았고, 주요한 정보가 어디에 있는지 파악이 어려웠으며, 그래서 이걸 어떻게 사용할 수 있는지에 대한 예시가 부족했습니다.
개편된 정보 계층 구조는 다음과 같습니다. 동일하게 프로덕트의 형태로 큰 카테고리를 나눴으며, Home에서는 전반적인 Cochl.Sense에 대한 소개와 사용자들이 ‘어떻게 Cochl.Sense를 사용할 수 있는지’에 대한 의문을 해소할 수 있는 정보를 반영했습니다.
그다음, Cochl.Sense Dashboard를 추가해 Dashboard에서 Cochl.Sense를 사용하는 흐름을 정리했습니다. 이에 따라 기존에는 Dashboard에 관련된 내용이 중복되거나, 제한된 내용만 기재되어 사용 흐름을 파악하기 어려웠다면, 이번 개편을 통해 서비스 간 alignment를 맞출 수 있었습니다. 그리고 Dashboard에서 사용할 수 있는 다양한 기능을 함께 소개하면서 사용자가 Cochl.Sense를 다룰 수 있는 여러 아이디어를 제시했습니다.
Cochl.Sense Cloud API와 Cochl.Sense Edge SDK, Cochl.Sense Mobile apps의 경우 큰 변화없이 중복되었던 내용을 정리하고 각 부분에 맞는 내용을 일목요연하게 보여주는 쪽으로 개선했습니다.
마지막으로 앞서 언급한 FAQs를 추가하면서 사용자가 궁금해할 수 있는 영역들을 정리했습니다.
이렇게 기술 문서 사이트의 정보 계층 구조를 다듬어 보았습니다.
3. UX writing
우리가 흔히 코딩할 때 ‘코딩 컨벤션’을 지키는 것이 중요하다고 말합니다. 코드를 작성하는 규칙을 잘 지켜야 모두가 ‘읽을 수 있는’ 상식적인 코드가 완성되거든요. 네이밍 규칙이라든지, 들여쓰기 등 정리된 규칙을 지키지 않고 본인이 원하는 대로만 작성하게 된다면 같은 내용임에도 불구하고 사람들마다 해석의 여지가 달라 잘못된 결과물을 만들어낼 수 있습니다.
기술 문서에서도 마찬가지입니다. 샘플 코드에서 사용된 변수나 함수 네이밍이 샘플 코드마다 다르다면 어떻게 할까요? 가령 어떤 샘플 코드에서는 audio_window라고 되어 있던 것이 다른 샘플 코드에서는 audioWindow라고 되어 있다면 같은 의미를 담았을지라도 전혀 다르게 해석될 수 있습니다.
하물며 코딩 컨벤션도 잘못 기재가 되었을 때 고개를 갸우뚱하게 되는데, 서비스 내 자주 사용되는 단어가 통일되지 않거나, 혹은 오탈자가 보이거나, 아니면 페이지마다 다른 넘버링 방식을 사용하고 있다면 어떨까요? 내용을 이해하는 데는 어려움이 없을 수 있으나 사용자에게 부정적인 경험을 제공하고 서비스를 사용하는데 혼란을 줄 수 있습니다.
Cochl에서는 이 부분을 해소하기 위해 자주 사용되는 단어와 표기 형식에 대해 용어 정리를 시작했습니다. 사이트별로 단어들의 포맷을 맞추고 모호했던 단어들도 하나씩 나열해 단순 변경 / 용어 통일 / 삭제 의 기준으로 정리했습니다. 이 과정에서 문법 오류나 오탈자도 함께 잡을 수 있어서 결과적으로는 전체적인 콘텐츠의 퀄리티를 한층 더 높일 수 있었습니다.
이와 함께 디자인팀에서 UX writing guideline을 작성해 기술 문서 뿐만 아니라 Cochl이 운영하는 여러 사이트와 어플에서도 통일된 양식을 적용할 수 있었습니다. Cochl이 다루고 있는 기술은 매우 전문적이고, 기술적인 영역이기에 이렇게 정제된 UX writing을 적용함으로써 신뢰감 있는 서비스라는 이미지를 줄 수 있습니다.
또한 기술 문서를 읽는 사람은 누구일까요? 기술 문서 사이트까지 들어오게 된 사용자는 대체로 개발자 혹은 리서쳐일 확률이 높겠지만 그렇다고 해서 그 두 집단이 서비스가 포함된 산업군의 전문가는 아닐 수 있습니다. 그런데 기술 문서가 온통 전문적인 용어나, 학계에서만 사용되는 용어로만 적혀있다면 그 기술 문서는 긍정적인 사용자 경험을 줄 수 있을까요? 어려운 내용도 쉽게 표현해 독자의 이해도를 높이는 것이 긍정적 사용자 경험을 만드는 데 더 도움이 되지 않을까요?
사용성 평가에서 받았던 피드백 중 하나로 기존의 기술 문서 사이트가 텍스트 위주라 설명을 이해하는 데 시간이 많이 들었고, 이를 위해 다른 부가적인 자료들을 제공해 이해를 도와주면 좋겠다는 내용이 있었습니다. 기술 문서 내 콘텐츠를 작성하는 사람들은 이미 그 내용에 대한 이해와 배경 지식이 있는 상황에서 작성하기 때문에 텍스트만으로도 쉽게 상황을 상상하고 받아들일 수 있습니다만 우리의 독자들은 다릅니다. 그렇기 때문에 독자가 텍스트를 읽고 그 상황을 재현해볼 수 있도록 자료를 제공해주는 것을 목표로 삼았습니다.
예를 들어 ‘Result summary’의 경우 기능을 끄면 상세 결과를 확인할 수 있고 기능을 켜면 요약된 결과를 확인할 수 있다는 설명이 있습니다. 그렇다면 상세한 결과는 얼마만큼 상세한 내용이 나오고 요약된 결과는 얼마나 요약된 내용이 나오는 걸까요? 사람마다 상상 가능한 결과물은 천차만별입니다.
그래서 위와 같은 이미지 파일을 삽입하여 독자들로 하여금 결과물을 바로 이해하게 도왔습니다. 시각적 자료를 통해 기능의 On/Off를 비교해 보는 방식은 간단하지만 확실하게 이해도를 높여줄 수 있는 방안입니다.
사실 좋은 기술 문서 사이트에 대한 기준은 사람마다 다르고, 누군가에겐 아주 직관적이고 편리한 기술 문서 사이트가 누군가에게는 불친절할 수도 있습니다. 하지만 사람들이 ‘좋다’고 생각하는 기술 문서 사이트에는 공통된 점들이 있습니다. 바로 ‘사용자’의 관점에서 내용들이 제공되고 있다는 점입니다.
어떻게 보면 사소하지만 위 방식들을 통해 Cochl의 기술 문서는 한층 더 정제되었고 독자들이 원하는 내용으로 바뀌었습니다. 모든 것을 한 번에 덜어내고, 뜯어고칠 수는 없지만 우리가 가진 문제가 무엇인지 파악하고 이를 어떻게 해결할 수 있는지를 고민하는 과정을 거쳐 하나씩 바꿔나가고 있습니다.
지금까지 언급된 내용은 현재 기술 문서 사이트에 업데이트가 되어 있으니 한번 씩 들어오셔서 확인해 주세요 마지막 아티클은 ‘다양한 유즈케이스와 샘플 코드’ 추가를 중점적으로 다뤄볼 예정입니다. Cochl의 기술 문서나 사용성 평가, UX writing에 관심이 있으시다면 편하게 연락해 주세요!
마지막 아티클은 ‘다양한 유즈케이스와 샘플 코드’ 추가를 중점적으로 다뤄볼 예정입니다. Cochl의 기술 문서나 사용성 평가, UX writing에 관심이 있으시다면 편하게 연락해 주세요!