역할극 아이디어 발상법(role-play ideation)

Role-play Ideation이란?

Role-play ideation은 UX 리서치와 디자인 씽킹에서 사용되는 아이데이션 방법론으로, 참여자들이 특정 역할을 맡아 실제 시나리오를 연기하면서 사용자 경험을 시뮬레이션하는 기법이다. 주로 서비스나 제품 아이디어를 설명하기 위해 공동 디자인 세션에서 사용된다.

주요 특징 및 장점

Role-play는 서로 다른 이해관계자 역할을 하면서 브레인스토밍을 하는 접근법이다. 다양한 시나리오에서 대안적 솔루션을 탐색하도록 장려하여 창의성을 자극하고, 참여자들이 비판에 대한 두려움 없이 자유롭게 행동할 수 있어 더 진정성 있고 자유로운 피드백을 얻을 수 있습니다. 다른 아이데이션 방법에 비해 더 많은 시나리오를 생성하고, 더 풍부하고 상세한 인사이트를 제공한다. 활용 사례: 사용자 온보딩 프로세스 검증, 서비스 청사진 작성, 접근성 시나리오 테스트, 초기 단계 아이데이션, 공감 워크숍

• 팀 간 협업 및 커뮤니케이션 향상(토론이 촉진)
• 실제적이고 자연스러운 인사이트 도출
• 사용자 관점에서의 공감(empathy) 형성
• 숨겨진 pain point 발견

실행 가이드

1. 정의(Definition) : 목표를 정의하고, 탐색할 시나리오 유형을 선택하며, 참여자가 맡을 역할을 명확히 합니다
   
   1. 전형적인 사용자 플로우부터 엣지 케이스까지 다양한 시나리오 설정
   2. 배경 스토리와 동기를 포함한 페르소나 준비
2. 워밍업(Warm-up) : 참여자들이 활동에 익숙해지도록 돕습니다
   1. 간단한 아이스브레이킹 활동
   2. 역할에 대한 이해도 점검
3. 역할극 실행(Playing) : 팀원 간 다양한 역할을 정의합니다. 일부 참여자는 사용자 역할을, 다른 이들은 시스템 측을, 또 다른 이들은 관찰자 역할을 합니다
   1. 사용자의 예상 행동대로 역할극 시작
   2. 각 선택이나 시나리오는 명확한 아이디어를 위해 분리
   3. 역할 돌리기 : 다른 역할을 돌아가면서 할 수 있도록 재할당
   4. 컨셉 돌리기 : 맡은 역할의 특성에 따라 종이 위에 아이디어를 스케치 하고 그것을 다음 사람에게 전달해서 그가 맡은 역할에 기반한 아이디어를 추가/수정
4. 마무리(Finalization)
   1. 역할극 종료 후 정리 시간
   2. 발견된 내용 기록
5. 평가(Evaluation) : 관찰된 발견 사항을 탐색하고 팀 참여자들과 논의합니다. 필요한 경우 다른 시나리오와 세부 사항으로 프로세스를 반복할 수 있습니다
   1. 내가 A라는 역할을 해본 결과, A는 이런 저런 기능을 원할 것이다 라고 생각했다. 하지만 다른 사람들이 A라는 역할을 했을 때 내가 생각했던 기능이 필요없다고 느낄 수 있다. 그러니 A라 역할을 서로 몰입해 봤을 때 어떤 기능들이 필요/불필요한지 논의하는 과정은 필수다. 예: 

[초기 기획 방향]
콘텐츠 심사 시, 디자인 심사와 텍스트 심사 담당자가 구분될 가능성을 고려했습니다. 이에 따라 심사 대상별로 필터링 기능을 구현하고, 이를 위해 대상별 상태(Status) 관리가 필요하다고 생각했습니다.

[문제 및 현황]
하지만 이는 운영 환경에 대한 확인 없이 진행된 가정이었습니다. 실제 운영자에게 심사 담당자가 구분될 가능성을 사전에 확인했더라면, 복잡한 필터링/상태 관리 기능을 기획할 필요가 없었을 것입니다.

[개선 방안]
향후 기능 기획 전에는 운영 프로세스 및 운영 주체의 역할 분담에 대해 운영 담당자에게 필수적으로 사전 확인하는 단계를 추가하겠습니다.

