UX 시나리오 - 정황 시나리오 작성법
퍼소나 기반 시나리오를 통한 디자인 요구사항 도출
안녕하세요. 앞선 글들에 이어 시나리오 작성법을 설명하고자 합니다. 앞선 글들에서 사용자 모델을 작성하는 방법을 익히셨을 것이라 생각합니다. 시나리오는 사용자 모델과 실제 디자인을 연결시켜주는 중요한 역할을 합니다. 먼저 시나리오는 연극, 영화에서도 많이 사용되는 방법인 만큼 흔히 잘 알고 계실 것이라고 생각합니다. 하지만 이 글에서는 목표 지향 디자인 방법론에서 설명하는 세 종류의 퍼소나 기반 시나리오를 소개하며, 디자인 프로세스 속에서 시나리오가 어떻게 사용되는 지를 적고자 합니다. 글은 두 파트로 나뉘어 작성될 예정입니다. (About Face4 내용을 기반으로 작성됩니다.)
목표 지향 디자인 방법론에서는 프로세스의 진행 과정에서 단계적으로 다른 세 가지 시나리오를 작성합니다. 정황 시나리오, 주요 경로 시나리오, 점검 시나리오의 세 가지로 나뉘며 이번 글에서는 정황 시나리오만 소개됩니다.
1. 정황 시나리오
정황 시나리오는 디자인 요구사항을 도출하기 위해 사용됩니다. 여기서 디자인 요구 사항은 '무엇을' 디자인할 것인지 결정하는 단계를 말합니다. 쿠퍼사의 Robert Reimann, Kim Hoodwin, Dave Cronin, Wayne Greenwood, Lane Halley 가 개발한 디자인 요구사항 도출 프로세스를 살펴보겠습니다.
1) 문제 선언문, 디자인 목표 선언문을 작성한다.
2) 브레인스토밍
3) 퍼소나의 기대치를 파악한다.
4) 정황 시나리오를 제작한다.
5) 디자인 요구사항을 도출한다.
문제 선언문과 디자인 선언문은 앞서 살펴보았던 리서치와 사용자 모델의 내용을 바탕으로 제작해야 합니다. 사용자의 목표와 니즈는 1순위, 2순위 퍼소나로부터 도출하고, 사업목표는 임원진 인터뷰나 회의를 통해 참고합니다. 그리고 두 번째 단계는 디자이너들이 흔히 사용하는 브레인스토밍입니다. 여기서 중요한 점은 의견을 제한하거나 아이디어를 비판해서는 안된다는 것입니다. 아이디어를 평가하는 것은 프로세스의 뒷부분에 이루어질 내용임으로 엉뚱한 아이디어라도 매우 값지게 활용되는 경우가 많습니다. 브레인스토밍에는 너무 많은 시간을 투자하지 않으며, 몇 시간 정도면 충분합니다. 더 이상 톡톡 튀는 아이디어를 발견하지 못하거나 똑같은 의견이 반복되면 멈춥니다. 세 번째는 퍼소나의 기대치를 파악하는 것입니다. 이 경우 멘탈 모델을 찾아내는 것과 같습니다. 퍼소나의 상세 설명만으로도 충분한 정보를 이끌어낼 수 있습니다.
네 번째는 정황 시나리오입니다. 정황 시나리오는 가장 서술적인 이야기 형식을 띄는 것이 특징입니다. 멘탈 모델과 동기를 바탕으로 퍼소나의 행동을 상세히 묘사합니다. 일반적으로 정황 시나리오는 퍼소나가 하루 동안 일어나는 일을 묘사하는 것입니다. 정황 시나리오는 범위는 넓고 깊이는 얕게 작성해야 합니다. 상세한 기능이나 세세한 인터랙션을 설명하지 않습니다. 이는 사고의 폭을 좁힐 수 있기 때문입니다.
정황 시나리오에 필요한 내용들
제품이 어떤 환경에서 사용되는가?
얼마나 오랜 시간 동안 사용되는가?
퍼소나가 제품을 사용하는 동안 방해받는 외부 요소가 있는가?
여러 명이 한 제품을 사용하는가? 한 공간에 몇 명이 함께 업무를 진행하는가?
함께 사용하는 다른 제품에는 어떤 것이 있는가?
퍼소나가 목표를 달성하려면 어떤 활동을 해야 하는가?
제품을 사용함으로써 얻을 수 있는 최종 결과는 무엇인가?
제품을 복잡하게 설계하더라도 사용자가 이해할 수 있는가? 퍼소나의 능숙도와 친숙도는 어느 정도인가?
정황 시나리오는 기존 제품을 사용하는 상황을 설명하는 것이 아닌 새롭게 디자인하려고 하는 제품을 소개해야 합니다. 초기 단계에는 제품의 작동법과 구현 방법은 생각하지 않으며, 사용자 목표에만 집중합니다. 제품마다 1개 이상의 정황 시나리오를 제작해야 하며, 1순위 퍼소나가 여러 명인 경우라면 정황 시나리오 또한 여러 개 작성해야 합니다.
마술상자 얍!초기 단계에서는 인터페이스가 마술 상자라고 생각하면 매우 유용합니다. 즉, 제품이 어떻게든 사용자의 목표를 마술처럼 만족시켜준다고 생각하면 됩니다.
마지막으로 정황 시나리오 초안을 바탕으로 디자인 요구사항을 도출합니다. 일반적인 요구사항은 주변 정황과 대상, 사용자의 행위로 구성됩니다. 요구사항은 기능이나 표면적인 과업을 의미하는 게 아니기 때문입니다.
ex) 운전을 하면서(주변 정황) 고객의(대상) 전화를 바로 받을 수 있다(행위).
추가적으로 정보, 기능, 정황 요구사항도 따로 제작합니다. 정보 요구사항의 경우 퍼소나가 제품을 사용하면서 얻고자 하는 정보를 의미합니다. 기능 요구사항은 제품을 사용하는 동안 조작하거나 작동하고 싶은 기능적 니즈를 의미합니다. 기능적 니즈가 인터페이스에 직접 반영되는 경우가 아주 많습니다. 정황 요구사항은 사용될 제품 간의 관계나 종속성을 설명하거나 환경적 요인, 퍼소나의 스킬과 역량을 의미합니다.
디자인 요구사항을 작성한다면 디자인과 개발 방향성을 제시해주며 업무 범위를 임원진에게도 전달해줍니다. 제품이 어떻게 사용자의 목표를 만족시켜야 하는지 대략적인 개념을 잡을 수 있기 때문입니다. 사실 디자인 요구사항이 작성되는 시점이라면 제품, 퍼소나, 주변 정황에 대한 이해도가 매우 높은 상태여야 하며, 대략적인 컨셉이 나온 상태입니다. 이를 바탕으로 상세 디자인 설계를 한다면, 좋은 디자인 결과물이 탄생할 수 있을 것입니다. 다음 글은 디자인 설계도를 제작하는 방법을 소개하면서 주요 경로 시나리오, 점검 시나리오를 포함하여 소개하려고 합니다.
+ 추가글 (예시를 추가해보려고 합니다. 실제 서비스가 진행되고 있는 사례를 간단히 적어보겠습니다.)
1. 희윤씨는 매일 아침 출근 준비와 함께 딸 수민이의 유치원 준비를 함께 합니다. 오늘 준비물은 무엇인지 체크하기 위해 핸드폰으로 유치원 준비물을 확인합니다. 딸의 아침 준비를 해야합니다.
2. 출근한 희윤씨는 수민이가 안전하게 등원하였음을 알리는 문자를 받은 뒤 오늘 유치원의 교육 내용을 확인합니다. 간단한 클릭만으로도 유치원에 언제든 전화할 수 있습니다.
3. 점심 시간이 되자 오늘 수민이가 먹을 점심메뉴를 사진으로 확인하였습니다. 그리고 오전 시간에 아이들이 활동한 사진들을 확인하며, 다른 어머니들과 댓글을 통해 의견을 나누었습니다.
4. 유치원 퇴원시간 전오늘은 수민이를 제 시간에 데리러 갈 수 없음을 핸드폰을 통해 유치원에게 알렸습니다. 수민이는 다른 몇몇 아이들과 선생님과 함께 시간을 보냈습니다.
5. 늦은 퇴근으로 인해 오늘은 수민이 친구 정희 어머니에게 수민이의 귀가를 부탁합니다. 수민이 귀가를 위해 필요한 귀가동의서를 핸드폰을 통해 간단히 입력한뒤 서명하였고 유치원에 전달하였습니다. 정희 어머니는 수민이를 데리고 귀가를 하였습니다.
6. 희윤씨는 퇴근 후 수민이를 데리고 귀가합니다. 도착 후 핸드폰을 확인하자 내일 유치원 준비물 확인 문자가 와있었습니다.
객관적인 사실이나 용어가 잘못된 경우 알려주시고, 주관적인 의견도 다양한 피드백과 크리틱은 언제나 환영입니다. 읽어주셔서 감사합니다. ux 관찰과 공부라는 주제로 함께 글 올리실 분은 환영입니다. 매거진 들어가신 후 참여 신청 누르시면 됩니다. 매거진을 통해 서로 의견을 공유하고 공부하는 공간이 되길 바랍니다. 댓글과 구독, 좋아요는 힘이 됩니다!!
*글은 이주에 한번 이상 올릴 계획이고, 중간중간에 사례 소개나 분석하는 글을 섞어 올릴 예정입니다.
