-지난 글에 이어-
지난 글에서는 챗봇 UX 설계 시 체크 포인트 중 ‘1. 채널, 2. 경로’에 대해 이야기했습니다.
잠깐 기억을 되살리는 의미로 요약을 하자면 다음 내용이 되겠지요.

1. 채널
   지원 채널 지정에 대한 내용을 얘기하고 다채널 지원 시 고려할 점을 정리했습니다.
   . 채널 간 일관성 부여
   . 채널 별 차이점, 특이사항에 대한 사전 안내
2. 경로
   경로가 갖는 의미를 살펴보고 적용하고 활용할 부분을 짚어보았습니다.
   . 우선 고려 사항 ‘접근성’
   . 적절한 Signal의 사용
   . 최단 동선의 봇 실행
   . 母페이지의 활용

그럼 이제 봇의 핵심 요소인 ‘대화’에 대해 본격적으로 시작합니다.

–

3. 대화
– 대화 인터페이스가 갖는 가치-
‘대화’라는 짧은 단어에는 여러 가지 스토리가 있습니다.
대화를 시작할 때의 상황(처음인 사람, 늘 오는 사람, 급한 사람, 놀러온 사람, 활발한 사람, 조심스러운 사람), 대화가 진행될 때의 상황(쉽게 설명을 잘 해주는 사람, 어려운 용어를 남발하는 사람, 무슨 얘긴지 장황해서 파악하기 어려운 사람, 전후 설명 없이 선택만 재촉하는 사람), 대화하는 태도(먼저 아는 척 해주는 사람, 말 걸기 전까지 외면하는 사람, 상대의 얘기를 이해하려는 사람, 내 얘기만 하는 사람, 자신이 할 수 없어도 도움을 주려는 사람, 자기 맘대로 단정하고 말을 끊는 사람)만 봐도 다양한 이야기가 생깁니다.
이렇게 대화의 요소는 우리가 일반적으로 대화할 때의 상황을 봇의 대화에 담는다고 생각하면 좋을 것입니다.

–

<첫인사>
그 중 첫인사는 방문자에 대한 환영과 더불어 봇이 감당할 수 있는 범주, 역할, 수준과 성격까지 담고 있는 중요한 요소이지만, 그 자체가 목적이나 결론이 아니고 그곳으로 들어갈 수 있게 하는 게이트라는 것을 기억해야 합니다.

• 따라서, 짧지만 임팩트 있게 최소한의 메시지와 영역으로 이용에 불편과 부담을 주지 않도록 구성해 보세요.
  매장 출입문을 열자마자 매니저가 20~30분을 붙잡고 인사와 영업 멘트를 날린다면 매장을 둘러보기도 전에 지칠 수 있는 것처럼 과하게 욕심내지 않는 것이 필요합니다. 다만, 인사말은 가볍고 간단하되 해당 봇의 핵심 메시지는 담고 있어야 합니다.

 

[최소화] 봇의 핵심 기능 또는 역할만 간단히 표현하고 바로 대화를 시작하도록 유도하고 있는 사례

• 또한 방문자(이용자)의 방문 상황이 제각각 이라는 것도 잊어서는 안될 점이죠.
  한달 내내 오는 사람과 오늘 처음 온 사람, 자기가 찾아서 오는 사람과 어딘가에서 보내서 오는 사람, 놀려고 오는 사람과 화가 나서 오는 사람에게 항상 똑 같은 멘트나 날리고 있으면 인사를 받는 사람은 어떤 기분일까요?
  방문 시간대와 주기, 기타 환경적 요인에 따라 다르게 반응할 수 있어야겠습니다.
  만약, 구현할 봇의 기술이 방문 목적이나 이용행태 예측이 가능한 경우라면, 그 예측하는 기능이나 답을 먼저 물어보거나 제안할 때 감동을 주지 않을까요?

 

[방문 시점, 주기에 따른 대응] 첫 방문/재방문에 따른 명확한 태도 설정으로 친근감과 편안함을 주는 사례

 

 

