사용자가 말하지 않는 불편에 관심을 기울이기 시작했습니다

AI 요약

버튼이 작동하고 자동화가 실행되며 데이터가 제자리에 도착해도 제품 사용 경험이 매끄럽다는 뜻은 아닙니다. 만든 사람은 다음 단계를 알고 필드의 의미도 이해하지만, 처음 온 사용자는 그런 맥락이 없습니다. 설정 안내가 말은 되지만 한 단계가 불분명하거나, 가입 뒤 무엇을 해야 할지 모르거나, 기능이 작동하는 이유를 이해하지 못하는 문제는 버그로 드러나지 않을 수 있습니다.

첫 사용 과정 살펴보기

글쓴이는 기능이나 자동화를 더하는 대신 사용자가 처음 몇 분 동안 겪는 경험에 더 신경 쓰기 시작했습니다. 직접 사용자의 행동을 관찰하면 명시적인 피드백을 기다릴 때 놓치는 혼란을 발견할 수 있습니다.

댓글에서는 팀 밖의 사람에게 제품을 시험하게 하고, 사용자가 설정하는 동안 생각을 소리 내어 말하게 하는 방법을 제안합니다. 가입 절차를 단계별로 기록하면 어느 지점에서 사용자가 멈추는지 확인할 수 있습니다. 한 팀은 가입자 49명 가운데 33명이 첫 단계인 브라우저 확장 프로그램 설치를 하지 않았다는 사실을 온보딩 이메일을 켠 뒤 알아냈습니다. 아무도 문제를 직접 알리지는 않았습니다.

사용자의 망설임이나 되돌아가기는 문제의 위치를 알려주지만 이유까지 설명하지는 않습니다. 관찰로 질문거리를 찾고, 사용자가 부담 없이 답할 수 있는 방법을 마련하면 행동 데이터와 직접 피드백을 함께 활용할 수 있습니다. 제출 실패 기록도 단서가 됩니다. 입력값 자체를 저장하지 않고 실패한 필드와 규칙을 기록하면 사용자가 어디에서 거부당하고 수정하거나 이탈하는지 파악할 수 있습니다.

Indie Hackers 반응

• @Sanjeev617 — 서로 다른 사용자에게 블라인드 테스트를 합니다. 팀 안에서도 다른 부서 사람들에게 부탁하고, 때로는 고객에게 참여를 요청합니다. 실제 사용자의 솔직한 피드백과 견줄 만한 것은 없습니다.
• @wenyueyue — ‘버튼이 작동한다’는 말은 클릭한 다음에 무슨 일이 생기는지도 생각하게 합니다. 사용성 테스트에 느린 응답과 빈 결과를 한 번씩 넣고, 사용자가 무슨 일이 일어났다고 생각하는지 물어보겠습니다. 작업이 끝났다고 아는지, 실패했다고 생각하는지, 다시 클릭하는지 확인해야 합니다. 백엔드가 제대로 작동해도 정상 경로만 테스트하면 이런 불확실성을 놓칠 수 있습니다.
• @serverdrop — 비용이 적게 드는 방법 하나는 새 사용자가 가치를 얻기 전에 꼭 이해해야 하는 내용을 한 문장으로 적는 것입니다. 그런 다음 첫 화면이 끝날 때까지 한 사람이 그 내용을 이해하는지 지켜보세요. 이해하지 못한다면 그다음 단계는 아직 중요하지 않습니다. 사용자가 떠난 지점뿐 아니라 떠나기 직전에 한 행동도 살펴보세요. 멈추거나 이전 화면으로 돌아가거나 같은 메뉴를 두 번 여는 행동은 의미를 모르겠다는 신호일 때가 많습니다. 버그가 아니라서 버그 신고에는 잘 나타나지 않습니다.
• @chely — 피드백을 기다리는 것보다 첫 세션에서 사용자가 망설이는 모습을 지켜보며 더 많은 것을 얻었습니다. 문제는 대개 버그가 아니었습니다. 비교할 대상이 없어서 사용자가 좋은 결과가 무엇인지 몰랐습니다.
• @elijahbrown — 비용이 적게 드는 정보원으로 검증 오류 기록도 있습니다. 제출이 거부될 때 값 자체가 아니라 실패한 필드와 적용된 규칙을 기록하면, 사용자가 시도했다가 거부당한 뒤 수정했는지 떠났는지 확인할 수 있습니다. 공백을 허용하지 않는 전화번호 필드나 이해하기 어려운 필수 항목은 며칠 안에 드러나지만, 사용자가 이메일을 보내 알려주는 경우는 없습니다.
• @Youssef_Bezza — 온보딩 이메일을 켰을 때 가입자 49명 중 33명이 첫 단계인 확장 프로그램 설치를 하지 않았다는 사실을 알았습니다. 누구도 문제를 말해주지 않고 그냥 사라졌습니다. 설정 단계를 각각 추적하고, 한 사람에게 설정을 하며 망설이는 지점을 말해달라고 부탁하는 방법이 도움이 됐습니다. 테스트 참가자는 “실제 계정을 연결할 만큼 믿어도 될까요?”라고 말했습니다. 분석 데이터만으로는 그 말을 들을 수 없었을 겁니다.
  • @Eva — 33명 중 49명이라는 숫자가 많은 것을 말해주네요. 아무도 문제를 알리지 않고 그냥 멈췄다는 점이 눈에 들어왔습니다. 제 경우에는 첫 설정 단계에서 사용자가 조용히 이탈할 것 같습니다. 제가 만든 흐름을 너무 잘 알아서 처음 보는 사람에게도 당연한 단계라고 생각할 수 있습니다. 소리 내어 말하게 하는 테스트도 좋네요. 분석에만 기대지 말고 더 해봐야겠습니다.
  • @Youssef_Bezza — 원하시면 제가 “소리 내어 말하는” 테스터가 되어드리겠습니다. 설정 과정을 따라가며 망설이는 부분을 적겠습니다. 괜찮다면 서로 FollowToDM도 살펴봐 주세요. 첫 단계를 새로운 눈으로 보는 것이 우리 둘에게 필요합니다.
