사용자를 AI 기능에 대해 흥분하게 만드는 온보딩과 사용법을 잘 익히게 만드는 온보딩은 서로 다른 결과물이며, 전자의 경우 지원 티켓(support tickets)을 양산하게 됩니다.

잘못된 목표

대부분의 AI 온보딩은 활성화(activation)를 최적화합니다. 즉, 사용자가 기능을 시도하게 만들고 첫 번째 결과물을 인상적으로 보여주는 데 집중합니다. 이는 첫 번째의 인상적인 결과가 이후의 모든 결과물을 대표하는 결정론적(deterministic) 기능에서는 효과적입니다.

하지만 AI에서는 그렇지 않습니다. 첫 번째 실행에서 인상적이었던 기능이 네 번째 실행에서는 자신 있게 틀린 답을 내놓을 수 있으며, 첫 번째 실행으로 기대치가 설정된 사용자는 방금 무슨 일이 일어났는지 이해할 프레임워크(framework)가 없습니다. 그 결과는 오류에 비례하는 실망이 아니라, 불균형적인 붕괴(disproportionate collapse)로 나타납니다. 왜냐하면 사용자가 가진 도구에 대한 모델(model) 상으로는 이런 일이 일어날 수 없다고 생각했기 때문입니다.

적절한 신뢰 (Appropriate reliance)

참고해야 할 문헌은 온보딩보다는 자동화에 대한 신뢰(trust in automation)입니다. Lee와 See의 2004년 리뷰 _Trust in Automation: Designing for Appropriate Reliance_는 핵심적인 점을 짚어줍니다. 설계 목표는 최대치의 신뢰가 아니라 '교정된(calibrated)' 신뢰, 즉 자동화의 실제 능력과 일치하는 신뢰를 구축하는 것이며, 교정되지 않은 양방향 모두 각기 다른 비용을 초래하는 실패입니다.

• **과잉 신뢰 (Over-trust)**는 검증이 필요한 상황에서도 의존하게 만듭니다. 실패 모드는 감지되지 않은 오류가 그대로 전달되는 것입니다. 보고서의 잘못된 수치나 메시지의 잘못된 이름 같은 것들입니다. 이는 비용이 많이 들고 사용자에게 책임이 전가되며, 이를 유발한 온보딩으로 원인을 추적하는 경우는 드뭅니다.
• **과소 신뢰 (Under-trust)**는 미사용(disuse)을 초래합니다. 기능이 존재하고 능력이 있음에도 불구하고, 단 한 번의 나쁜 경험이 일반화되어 사용되지 않습니다. 사용자에게는 비용이 들지 않지만, 당신에게는 완전한 손실입니다.

신뢰는 또한 역동적입니다. 경험에 의해 업데이트되며, 그 업데이트는 비대칭적입니다. 즉, 신뢰는 천천히 쌓이지만 실패 후에는 급격히 떨어집니다. 이는 온보딩이 적절한 수준의 신뢰를 한 번에 설치하고 끝낼 수 없음을 의미합니다. 온보딩의 역할은 나중에 발생하는 실패가 환멸을 주는 것이 아니라 해석 가능한 수준이 될 수 있도록, 충분히 정확한 '모델(model)'을 설치하는 것입니다.

첫 번째 실행이 해야 할 일

• 사용자의 실제 데이터로 단 한 번의 동작을 통해 실제 결과물을 생성하세요. 비디오도, 투어(tour)도, 샘플 문서도 아닙니다. 결과물만이 해당 기능이 무엇을 하는지 가르쳐주는 유일한 요소이며, 사용자의 데이터를 사용함으로써 그 기능이 '그들 자신을 위해' 무엇을 하는지도 가르쳐줍니다. 이는 사용자 데이터에서 도출된 제안(suggestions drawn from user data)과 동일한 논리입니다.
• 해당 기능이 확실히 잘 수행할 수 있는 작업을 선택하세요. 의도적으로, 그리고 그것이 쉬운 방향으로는 대표성이 부족할 수 있음을 인지한 상태에서 선택해야 합니다. 실패하는 첫 실행은 대표성이 부족할 정도로 매끄러운 실행보다 훨씬 더 나쁜 결과입니다. 하지만 바로 이 점 때문에 경계(boundary)를 동일한 세션 내에서 가르쳐야 합니다.
• 첫 번째 상호작용에서 복구 기능(recovery affordances)을 보여주세요. 사용자는 기능이 필요해지기 전에 재생성(regenerate) 컨트롤, 편집(edit) 컨트롤, 실행 취소(undo) 컨트롤을 미리 보아야 합니다. 잘못된 결과물이 나온 순간에 그것이 복구 가능하다는 사실을 발견하는 것은, 미리 알고 있는 것보다 훨씬 효과가 떨어집니다.
• 차단(gate)하지 마세요. 텍스트 박스 앞을 가로막는 차단형 투어(blocking tour)는 그것이 가장 필요한 사람들에 의해 건너뛰어지며, 누구에게도 기억되지 않습니다. 가르칠 가치가 있는 모든 것은 사용 시점의 인터페이스를 통해 가르칠 수 있습니다.

