7편. Design Research Process(2)
UX 디자인 입문
생각보다 양이 많아져서 부득이하게 두 편을 나눠서 글을 올리게 되었습니다. 이번 편에서는 서비스 콘셉트, HWM, 우선순위, 유저 스토리, 유저 시나리오, 유저 플로우 이렇게 6개 부분에 대해서 공부해볼 것입니다. 그리고 내용이 길어지지 않는다면 프로세스를 디자인하는 과정 또한 다뤄봅시다. 저번 1편과 내용적으로 뚜렷하게 이어지는 것은 아니지만 기본적인 개념을 위해 1편을 보고 오는 것이 나을 것 같습니다. 그럼 공부를 시작해볼까요?
01. 서비스 콘셉트
서비스 콘셉트란 앞에서 있었던 문제의 정의, 리서치 (시장조사, 유저 조사, 서베이, 경쟁사 분석, 사용자 인터뷰 등) 그리고 이를 위해 사용한 방법론(페르소나, 사용자 여정 지도, 브레인스토밍 등)을 통해 나온 결과에 의미를 부여하는 것이라고 생각하면 됩니다.
그래서 뭘 만들겠다는 거야?
서비스 콘셉트를 세우기 위해 간단하게 구조를 만들고 싶다면 우리가 잘 아는 방식을 통해 해결할 수 있습니다. "언제, 누가, 무엇을, 어떻게"라는 4가지의 큰 질문을 통해 콘셉트 구조를 이해해보죠. 아래의 그림은 예로 작성해본 서비스 콘셉트입니다.
내용 출처 : 패스트캠퍼스 온라인 강의그렇다면 서비스 콘셉트를 설계하는 방법에는 무엇이 있을까요? 이제부터 앞에 개요에서 설명한 방법론들이 등장합니다. 차례대로 HMW부터 공부해봅시다!
02. HOW MIGHT WE (HMW)
디자인 씽킹 프로세스 중 한 단계로 "우리가 어떠한 문제를 어떻게 해결할 수 있을까?"라는 질문을 통하여 일반적으로 내놓았던 추상적인 문장으로 나열된 해결방안들을 실천하기 쉬운 작은 계획으로 바꾸는 방법입니다. 너무 애매모호하게 또는 넓게, 좁지 않게 말해야 하죠. 그렇기 때문에 어떻게 하면 더 행복하게 사용할 수 있을까? 와 같은 질문은 하지 말아야 합니다. 이러한 HMW는 여러 디자인 방법론에서 응용됩니다. 최근 많은 회사에서 빠르게 아이디어를 만들어 내고 프로토타이핑을 빠르게 내야 하기 때문에 구글 스프린트에서도 사용되는 방법이며, MAP 단계에서도 사용되기도 하죠.
AS IS - TO BE를 활용한 "HMW 방법론"HMW에서는 AS-IS와 TO-BE가 중요합니다. 왜냐하면 근본적으로 디자인 프로세스를 하는 이유는 앞에서 언급한 두 가지를 해결하기 위함이기 때문이죠. 앞에서 현재 상태의 문제점을 발견한 뒤, 개선된 가치를 제공하고, 사용자들에게 더 나은 경험을 제공해주는 것이 중요합니다. 이렇게 함으로써 사용자가 직면하는 문제점에서 해결책을 끌어내는데 도움이 되며 문제점은 사용자의 맥락과 상황 등 많은 것들과 깊은 연관이 있습니다. 특히 유저 저니맵을 통해 맥락에 따른 페인 포인트를 쉽게 파악할 수 있는데, 여기서 콘텍스트와 페인 포인트를 합한 것이 HMW이라 할 수 있죠.
"월초 카드결제 날마다"는 콘테스트가 되며, "카드값 입금을 잊어버리고 연체하여" + "신용도가 하락한다."는 두 개의 페인 포인트가 될 수 있습니다. 이때 우리가 설정할 HMW는 "월초마다 카드 결제액을 잊지 않고 입금할 수 있도록 할 수 있을까?"로 설정할 수 있고, 이를 위한 간단한 예제를 설정할 수 있는 표를 첨부하겠습니다.
03. 우선순위 세우기
실무에서는 각종의 리소스들이 부족합니다. 그렇기 때문에 우선순위를 결정하고 정리하는 것이 중요하죠. 프로젝트를 진행할 때는 여러 직군의 사람들이 모여서 진행하는데 그렇기 때문에 프로덕트 매니저의 역할이 중요합니다. 우선순위를 정하는 방식은 운영의 방식과 목적에 따라 다양하게 사용되는데, 그중 자주 사용하는 것은 포지셔닝 맵입니다.
포지셔닝 맵은 X와 Y축 기준을 두고, 우선순위 아이데이션을 정리하는 것으로 기준은 특성에 따라 여러 기준을 설정할 수 있습니다. 이 방법을 진행하면서 서비스 전체의 방향성이 정해질 수 있는데 시작점에서부터 개선 결과까지의 연결고리가 논리적이어야 상대방을 설득할 수 있고, 스스로 납득할 수 있죠.
04. 유저 스토리(USER STORY)
디자인과 개발을 하게 될 매인 Feature와 Task를 설명합니다. Feature를 사용하는 주체, 기능, 목적을 정의하고 프로젝트에 연관된 실무자들을 위한 커뮤니케이션 도구 역할을 하며 애자일 방법론에서 많이 사용합니다. 유저들의 니즈를 짧게 묘사하는 방법 중 하나로 스크럼을 실행하는 조직에서도 사용되기도 하죠.
그림 출처 : 패스트캠퍼스 온라인 강의유저 스토리의 경우 애자일 중 스크럼을 실행하는 조직에서 사용됩니다. 스프린트는 작업량 작고, 개발기간도 짧으며, 반복적인 개발 주기를 의미하며, 지속적으로 할 수 있는 개발단위를 설명하는 단어죠. 즉, 스프린트 기간(평균적으로 약 2주) 동안 스토리를 작성해서 개발하고 회고하는 것으로 개발이 가능한 스토리를 묶어서 이 기간 동안 개발할 수 있는 상황의 유저 스토리를 작성하며 사용자 목표에 기반을 둡니다.
유저 스토리는 크게 3가지를 기준으로 설정할 수 있는데, 아래의 내용은 3가지의 기준에 대한 설명이며 이에 맞는 예시, 그리고 연습할 수 있는 과제 형식을 제공하고 있습니다.
05. 유저 시나리오(USER SCENARIO)
위에 언급한 에픽에 더 가까운 모양입니다. "사용자들이 이렇게 행동을 한다면 어떨까?"와 같은 질문을 끊임없이 던지면서 진행되죠. 즉, 서비스나 제품이 제공할 새로운 사용자 경험을 이야기 형태로 기술하는 것으로 유저 스토리보다 더 넓은 범위의 사용자 목표들을 다룹니다. 동시에 가능한 디자인 대안을 구체적으로 설명하는데 효과적이고, 서비스나 제품이 사용자들과 어떻게 커뮤니케이션을 하는가에 효과적으로 사용됩니다.
시나리오의 주체가 우리가 정한 페르소나일 경우 시나리오의 힘이 제대로 발생하는데, 사용자의 행동 패턴과 동기를 이해하고 들어가기 때문입니다. 이때 테스크의 중요도와 순서, 페르소나의 목표에 초점을 맞추어 사용자에게 어떤 기능과 가치를 제공해야 하는지 생각하고 그것에 맞춰 디자인의 방향을 설정할 수 있죠. 구성요소의 경우 사용자가 목표를 이루기 위해 필요한 리서치 내용을 바탕으로 테스크와 맥락을 이해할 수 있습니다. 아래의 예제를 통해 공부하고 실습해보도록 합시다.
시나리오를 통해서 우리들은 사용자들의 목표와 동기를 이해할 수 있습니다. 그렇기 때문에 사용자가 어떤 테스크를 수행해야만 목표를 이룰 수 있을지를 생각해서 짜야합니다. 내비게이션(정보의 접근 방법), 콘텐츠와 정보적인 관점에서 접근의 방법을 고려할 수 있습니다. 또한 사용성 테스트에서도 좋죠. 시나리오를 잘 작성해놓으면 사용자가 시나리오를 따라가면서 테스트를 했을 때 목표와 동기를 검증할 수 있는 가이드로 사용할 수 있으며, 이상적인 상황을 설명하기 때문에 전체적인 관점에서 실사용자들의 관점으로 디자인할 수 있도록 도와줍니다. 그렇기 때문에 사용자가 어떻게 생각하고 행동하는지 주의를 기울이면서 작성해야 하죠.
다만, 시나리오는 디자이너의 추측과 아이디어를 기반으로 작성되지만 이러한 추측과 아이디어들은 사용자 리서치와 데이터 모델링 단계에서 수집되고 충분하게 분석된 자료들을 근거로 만들어져야 합니다. 또한 시나리오상 테스크들이 사용자의 목표를 중심으로 선택되었는가를 반복적으로 확인할 필요가 있습니다.
06. 유저 플로우(USER FLOW)
유저가 서비스 또는 제품을 이용하면서 수행하는 구체적인 Task들의 Path를 나타냅니다. 구체적인 화면, 기능, 인터랙션 등을 정의하죠. 따라서 개발할 수 있는 단계의 로직을 구성하는 경우 기획자는 매우 세밀하고 완벽하게 플로우를 그려야 합니다.
디자이너의 경우는 개발자와 플로우를 공유하면서 보완해나가고 기능을 추가, 삭제, 수정 등을 진행할 수 있습니다. 또한 페르소나에 따라 플로우가 달라지는 경우가 있기 때문에 각각의 페르소나에 맞는 플로우를 그릴 수 있어야 합니다. 플로우의 경우 종류가 많기 때문에 상황과 기능, 종류에 따라 다양하게 그려질 수 있다는 점을 기억합시다.
06. 정보구조(Information Architecture)
제품 또는 서비스를 구성하는 정보, 요소들의 우선순위와 내비게이션, 구조 등을 도식화한 것을 말합니다. 정보구조가 잘 설계되어 있어야 정보에 대한 직관적인 접근이 가능하며, 사용자가 정보를 빠르게, 그리고 쉽게 발견하여 목표를 달성할 수 있죠. IA는 서비스의 각 기능이 어떻게 묶여 있는지, 그 안의 콘텐츠는 무엇이 있는지 한눈에 확인할 수 있기 때문에 서비스 또는 제품의 전체적인 그림 및 구조를 파악하고 확인할 수 있습니다.
화면 또는 기능의 흐름에서 상하 관계를 고려하는 것이 가장 간단하게 정리하는 방식이며, 이러한 방식은 크게 3가지로 나뉩니다.
01. Hierarchical Navigation
한 화면에서 시작해 한 뎁스씩 아래로 내려가는 방식으로 Setting이나 Mail앱에서 흔히 발견되는 내비게이션의 형태입니다. 다른 Path로 가기 위해서는 처음 시작한 화면으로 되돌아와야 합니다.
02. Flat Navigation
여러 카테고리의 콘텐츠 간 이동이 가능한 형태로, Music, App store 등 하단 탭이 있는 모바일 앱에서 보이는 구조입니다.
03. Content-Driven Navigation
콘텐츠 간 이동이 매우 자유로운 구조로, 콘텐츠 자체가 내비게이션을 결정합니다. 흔히 모바일 게임이나, 전자책 서비스(E-Book)에서 많이 보이는 형태입니다.
항상 IA는 명확하고 직관적인 Path를 제공하는 것이 중요합니다. 사용자는 서비스 내에서 자신의 위치와 다음 목적지로 가기 위해 무엇을 해야 할지 인지할 수 있어야 하죠. 사용자가 정보와 콘텐츠에 접근하기 쉽도록 구조화하는 것에 집중을 하는 대신, 사용자의 탭, 스와이프, 화면 간의 이동은 최소화하는 것이 좋습니다.
오랜만에 적은 UX는 정리하는 내용이 많아 꽤 시간이 오래 걸렸습니다. 강의를 듣는 시간 자체는 오래 걸리지 않지만, 이를 정리하는 것이 생각보다 오래 걸렸거든요. 앞으로 정리해갈 내용이 많은데 한동안 꽤 고생할 것 같아서 눈물이 앞을.... 일단 하던 프로젝트도 정리해야 하고, 브랜딩은 또 강의를 듣고, 으악 이것저것 할 게 너무 많은데 힘을 내야 할 것 같아요.