[진입 목적에 따른 대응] 진입 경로에 따라 다른 정보를 제공함으로 방문의도에 적합한 대응을 시도하려는 사례

–

<레이아웃>
봇을 실행하고 첫인상을 정리했다면, 이제 봇의 화면 구조와 구성, 주 요소의 표현 형태를 생각해 보겠습니다.

• 봇의 화면은 母페이지에 종속되지 않는 독립적 구조로 구성하는 것이 유리합니다.
  母페이지에 종속되는 디렉토리 구조이거나 프로세스를 적용할 경우, 사용자는 원하는 답까지 가기 전에 길을 잃을 수 있고 그 후 돌아왔을 때, 처음부터 다시 시작해야 하는 불편한 상황에 처해지고 맙니다.
  예를 들어 봇에게 요청한 결과나 중간에 확인할 내용이 모두 母페이지에 있다면 그 내용을 확인하려는 순간, 사용자는 자신의 의사와 관계없이 봇과의 대화가 끊기거나 봇 화면에서 강제 이탈됩니다.
  이런 이유로, 실행 순간부터 모든 Task는 봇 화면에서 시작하고 봇 화면으로 귀결하는 네비게이션 구조로 설계하시기 바랍니다. 또한, 부득이하게 봇 화면을 벗어나는 경우라면 이탈에 대한 명확한 확인과 되돌아 올 수 있는 방법을 준비해 둘 수 있어야 합니다.

• 따라서 母페이지 의존도를 최소화 할 수 있도록 요청된 정보를 봇 화면 내에서 처리할 수 있게 구성할 필요가 있습니다.
  원천정보는 母 서비스에서 호출하되 결과는 봇 화면 내에서 제공할 수 있도록 정보의 형태, 프로세스에 따라 UI 템플릿을 구성하여 적용해 보세요. 효율적인 동선 처리로 불필요한 이동 없이 짧은 스텝의 업무처리가 가능해집니다.
  또한 봇 내에서 처리할 수 있는 기능이 많다는 인식을 주어 봇에 대한 긍정적인 감정과 이후 자연스럽게 봇을 찾도록 하는데 도움이 됩니다.

 

[봇 화면 내 자체 처리] 별도의 프로세스, 화면 이탈 없이 대화창 내에서 바로 결과를 제공하는 사례

 

[母 서비스 호출 후 봇 내 처리] 옵션 선택, 프로세스를 위한 별도 화면 필요 시 봇의 네비게이션을 적용하여 母페이지 이동 없이 봇으로 복귀하는 사례

그럼 이렇게 처리한 결과를 어떻게 보여주면 좋을까요?

 

• 우선 명확한 포맷이 있는 결과와 답은 문장이 아니라 정보에 맞는 템플릿(가장 흔한 예로 카드형 UI가 있습니다.)으로 구성해 보세요.
  대화형 인터페이스라는 한계에 갇혀 다양한 메타를 문장으로 제시할 경우 정보의 명확성은 물론 중요한 내용의 변별력도 흐려집니다.

[카드 UI] 정보 속성에 따라 비주얼 카드, 텍스트형 카드를 선택하여 시각적 구분을 명확히 하는 사례

• 메타 정보와 서술형 답변, 지시어가 섞여 있다면 그 속성에 따라 명확히 구분하는 것도 필요합니다.
  정보의 속성, 기능에 따라 구분하더라도 한쪽 또는 전체적인 답변의 길이가 길다면 맥락이나 정보의 용도, 목적에 따라 조금 더 세분화된 단위로 단락을 끊어서 표현하는 것이 좋습니다. 이는 사람이 한 눈에 읽어 인지하는 단위가 그리 길지 않다는 사실을 생각하면 쉽게 이해할 수 있습니다.

[정보 속성에 따른 구분] 좌 : 중심정보+부가정보로 구성된 사례, 우 : 피드백 메시지+중심정보+연관기능으로 구성된 사례

