챗봇UX 작업기
화면 없는 사용성디자인
지금부터 제가 쓰려는 작업기는 약 1년 전 챗봇 개발에 참여했던 경험입니다.
네, 한달 전이 아니라 1년 전이 맞습니다. 약 1년 전 일을 무려 지금 쓰다니 좀 너무하긴 했네요.
그래도 그 당시 느꼈던 점을 개인적으로 기록할 겸 민망함을 무릅쓰고 적어봅니다.
시작하기
2016년 여름 언젠가 회사에서 사이드 프로젝트로 AWS Serverless Chatbot Competetion에 제출할 챗봇을 만들게 되었고 "네가 있으면 도움이 될것 같다"는 말에저도 참여하게 되었습니다. 처음 해보는 분야의 일이었고 제가 뭘할 수 있을지 고민되었지만 일단 한번 해보기로 했습니다.
기본조건 파악하기
저는 사실 챗봇에 관심도 없었고, 어떤식으로 작동하는지에 대한 이해도 부족한 상태었습니다. 제가 하던 일과는 작업 환경이 완전히 달랐기 때문에, 시작 전에 제가 '할수 있는 것'과 '할수 없는 것'을 먼저 파악했습니다.
1. Slack에서 돌아가는 챗봇 : slack에서 제공하는 api를 활용해서 만들어야 한다.
2. AWS Lamda를 활용하는 챗봇 : 봇 응답시간과 관련해 약간의 제약이 있다. (이 부분에 대해 특별 과외를 받았습니다만, 솔직히 아직도 제대로 이해 못했습니다. 미안해요 개발자님ㅜㅜ)
3. 자연어 처리가 어렵다 : 원하는 명령어를 입력하도록 유저를 유도해야한다.
그리고 약간의 리서치로 제가 어떤 것들을 활용할 수 있는지 대략 봐두고, 다른 챗봇들도 설치해서 많이 사용해보았습니다.
주제와 프로젝트 골 정하기
말그대로 사이드 프로젝트였기 때문에 주제는 어느 것이든 상관 없었고, 이왕이면 재미있는 것을 하고 싶었기 때문에 많은 직장인들이 매일하는 그 고민 "오늘 뭐먹지"를 도와줄 챗봇을 만들기로 결정했습니다. 예를 들면 유저가 이 챗봇에게 "오늘 뭐먹지?" 이렇게 말을 걸면 주변의 멋진 식당을 추천해주는 것이죠. 다섯개 정도의 무작위 후보를 골라주고, 마음에 들지 않으면 또 다른 다섯개를 추천해줍니다. 여기에 아이디어를 좀 추가해서, 같이 밥먹으러 갈 멤버들을 초대하여 투표를 하도록 하기로 했습니다.
자.. 그럼 이제 뭘 해야하지?
이때부터 문제가 좀 생겼습니다. 새로운 프로젝트를 시작할때 저를 포함한 UX디자이너들은 대체로 비슷한 과정을 거치죠. 대략적인 방향이 나왔다면 달성해야하는 과제들을 정리하고 피쳐를 고민한 후, IA를 작업하면서 구조를 고민하고, 와이어프레임을 만들고, 유저테스트도 진행하고...... 이 과정들을 왔다갔다하며 작업하는 그런 일반적인 방식이요. 하지만 챗봇 프로젝트를 하니 길을 잃은 기분이었습니다..
왜그럴까 생각해보니 화면이 없는 게 문제였습니다. 그때까지 깨닫지 못했지만 저는 프로덕트를 만들때 화면 단위로 생각을 하고 있었습니다. 화면 디자인을 생각하다는 뜻은 아니고, 유저플로우를 머리속으로 그릴때 가상의 화면을 그리면서 프로덕트로 발전시키는 방향이었죠. 예를 들면 "메인페이지에서 유저에겐 이런 정보를 보여주고 추가적으로 보여줄 것이 있으면 디테일 페이지로 가도록 유도해야겠다. 그다음엔 다른 페이지로 이동시키고, 다시 돌아오게 하려면 어떻게 하고..." 이런식으로요. 그러고보니 플로우차트도 화면으로 어느정도 감이 잡혀야 그리면서 아이디어를 보완하고 탄탄하게 하는 방식으로 작업했었죠. 그러다가 화면이 전혀없는 프로젝트를 만나니 시작이 어려웠습니다.
기본적인 유저 시나리오부터 단순하게 시작해 보기
이번에는 화면 단위로가 아니라 유저가 봇을 실행하서 마치기까지의 유저의 행동에만 초점을 맞추기 시작했습니다. 일단은 유저가 봇에게 먼저 말을 걸어서 깨운 뒤 뭘 먹을지 물어보고, 레스토랑을 추천받아야겠죠. 이 시나리오부터 그리기 시작했습니다.
실제로 이 화면으로 작업한 것은 아니지만, 제 생각을 정리하기 위해 간단한 이미지로 정리했습니다.시나리오 보강하기
일단 기본적인 시나리오를 그리고 나니, 채워 넣어야하는 부분이 조금씩 눈에 보였습니다.
일단 레스토랑을 추천해주려면 유저가 사는 지역을 알아야하죠. (데이터는 yelp에서 가지고 왔습니다) 그러나 우리가 자동으로 사용자의 위치를 알수는 없었기 때문에 위치를 묻는 절차가 필요했습니다. 필요한 내용을 추가했습니다.
다음은 slack에서 돌아가는 챗봇이기 때문에 생긴 이슈인데, 친구를 초대해서 투표를 하게 하려면 봇이 새로운 채널(slack에서 채널은 카톡의 대화방 같은 것입니다)을 생석해야하는데, 그러려면 봇을 사용하는 유저에게 권한이 필요해 별도의 과정을 거쳐 받아야 했습니다. 그래서 권한을 받는 과정이 필요했죠.
다른 문제는, 투표를 할때 투표를 안하는 사람이 생기거나, 동점 상황에 대한 고려를 하지 않았다는 것입니다. 가볍게 이용하는 챗봇인 만큼 시간 5분의 시간을 두고 그 안에 투표를 하도록 하고, 전원 참여하지 않더라도 그냥 결과를 보여주기로 했습니다. 동점인 경우에도 임의로 식당을 하나로 정해주기로 했습니다.
주요 플로우 별로 정리하기
이렇게 하다보니 유저플로우도 점점 복잡해졌습니다. 유저에 따라 건너 뛰는 과정도도 생기고, 또 유저가 정확한 명령어를 입력하지 않은 경우는 계속 진행시키지 않고 일부분을 반복 해야할 필요도 있다보니 유저 플로우를 체계화 시킬 필요가 있었습니다. 유저플로우를 몇 가지 덩어리로 나누고, 이름을 붙였습니다. 저는 먼저 상세 내용을 정리하고 체계화 시켰지만, 사실 반대로 작업하는 것이 더 좋다고 생각됩니다.
이렇게하여 유저 플로우가 완성되었습니다. 위의 차트는 간소화한 것이고 실제로는 조금 더 복잡해서 아래처럼 flow별로 따로 페이지를 만들어 정리를 했습니다.
flow를 벗어나는 상황에 대처하기
모든 유저가 우리가 만들어놓은 길을 따라서 우리가 원하는 대로 깔끔하게 봇을 실행하고 정상적으로 완료를 한다면 얼마나 좋을까요. 하지만 ux디자이너들은 모두 알죠. 절대 그렇게 되지 않는다는걸. 되도록 보여주는 상황을 만들지 않으려고 노력해야하지만 그래도 에러메시지는 필요했습니다.
초반에 제가 에러메시지를 작업한 방식은 이랬습니다.
저는 기본 flow를 보면서 아래 그림처럼 에러메시지가 필요한 부분을 생각했고, 이렇게 flow를 따라다니며 예상 가능한 문제와 그에 따른 에러 메시지를 준비했습니다. 하지만 이런식으로 작업을 하니 빠뜨리는 내용이 너무 많았습니다.
사용자는 챗봇 사용 어느 단계에서든 예상치 못한 반응을 보일 수 있습니다. 예상치 못한 반응이란 챗봇 제작시에 정의한 명령어 외의 모든 반응입니다. 물론 정의한 명령어도 상황에 따라서는 에러가 될 수도 있습니다. 이런 다양한 상황에 대처하기 위해 지금까지와는 다른 방법으로 진행할 필요가 있었고, 저는 아래 표처럼 정리해서 각 상황에 맞는 메시지를 정리하는 게 유용했습니다.
표의 가로는 저희가 챗봇 내에서 사용하도록 정의한 명령어들 ('What to eat', 'Stop', 'Demo')과 'invalid input'이고, 세로는 아까 체계화 한 flow들입니다. 이렇게 하면 모든 flow에서 모든 명령어와 예상하지 못한 인풋에 대한 대처할 수 있습니다. 아래는 제가 실제 작업한 화면입니다. 왼쪽은 각 상황에 어떤 동작이 실행되어야 하는지 표기했고, 오른쪽은 챗봇의 워딩을 정리한 화면입니다. (오른쪽처럼 워딩을 정리하는 것은 다른 분이 하셨고 제가 직접 한 것은 아닙니다)
단순히 정리했습니다만, 에러가 되는 상황과 그렇지 않은 상황에 대해 좀 더 구체적으로 정의할 수도 있습니다. 섬세한 설계를 할수록 좀 더 사용자에게 친절한 서비스가 될 수 있을 겁니다.
그렇게하여...
이렇게 BOPBOT이라는 챗봇이 완성되었습니다. 그리고 이 사이드 프로젝트의 목표이던 AWS Serverless ChatbotCompetetion 에 출품도 했습니다. 그리고 그 결과로!!! 기분 좋게 수상도 하게 되었습니다.(증거) 아마 대회 첫 해라서 가능했다고 생각은 들지만 뿌듯하긴 했습니다.
밥봇이 궁금하시다면 여기서 더 자세히 보실수 있습니다.
챗봇이기 때문에 고려해야 하는 것들
그리고 간단하게 웹이나 앱 UX와 달랐던 점을 정리해봅니다.
1. 출구를 만들어 줘야합니다.
챗봇은 일방통행 길과 비슷합니다. 앱이나 웹은 화면에 여러가지 길을 두어 자유롭게 드나들 수 있지만, 챗봇은 봇이 제시한 길만 따라가는 것이죠. 그래서 한번 유저가 빠져나올 수 있는 문을 만들어줘야 합니다. 인터페이스의 한계때문에 시각적으로 그러한 정보를 전혀 줄 수 없다는 문제가 있습니다. 그래서 저희는 flow 시작 전과 유저가 예상치 못한 인풋을 넣었을때 지속적으로 챗봇과의 대화를 그만두는 방법을 안내해주었습니다.
사실 텍스트에 모든 것을 의존하기 때문에 출구만이 아니라 다른 메뉴들도 마찬가지이지만, 잊기가 쉽고 또 빠뜨려서는 안되는 요소이기 때문에 출구를 만드는 것을 강조했습니다.
2. 정확한 인풋을 넣을 수 있게 유도해야 합니다.
직접 입력보다는 몇가지 옵션을 주어 그 중에 선택하게 하는 것이 좋습니다. 선택은 버튼 형식이라 클릭 한번에 가능한 것이 좋겠죠. 밥봇을 제작할때는 버튼으로 만들 수 없는 선택은 숫자를 타이핑하도록 했고, 그 외의 요소들은 대부분 버튼으로 만들었습니다.
3. 스크립트는 매우 중요합니다.
텍스트 의존이 매우 높은 만큼 간단하고 명료한 문장으로 전달을 하는 것이 중요합니다. 문장이 필요이상으로 길어지지 않도록 하고, 부정적인 문구는 되도록 피하는 등 앱과 웹을 디자인 할 때 고려했던 것들을 챗봇 스크립트를 작성할 때도 적용하면 좋습니다. 추가로 고려할 내용은 챗봇은 대화의 형태를 띈만큼 좀 더 가벼운 어조가 어울립니다. 가벼운 농담이나 이모티콘같이 약간의 재미를 추가한다면 유저의 흥미를 일으킬 수 있습니다.
