brunch

매거진 AI 봇

라이킷 24 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 젠틀파이 제이미 Jul 14. 2020

대화형 UX 사용성 체크리스트

챗봇 기획, 젠틀파이, 챗봇 UX, AI봇, UX 전문, 서비스 기획

"A봇 진짜 별로지 않아요?"

몇 달 걸쳐 밤낮 고민해가며 만들어 놨더니, 지나가는 말로 툭툭 내 마음을 아프게 한다. 대체 뭐가 별로라는 거예요? 무심하게 툭 내뱉는 '그거 별로'라는 말의 뜻은 '디자인 안 이쁘다' '홈으로 가기 어렵다' 등 단순한 한 두 가지 문제일 수 도 있지만, 막상 찬찬히 따져보면 그렇게 간단하지 않은 경우가 더 많다.

"B봇보다는 잘 만들어 주세요"

'어떻게 더 잘 만들라는 말씀이신가요?'라고 되물어보면, "아이, 그냥 알아서 잘 만들어 주세요."라는 답변이 오곤 한다. 그렇게 말하는 사람이 잘못된 것이 절대 아니다. '별로야' '더 잘 만들어'라는 말의 의미를 제대로 이해하는 것부터가 우리의 일이니까. '별로'라는 형용사를 의미 파악이 가능한 형태로 정의하기 위해서는 테스트를 해야 하고, 이 테스트에는 테스트 항목이 필요하다. 저마다 각기 다른 생각을 합리적으로 정의, 공통의 이해를 이끌기 위해서다.

젠틀파이 CUX 방법론

젠틀파이 CUX(Conversational UX) 방법론 1. Understanding & Analysis 단계엔 CUX 사용성 체크리스트가 있다. 우리의 사용성 체크리스트가 전 세계 이백만 명의 과학자가 수십 년간 연구한 결과였다면 확실히 좋았겠지만, CUX의 짧은 역사상 현실적이지 않았고, 비교적 가장 널리 알려진 Jakob Nielsen의 Heuristic Evaluation을 봇 분야에 맞춰 재구성했다. 물론 4년여의 챗봇 구축/운영 프로젝트 경험과 UX팀의 장기적인 노력이 큰 도움이 되었다. 이 체크리스트에서는 봇의 목적에 맞는 대표 시나리오를 선정, 7개 카테고리*로 테스트 진행하며 점수를 매긴다. 유사 시나리오가 있으면 비교를 위해 동일 시나리오로 테스트하고, 시나리오별 페인 포인트/인사이트를 확인하게 된다.

*CUX 사용성 테스트의 7개의 카테고리는 다음과 같다.

1. Personality : 봇의 Persona는 진행 중인 대화에 맞춰 자신만의 개성을 갖고 있는가

2. Onboarding : 챗봇의 역할/기능 등 상호작용 방법에 대해 이해할 수 있는가

3. Understanding : 명령을 비롯한 스몰톡, 비속어, 오타 등을 이해하고 대응하는가

4. Answering : 챗봇의 요소들이 콘텐츠에 적합하게 사용되어 응답하는가

5. Navigation : 대화를 얼마나 쉽게 시작하고 이어갈 수 있는가

6. Error management : 에러 발생 상황에 얼마나 잘 대처할 수 있고, 복구가 가능한가

7. Intelligence : 컨텍스트에 맞게 대응하는가

젠틀파이 CUX 체크리스트 중 일부 발췌 : 1. Personality

CUX 체크리스트를 만들고 나서, 실제 UX 컨설팅 프로젝트에 적용해 보았다. 구체적인 대상이 있어 훨씬 더 정교화할 수 있었다. 7개의 항목을 골고루 평가하고 해당 봇의 상대적으로 Intelligence와 Error Management였다. 이런 식으로 평가하니 그 부분에 더 초점을 두어 개선안을 도출할 수 있었다. 물론 초기에 만든 체크리스트를 실제 적용해 보니 모든 것을 아우르기가 어려웠고, 또 텍스트봇이 아닌 음성봇을 리뷰할 때는 추가로 확인할 리스트가 더 필요했다. 음성봇에서 사용자가 발화인지/턴을 인식할 수 있는 피드백이 주어지는지, 또 오류의 알림이 제시되는지, 유저의 실수 혹은 대화 실패 시 적절한 대응이 마련되는지 등이다. 모두 텍스트형 챗봇에서는 체크되지 않는 항목들이다.

사용성 체크리스트 만들자. 만들 수 있다.

앞서 언급했듯이 사용성 체크리스트를 수십 년에 걸쳐 연구할 필요도 없고 국가 인증을 받을 필요도 전혀 없다. 대내외 구성원의 합의를 이끌 수 있을 정도로, 기존 봇과 이후 봇의 사용성 차이를 수치화 혹은 리스트화하고 문제점을 파악할 수 있을 정도로 만들면 된다. 무엇보다 평가 요소가 사용성 전반에 적용되어 심각한 문제를 혹여 빠뜨리지 않을 수 있도록 만드는 게 좋겠다.

만들고 나서 '꼭' 쓰자.

솔직히, 가이드나 체크리스트가 없어서 안 했던 건 아닌 것 같다. 웹/앱 개발에도 적용할만한 체크리스트가 많이 있었고 가이드라인도 있었다. 방법론은 회사의 정책이 되어야 하고, 그 정책을 ‘시간’과 ‘의지’로 녹여내는 노력, 그리고 '그렇게 하니까 결국 더 나은 결과가 생기더라'라는 프로젝트 구성원 간의 암묵적 합의의 결과로써만 드러난다. 리스트를 만들고 평가하고 그걸 적용해서 수정하고 - 이 모든 것은 시간과 노력, 직설적으로 말하면 돈의 문제다. 실제로 회사 내부에서도 방법론 및 사용성 체크리스트를 만들고 나서 프로젝트에 적극 반영하라고 했지만 모든 프로젝트에 적용되지 않았다. 아무리 좋은 툴이라도, 본인 + 동료 + 리더 + 회사 + 파트너 등의 적극적 참여와 지지가 수반되지 않으면 아무도 사용하지 않는다.

다행인 점은, 젠틀파이는 이런 과정이 의미 있고 프로세스화를 통한 공통의 합의가 중요하다고 여기는 사람들이 중심에 있다. 그리고 앞으로도 그런 사람들이 합류해주길 바란다.