[단락 구분] 긴 정보를 세분화하여 읽기 단위를 조절한 사례

사용자에게 응답하는 레이아웃을 보았으니 사용자가 봇을 호출하는 부분도 살펴보겠습니다.

• 한마디로 타이핑이던 보이스이던 ‘입력수단 중심으로 쉽고 단순하게’ 구성되어야 할 것입니다.
  할 수 있는 게 많다고 할 수 있는 것을 모두 꺼내놓을 필요는 없습니다.
  백종원이 그 수많은 골목식당에서 왜 많은 메뉴들을 줄여나갔을까요?
  선택지가 많다고 결정이 쉽거나 편리한 것은 아닙니다.
  핵심 기능, 이용 빈도, 니즈, 필요 시점을 고려하여 상시 노출될 항목을 선별하는 것이 중요합니다. 그 외에는 필요로 하는 위치나 시점에 제공할 수 있도록 조정해 보세요.

 

[입력 수단 외 정보 상시 노출] 대화창 내 가이드, 주요 기능 등을 상시 노출하되 입력 영역은 ‘입력 수단’ 위주로 심플하게 구성한 사례

[기능 호출 시 노출] 주요 기능을 입력 영역에 같이 제공하되 최소화 노출로 필요 시 사용자가 호출하여 사용하게 한 사례

[상황 발생 시 노출] 빅스비 : 대응 결과에 연관된 명령어 제공, 샘 : 키워드 입력 시 자동완성 기능 제공으로 그 상황에 가장 적절한 지원을 시도한 사례

단, 상시로 노출은 하지 않되 도움 받을 수 있는 정보를 주고 싶다면 일정한 위치에서 찾을 수 있다는 힌트를 주는 것이 좋습니다.
이때 지원/도움 기능은 입력 수단과 용도가 다르므로 명확히 구분이 되도록 구성합니다.

–

<명령 대응>
봇 실행 후 첫 대면(인사)에 대한 부분과 레이아웃을 살펴보았습니다.
이제 봇이 대응하는 방식에 대해 생각해 봅시다. 모든 케이스를 얘기할 수는 없으니 다음 몇 가지 상황만 짚어보겠습니다.
– 케이스 1. 미완료, 미수행 업무(명령)가 있는 경우
– 케이스 2. 프로세스를 거쳐야 하는 업무(명령)가 있는 경우
– 케이스 3. 끼어들기 업무(명령)가 요구된 경우
– 케이스 4. 처리 불가, 인식 불가 업무(명령)가 요구된 경우

• 케이스 1. 미완료, 미수행 업무(명령)가 있는 경우
  아무리 앞서 얘기한 체크 포인트들을 잘 정리해서 설계하였더라도 예기치 않은 상황(기술적 처리 불가, 사용자의 무단 이탈, 현실적 대응 불가, 프로세스 상 대기시간 발생 등)으로 미완료 업무는 발생하기 마련입니다.
  이런 경우 이어서 진행 또는 진행여부를 확인할 수 있다면 매번 초기화 되어 처음부터 시작하는 母 서비스와는 다른, 봇만의 장점을 살릴 수 있을 것입니다. 히스토리를 관리하여 사용자가 이어서 시도할 수 있는 기회나 접근 경로(또는 동작)를 추적하여 명령 수행이 바로 가능한 Flow로 진입하도록 설계해 보면 어떨까요.

[미완료 Task 이어서 진행] 봇 메인, 히스토리에서 신규와 이전 대화를 선택할 수 있고, 이전 대화로 진입 시 기 진행 중이던 내용에 이어서 대화가 가능한 사례

[명령 수행 Flow로 바로 진입] 실행 버튼의 후킹 메시지를 명령어 입력으로 간주하여 해당 Task Flow로 바로 진입 가능한 사례

