결국 시스템/서비스의 성패를 가르는 것은 사용자다.
아무리 사무실에서 좋은 전략을 수립하고, 좋은 기획을 만들어도,
사용자가 불편하고 굳이?라는 감정을 느낀다면
비즈니스가 성공할 수가 없기 때문이다
아래는 조사를 통해, 분류한 사용자 분석 방법론들이다
사용자 데이터를 충분히 수집할 수 있는 채널을 만들어두었다면,
연역적-정량적인 방법이 베스트가 될 수 있을 것이다.
연역적 | 귀납적 | |
정성적 | 페르소나 페르소나 스펙트럼 |
컨텍스츄얼 인쿼리 쉐도잉 |
정량적 | 사용자 트래킹 GA(구글 애널리틱스) 기타 데이터기반 분석방법 |
AB 테스트 |
하지만 대다수의 경우, 그렇지 못한 경우가 대부분일 것이고,
그럴 때에는 다른 전통적 사용자 조사/분석 방법을 활용해야 한다.
심지어, 사용자 데이터 수집 채널을 만들어두었다 할지라도,
- 채널 자체에 대한 지나친 과신,
- 잘못된 데이터 분석,
- 데이터가 알려주지 않는 비즈니스 또는 경쟁자 환경 변화
등에는 연역적-정량적 방법만으로 대응할 수 없다.
따라서, 사용자 분석에 있어서는 온고지신의 마음을 겸비하자는 게 내 경험에 의한 생각이다
정성적+연역적 : 페르소나 / 페르소나 스펙트럼
페르소나는 왜 중요한가?
앞서, 타겟 고객을 설정했다고 하더라도,
기획 과정 및 개발 중 의사결정과정에서, 일관성을 잃기 십상이다.
예컨데, 정비사에게 설명용 비디오를 개발한다고 하자.
정비하기에도 시간이 모자란 정비사의 이해를 돕기 위함으로 개발 목적을 정한다.
하지만, 막상 개발과 QC 과정에서, 시간 단축을 위해 속도를 높여야 한다는 이야기가 나온다
그렇게 영상 개발사는, 개발 주관사의 말을 반영한다
이런 일이 반복되면 영상 재생 속도가 빠른 게 Default가 되며
결국 내용을 모르는 정비사들은 이해하기 어려운 빠르기만한 결과물이 나온다
이런 의사결정의 오류는 개발사, QC담당자 뿐 아니라
심지어 최초 기획자로부터 나오기도 한다.
전체 개발 과정은, 기획에 소요되는 시간보다 훨씬 길기 때문에,
사전에 논의되었던 내용들은 금새 휘발되며 변질되기 때문이다
따라서, 페르소나를 써내려가는 것은, 개발/운영팀이 시간이 지나더라도
일관성을 잃지 않기 위함이 가장 크다.
페르소나는 가상의 타겟 고객을 설정하는 것으로 시작한다
막연하게 머릿속 이미지로만 갖고 있던 고객을 구체화시킴으로서,
어떤 방향으로 디자인/개발을 해나갈지를 결정하는 데 활용하면 된다
인터넷에 검색해보면, 여러가지 페르소나 샘플들이 나오긴 하나
너무 복잡하게 많이 적는 것도, 너무 단순하게 적는 것도 아닌 듯 싶다.
의사결정에 영향을 미칠 수 있는 팩터만 남기는 게 좋다고 생각한다
- 인생에서(서비스/업무 등) 중요하게 생각하는 가치
- 갖고 있는 기술
- (서비스/시스템)을 사용할 때의 감정
- (서비스/시스템)을 이용하는 목적
- 사회&문화적 배경
- 경험/구체적 보유 지식 / 시스템에 대한 능숙도 등
- 인구통계학적 분석 (연령/성별 등)
- 한 줄의 핵심 설명 문구
개인적으로 사진/이름 등의 이력서에나 쓸 법한 디테일성은 불필요하다고 본다
페르소나에 대한 전문적 글이 있어 참고하면 좋을 거 같다.
마이크로소프트 Inclusive Design 팀은 페르소나 기법의 문제점을 찾아낸다.
이 방법은 '특정 가상 인물 한 명'만을 목표로 하는 프로젝트를 디자인/개발하는 데 기여한다는 것이다
실제, 비즈니스는 보다 범용적인 솔루션을 목표로 할 뿐 아니라,
페르소나 관점의 개발은 생각치도 못한 용처를 일반 사용자들이 찾을 수 있는 가능성을 낮춘다.
따라서, 이를 해결하고자 MS는 페르소나 스펙트럼이라는 대안을 제시한다
이는 다양한 사용자 요구와 상황을 반영할 수 있는 보다 포용적인 디자인을 목표로 한다
가령, 페르소나가 구체적인 '한 인물'의 캐릭터를 설명한다면
페르소나 스펙트럼은, 서비스/시스템을 사용할 수 있는 '인물들'의 '상황들'을 정리한다
예컨데, 주식정보를 제공하는 웹사이트를 개발한다고 가정하자.
이 웹사이트를 접속하는 상황이란,
- 주식 초보들이 그들이 이해 가능한 빠른 정보를 스캔하기 위해서
- 고수들이 구체적인 재무제표와 시장 상황을 확인하기 위해서
- 트레이더들이 실시간 데이터를 확인하고, 나아가 데이터 분석을 하기 위해서
등 여러가지 목적이 겹칠 수 있을 것이다
정성적+귀납적 : 컨텍스츄얼 인쿼리 / 쉐도잉
컨텍스츄얼 인쿼리와 쉐도잉은 실제 사용자 테스트를 기반으로 하는 기법들이다
컨텍스츄얼 인쿼리는 시스템/서비스를 실험자가 직접 테스트를 한다
테스트 목적에 따라 테스트 시나리오를 줄 수도 있으며, 미션을 줄 수도 있다
그리고, 사용자 분석가가 실시간으로 중간중간 필요한 질의를 건내며 사용자의 모습을 관찰한다
쉐도잉은 반대로 사용자 분석가가 테스터와 분리된 상태에서 진행되는 것으로
절대 테스터의 집중과 자유에 방해하지 않는 방식이다
진짜 사용자의 행태를 관찰할 수 있기 때문에,
어떤 방법보다 실용적이고 직접적인 피드백을 얻을 수 있다.
예컨데, 변한다는 의미를 전달하기 위해 화살표 이미지를 넣은 적이 있다
그런데, 테스터가 '변해라'라는 의미로 화살표를 누르는 것이었다
화살표에 디자인적 기능 외에 어떤 기능도 없었기 때문에 당연히 아무일도 일어나지 않았고
테스터는 약간 혼란에 빠지는 모습을 보았다
테스트 이후, 나는 화살표에 기능을 추가했다
사실, 테스트보다 테스트 관찰과 분석이 더 핵심 활동이다.
방금 전의 예시에서도,
어떤 테스터는 이것에 대해 직접적으로 코멘트를 남기는 한편,
어떤 테스터는 사소한 실수라고 여기고 다음 것을 진행한다
만약, 어떤 테스터도 코멘트를 남기지 않았다면, 잠재된 UIUX불편을 알아낼 수 있는건
같이 화면을 보고 있던 관찰자 뿐이다.
테스터가 사소하다고 생각하거나 묵인하는 개선점까지 잡아내야한다.
나는 가끔 '거짓말을 하는 사람들의 특징', '행동 심리학'등 관련된 유튜브 영상을 찾아보는데,
확실히 테스터의 행동과 말을 분석하는 데 도움이 된다
정량적+연역적 : 사용자트래킹/GA/뷰저블
이 방식은 사용자 행태를 수집할 수 있는 채널을 충분히 확보했다는 가정하에만 유의미하겠다
즉, 시스템/서비스가 이미 런칭된 상태여야, 이 방법을 사용할 수 있다는 이야기이기도 하다.
개인적으로 GAIQ를 알고 싶어서 Certification은 받아두긴 했지만,
다른 수학할 것이 많아 블로그에 적용해보는 것은 뒤로 계속 미뤄두고 있는 중이다.
회사 프로젝트에서도 뷰저블을 적용할지 최근 고민 중이다.
뷰저블 홈페이지 링크는 아래와 같다. 한 번 참고해보면 좋을 거 같다
정량적+귀납적 : AB 테스트
역시 서비스 중인 상태에서 쓰이는 테스트이다
이 테스트 역시, 어떤 안이 최적안인지 도출하기 위해서,
사용자 데이터 수집에 대한 파이프라인을 기 구축해야하므로
이미 개발 완료된 상태에서만 가능하다
아래는 토스 UIUX 디자이너가 AB테스트에 대해 본인의 경험을 풀어 쓴 내용이다
'기획 > PM&PO' 카테고리의 다른 글
XXX 기획 : 분석 이후 그리고 기획 8 (5) | 2024.09.30 |
---|---|
XXX 기획 : 비즈니스&사용자 고려한 기획 7 (0) | 2024.09.30 |
XXX 기획 : 비즈니스 해석 5 (2) | 2024.09.28 |
XXX 기획 : Product Manager가 되자 4 (1) | 2024.09.28 |
XXX 기획 : 내가 생각하는 좋은 기획자의 조건 3 (1) | 2024.09.25 |