아티클 인사이트

오늘 아티클은 지난 번에 설계했던 UT를 생각하며, 토스 기술블로그에서 선정헀다. 가장 집중해서 읽었던 부부은 '우리가 설계했던 UT의 목적이 적절했는지'였다. 

 

휴리봇 이야기 #1: 토스는 AI 봇에게 사용자 인터뷰를 한다

https://toss.tech/article/research-platform-ai

휴리봇 이야기 #1: AI 제품을 실무에 적용하는 방법

 

제품을 만들다 보면 사용장게 궁금한 점이 많다.

🤔 ’사용자는 이 페이지를 어떻게 이해할까?’
🤔 ‘화면이 복잡해 보이진 않을까?’
🤔 ‘이 그래픽은 어떤 의미로 느껴질까?’

 

하지만 원할 때마다 사용자를 만나 궁금한 점을 묻기는 어렵다. → '휴리봇'을 통해 해결해보자!

 

1. <프롬프팅 전> 해결하고자 하는 문제 좁히기

프로젝트를 시작할 때 우선으로 해야 하는 일: 해결하고자 하는 문제와 목표를 뚜렷하게 정의

 

asis

'유저 무물데이'를 통해 원할 때면 언제든 사용자를 만나 온라인 UT를 진행할 수 있다. 프로세스가 잘 마련되어 있다. 

BUT UT를 진행하기 위해 UT용 프로토타입, 질문지를 준비 + 사용자를 만나는 심리적인 부담 

→ 작은 그래픽 하나, 한 문장, 작은 버튼의 사용성 확인을 위해 이런 준비 과정을 거치기에는 부담감 多

[UT 공통 질문]
❓이 화면이 어떻게 이해되는지 설명해 주세요
❓이 버튼을 누르면 다음 화면에 뭐가 나올 것 같으세요?

 

프로젝트 목표: 문제가 해결되었을 때 어떤 모습이길 기대하는지 (프로젝트를 통해 달성하고자 하는 이상적인 바 ❌)

→ 휴리봇의 목표: ‘디자이너가 가볍게 훨씬 자주 사용성을 점검하게 되는 것'

✅흥미로운 점
휴리봇의 목표를 '토스 유저와 비슷하게 대답하는 것'이 아니라, 사용자인 디자이너에게 제공될 가치로 설정한 것이 인상깊다. 결국 이걸 사용할 사람이 누구인지 명확하게 정의하고, 그 사람들에게 기대하는 모습을 정의하는 게 목표이다.

 

AI 제품을 만들기 위해서는 문제와 목표에 대한 공감대 형성이 매우 중요

휴리봇이 해결하려는 문제는 'UT의 확장' → 공감
BUT "반드시 AI가 필요하냐?" → 우려

 

AI가 할 수 있는 것과 없는 것을 구분 ❌ → AI를 '어떻게 활용할지'⭕가 더 중요

휴리봇의 역할 ≠ 사용자를 대상으로 하는 UT → 사용자의 사용성을 '검증' ❌ → '점검'⭕

 

2. <프로프팅 중> 초기 제품으로 가치 검증하기

• 효율적인 사용성 점검
• 제3자의 시각 제공

 

3. <프롬프팅 후> 워크플로에 넣기 위한 스펙아웃

MVP 제품을 만들기 위해 가장 먼저 했던 작업은 '기능 우선순위' 설정하기

→ 제품의 핵심 가치는 무엇이고, 이 가치를 전달하기 위한 최소한의 기능을 무엇일지 판단하는 과정: 어떤 기능이 꼭 필요한지, 필요하지 않은지를 정의

 

tobe

지금보다 훨씬 자주 가볍게 사용성을 점검하기 위해 새로운 UT 방식 도입

[MVP에 들어가야 하는 필수 기능]
(1) 화면 이미지를 넣고 (2) 질문하면 (3) 답변을 주는 기능

 

---

 

인사이트

 

  <MVP 프로젝트> UT를 직접 설계하면서 가장 많이 했던 고민이 “내가 지금 제대로 하고 있나?” 였다. 이 글을 읽으면서 그 고민에 대한 답을 조금 찾은 것 같다. 지금까지 나는 UT를 단순히 '과업을 제시하고, 사용자가 우리가 세운 가설대로 행동하는지'만 검증하는 데 집중했다. 그런데 돌이켜보면 그 전에 우리 스스로 서비스의 사용성을 먼저 ‘점검’하는 과정이 필요했다. 만약 사전에 AI를 활용해 사용성을 점검하고 부족한 부분을 보완한 뒤 실제 UT를 진행했다면, 훨씬 더 밀도 있는 검증이 가능했을 것이다. 다음 최종 프로젝트에서는 꼭 AI 기반 사전 점검 → 실제 UT를 통한 검증 의 흐름으로 진행해야겠다.

  그리고 실무 사례를 볼 때마다 항상 느끼지만, 결국 가장 중요한 건 목표와 문제 정의 인 것 같다. 특히 이번 글에서 인상 깊었던 건 휴리봇의 목표 설정 방식이었다. 나라면 아마 “토스 사용자와 유사한 답변을 도출하는 것” 을 목표로 설정했을 것 같다. 하지만 저자는 기능이나 결과물이 아니라, 이 서비스를 사용할 사람이 누구인지, 그리고 이 서비스를 통해 그 사람에게 어떤 변화를 기대하는지 를 먼저 정의했다. 결국 서비스의 목표에는 우리가 왜 이 서비스를 만드는지 가 담겨 있어야 한다는 것을 나는 그동안 기능 자체를 목표로 착각했던 것 같다. 앞으로는 프로젝트를 진행할 때 기능 중심이 아니라 “어떤 사용자에게, 어떤 가치를 전달할 것인가” 를 기준으로 목표를 정의해야겠다.

  그리고 여전히 가장 어렵게 느껴지는 부분은 MVP 설계다. 특히 항상 고민되는 건 “MVP에서 사용자의 편의성은 어디까지 고려해야 하는가?” 이다. MVP에서 불친절로 인한 불편을 겪은 사용자는 다시는 우리 서비스를 찾지 않을 것이라고 생각했기 때문에, 편의성을 배제한 MVP가 과연 맞는 방향인지 늘 의문이었다. 그런데 생각을 정리하다 보니 답이 명확해졌다. MVP의 목적은 사용자가 우리 서비스를 편하게 이용하도록 만드는 것 이 아니라, 우리가 만들고자 하는 '서비스의 핵심 가치에 사용자가 공감하는지 검증하는 것'이다. 그렇게 본다면 편의성을 높이는 부가 요소들은 MVP 단계에서 반드시 포함될 필요는 없다. 결국 MVP는 완성된 서비스를 만드는 과정이 아니라, 우리가 전달하려는 가치가 실제로 유효한지를 확인하는 과정이라는 점을 잊지 말아야겠다.

  헷갈리지 말자. 결국 서비스는 기능을 만드는 일이 아니라, 사용자에게 어떤 가치를 전달할 것인지 정의하고 검증하는 과정이다.

📌“지금 충분히 검증 가능한 방식으로 테스트하고 있는가?”
📌“내가 정의한 목표는 기능이 아니라 사용자 가치 중심인가?”
📌“지금 MVP에서 검증해야 하는 것은 편의성이 아니라 핵심 가치 아닌가?”