• 케이스 2. 프로세스를 거쳐야 하는 업무(명령)가 있는 경우
  봇에게 요구되는 명령에는 단순한 가십거리나 수다 외에 상당히 길고 복잡한 프로세스나 옵션을 선택해야 하는 업무도 있습니다.
  이때 봇의 대화창 내에서 계속 묻고 답하기만으로 처리를 한다면 어떨까요?
  끝도 없이 올라가는 말풍선은 단계가 길어질수록 결정할 내용이 많을수록 언제 끝날지, 현재 어디까지 했는지 알 수 없게 만듭니다.
  그럴 때는 별도의 화면으로 구성하여 전체 내용과 과정을 파악하게 설계해 봅시다. 대화창 내에서 가능할 정도의 내용이라면 넘버링을 붙여 단계를 파악하게 하는 것도 좋은 방법입니다.

[복잡한 Task에 대한 독립화면 구성] 업무의 성격, 단계, 옵션이 많거나 구분되는 경우 별도의 화면을 제공하여 독립된 동작이 가능하도록 한 사례

• 케이스 3. 끼어들기 업무(명령)가 요구된 경우
  복잡한 업무 처리를 위해 별도의 화면을 지원하더라도 대화의 주 흐름과 시작, 귀결은 대화창 내에서 진행되기 때문에 봇이 대화의 줄기를 잡고 이어가게 하는 것은 중요합니다.
  만약 대응이 완료되지 않았는데 새로운 명령이 요구되었다면 어느 명령을 수행할지 확인 받는 시나리오를 고려해 보세요.
  이때 기존 명령과 신규 명령을 매번 물어봐야 한다면 어느 쪽도 불편한 단계를 거칠 수 밖에 없습니다. 또한, 어느 쪽 중 하나만 수행한다고 하면 한쪽은 다시 처음부터 해야 하는 귀찮은 상황을 만날 수 밖에 없습니다.
  그럴 땐 신규에 대응 후 기존 명령을 상기시키는 것이 효과적이지 싶습니다.

[끼어들기 업무 대응] 수행 중 새로운 명령이 끼어들 경우 새로운 명령 수행 후 이전 명령에 대한 복귀 여부를 확인하는 사례

• 케이스 4. 처리 불가, 인식 불가 업무(명령)가 요구된 경우
  사람도 대화 중 그 진위를 알아들을 수 없거나 답을 할 수 없는 영역을 요구 받기도 합니다.
  같은 상황에서 봇은 (많이 좋아졌기는 하지만)이런 반응을 많이 하죠.
  ‘이해할 수 없어요’, ‘아직 부족해요’, ‘찾을 수가 없어요’ 등의 부정적 답변을 내놓거나 생뚱맞은 결과를 보여주고 천연덕스럽게 있거나요.
  당신이 그런 상황에 처했다면 어떤 반응을 할 것 같은가요? 당신의 요구(질의)에 상대가 어떻게 반응하면 좋을 것 같나요?
  이렇게 인식 불가 명령, 처리 불가 업무일 경우 봇의 답변에 사용자가 이해를 하거나 납득할 수 있는 방법을 제시하도록 설계해 보길 바랍니다.
  요구한 내용을 직접 처리를 할 수 없더라도 그럴 수 밖에 없는 이유를 얘기해 주거나 할 수 있는 범위에서 차선을 제안한다면 상대가 느끼는 감정은 충분히 달라질 테니까요.

좌 – [개선항목 수집] 봇이 업그레이드할 항목을 수집하는 사례
우 – [대안 제시] 답을 찾을 수 있는 다른 도움 방법을 제시하는 사례

 

좌 – [근거 제시] 봇이 반응한 이유의 내역을 알려주어 사용자가 이해할 수 있게 우회적인 설명을 하는 사례
우 – [역할/기능 안내] 봇이 할 수 있는 범위에 대해 안내하여 대응 불가에 대한 판단을 사용자에게 맡기는 사례

–

<종료 및 이탈>
봇과의 대화가 어느 정도 되었다면 봇을 나가는 과정은 어떻게 정리해야 좋을까요.