주의사항

Role-play는 시간 소모적이며 브레인스토밍과 역할극 자체에 더 많은 시간이 필요합니다. 또한 일부 참여자들은 역할극에 불편함을 느낄 수 있어 그들의 성과에 영향을 줄 수 있다.

---

구슬 마법사의 착각

완벽한 기획이라는 환상

라무는 퇴근길 내내 샘의 말을 되씹었다.

"구슬 안에 몇 명이 유인되었는지만 나와있는데..."

그 말이 뇌리에 박혔다. 마법기획자로 일한 지 3년, 처음으로 자신의 기획서가 회의에서 공개적으로 지적받은 날이었다. 라무는 집에 도착해서도 저녁을 먹지 못하고 작업실로 들어갔다. 구슬 마법의 주문서를 펼치고, 매출 연동 마법을 추가하기 시작했다.

하지만 이상했다. 가게 주인들의 매출 장부와 연결하는 주문을 짜면 짤수록, 마법의 마나 소비량이 급격히 늘어났다. 애초에 라무가 구슬 마법을 '저렴한 가격'으로 설계한 이유는 작은 가게 주인들도 부담 없이 쓸 수 있게 하기 위함이었다. 그런데 매출 추적 기능을 넣으니 가격을 두 배로 올려야 했다.

역할극의 함정

"역할극을 했어야 했는데."

라무는 중얼거리며 펜을 내려놓았다. 샘의 지적이 옳았다. 기획 단계에서 가게 주인 입장이 되어봤다면 매출 데이터의 필요성을 알았을 것이다. 하지만...

라무는 문득 생각했다. 정말 그랬을까?

다음 날 아침, 라무는 실제로 구슬 마법을 구매한 가게 주인들을 찾아갔다. 세 곳을 돌았다. 신기하게도, 세 명 모두 같은 말을 했다.

"매출이요? 그건 제 장부 보면 되는데요. 이 구슬은 간단해서 좋아요. 아침에 출근하면서 확인하고, '오늘은 사람들이 많이 지나가는구나' 싶으면 기분이 좋아지거든요."

기획자의 기획

저녁 회의에서 라무는 샘에게 말했다.

"매출 연동 기능을 넣으면 가격이 두 배가 됩니다. 그리고... 제가 가게 주인 세 분과 이야기해봤는데, 다들 지금 구슬에 만족하고 있어요."
샘이 눈살을 찌푸렸다. "하지만 더 나은 기능이잖아요."

"더 나은 기능이 항상 더 나은 제품을 만드는 건 아닌 것 같아요." 라무가 천천히 말했다. "역할극을 했어야 한다고 자책했는데, 알고 보니 저는 이미 역할극을 하고 있었어요. 진짜 가게 주인이 아니라, 제 머릿속에 있는 '완벽한 가게 주인'의 역할을요."

회의실이 조용해졌다.

"실제 사용자들은 간단함을 원했어요. 아침에 출근하면서 숫자 하나 보고 기분 좋아하는 거. 그게 전부였어요. 매출은 이미 장부로 보고 있고요."

라무가 배운 것

라무는 그날 밤 기획 일지에 적었다.

'역할극의 위험: 사용자가 되는 게 아니라, 내가 상상한 사용자가 되는 것. 진짜 역할극은 상상이 아니라 관찰에서 시작한다.'

구슬 마법은 수정 없이 계속 판매되었다. 그리고 3개월 후, 라무는 또 다른 구슬 마법을 출시했다. 이번에는 고급 버전이었다. 매출, 재방문율, 시간대별 분석까지 모두 들어간 프리미엄 구슬.

가격은 세 배였지만, 체인점을 운영하는 대형 가게 주인들에게 불티나게 팔렸다. 그들에게는 정말로 필요한 기능이었으니까.

라무는 배웠다. 완벽한 기획이란 모든 기능을 넣는 게 아니라, 맞는 사람에게 맞는 기능을 주는 것이라고. 그리고 그걸 알기 위해서는 상상 속 역할극이 아니라, 진짜 사람들의 목소리가 필요하다는 것을.