투어 없이 경계(boundary)를 가르치기

경계(boundary)야말로 온보딩(onboarding)이 진정으로 지향해야 할 목표입니다. 하지만 경계는 한계점의 목록으로 전달될 수 없습니다. 왜냐하면 아무도 그것을 읽지 않고, 아무도 기억하지 않기 때문입니다. 세션이 아닌 사용 시점에 밀착되어 작동하기 때문에 효과적인 세 가지 기술은 다음과 같습니다:

제품이 사용자의 차례를 맞이하기 전에 발생하는 온보딩 단계도 있습니다: 바로 마케팅 문구 (marketing copy)입니다. 만약 랜딩 페이지가 모든 것을 처리하는 어시스턴트를 약속했다면, 첫 실행 경험 (first-run experience)은 기대치를 설정하는 것이 아니라, 기대치를 복구하는 과정이 됩니다. 그리고 당신이 이 두 가지 작업 중 어떤 것을 수행하고 있는지 아는 것은 매우 가치 있는 일입니다.

첫 번째 실패는 온보딩의 일부입니다

누군가가 AI 기능을 계속 사용할지 여부를 결정하는 순간은 첫 번째 성공의 순간이 아닙니다. 그것은 첫 번째 실패의 순간이며, 거의 아무도 이를 설계하지 않습니다. 왜냐하면 실패는 디자인적 주의가 집중된 온보딩 흐름 (onboarding flow) 내부에서 발생하지 않기 때문입니다.

이를 계측(Instrument)하십시오: 사용자당 발생하는 첫 번째 부정적인 결과 — 다시 생성 (regenerate), 폐기 (discard), 중단된 세션 (abandoned session), 명시적인 비추천 (explicit thumbs-down) — 를 찾아내고, 해당 이벤트를 온보딩의 마지막 단계로 취급하십시오. 그 시점에서 인터페이스가 무엇을 하는지는 첫 화면에서의 그 무엇보다 중요합니다. 구체적으로, 그 순간 사용자는 복구 경로 (recovery path)가 명확해야 하며, 변명처럼 들리지 않는 발생 상황에 대한 해석, 그리고 대신 시도해 볼 수 있는 구체적인 무언가가 필요합니다. 이 세 가지가 모두 존재한다면, 실패는 신뢰를 조정(calibrate)합니다. 만약 이 중 어느 것도 없다면, 관계는 종료되며, 아무리 첫 실행 경험을 다듬더라도 이를 회복할 수 없습니다.

이것의 한 가지 버전은 의도적으로 실행해 볼 가치가 있지만, 어느 정도의 배짱이 필요합니다. 즉, 첫 실행 시 기능이 불완전하게 처리하는 무언가를 포함시키고, 그 불완전함을 잘 다루는 것입니다. 80% 정도만 정확한 출력을 보고, 인터페이스가 어느 부분이 불확실한지 인정하는 것을 확인하며, 두 번의 클릭으로 이를 수정하는 사용자는 단 한 번의 상호작용만으로 해당 기능의 실제 작동 모델 (operating model)을 학습하게 됩니다. 반면, 결점 없는 세 번의 출력을 보는 사용자는 나중에 인터페이스조차 없는 더 좋지 않은 상황에서 거짓으로 판명될 모델을 학습하게 됩니다.

동일한 논리가 온보딩 (onboarding)의 길이에도 적용됩니다. 이 페이지의 모든 내용은 온보딩을 더 늘리는 것이 아니라 줄여야 한다고 주장합니다. 즉, 설명을 줄이고, 화면 수를 줄이며, 투어 (tour)를 없애고, 사용 시점에 맞춰 제한 사항을 부착하되 이를 별도의 레슨 (lesson)으로 모아두지 않는 것입니다. 사라진 내용을 대체하는 것은 일상적인 작동 중에 인터페이스 자체가 정직해지는 것입니다. 이것이 이 클러스터 (cluster)의 핵심이며, 온보딩이 이 중 가장 짧은 페이지 중 하나인 이유입니다. 만약 제품이 사용 가능하기 위해 투어가 필요하다면, 그 투어는 무언가를 보완하고 있는 것이며, 그 '무언가'가 바로 해결해야 할 과제입니다.

관련 항목 (Related)

• 기대치 설정하기: 사용자에게 AI가 할 수 없는 것을 알려주기
• 프롬프트 제안과 빈 캔버스 문제 (Prompt Suggestions and the Blank Canvas Problem)
• 확률적 출력 (Probabilistic Output)을 위한 설계