• @plugiva — 사용자는 불편을 늘 직접 알리지는 않습니다. 우회하거나 망설이거나 떠날 수 있습니다. 관찰할 수 있는 것을 개선할 수 있다고 생각하지만, 관찰만으로 사용자가 겪은 일을 항상 알 수 있는 것은 아닙니다. 막히는 지점을 보면 문제가 어디 있는지 알 수 있고, 부담이 적은 응답 방법을 마련하면 이유를 이해하는 데 도움이 됩니다. 두 방법은 서로 보완하며 대체 관계가 아닙니다. 피드백 요청은 처음 제품을 쓰는 모습을 관찰하는 일을 대신할 수 없고, 관찰만으로 무엇이 혼란스러웠는지 항상 알 수는 없습니다. 제품을 쓰는 모습을 지켜볼 때 사용자가 실제로 말하는 내용과 다른 문제도 발견하시나요?
  • @Eva — 네, 확실히 다릅니다. 누군가 어려워하는 모습을 봤지만 나중에는 모든 것이 괜찮았다고 말하는 경우가 있습니다. 같은 단계에서 몇 초 멈추거나 이전 화면으로 돌아가는 모습이 보이기도 합니다. 피드백에만 의지하지 말아야겠다는 점을 다시 생각하게 됐습니다. 제품 사용 모습을 더 자주 지켜봐야겠습니다.
  • @plugiva — 두 방법은 경쟁 관계가 아니라 보완 관계라고 생각합니다. 멈춤이나 되돌아가기는 살펴볼 만한 신호지만, 사용자가 혼란스러웠는지 다른 일에 정신이 팔렸는지 확인 중이었는지 생각하고 있었는지까지 알려주지는 않습니다. 반대로 사용자는 괜찮았다고 말해도 행동에서는 반복되는 망설임이 보일 수 있습니다. 관찰은 질문을 찾는 방법이지, 질문을 대신하지는 않습니다. 먼저 ‘여기서 무언가 일어났다’는 점을 알아차리고, 사용자에게 부담이 적은 방식으로 실제 이유를 물을 수 있습니다. 분석이나 피드백 하나에만 기대는 것보다 두 방법을 함께 쓰는 편이 유용합니다.

원문: Indie Hackers / 번역·요약: Trawling