UX 디자이너, 기획자가
놓치지 말아야 할 것
UX 디자이너와 기획자의 To-Be를 위하여 | 이은경
본 글은 A 항공사의 모바일 앱 개편 사업 기획자로 참여했던 경험과 엑스플리트에서 진행했던 B 항공사의 UX 컨설팅에 참여했던 경험을 바탕으로 썼습니다.
기획자로서, UX 디자이너로서 항공 서비스를 경험하며 느꼈던 구축 기획자와 UX 디자이너의 같지만 달랐던 업무들을 살펴보며 사용자에게 가치 있는 이용 경험을 제공하기 위한 의견을 공유하고자 합니다.
기획자와 UX 디자이너의 업무 방식누구를 위한 기능인가?
구축 기획자는 현업에서 추가하고 싶은 기능, 개선하고 싶은 프로세스를 구체적으로 정의합니다.
클라이언트였던 A 항공사는 경쟁사는 있지만, A 항공사는 없었던 자주 타는 탑승자 등록과 비행기 모드(데이터 없이 기내에서 사용할 수 있는 콘텐츠) 개발을 원했습니다. 경쟁사에 없는 Price Watch(구간, 요일, 가격대를 설정해 해당하는 운임이 있을 시 알림 발송)라는 신규 기능을 제공하고 싶어 했습니다. 현업부서에서 요구했던 유/무상 예매를 통합하는 것도 중요한 과업 중 하나였죠. 클라이언트의 요구사항은 주로 경쟁사에 있는데 현행 서비스는 제공하고 있지 않은 기능, 경쟁사에 없는 신규 기능의 개발이었습니다.
반면 UX 디자이너는 기능 단위가 아닌, 기술적으로 구현 가능 여부가 아닌 궁극적으로 어떤 서비스를 제공하고 싶은지 클라이언트의 비즈니스 목표를 확인합니다.
B 항공사 관계자는 고객이 온라인 채널을 통해 최적의 항공권을 쉽게 찾을 수 있고 항공사에서 제공하는 서비스/혜택을 잘 누릴 수 있기를 바랐습니다. 하지만 실제 사용자들은 B 항공사의 서비스를 어떻게 쓰고 있었을까요? 행태 분석 툴을 이용해 현행 서비스의 이용 행태를 알아보았습니다.
뷰저블을 통해 본 B항공사의 항공편 운임 선택 화면의 이용 행태화면을 보면 터치할 수 없는 출/도착지 영역에 hit가 많이 발생하고 있습니다. 이전 버튼을 통한 이탈률도 높게 나타났죠. 스케줄과 운임을 선택할 때 구간을 변경하는 여정 변경에 대한 니즈가 나타난 것이죠. 실제 사용자들은 B 항공사 서비스 이용 시 항공권 탐색에 불편함을 겪고 있었습니다.
아마도, 이런 생각을 하지 않았을까요?
U1 : “목적지를 바꾸고 싶은데 안되는구나. 나가야지”
U2 : “출발 변경 옵션은 추가하는 건가? 쓰기 어렵네. 나가야지”
U3 : “항공권 조회하는 데 너무 느리다. 나가야지”
구축과 컨설팅에서 정해진 요구사항은 TO-BE 모델에 반영해야 합니다. 구축은 기획자가 실제 사용자들이 쓸 기능을 아주 구체적으로 정의한다면, UX 디자이너는 비즈니스 목표를 파악해 전체적인 방향성을 정립하고, 사용자들의 이용 행태를 확인해 AS-IS의 문제점을 진단하여 개선 포인트를 도출하는 차이가 있습니다.
모든 화면의 논리적인 설계, 사용자 경험의 설계
화면 설계 시 기획자는 서비스 오픈 후 발생할 수 있는 모든 경우의 수를 고려해야 합니다. 사용자가 어떤 상황에서 서비스를 사용할지 예측할 수 없을뿐더러 오픈 후 발생하는 오류는 VOC와 직결되기 때문이죠.
A 항공사에는 나이 계산기라는 서비스가 있습니다. 탑승객 유형에 따라 요금이 달라지기 때문에 대부분의 항공사에서 제공하고 있는 서비스죠. 가는 날 유아였던 탑승객이 오는 날 소아가 되기도 하고, 성인 없이 국내선을 이용하는 소아, 다구간 여정에 국제선/국내선 add on이 포함된 경우 등 여정에 따라 유/소아의 기준이 달라지기도 하고, 입력해야 할 정보와 안내 사항이 달라지기 때문에 발생할 수 있는 모든 케이스를 화면 설계에 담아야 했습니다.
반면, UX 디자이너는 전체적인 사용자 경험을 설계합니다. 프로젝트 관계자 다수가 참여한 스프린트 워크숍을 통해 합의된 UX 목표와 전략, 솔루션을 도출하여 와이어 프레임화 합니다.
B 항공사의 경우 데스크 리서치가 끝난 후 UX 디자이너, 기획자, 현업, 운영, 개발팀이 모여 스프린트 워크숍을 진행했습니다. 워크숍을 통해 B 항공사 온라인 채널의 핵심 목표를 다시 한번 확인하고 중요하게 다뤄야 할 MVP를 선정했습니다. 솔루션을 프로토타입화 하며 도출된 UX 목표는 “기대하는 여정이 완성되는 경험”이었습니다.
스프린트 워크숍은 준비하는 것도, 진행하는 것도, 참여하는 것도 힘들고 많은 시간을 할애해야 합니다. 다양한 파트에서 참여하다 보면 실제 운영, 개발에 대한 이야기가 나오기도 하죠.
개발팀 : “이게 개발 가능한가?”
운영팀 : “반응형으로 못할 것 같은데요?”
항공서비스팀 : “이때는 기내식 변경이 안 될 텐데”
하지만 워크숍이 끝나면 프로젝트 구성원의 관점이 같아집니다. 하나의 목표 아래 상하 관계가 아닌 파트너로서 하나의 서비스를 만들어 간다는 걸 느낄 수 있습니다.
구축 기획자의 설계를 하나의 기능, 프로세스에서 발생할 수 있는 모든 케이스에 대응하는 논리적인 회로라고 한다면 UX 디자이너의 설계는 서비스 개선 과정의 중심이 되는 공동의 목표를 설정하고 확인하는 기준서라고 할 수 있습니다.
이슈를 대하는 자세
프로젝트를 수행하다 보면 다양한 이슈가 발생합니다. 구축에서는 별도의 이슈 대장을 만들 정도로 중요하게 관리되며 기획자는 이슈를 해결할 때 현업의 의사결정과 어떻게 해결할 수 있는지 기술적인 고민을 합니다.
A 항공사의 탑승객 등록은 개발할 때 많은 이슈가 있었습니다.
담당자1 : “여권 정보도 저장했으면 좋겠어요. 은행에 자주 쓰는 계좌를 등록하는 것처럼요."
담당자2 : "타사는 여권 정보까지 저장하지 않으니까. 우린 했으면 좋겠네요."
경쟁사는 지인의 여권 정보까지 등록하는 기능은 없었기에 A 항공사 담당자는 여권 정보까지 저장하기를 원했습니다. 그런데 여권 번호는 주민등록번호와 같은 고유 식별 번호라 정보제공자 본인의 허락 없이 타인이 대리하여 등록/저장할 수 없었고, 미성년자의 경우 법정 대리인의 동의 및 인증이 필요했습니다.
담당자의 요건과 동의가 꼭 필요하다는 이해의 상충으로 고안해낸 방법은 정보 제공 당사자에게 URL을 전송하는 것이었습니다. 탑승자 정보 등록을 원하는 대상에게 정보를 입력할 수 있는 화면(URL)을 전송하고 여권 정보를 입력받는 구조였죠.
탑승객의 정보 입력을 편리하게 하려고 제공한 기능인데 그 기능을 이용하기 위해 URL을 전송하고, 주소를 받은 사람은 정보를 입력해야 하는 또 다른 절차들이 발생해버렸죠.
UX 디자이너는 업무 자체가 현업과 떨어져서 진행되기에 현장의 이슈가 즉시 공유되기 어렵습니다. 전체를 설계하다 보니 구축을 위한 자세한 부분들을 놓칠 때도 있죠.
B 항공사의 경우 컨설팅이 마무리되는 시점에 화면 설계가 시작되었습니다. UX 컨설팅 프로젝트는 끝났기 때문에 구축 시 발생하는 이슈의 공유, 대응이 어려웠습니다. 결국 구축하는 과정에서 UX 목표가 흔들리고 기존 서비스보다 더 나은 경험을 제공할 수 없는 상황이 발생하고, 서비스의 사용성이 떨어지기 시작했습니다.
그래서 구축 중인 TO-BE 서비스에 대한 전문가 평가를 시행했습니다. UX 전략과 목표를 확인하고 실제 사용자 관점에서 서비스를 사용해보며 여러 불편사항을 발견하였고 사용성 개선에 적합한 방안을 제언하였습니다.
구축 기획자는 프로젝트 중 발생하는 다양한 이슈를 체계적으로 관리하고 기술적인 해결 방법, 현업의 의사결정을 바탕으로 정리한다면 UX 디자이너는 컨설팅 이후 사용자의 관점에서 서비스를 사용해보며 또 다른 문제점을 발견한다고 할 수 있습니다.
우리의 과업 이후 개선될 To-Be를 생각하며,
UX 디자이너라면 기획, 개발에서 활용할 수 있는 가이던스를 명확히 전달하는 것이 중요합니다. 개발 중인 서비스의 사용성을 진단하거나 프로젝트 실무자들이 점검할 수 있는 체크리스트를 제공하는 것도 좋은 방법이라 생각합니다. 기회가 된다면 컨설턴트가 구축을 경험해보는 것도 명확한 가이던스를 전달하는 데 큰 도움이 될 것입니다.
기획자라면 본 설계 전 요구사항 정의 단계에서 기획, 디자인, 퍼블리싱, 개발, 현업부서의 담당자가 모여 워크숍을 진행하는 걸 추천해 드립니다. 제공자가 아닌 사용자의 관점에서 그들이 이용하는 메인 프로세스를 정의하고 문제점을 발견하고 솔루션을 찾아보는 과정을 거친다면 공동의 목표를 정의할 수 있을 것입니다. 이 목표는 길게는 1년 이상 진행되는 구축 기간에 발생하는 다양한 이슈의 해답을 찾는 데 많은 도움이 될 것입니다. 더불어, 프로젝트 참여자들의 크고 작은 의사 결정 시 중요한 판단 기준으로 작용할 것입니다.
추가로 프로젝트 의뢰를 앞둔 클라이언트라면 사용자들이 현행 서비스를 어떻게 쓰고 있고 무엇을 바라는지 운영하는 서비스에 대해 좀 더 객관적으로 파악할 필요가 있습니다. 프로젝트 전 사용자 분석이 선행된다면 단순한 기능 개선, 제공자 입장의 기능 제공이 아닌 사용자 중심의 서비스 구현을 위한 요구사항 정의에 많은 도움이 될 것입니다.
지금 엑스플리트에서는
다양한 구축과 UX 컨설팅 경험을 바탕으로 클라이언트 스스로 서비스를 진단하거나 품질관리를 할 수 있는 진단 툴킷을 제작 중이며 엑스플리트만의 UX 컨설팅 패키징을 고도화하고 있습니다.
운영 중인 서비스의 문제점 파악이 어려운 경우, 문제는 인지했으나 무엇을 해야 할지 모르는 경우, UX 컨설팅을 통해 어떤 결과를 얻을 수 있는지 궁금하다면 이후 업로드될 엑스플리트 소식을 기다려주세요.
