퍼소나라는 말은 기획 문서에서 자주 만나지만, 실제로는 상상으로 만든 인물인 경우가 많았습니다.
"30대 직장인 김 모 씨, 취미는 여행" 같은 카드를 만들어 놓고 나면 그 뒤로는 아무도 펼쳐 보지 않기도 해요.
저는 이 카드를 데이터에서 출발해서 만들면 팀이 더 잘 쓸 수 있지 않을까 생각했습니다.
오늘은 세그먼트에서 퍼소나로 가는 흐름을 제 방식대로 정리해 볼게요.
퍼소나의 목적은 팀이 같은 사람을 떠올리며 이야기하게 하는 것입니다.
"사용자는 이걸 좋아할 거예요"라고 할 때, 사람마다 머릿속의 사용자가 다르면 논쟁이 끝나지 않아요.
퍼소나가 있으면 "이 사람이라면 이 화면에서 무엇을 할까"라고 물을 수 있습니다.
그러면 의견이 취향 싸움이 아니라 근거 있는 토론으로 바뀝니다.
다만 퍼소나가 실제 사용자와 동떨어져 있으면 오히려 오해를 키워요.
그래서 데이터를 바탕으로 하자는 생각이 나왔습니다.
1단계, 세그먼트부터 나눈다
퍼소나보다 먼저 필요한 것이 세그먼트, 즉 사용자 묶음입니다.
이미 가지고 있는 데이터에서 나눌 기준을 찾아봐요.
흔히 쓰는 기준은 이런 것들입니다.
어떻게 들어왔는가, 얼마나 자주 오는가, 어떤 기능을 쓰는가, 무엇을 샀는가.
나이나 성별 같은 인구 통계 정보도 쓸 수 있지만, 저는 행동 기준이 더 쓸모 있다고 느꼈어요.
같은 30대여도 행동이 전혀 다른 경우가 많기 때문입니다.
가상의 요리 레시피 서비스를 예로 들어 보겠습니다.
방문 빈도와 사용 기능으로 나누면 이런 묶음이 나올 수 있어요.
첫째는 주말마다 와서 새 레시피를 저장만 하는 사람들입니다.
둘째는 평일 저녁에 와서 저장한 레시피를 바로 따라 하는 사람들입니다.
셋째는 한 번 와서 검색만 하고 나가는 사람들입니다.
이 예시의 묶음과 비율은 모두 가정입니다.
2단계, 묶음마다 숫자 몇 개를 붙인다
나눈 묶음마다 크기와 특징을 숫자로 붙여 봅니다.
전체 사용자 중 비중, 평균 사용 시간, 주로 들어오는 경로, 전환 여부 정도면 충분해요.
이때 중요한 것은 묶음의 크기와 가치를 같이 보는 것입니다.
사람 수가 많은 묶음이 사업에 중요한 묶음이라는 법은 없습니다.
작더라도 구매나 추천을 많이 하는 묶음이 있을 수 있어요.
숫자를 붙이다 보면 묶음이 너무 많아져서 퍼소나가 열 개가 되기도 합니다.
저는 팀이 기억할 수 있는 세 개에서 다섯 개 정도로 줄이는 것이 좋다고 느꼈어요.
줄일 때는 비슷한 묶음을 합치되, 서비스에서 해 줘야 할 일이 다르면 합치지 않습니다.
위의 요리 서비스 예시에서 저장만 하는 사람과 바로 따라 하는 사람은 필요한 기능이 다릅니다.
전자는 보관함 정리가 중요하고, 후자는 조리 중에 화면을 넘기기 쉬운 구성이 중요할 거예요.
이처럼 필요한 도움이 다른지를 기준으로 묶으면 퍼소나가 실제 설계에 도움이 됩니다.
3단계, 정성으로 이야기를 입힌다
숫자만으로는 사람이 그려지지 않습니다.
이 단계에서 인터뷰나 설문, 고객 문의 같은 정성 자료로 이야기를 더해요.
위의 예시에서 저장만 하는 사람들에 대해 몇 분과 이야기를 나눠 본다고 가정해 봅시다.
"만들 시간은 없지만 저장해 두면 마음이 편해서요" 같은 이유가 나올 수 있어요.
이 대사는 가정이고, 실제로는 전혀 다른 이유가 나올 수도 있습니다.
어쨌든 이런 이유를 알게 되면 "저장만 한다"는 숫자가 한 사람의 이야기가 됩니다.
퍼소나 카드에는 이름과 사진보다 다음 항목을 넣는 것을 추천해요.
이 사람이 서비스에서 이루고 싶은 것.
이 사람이 자주 막히는 지점.
이 사람이 쓰는 상황과 기기.
근거가 된 데이터와 정성 자료의 출처.
마지막 항목이 특히 중요합니다.
근거가 적혀 있어야 나중에 업데이트할 때 무엇을 다시 확인할지 알 수 있어요.
퍼소나는 만드는 것보다 쓰는 것이 어렵습니다.
저는 회의 때 "이번 기능은 어떤 퍼소나를 위한 것인가"를 먼저 말하는 습관을 권하고 싶어요.
한 기능이 모든 퍼소나를 만족시키려고 하면 아무도 만족시키지 못합니다.
이번 분기에 집중할 퍼소나를 정해 두면 우선순위를 정할 때 도움이 많이 돼요.
그리고 반년에 한 번쯤은 데이터를 다시 보고 카드를 고쳐 줍니다.
서비스가 바뀌면 사용자도 바뀌기 때문이에요.
퍼소나를 만들 때 조심할 점도 하나 있습니다.
평균적인 사람을 그리다 보면 실제로는 존재하지 않는 사람이 만들어질 수 있어요.
그래서 저는 카드에 이 사람은 이 묶음의 대표 사례일 뿐이라는 점을 적어 둡니다.
또 한 사람의 취향을 지나치게 풍부하게 꾸미지 않도록 합니다.
근거 없는 디테일이 늘어날수록 팀은 그 디테일을 사실처럼 믿게 되거든요.
작은 팀이라면 이 과정을 며칠 안에 끝내는 가벼운 버전도 가능합니다.
이미 있는 데이터에서 묶음 세 개를 뽑고, 각 묶음에서 두세 명에게 짧게 이야기를 들은 뒤, 카드 한 장씩만 만들어 보는 거예요.
완벽한 카드가 아니어도 팀이 같은 사람을 떠올리기 시작하는 것만으로 충분히 가치가 있었습니다.
나중에 데이터가 더 쌓이면 그때 카드를 다듬으면 돼요.
데이터로 만든 퍼소나는 그럴듯한 이야기보다 덜 매끄럽지만, 팀이 믿고 기댈 수 있는 장점이 있다고 생각합니다.
다만 데이터는 이미 서비스를 쓰는 사람만 보여 준다는 한계가 분명해요.
그래서 남은 질문이 있습니다.
아직 서비스에 오지 않은 사람의 퍼소나는 어떻게 만들어야 할까요.
그리고 데이터가 적은 초기 서비스에서는 어디까지 추측하고 어디부터 확인해야 할까요.
이 부분은 작은 프로젝트에서 직접 시도해 보며 정리해 보려고 합니다.
'Archive > Collection' 카테고리의 다른 글
| 히트맵 도구 기반 개선 사례를 읽는 법 (0) | 2020.08.12 |
|---|---|
| 페이지 하단 콘텐츠의 스크롤과 클릭 지표 읽기 (0) | 2020.08.12 |
| 퍼널 분석, 어디부터 볼 것인가 (0) | 2020.08.12 |
| 유입 경로별로 사용자 행동 비교하기 (0) | 2020.08.12 |
| 스타트업에서 사용자와 사업 니즈를 함께 반영하는 디자인 (0) | 2020.08.12 |