사용자 관점에서 생각해보기
사실 나는 제대로 된 기획 공부를 하지 못하고 덜컥 실무에 던져진 진짜 쪼렙 of 쪼렙이다보니, 다른 분들의 기획서나 프로젝트 진행을 통해 통해 기획 업무를 익혀 나갔다.
그러다보니 우리 회사에서 쓰지 않는 개념은 잘 모를 때가 있고, 서비스 기획 책에 등장하는 기본 용어들이 낯설 때도 있다 ㅠ_^;
계속 같은 회사를 다니는 것도 아니고(읭? 갑ㅈㅏ긔?)…
모자란 기획 공부를 지금이라도 보충하고자 하는 마음으로 기획의 기본을 좀 더 공부해야겠다는 생각이 들었다.
그래서 오늘 공부할 내용은 서비스를 기획할 때 더 사용자 중심적으로 생각하고, 사용자를 이해하기 위해 사용하는 유저 시나리오와 유저 스토리이다.
User Scenario(유저 시나리오)
개념
유저 시나리오란 사용자가 어떤 상황이나 환경에서 자신의 목표를 이루기 위해 어떻게 행동할 건지를 적어보는 것이다. 서비스 타겟을 정하면, 그 타겟의 페르소나를 정리하게 되는데 그 페르소가 서비스 관련 문제 상황에서 어떻게 행동할 것인지를 쭉- 적어보는 것이다.
나는 아래 예시를 보니 좀 이해가 됐다.
예시
“의료용품 회사의 시니어 매니저인 52세 Jeremy는 최적의 자원 사용/배분을 위해 사무실과 병원들을 오가며 구매 관련 문제에 대해 지속적으로 업데이트되는 정보가 필요하다. 그는 매우 숙련되고, 체계적이며 부지런한 사람이다. 그러나 최근 정리해고로 인해 그는 현재 업무량을 관리하는 데 어려움을 겪고 있으며, 커리어를 단순히 즐기기에는 너무 피곤하다. 그는 이슈를 최신 상태로 유지하며 공급망 문제를 조사하는 한편, 금융 환경에서 더 경제적일 대안을 모색하기 위해 애쓴다.
제레미는 앱처럼 편리한 것을 원하는데, 여기에는 주가 관련 정보 피드, 외국 공급업체에 대한 관세, 국내 병원의 예산 결정, 그가 취급하는 의료기기(대부분 폐 및 심혈관 제품)의 혁신 등이 포함되면 좋겠다. 그는 다른 세 명의 매니저와 회사 인트라넷을 통해 계속 연락하며 1시간 동안 업무 종료 보고서를 생성하는 대신, 필요한 모든 정보를 스마트폰에 안전하게 저장하고, 후배 직원들이 실시간으로 스크린샷을 전송하여 검토하고 조언할 수 있기를 바란다.”
“아! 타겟의 특성을 이해하고, 그 바탕으로 서비스에 어떤 것을 기대하고 어떻게 사용할 건지 써보는 게 유저 시나리오구나” 라고 이해했지만, 나같은 쪼렙이는 “그래서 뭘 써야 하는데?” 라고 또 의문이 든다^^;;ㅎ
유저 시나리오에는 아래 내용이 포함되면 더욱 더 디테일하고 풍부한 글이 된다고 한다.
1) Who (페르소나의 디테일)
: 의료용품 회사의 시니어 매니저인 52세의 Jeremy. 매우 숙련되고, 체계적이며 부지런한 사람
2) What 사용자가 이루고자 하는 게 무엇인지
: 주가 관련 정보 피드, 외국 공급업체에 대한 관세, 국내 병원의 예산 결정 등을 앱으로 편리하게 보는 것
3) When 사용자가 언제 task를 행할 것인지 (장애물 포함)
: 실시간으로 사용하고 공유하고자 함
4) Where 사용자가 어디서 이것을 할 건지 (장애물 포함)
: 사무실과 병원들을 이동하는 중에도 사용하고 싶어함
5) Why 왜 사용자가 이걸 해야 하고, 언제 subtask를 할 건지 등
: 혼자 알아보기에는 업무량이 과다하고, 이슈를 최신 상태로 유지하며 후배 직원들에게 업무를 조언하기 위해
장점과 유의사항
사용자의 관점에서 서비스가 필요한 이유, 언제 어디서 어떻게 쓸 건지 등을 생각하면 기획자와 디자이너는 사용자들의 Motivation, Needs, 그리고 Barriers 를 더 잘 이해할 수 있고 서비스에 녹여낼 수 있다.
그러나 작성 시 아래 내용들을 유의해야 한다.
– 큰그림을 봐야 하지만 문화적 특성, 정보 습득량의 차이처럼 서비스 사용에 영향을 미칠 포인트를 고려하기
– 기술적 배경이 없는 사람들도 이해할 수 있게끔 시나리오를 작성하기
– 유저 중심적으로 작성하기
이제 실제로 한 번 가상 서비스에 대해 유저 시나리오를 정리해보았다.
쪼렙 서비스 기획자의 적용 예시
- 서비스 – 스트레스 관리 어플
- 타겟 – 20대 중후반의 사회초년생
- 서비스 목적 – 20대의 사회초년생들이 일상에서 받은 스트레스를 기록하고 해소하는 데 도움을 주고자 함
“판교 IT 회사에 출근한 지 6개월 차인 신입 기획자 김지영씨는 요즘 정신없는 나날들을 보내고 있다. 회사와 집이 지하철로 1시간 거리라 일찍 일어나려고 노력하는데, 그래도 출근 시간에 딱 걸리면 지하철 속 사람들에 낑겨 힘겹게 회사에 도착한다.
아직은 회사 업무가 익숙지 않아 자신이 어떤 일을 도맡아야 팀에 도움이 될지 잘 모르겠다. 지금 맡은 업무도 나름대로 열심히 하고 있지만, 다른 팀원들에 비해 자신의 역량이 부족한 것 같아 고민이 된다. 옆팀 개발자랑 회의라도 하면 모르는 용어들이 많아 기가 죽어 하고 싶던 말도 못하게 된다.
저녁에 퇴근을 하면 고3 여동생이 온갖 짜증을 부리며 조용히 하라고 해서 평소 취미인 방에서 음악 크게 듣기도 못하고 있다. 인터넷 쇼핑이라도 좀 할라치면 엄마는 재테크는 하면서 돈 쓰는 거냐고 핀잔을 주니 집에서도 쉬는 것 같지가 않다.
통근길, 회사, 집에서 모두 작고 큰 스트레스를 받는데, 어떻게 풀어야 할지 모르겠다. 스트레스가 계속 쌓이니 몸도 마음도 무기력해지는 것 같다. 다른 사람들은 스트레스를 안 받는 건지, 아니면 스트레스를 잘 관리하는 건지 궁금하다. 친구에게 매일 털어놓기도 이제는 좀 미안하고 혼자 담아두고 있기엔 내가 너무 힘들다. 그렇다고 어디 상담을 가는 건 부담스럽거니와 귀찮다.
어떤 서비스에서 내가 스트레스 받을 때마다 바로 풀도록 도와주거나, 아니면 나와 비슷한 다른 사람들은 어떻게 스트레스를 푸는지 알려줬으면 좋겠다. 그리고 스트레스를 기록하고 해소하는 과정이 귀찮지 않고 가볍고 재밌으면 좋겠다.”
1) Who (페르소나의 디테일)
: 판교 IT 회사에 출근한 지 6개월차 신입. 통근길 & 집 & 회사에서 모두 스트레스를 받고 있으나 어떻게 풀어야 할지 모르고 있음
2) What 사용자가 이루고자 하는 게 무엇인지
: 스트레스를 잘 풀고자 함
3) When 사용자가 언제 task를 행할 것인지 (장애물 포함)
: 스트레스를 받을 실시간으로
4) Where 사용자가 어디서 이것을 할 건지 (장애물 포함)
: 스트레스를 받은 장소. 집, 이동 중, 회사 어디든지 될 수 있음
5) Why 왜 사용자가 이걸 해야 하고, 언제 subtask를 할 건지 등
: 스트레스를 많이 받아서 몸과 마음이 무기력해지는 걸 막기 위해. 친구랑 얘기하는 것은 한계가 있고 상담까지 받으러 가기는 귀찮아서. 다른 사람은 스트레스를 어떻게 푸는지 알고 싶어서.
오오! 잘 쓴 건지는 모르겠지만, 확실히 유저 입장에서 이 서비스를 써야 하는 이유와 언제 쓰고 싶은지를 정리하니 서비스가 “실시간으로 쉽게 기록하고 해소할 수 있는” 서비스가 되어야 한다는 방점을 얻었다.
User Story (유저 스토리)
개념
유저 스토리란 사용자가 서비스에서 원하는 목적을 달성하기 위해 해야 하는 액션을 한 문장으로 정리한 것이다. 유저 스토리는 애자일로 서비스를 개발하는 과정에서 중요하게 여겨지는데, 그 이유는 한 문장으로 액션을 정리하는 게 요구 사항 (Requirements)처럼 사용되면서 유저 스토리 하나 하나가 개발해야 할 스펙 단위가 되기 때문이다. 그래서 디자이너, 기획자, 개발자 간의 공용어(Universal Language)로 사용된다.
디자이너, 개발자, 기획자가 쓰는 전문 용어가 다르더라도 우리는 이 스펙을 위해 이 기능을 구현한다는 공통적인 이해를 바탕으로 업무를 할 수 있다!
유저 스토리를 쓸 때는 보통 아래와 같은 포맷으로 쓴다.
“As a , I want , for this ”
As a <user/who>
I want <action/what>
So that <purpose/why>
“고객/사용자는 목적/목표를 위해 필요/욕구를 원한다”이라는 의미인데 타겟이 서비스에서 어떤 것을 얻기 위해 무슨 기능을 원하는지에 대해 생각해보는 것이다.
예시를 찾아보며 이해해보자.
예시
*죠스바를 블랙핑크와 콜라보하여 패키지를 기획하는 상황
-> User Story : 전 세계의 블랙핑크 팬들은 (user)
최애 멤버의 죠스바를 구입하기 위해 (purpose)
죠스바 포장지에 그려져 있는 블랙핑크 멤버를 한 눈에 딱 알아보고 싶다. (action)
*카카오톡 멀티프로필 PC버전을 기획하는 상황
-> User Story : 카카오톡 PC 버전의 사용자들은 (user)
PC버전에서도 원활한 멀티프로필의 사용을 위해서 (purpose)
PC버전에서도 멀티프로필을 추가할 수 있는 기능을 원한다. (action)
아가륏~! 이라고 생각하고 서비스에 이론을 적용해보았다.
쪼렙 서비스 기획자의 예시
(이미 있는 기능이지만) 쿠팡에서 주문서로 이동하지 않고, 상품 상세에서 바로 구매 가능한 “바로 결제” 기능을 개발한다고 해보자.
어떤 기능을 추가해야 할지에 대해 이렇게 유저 스토리를 작성해볼 수 있다.
*바로 결제 사용자는 (user)
상품을 자신이 원하는 곳에 받기 위해 (purpose)
주소지 확인 및 변경을 할 수 있다. (action)
*바로 결제 사용자는 (user)
주문서로 이동하지 않고 빠르게 결제하기 위해 (purpose)
한 손가락으로 밀면 바로 결제할 수 있다. (action)
*바로 결제 사용자는 (user)
현금영수증 처리를 위해 (purpose)
현금영수증이 발행되는 전화번호를 확인 및 변경할 수 있어야 한다. (action)
쉽게 생각했는데 막상 한 문장으로 정확히 목적과 필요 사항을 정리하는 게 생각보다 어렵다 ;;
장점과 유의사항
한 문장으로 스펙을 정의하기 때문에, 심플하고 이해하기도 쉽다. 또 애자일에서처럼 프로젝트를 작은 마일스톤 단위로 구분지을 수 있다.
그러나 기능 하나하나를 문장으로 설명하는 만큼, 수백개의 케이스를 고려해야 하는 대규모 프로젝트에서는 유저스토리만 사용하는 건 좀 무리이다. 또 정확한 스펙을 정의하는 게 아니기 때문에 개발자와 기획자 간에 협의해야 할 사항도 많다. 문장으로 서술한 만큼, 개발 이후 성과 측정이 어렵고, 비기능적인 부분을 놓칠 수도 있다.
유저시나리오와 유저스토리의 핵심은 “사용자 관점“에서 생각하는 것 같다. 그래서 서비스를 기획하거나 개선하는 초기 기획 단계에 사용자가 이 기능을 왜 필요로 할지, 어떻게 사용할지 생각해볼 때 유용한 방법인 것 같다.
또 기획을 하다 보면 공급자적 마인드에서 생각하게 되는 순간이 생기는데, 서비스를 이용하는 사용자를 가장 최우선 순위로 두어야 한다고 다시 한 번! Keep In Mind를 해본다.
참고
쪼렙 서비스 기획자님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
