UX 프로세스 배우기
UX 디자인 배우기 #66
Today UX 아티클
GoogleDevelopers에 업데이트된 Mustafa Kurtuldu의 글 Basicsof UX를 전문(全文) 번역한 글입니다.
고객을 위해 더 나은 사용자 경험을 개발하는 데 필요한 강력하면서도 의미 있는 프로세스를 활용할 수 있는 UX 프로세스를 소개합니다. 이 프로세스 중 일부 파트만 따로 쓸 수도 있지만, 전체를 함께 쓰는 것이 가장 이상적입니다.
이 프로세스는 디자인 스프린트(DesignSprint) 방법론에서 주로 차용한 것으로, 구글 내 여러 팀에서 셀프 드라이빙 카(SelfDriving Car)와 프로젝트 룬(Project Loon)과 같은 도전 과제를 해결하고 푸는 데 이용합니다.
더블 다이아몬드
이 워크플로우는 UX분야에서 더블 다이아몬드라고 부르는 것을 기반으로 하는데, 이는 British Design Council에 의해 유명해졌습니다. 리서치를 통해 아이디어를 확산했다가, 도전 과제를 정의하기 위해 수렴했다가, 개별적으로 스케치하기 위해 확산했다가, 아이디어를 공유하고 최선의 방법을 결정한 다음에 테스트하고 검증하는 방법입니다.
British Design Council ]에서 개척한 ‘더블 다이아몬드’ 디자인 프로세스 모델에는 이해(Understand), 정의(Define), 확산(Diverge), 결정(Decide), 프로토타입(Prototype), 검증(Validate) 등과 같은 단계가 들어갑니다.
준비하기
먼저 당장 닥친 근본적인 문제부터 시작해서 스스로에게 “내가 해결하려고 하는 문제가 정확히 무엇인가?”라는 질문을 던지면서 계획안처럼 적어봅니다. 도전 과제에 대한 설명문은 목표를 포함해 프로젝트에서 준비하고 있는 내용을 요약하는 겁니다.
이런 도전 과제는 더 정제되어야 할 필요가 있는 기존 제품 기능에 대한 것이 될 수도 있고, 완전히 새로운 제품에 대한 것이 될 수도 있습니다.
여러분의 태스크가 무엇이 되건, 달성하고자 하는 목표에 맞게 말을 조정하면 됩니다. 설명문은 팀 목표에 맞아야 하며, 오디언스에게 초점을 맞추고, 영감을 주면서도 간결하게 작성해야 합니다.
다음은 제가 지금까지 작업했던 실제 제품의 도전과제를 한 문장으로 쓴 예시입니다.
내반족(內反足) 환자의 치료 및 추후 간호를 관리하는 시스템을 디자인한다
복잡한 재무 시스템을 간소화해주고 필수적인 부분만 남기고 줄여주는 앱을 만든다
브랜드를 희생하지 않고 서로 다른 플랫폼에서 일관성을 가지는 모바일 앱을 디자인한다
도전과제 문장 업데이트하기
몇 가지 버전의 목표를 쓰고 나면, 팀에게 그것을 보여주고 합의를 도출해냅니다. 이 문장은 팀이 문제에 집중하는 데 도움이 될 것이기 때문에 데드라인을 포함하는 것도 좋습니다. 위에서 언급했던 사례에 수정 사항을 추가하면 다음과 같이 바꿀 수 있습니다.
올해 1분기 론칭을 위해 2세 이하 내반족(內反足) 환자의 치료 및 추후 간호를 관리하는 시스템을 디자인한다
2017년 1월 최초 론칭을 위해 재무 세계에 대한 사전 지식 없이 한 번의 버튼 탭만으로도 주식을 사고팔 수 있게 해주는 간단한 재무 앱을 만든다
올해 말까지 여러 플랫폼에서 유연하게 적용되면서도 회사의 브랜드가 각 플랫폼에 효과적으로 자리 잡을 수 있게 해주는 디자인 가이드를 만든다
도전과제 문장이 마무리되면, 작업하는 동안 볼 수 있게 눈에 잘 띄는 곳에 걸어 놓습니다. 지속적으로 곱씹어 보게 될 것이며, 프로젝트를 진행하면서 업데이트하거나 수정하게 될 수도 있습니다.
문제의 타당성 검증하기
다음 단계는 그 도전 과제에 대해 리서치하고 문제에 대해 배우는 것입니다. 문제에 대해 팀에서 이해한 내용이 타당한지 아닌지 밝혀내는 것이 여러분이 해야 할 일입니다.
우리는 상당히 자주 우리만의 관점에서 문제를 바라보게 되는데, 우리처럼 기술 분야에 있는 대부분은 사실 파워 유저이자 소수의 유저에 해당되기 때문에 이는 위험한 일입니다. 우리는 목소리가 큰 소수이기 때문에 실제 문제가 아닌 것을 문제라고 잘못 생각하기 쉽습니다.
도전 문제의 타당성을 검증하기 위해 데이터를 수집하는 데는 여러 방법이 있습니다. 방법은 팀마다 달라질 수 있으며 유저에게 접근할 수 있는지 없는지에 따라 달라질 수도 있습니다. 목표는 당면한 문제를 더 잘 이해하는 것입니다.
이해관계자 대상 내부 인터뷰
이해관계자를 대상으로 하는 인터뷰는 회사 혹은 팀 내에서 인사이트를 발견하는 데 많은 정보를 줄 수 있습니다.
인터뷰를 하는 프로세스에는 회사 내에 마케팅부터 시작해서 회계팀까지 각 팀 멤버 및 이해관계자 인터뷰가 포함됩니다. 이런 과정은 그들은 무엇이 정말 문제라고 생각하는지, 그 잠재적 해결방안은 무엇이 될 수 있는지 알아내는 데 도움이 될 것입니다.
여기서 ‘해결방안’이라 함은 기술적 해결방안을 뜻하는 것이 아니고, 최선의 케이스 시나리오가 무엇이 될 수 있는지, 회사나 제품의 최종 목표가 무엇이 될 수 있는지 뜻하는 것입니다. 예를 들어 위에서 언급했던 사례를 들어 말해보면, “올해 말까지 의학 기관의 80%에 우리 소프트웨어를 보급한다”가 훌륭한 목표가 될 수 있습니다.
한 가지 위험요소도 있습니다. 이런 식의 타당성 검증 방법은 팀 토론과 협업 등을 못하게 하고 조직 내 단절된 분위기를 잠재성이 있기 때문에 가장 덜 선호하는 방법입니다. 그렇기는 하지만 이렇게 하지 않으면 놓쳤을 클라이언트와 디자인 도전 과제에 대한 좋은 정보를 얻을 수 있게 해주는 방법입니다.
라이트닝 토크(Lightning Talk)
라이트닝 토크란 몇 분 정도 길이의 매우 짧은 프레젠테이션을 뜻합니다.
내부 인터뷰와 비슷하긴 하지만 이번에는 한 방안에 모든 이해관계자를 불러 모으는 겁니다. 그다음에 그중에서 5명 혹은 6명 정도의 이해관계자(마케팅, 영업, 디자인, 회계, 리서치 등)를 선출하여 각자의 관점에서 생각하는 도전 과제에 초점을 맞춘 이야기를 최대 10분 정도 하게 합니다. 이들이 발표를 할 때 반드시 다뤄야 할 주제는 다음과 같습니다.
비즈니스의 목표
그들의 관점에서 볼 때 본 프로젝트의 도전과제 (기술적인 내용일 수도 있고, 연구자료 수집에 대한 것일 수도 있고, 디자인 제작에 대한 것일 수도 있음)
여러분이 최근에 했던 유저 리서치
마지막 5분은 질문 시간을 위해 남겨두고, 한 사람을 미리 정해 발표가 진행되는 동안 노트 필기를 하게 합니다. 끝나고 나면 새로 배운 내용을 반영하여 도전 과제를 업데이트하고 싶을 수 있습니다. 제품의 목표를 달성하는 데 도움이 되는 기능이나 플로우를 끌어낼 수 있는 요점을 수집하는 것이 이 활동의 목표입니다.
유저 인터뷰
유저 인터뷰는 사람들이 어떤 태스크를 수행하며 겪는 고충을 알아내는 훌륭한 방법입니다.
유저 인터뷰는 사용자 여정, 고충, 플로우 등에 대해 배우는 가장 좋은 방법일 것입니다. 유저 인터뷰를 최소 5회 정도 계획하고 가능하다면 더 하는 것도 좋습니다. 유저에게 던질 질문에는 아래와 같은 것이 들어가야 합니다.
기존 태스크는 어떻게 완수하고 있는가? 예를 들어, 위에서 언급했던 재무 앱을 사례로 들면, “지금은 주식을 어떻게 사고 있나요?”라고 물을 수 있습니다.
이플로우에서 그들이 좋아하는 것은 무엇인가?
이플로우에서 그들이 싫어하는 것은 무엇인가?
유저가 현재 사용하고 있는 유사 제품은 무엇이 있는가?
무엇을 좋아하는가?
무엇을 싫어하는가?
마술 지팡이를 가지고 있고 이 프로세스에서 하나만 바꿀 수 있다면 무엇을 바꾸겠는가?
인터뷰는 유저 본인이 겪고 있는 문제에 대해 스스로 말하게 하는 것입니다. 유저와 토론을 해야 하는 시간이 아니며, 따라서 여러분은 최대한 조용히 있어야 합니다. 유저가 말하기를 멈출 때도 마찬가지입니다. 항상 유저가 생각을 정리할 수 있는 시간을 기다려줘야 합니다. 사람들이 몇 초간 말하기를 멈춘 후에도 얼마나 말을 잘 이어가는지 알면 놀랄 겁니다.
인터뷰를 하는 내내 노트 필기를 하고, 가능하다면 대화를 녹음해두면 놓친 부분을 잡아내는 데 도움이 됩니다. 여러분이 수집한 유저 인사이트와 기존에 세웠던 도전과제를 비교해보는 것이 목표입니다. 서로 비슷한가요? 도전과제 문장을 업데이트할 만한 새로운 것을 배웠나요?
에스노그래픽 필드 리서치(Ethnographic field research)
유저가 자연스러운 환경에 있는 것을 보는 것은 그들이 직면한 도전 과제를 어떻게 해결하는지 이해하는 가장 좋은 방법입니다.
가령 유저가 어떻게 쇼핑을 하는지, 어떻게 출근을 하는지, 어떻게 SMS 메시지를 보내는지 등 유저가 무언가를 하고 있는 중에, 그 맥락 안에서, 그 현장에서 유저를 관찰하는 방법입니다.
유저의 말을 들으면 여러분이 듣고 싶어 한다고 생각하는 말만 해줄 수도 있기 때문에 이런 방법을 취하는 겁니다.
유저가 행동을 취하고 직접 태스크를 수행하는 모습을 보면 많은 인사이트를 얻을 수 있습니다. 기본적으로 해석하지 않으면서 관찰을 해야 하며, 유저가 무엇을 쉽게 하고 무엇을 어렵게 하는지 그리고 무엇을 놓쳤는지 관찰해야 합니다. 유저의 고충을 더 잘 공감하기 위해 유저의 환경에 여러분 스스로를 대입해보는 것이 목표입니다.
이러한 테크닉은 보통 어느 정도 긴 시간을 가지고 해야 하며 이끌어 줄 리서처도 필요합니다. 하지만 자연스러운 환경에 있는 많은 사람을 관찰하는 것은 가장 많은 인사이트를 찾을 수 있는 방법입니다.
합치기
프로젝트에서 학습 단계를 마치고 나면, 마지막으로 다시 한번 도전과제 문장을 봐야 합니다. 잘 가고 있나요? 더 추가해야 할 부분은 없나요? 지금까지 배운 내용을 전부 적어 보고 그 리스트를 카테고리별로 묶어보세요. 이는 여러분이 해결하고 있는 문제가 무엇이냐에 따라 기능이나 플로우의 기반이 될 수 있습니다. 도전 과제를 업데이트하고 수정하는 데 이용할 수도 있습니다.
충분한 피드백과 인사이트를 얻고 나면 이제는 프로젝트 맵을 만드는 데 그 지식을 적용할 차례입니다.
프로젝트 맵(Project Map)
여러분이 해결하고자 하는 문제는 보통 다양한 유형의 사람들(혹은 플레이어들)로 구성되어 있으며, 각각은 프로젝트의 플로우에서 지분을 가지고 있습니다. 배운 내용에 기반하여 가능한 플레이어의 리스트를 작성해야 합니다. 가령 “내반족을 진료하는 의사”, “내반족 환자”, “환자를 돌보는 간병인” 등과 같이 유저 유형이나 이해관계자가 될 수도 있습니다. 종이나 화이트보드 왼쪽 면에 각각의 플레이어를 적고 오른쪽에는 각 플레이어의 목표를 적습니다.
끝으로 각 플레이어에는 각자가 목표에 도달하려면 필요한 단계의 수를 적습니다. 예를 들어, “내반족을 진료하는 의사” 같은 경우에 “내반족 환자 치료”가 목표가 될 수 있습니다. 그러면 목표로 가는 단계는 “시스템에 환자 등록”, “치료 플랜 시작하기”, “의학적 건강 사이클 리뷰 작성”, “진료 과정 수행” 등이 될 수 있습니다.
프로젝트 맵은 각 유저 혹은 플레이어가 플로우 내에서 밟게 되는 주요 단계를 계획하게 해줍니다.프로세스의 주요 단계가 적힌 프로젝트 맵이 결과물이 됩니다. 이를 너무 많은 디테일은 생략한 프로젝트의 오버뷰라고 생각하세요. 맵이 도전과제와 매치가 되는지 판단하는 데도 사용할 수 있습니다. 나중에 각 단계를 쪼개다 보면 더 많은 세부 사항이 들어가게 될 겁니다. 하지만 지금 당장은 유저가 최종 목표를 완수하는 데 필요한 큰 단계들만 프로젝트 맵에 표현될 겁니다.
와이어프레임과 스토리보딩
Crazy 8s
이 단계에서는 ‘Crazy 8s’라는 방법을 쓰기를 권장합니다. 반으로 접은 종이를 두 번 더 접어서 8칸을 만듭니다. 각 칸에는 지금까지 배운 모든 것을 기반으로 아이디어를 그려냅니다. 10분 정도 시간을 가지고 8칸을 모두 채워 넣을 아이디어를 생각합니다. 20분 이상을 시간을 가지게 되면 늑장을 부리게 될 수 있으니 가서 커피를 마시거나, 이메일을 확인하거나, 팀원들과 일상적인 대화를 하거나 다른 일을 해보세요. 이 단계에서는 빠르고 효과적으로 작업하게 되기 때문에 절박감을 가지고 만들 수 있습니다.
팀원들과 함께 작업한다면 각자 자신의 버전을 만들어보게 합니다. 이 프로세는 생각에 시동을 걸어주어 도전과제에 대한 생각을 시작하게 해줄 것입니다. 일반적으로 이 스케치는 인터페이스 디자인 와이어프레임이 될 것입니다.
그 후에, 팀원들과 함께 각자의 아이디어를 발표합니다. 모든 사람들은 반드시 8개의 아이디어와 왜 그런 경로를 선택했는지 자세히 설명해야 합니다. 아이디어를 뒷받침하기 위해 앞서 배운 내용들을 이용해야 한다는 점을 팀원들에게 다시 한번 상기시켜야 합니다. 모두 한 번씩 발표를 했으면 이제 투표를 할 시간입니다. 각자 스티커를 두 개씩 가지고 좋다고 생각하는 아이디어에 투표하면 됩니다. 한 아이디어가 정말 좋다면 하나에 두 스티커를 모두 붙일 수도 있습니다.
Crazy 8s는 한 페이지에 모든 아이디어를 담을 수 있는 훌륭한 방법입니다.
이젠 지금까지 배운 내용을 기반으로 세부 디자인을 할 차례입니다.디자인 정제하기
투표를 한 후에, 가장 많은 표를 받은 아이디어를 가지고 최종 아이디어를 스케치합니다. 동료에게 들은 다른 아이디어를 차용해도 됩니다. 10분 정도 시간을 가지고 이 태스크를 마무리합니다. 다 하고 나면 팀에게 아이디어를 발표하고 앞서 했던 것처럼 다시 투표를 합니다.
아이디어를 스토리보드에 그리기
스토리보드에는 종합적인 플로우에 아이디어와 스케치를 통합해서 넣습니다.지금까지 나온 디자인을 가지고 이제는 유저가 이용하는 내용을 담은 스토리를 만들 시간입니다. 이쯤 되면 유저가 밟게 될 다양한 스텝들에 대해 이미 생각했어야 합니다. 동료들의 디자인을 플로우에 집어넣는 것도 흔히 있는 일입니다. 유저의 경로가 갈라지는 지점까지 포함해서 각 단계를 명확하게 그려야 합니다. 디자인이 앞서 세웠던 목표에 부합하는지 확인하기 위해 프로젝트 맵으로 다시 돌아가서 살펴봐야 합니다.
프로토타입 만들기
프로토타입을 만드는 것은 완벽한 코드를 짜는 것이 아닙니다. 누군가 이용했을 때 그럴싸한 무언가를 만들면 됩니다. 프로토타입을 만드는 데는 사람마다 다양한 툴을 이용합니다.
Keynote나 Powerpoint를 이용하면 디자인 디테일보다는 플로우에 대해서 생각해보게 됩니다.
동작을 더 컨트롤할 수 있는 Balsamiq, Marvel, Framer 등과 같은 툴을 배우는 데 시간을 들이는 것도 괜찮습니다.
어떤 툴을 이용하건, 플로우에 초점을 맞추고 실제처럼 보이게 만들어야 합니다. 실제 사람을 대상으로 프로토타입을 테스트해야 하기 때문에 최대한 그럴듯하게 만들어야 하지만, 만드는 데 몇 주나 걸리면 안 됩니다.
프로토타입인 그럴싸하게 보일 정도로만 만들면 됩니다.프로토타입을 만드는 것은 시간과 진정성 사이의 균형을 맞추는 것이기 때문에 어느 한쪽에 지나치게 많이 편중되지 않게 해야 합니다. 어떤 쪽이 되든 결국 시간을 낭비하게 될 것입니다.
디자인의 사용성 테스트하기
테스팅 랩이 있다면 아주 좋습니다. 하지만 없어도, 만드는 것이 별로 어려운 일은 아닙니다. 유저가 방해받지 않는 편안한 환경을 만들어줄 마음만 있다면 말이죠.
테스팅에는 보통 한 명의 유저와 두 명 정도의 팀원이 참여하여 한 팀원은 노트필기를 하고 다른 팀원은 질문을 던집니다.
Hangouts 같은 앱을 이용하여 그들의 액션을 기록하는 것도 좋은 방법이며, 이렇게 하면 다른 방에 있는 나머지 팀원들도 쉽게 관찰할 수 있습니다. 야생에서 우리 디자인이 사용되는 모습을 보는 것은 앱을 만드는 사람들에게 상당히 두려운 일일 수 있습니다. 하지만 새로우면서도 정신이 번쩍 드는 경험이 될 것입니다.
물어볼 질문
디자인을 테스트할 때는, 유저에게 앱을 이용해 태스크를 수행해보라고 하고, 무엇을 하고 있고 왜 하는지 말로 설명하게 해야 합니다. 이상한 일 같아 보일 수도 있지만, 그들이 무슨 생각을 하는지 들어보는데 도움이 될 것입니다. 중간에 끼어들면 안 되고, 유저가 무엇을 해야 할지 모를 때도 알려주면 안 됩니다. 다 끝낸 후에 (혹은다 끝내지 못한 후에) 왜 그런 플로우를 택했는지만 물어봐야 합니다.
여러분이 알아내야 할 것은 다음과 같습니다.
유저는 프로토타입에서 무엇을 좋아했는가?
유저는 프로토타입에서 무엇을 싫어했는가?
어디에 문제가 있는가?
해당 플로우가 괜찮았던 이유는?
해당 플로우가 괜찮지 않았던 이유는?
무엇을 개선했으면 좋겠다고 하는가?
전반적인 디자인/플로우가 그들의 니즈를 충족하는가?
디자인을 바꾸고 다시 테스트를 진행하기
이제 작동하는 프로토타입과 피드백이 생겼습니다. 이제는 디자인을 고치고, 무엇이 괜찮았고 무엇이 괜찮지 않았는지 분석해볼 시간입니다. 완전히 새로운 와이어프레임 스토리보드와 새로운 프로토타입을 만드는 것을 두려워하지 마세요. 다시 시작하는 것이 기존 프로토타입에서 일부를 바꾸는 것보다 더 나은 플로우를 만들 수도 있습니다. 프로토타입에 불과하기 때문에 너무 귀하게 생각할 필요는 없습니다.
디자인이 마음에 들면 다시 한번 테스트해보고 더 고치면 됩니다. 프로토타입이 전혀 목표를 달성하지 못한 경우에는, 프로젝트가 실패했다고 생각할 수도 있습니다. 하지만 사실은 그렇지 않습니다. 실제로 디자인을 만든 경우보다 더 적은 개발 시간을 들이고도 유저가 실제로 무엇을 좋아하는지 알아냈기 때문입니다.
디자인 스프린트에는 ‘이기거나 배우거나’라는 철학이 있으니, 아이디어가 계획한 대로 흘러가지 않더라도 스스로를 너무 탓할 필요는 없습니다.
만들기!
지금까지 아이디어를 테스트해 보았습니다. 유저가 좋아했고요. 이해관계자들도 처음부터 참여했기 때문에 동의했습니다. 이제는 실제로 만들어볼 차례입니다. 이쯤 되면 무엇을 만들어야 하고 어떤 경험을 우선적으로 생각해야 하는지 명확히 알고 있어야 합니다.
프로젝트의 각각의 중요 단계에서 작업 내용을 검증하기 위해 사용성 테스트를 도입하면서 계속 일을 진행할 수도 있습니다.
올바른 해결책이 되지 않을 것에 많은 작업, 시간 노력을 들이기 전에 최대한 많은 것을 찾는 것이 얼마나 중요한지 더 이상 강조하지 않아도 잘 아실 겁니다.
이 글을 통해 UX의 기초와 그 중요성을 배우셨기를 바랍니다. UX는 디자이너나 리서처의 역할로만 여겨져서는 안 됩니다. 프로젝트에 관련된 모든 사람들의 책임이기 때문에 기회가 되는 모든 때에 참여하기를 권장합니다.
감사합니다.
전민수 UX 컨설턴트 소개
(UX 실무 경력: 27년차 UX 전문가: LG전자, 서울시청 등 약 300회 이상 UX 컨설팅 수행)
(UX 강사 경력: 23년차: 삼성, SK, KT 등 약 1,000회 이상 UX 강의 진행)
https://brunch.co.kr/@ebprux/1332
[실시간 Live 강좌] (PM/PO/UI/UX/리서치) 수강생 모집 중
(이비피알유엑스 라이브클래스에서 매월 최소 1개에서 최대 4개 강좌 (온라인) 줌 Live 강좌 진행) (PM/PO/UI/UX/리서치/UX 방법론&프로세스 프레임웍)
[VOD 강좌] (PM/PO/UI/UX/리서치) 수강생 모집 중
(인프런에서 총 20개 VOD UX 강좌를 오픈했습니다)
(PM/PO/UI/UX/리서치/UX 방법론&프로세스 프레임웍)
https://www.inflearn.com/users/196290
