첫 사용자 의견으로 다음 버전 정하는 법

첫 버전을 연 지 2주가 지난 스타트업 대표님이 메모를 잔뜩 들고 오셨어요. 사용자 열두 명에게 받은 의견이었어요. 「알림이 있었으면」, 「다크 모드도 되나요」, 「엑셀로 내려받고 싶어요」. 대표님은 이걸 전부 다음 버전에 넣고 싶어 하셨어요.

메모를 하나씩 같이 읽어 보니 재밌는 게 보였어요. 알림을 바란 분들도, 엑셀을 바란 분들도 사실 같은 걸 말하고 있었거든요. 「내가 맡긴 일이 끝났는지 확인하기가 번거롭다」는 거였어요.

사용자는 해결책을 말하지만, 만드는 사람이 들어야 하는 건 그 뒤에 있는 불편이에요.

핵심은 요청을 그대로 받아 적지 말고, 같은 불편끼리 묶어서 가장 많이 겹치는 것부터 고르는 거예요. 의견이 열 개여도 불편은 두세 개로 줄어드는 경우가 많아요. 그 두세 개가 다음 버전의 범위예요.

의견을 받을 때 물어볼 질문

「불편한 점 있으세요?」라고 물으면 대부분 「괜찮아요」라고 답해요. 대신 실제로 쓴 순간을 떠올리게 하는 질문이 좋아요.

• 마지막으로 이 서비스를 쓴 게 언제였고, 무엇을 하려고 했나요?
• 그때 중간에 멈추거나 다시 돌아간 곳이 있었나요?
• 이 서비스가 없었다면 그 일을 어떻게 했을 것 같나요?
• 다른 사람에게 소개한다면 뭐라고 설명하시겠어요?

마지막 질문이 특히 쓸모 있어요. 사용자가 설명하는 말 속에 우리 서비스가 진짜로 쓰이는 이유가 들어 있거든요. 그 말을 그대로 첫 화면 문구로 옮기기도 해요.

요청을 불편으로 바꿔 적기

의견을 모았다면 한 줄씩 「이 사람은 어떤 상황에서 무엇이 불편했나」로 바꿔 적어요. 그러면 서로 달라 보이던 요청이 하나로 모여요.

이렇게 적고 나면 「일이 끝났는지 알기 어렵다」는 불편이 여러 번 나온다는 게 보여요. 그렇다면 해결 방법은 꼭 알림이 아니어도 돼요. 첫 화면에 「완료된 일」 칸 하나를 두는 것만으로 풀릴 수도 있어요. 더 작게 만들 수 있는 길을 찾는 거예요.

다음 버전에 넣을 것 고르는 기준

불편을 묶었다면 아래 세 가지를 차례로 따져 봐요.

1. 몇 명이 같은 불편을 말했나. 한 명만 말한 건 일단 목록에 남겨 두고 지켜봐요.
2. 그 불편 때문에 사용을 그만두나. 불편해도 계속 쓰는 것과, 불편해서 떠나는 것은 무게가 달라요.
3. 가장 작은 해결책은 무엇인가. 새 화면 대신 문구나 순서만 바꿔서 풀리는지 먼저 봐요.

목소리가 큰 한 사람의 요청이 순서를 정하지 않게 하는 것도 중요해요. 열심히 의견을 주는 분은 고맙지만, 그분이 전체 사용자를 대표하지는 않을 수 있거든요.

정하지 않은 것도 알려 주세요

의견을 준 사용자에게는 결과를 짧게라도 알려 주는 게 좋아요. 「말씀하신 불편은 이렇게 바꿨어요」, 「이건 다음에 다시 볼게요」. 이 한마디가 있으면 다음에도 솔직한 의견을 줘요.

그리고 다음 버전도 첫 버전처럼 만들기 전에 범위와 화면 시안을 먼저 정해 두면 훨씬 빨리 열 수 있어요. 고른 불편 두세 개를 시안으로 그려서 의견을 준 분들께 먼저 보여 주는 것도 좋은 방법이에요.

자주 묻는 질문

사용자 의견은 몇 명에게 받으면 되나요?

첫 버전이라면 많을 필요가 없어요. 실제로 써 본 분 대여섯 명과 이야기만 해도 반복되는 불편이 보이기 시작해요. 같은 말이 계속 나오면 그때 멈춰도 돼요.

설문지로 받는 게 낫나요, 직접 묻는 게 낫나요?

처음에는 직접 묻는 게 훨씬 좋아요. 설문은 우리가 생각한 질문 안에서만 답이 나오거든요. 대화하다 보면 미처 몰랐던 사용 장면이 나와요.

요청을 거절하면 사용자가 떠나지 않을까요?

이유를 설명하면 대부분 이해해요. 오히려 다 넣겠다고 하고 늦어지는 쪽이 더 실망을 줘요. 지금은 어떤 불편부터 풀고 있는지 알려 주는 것만으로도 충분해요.