• 자의에 의한 종료이건 Flow 상의 이탈이건 봇을 벗어날 때에는 대화의 종료 혹은 중단을 명확히 인지할 수 있게 하는 것이 필요합니다.
  일단 사용자의 요구에 응답을 하였으니 봇 화면에 있던 밖에 있던 무슨 상관이겠냐고 생각할 수 있지만, 봇 화면으로의 체크인과 체크아웃은 중요한 의미가 있습니다. 특히, 다양한 서비스를 함께 하고 있는 사이트에서는 대화의 종료를 인지해야 자신이 현재 어느 위치에 있는지 알 수 있습니다.
  일반 페이지와 봇의 화면은 구조와 수행하는 역할이 다르기 때문에 동일한 룰의 랜드마크를 부여하기 어렵습니다. 따라서, 지금 위치가 일반 페이지인지 아직 봇 화면 안인지 파악이 안되어 조작의 오류와 잘못된 피드백을 줄 수 있게 됩니다.
  봇 입장 역시 사용자의 종료 Sign이 명확하면 사후 피드백이나 재진입 시 반응을 더 효과적으로 할 수 있는 장점이 있습니다.

[이탈과 종료를 구분] 종료를 하지 않은 상태에서 봇 이탈 시에는 대화 내역을 봇 화면 내 유지(상담 품질 평가와 무관하게 이탈은 가능)하는 사례

[이탈과 종료 동일 시] 봇 이탈 시도 시 대화 종료 확인을 하며 재진입 시 봇 화면은 초기화 상태로 제공하는 사례

마지막으로, 사용자가 봇 화면을 벗어난 후에 할 수 있는 부분을 생각해 보겠습니다.
정상적으로 대화를 종료하였다면 봇 이용 단계 중 ‘경로’에서 얘기한 내용을 다시 상기해 보면 됩니다. 그러나 봇 화면을 벗어났지만 아직 봇이 완료하지 못한 대응이 있다면 사후 피드백을 보내는 것도 고려해 보시기 바랍니다. 이때는 Push 메시지도 좋지만 실행 아이콘의 ‘말 걸기’ 기능도 유용하게 활용할 수 있습니다.

적절한 사후 피드백은 봇이 내 얘기를 성의 있게 다루고 있다는 인상을 줄 수 있습니다.

단, 너무 잦은 피드백으로 차단을 유발하지는 마시고요.

–

-마치며-
지금까지 두 차례에 걸쳐 챗봇 서비스의 이용 여정에 따라 필자 나름의 입장과 순서대로 살펴 보았습니다.
각 포인트에서 얘기하고 싶은 내용을 조금이라도 이해했으면 하는 마음에 사례를 함께 사용했는데요. 실제 프로젝트에서는 적용해 볼 수 없는 상황이나 여건에 처할 수 있습니다. 어쩌면 전혀 다른 방향으로 정리를 하게 될 수도 있습니다.
그렇다 하더라도 챗봇 서비스를 전체적인 구조에서 바라보고 어떤 지점에서 고민을 하면 좋을지 정도라도 보였으면 하는 마음입니다.
그럼 당면했을 때의 막막함이 그만큼은 선명해질 수 있지 않을까 하는 희망을 품으면서요.
여러분의 프로젝트에 건투를 빌며 이만 마칩니다.

 

– 가치 UX그룹 김호준

 

 

_	* 1편 바로보기- 챗봇 기획자를 위한 실전 Tip – 챗봇 UX 설계 시 체크 포인트 (1) * 시리즈 보기 챗봇 기획자를 위한 실전 Tip – 챗봇 UX 설계 시 체크 포인트 (1) 챗봇 기획자를 위한 실전 Tip – 챗봇 UX 설계 시 체크 포인트 (2) 디자이너를 위한 챗봇 디자인 Tip -삼성카드 챗봇구축 인사이트 (1) 디자이너를 위한 챗봇 디자인 Tip -삼성카드 챗봇구축 인사이트 (2)

 

* 타이틀 이미지 출처 : giphy.com