UX 디자인의 기본사항을 단계별로 안내하는 가이드입니다.
이 도움말에서는 팀, 제품, 스타트업, 기업이 고객을 위한 더 나은 사용자 환경을 개발하기 위한 강력하고 의미 있는 프로세스를 만드는 데 도움이 되는 워크플로를 소개합니다. 프로세스의 여러 부분을 개별적으로 사용할 수도 있지만 일련의 단계로 사용하는 것이 가장 좋습니다.
이 가이드는 Google 전반의 여러 팀에서 자율주행 자동차 및 Project Loon과 같은 문제를 해결하기 위해 사용하는 디자인 스프린트 방법론을 많이 차용했습니다.
Double Diamond
이 흐름 작업은 UX계에서 영국 디자인위원회에서 대중화한 이중 다이아몬드라고 하는 것을 기반으로 합니다. 이중 다이아몬드에서는 팀이 연구를 통해 아이디어를 이해하기 위해 발산했다가 문제를 정의하기 위해 수렴하고, 개별적으로 스케치하기 위해 발산했다가 아이디어를 공유하고, 최선의 해결 방법을 결정하고, 테스트 및 검증합니다.

데이터 처리를 위한
가장 먼저 해결해야 할 근본적인 문제를 파악하고 '실제로 해결하려는 문제는 무엇인가요?'라는 질문을 던지면서 제안서처럼 작성합니다. 과제 문구는 목표가 포함된 프로젝트에 대해 설정하는 브리프입니다.
이 문제는 개선이 필요한 기존 제품 기능이거나 완전히 새로운 제품일 수 있습니다. 어떤 작업이든 달성하려는 목표에 맞게 언어를 조정하면 됩니다. 선언은 팀 목표와 연결되어야 하며, 시청자를 중심으로 하고, 짧고 명확해야 합니다.
다음은 제가 이전에 작업한 제품의 실제 사례입니다.
클러블풋 환자의 치료 및 후속 관리를 관리하는 시스템을 설계합니다.
복잡한 금융 시스템을 단순화하고 필수사항으로만 줄이는 앱을 만듭니다.
브랜드를 희생하지 않고 다양한 플랫폼에서 일관된 모바일 앱을 설계하세요.
챌린지 문구 업데이트
목표의 여러 변형을 작성한 후 팀에 제시하여 합의를 얻습니다. 팀에서 문제에 집중하는 데 도움이 되도록 기한을 포함하는 것이 좋습니다. 따라서 조정을 추가하면 위 목록은 다음과 같을 수 있습니다.
- 올해 1분기에 출시할 클러프풋이 있는 2세 미만 아동의 치료 및 후속 관리를 관리하는 시스템을 설계합니다.
- 금융에 대한 사전 지식 없이 버튼 하나만 탭하면 주식을 사고팔 수 있는 간단한 금융 앱을 만듭니다. 2017년 7월에 처음 출시되었습니다.
- 올해 말까지 여러 플랫폼에서 유연하게 적용되고 각 플랫폼에서 회사의 브랜드를 효과적으로 포지셔닝하는 디자인 가이드를 제작합니다.
과제 문구가 완성되면 작업하는 동안 볼 수 있도록 눈에 잘 띄는 곳에 표시합니다. 프로젝트 전반에서 지속적으로 참고하고 업데이트하거나 수정해야 할 수도 있습니다.
문제 확인
다음 단계는 문제를 조사하고 문제에 관해 알아보는 것입니다. 팀에서 문제를 이해하는 방식이 올바른지 확인해야 합니다. 종종 문제를 자신의 관점에서 바라보는 경우가 많습니다. 이는 기술 분야의 대부분의 사용자가 실제로는 전문가 수준의 사용자이고 소수의 사용자에 불과하므로 위험합니다. 소수의 목소리가 커서 실제로 문제가 아닌 것을 문제로 생각하게 될 수 있습니다.
챌린지 유효성을 검사하기 위해 데이터를 수집하는 방법에는 여러 가지가 있습니다. 각 방법은 팀과 사용자에 대한 액세스 권한에 따라 다릅니다. 목표는 당면한 문제를 더 잘 이해하는 것입니다.
이해관계자와의 내부 인터뷰

인터뷰 절차에는 마케팅팀부터 계정팀까지 회사의 각 팀원 및 이해관계자를 인터뷰하는 것이 포함됩니다. 이를 통해 실제 문제와 잠재적 해결 방법에 대한 사용자의 생각을 파악할 수 있습니다. 여기서 솔루션이란 기술적 솔루션이 아니라 회사 또는 제품에 가장 적합한 시나리오와 최종 목표를 의미합니다. 예를 들어 위의 '올해 말까지 의료 시설의 80% 에 클러프풋 소프트웨어를 보급'이라는 과제를 사용하는 것이 좋습니다.
한 가지 주의할 점이 있습니다. 이 검증 방법은 팀 토론과 공동작업을 방해하여 조직에 사일로식 분위기를 조성할 수 있으므로 가장 선호되지 않습니다. 그렇더라도 클라이언트와 설계 과제에 관한 유용한 정보를 얻을 수 있습니다.
짧은 발표

내부 인터뷰와 비슷하지만 이번에는 모든 이해관계자를 한 공간에 모읍니다. 그런 다음 이러한 이해관계자(마케팅, 영업, 디자인, 계정, 연구 등) 중 5~6명을 선발하여 각자 자신의 관점에서 과제에 대해 최대 10분 동안 발표하도록 합니다. 프레젠테이션에서 다루어야 하는 주제는 다음과 같습니다.
- 비즈니스 목표
- 담당자의 관점에서 프로젝트의 과제 (기술, 조사 수집, 디자인 제작 등)
- 현재 진행 중인 사용자 연구
끝에 5분 정도를 질문에 할애하고, 한 명이 메모를 작성합니다. 완료되면 새로운 학습 내용을 반영하도록 챌린지를 업데이트하는 것이 좋습니다. 목표는 제품 목표를 달성하는 데 도움이 되는 기능이나 흐름을 유도할 수 있는 글머리기호 목록을 수집하는 것입니다.
사용자 인터뷰

이는 사용자 여정, 문제점, 흐름을 파악하는 가장 좋은 방법일 수 있습니다. 사용자 인터뷰를 5회 이상 진행합니다. 액세스할 수 있는 경우 더 많이 진행합니다. 다음과 같은 질문을 할 수 있습니다.
- 기존 작업을 완료하려면 어떻게 해야 하나요? 예를 들어 위의 금융 앱 문제를 해결하려면 '지금 주식을 어떻게 구매하나요?'라고 물어볼 수 있습니다.
- 이 절차의 어떤 점이 마음에 드나요?
- 이 절차에서 어떤 점이 마음에 들지 않나요?
- 사용자가 현재 어떤 유사 제품을 사용하고 있나요?
- 고객이 원하는 것은 무엇인지,
- 싫어하는 것은 무엇인가요?
- 마술 지팡이가 있어 이 절차에 관해 한 가지를 바꿀 수 있다면 무엇을 바꾸고 싶으신가요?
인터뷰의 목적은 사용자가 겪고 있는 문제를 이야기하도록 유도하는 것입니다. 이 문제는 YouTube에서 논의할 사항이 아니므로 최대한 조용히 있어야 합니다. 이는 사용자가 말을 멈춘 경우에도 마찬가지입니다. 사용자가 생각을 정리하고 있을 수 있으므로 항상 잠시 기다립니다. 몇 초 동안 멈췄던 사람이 얼마나 계속 말하는지를 보면 놀랄 것입니다.
대화 중에 메모를 작성하고 가능하면 대화를 녹음하여 놓친 부분을 캡처하세요. 목표는 문제를 수집한 사용자 통계와 비교하는 것입니다. 일치하나요? 챌린지 문구를 업데이트하는 데 도움이 되는 점을 알게 되었나요?
민족지학 현장 연구

여기서는 사용자가 쇼핑하는 방식, 직장으로 이동하는 방식, SMS 메시지를 보내는 방식과 같은 작업을 하는 동안 현장에서 사용자를 관찰합니다. 사용자가 개발자가 듣고 싶어 하는 말을 한다고 생각하여 거짓말을 할 수 있기 때문입니다. 하지만 사용자가 직접 작업을 수행하는 모습을 관찰하면 유용한 정보를 얻을 수 있습니다. 기본적으로 교사는 간섭하지 않고 관찰하면서 학생이 쉽거나 어려운 부분, 놓쳤을 수 있는 부분을 기록합니다. 목표는 사용자의 환경에 몰입하여 사용자의 문제에 더 잘 공감하는 것입니다.
이 기법은 일반적으로 장기간에 걸쳐 수행되는 작업을 포함하며 연구원이 프로젝트의 이 부분을 이끌어야 합니다. 하지만 자연스러운 환경에서 연구 대상 집단을 관찰할 수 있으므로 가장 유용한 방법일 수 있습니다.
모두 모으기
프로젝트의 학습 단계를 완료한 후에는 과제를 한 번 더 살펴봐야 합니다. 올바른 방향으로 가고 있나요? 조정해야 할 사항이 있나요? 배운 내용을 모두 적어 카테고리별로 그룹화합니다. 이러한 목표는 해결하려는 문제에 따라 기능 또는 흐름의 기반이 될 수 있습니다. 챌린지를 업데이트하고 수정하는 데도 사용할 수 있습니다.
충분한 의견과 통계를 수집했다면 이제 그 지식을 프로젝트 맵을 만드는 데 적용할 때입니다.
프로젝트 맵
해결하려는 문제는 일반적으로 프로젝트 흐름에 이해관계가 있는 다양한 유형의 사용자 (또는 플레이어)로 구성됩니다. 학습한 내용을 바탕으로 가능한 플레이어를 나열해야 합니다. 사용자 유형 또는 이해관계자일 수 있습니다(예: '클러블풋을 치료하는 의사', '클러블풋 환자', '환자를 돌보는 간병인' 등). 각 참여자를 종이의 왼쪽에 적거나 액세스할 수 있는 경우 화이트보드에 적습니다. 오른쪽에 각 선수의 골을 기록합니다.
마지막으로 각 선수가 목표에 도달하는 데 필요한 걸음 수를 적습니다. 예를 들어 '클러블풋을 치료하는 의사'의 경우 목표는 '클러블풋 환자를 치료'하는 것이므로 '시스템에 환자를 등록', '의료 계획을 시작', '의료 상태 검토 주기 만들기', '의료 시술 수행' 등의 단계를 거칠 수 있습니다.

결과는 프로세스의 주요 단계가 포함된 프로젝트 맵입니다. 너무 많은 세부정보가 없는 프로젝트 개요라고 생각하면 됩니다. 또한 팀원이 지도와 챌린지 문구가 일치하는지 판단할 수 있습니다. 나중에 각 단계를 세분화할 때 더 자세히 설명할 예정입니다. 하지만 지금은 프로젝트 맵을 통해 사용자가 최종 목표를 달성하기 위해 취할 단계를 대략적으로 파악할 수 있습니다.
와이어프레임 및 스토리보드
Crazy 8s
이를 위해 종이를 두 번 접어 8개의 패널을 만드는 크레이지 8이라는 방법을 사용하는 것이 좋습니다. 그런 다음 각 패널에서 지금까지 배운 내용을 바탕으로 아이디어를 도출합니다. 10분 동안 8개의 패널을 모두 채울 아이디어를 생각해 봅니다. 20분 이상 시간을 두면 일을 미루고 커피를 만들거나 이메일을 확인하거나 팀원과 잡담을 하며 일을 피하게 될 수 있습니다. 이 단계에서는 긴박감을 조성하여 더 빠르고 효과적으로 작업하도록 유도해야 합니다.
팀으로 작업하는 경우 모든 구성원이 각자 자신의 리더십을 발휘하도록 합니다. 이 과정을 통해 두뇌가 활성화되고 과제에 관해 생각하게 됩니다. 일반적으로 스케치는 인터페이스 디자인 와이어프레임입니다.
그런 다음 나와 팀원 모두 아이디어를 그룹에 발표합니다. 모든 참가자는 8가지 아이디어를 각각 자세히 설명하고 특정 경로를 선택한 이유를 설명해야 합니다. 각 팀원에게 학습한 내용을 아이디어를 뒷받침하는 데 사용하라고 안내합니다. 모든 사람이 발표를 마치면 아이디어에 투표할 시간입니다. 각 사람은 스티키 도트 2개를 사용해 어떤 아이디어든 투표할 수 있습니다. 정말 마음에 드는 아이디어라면 두 표를 모두 한 아이디어에 줄 수 있습니다.


디자인 수정
투표가 끝난 후 가장 많은 표를 얻은 아이디어를 선택하여 최종 아이디어의 스케치를 작성합니다. 동료에게서 들은 다른 아이디어를 빌려올 수도 있습니다. 이 작업을 완료하는 데 10분 정도 더 걸릴 것 같습니다. 완료되면 아이디어를 다시 팀에 발표하고 이전과 같이 투표합니다.
아이디어 스토리보드

디자인이 완성되면 사용자와의 참여를 스토리보드로 작성합니다. 이 시점에서는 사용자가 수행하는 다양한 단계를 이미 생각해 보았을 것입니다. 동료의 디자인 중 하나를 흐름에 통합하는 것도 흔한 일입니다. 사용자가 달라질 수 있는 몇 가지 지점이 포함된 명확한 단계별 절차를 마련해야 합니다. 프로젝트 맵을 다시 참고하여 목표에 맞게 디자인을 검증합니다.
프로토타입 만들기
프로토타입을 만드는 것은 완벽한 코드를 만드는 것이 아니라 누군가 사용할 때 믿을 수 있는 무언가를 만드는 것입니다. 프로토타입을 만드는 데 사용되는 도구는 사람마다 다릅니다. 디자인 세부사항이 아닌 흐름을 생각하도록 강요하기 때문에 Keynote 또는 PowerPoint를 선호하는 디자이너도 있습니다. Balsamiq, Marvel, Framer와 같은 도구를 학습하는 데 시간을 투자하여 더 많은 동작을 제어할 수 있습니다. 어떤 도구를 사용하든 흐름에 집중할 수 있고 실제처럼 보이는 도구를 사용하세요. 실제 사용자를 대상으로 프로토타입을 테스트해야 하므로 최대한 믿을 수 있어야 하지만 만들기 위해 몇 주가 걸려서는 안 됩니다.

프로토타입을 만드는 것은 시간과 현실성 사이의 균형을 맞추는 것이므로 어느 한쪽으로 치우치지 않도록 주의하세요. 어느 쪽이든 시간을 낭비하게 될 수 있습니다.
디자인의 사용성 테스트
테스트 실험실이 있으면 좋습니다. 아직 없는 경우 사용자에게 방해가 되지 않는 편안한 환경을 만드는 데 주의를 기울이면 어렵지 않게 만들 수 있습니다. 테스트는 일반적으로 사용자와 팀원 2명(한 명은 메모를 작성하고 한 명은 질문을 함)이 참여합니다. 행아웃과 같은 앱을 사용해 사용자의 행동을 기록하는 것이 좋습니다. 나머지 팀원이 다른 방에서 관찰하도록 하려는 경우에도 유용합니다. 앱 제작자에게는 디자인이 실제로 사용되는 것을 확인할 수 있으므로 이러한 작업이 매우 두려울 수 있습니다. 상쾌하면서도 진지한 경험이 될 수 있습니다.

질문
디자인을 테스트할 때는 사용자에게 앱에서 작업을 수행해 달라고 요청하고 사용자가 수행하는 작업과 이유를 소리 내어 말하도록 합니다. 다소 이상한 행동이지만 아이의 생각을 듣는 데 도움이 됩니다. 문제가 발생했을 때 중단하거나 어떻게 해야 하는지 알려주지 마세요. 사용자가 특정 흐름을 완료한 후 (또는 완료하지 않은 후) 왜 해당 흐름을 사용했는지 물어보세요.
알아야 할 사항은 다음과 같습니다.
- 프로토타입에서 어떤 점이 마음에 드나요?
- 프로토타입에서 어떤 점이 마음에 들지 않나요?
- 어떤 문제가 있나요?
- 흐름이 작동한 이유
- 흐름이 작동하지 않는 이유
- 어떤 점을 개선하고 싶어 하나요?
- 전반적인 디자인/흐름이 요구사항을 충족하나요?
설계 검토 및 추가 테스트
의견이 포함된 작동하는 프로토타입이 있습니다. 이제 디자인을 수정하고 효과가 있었던 부분과 그렇지 않은 부분을 분석할 차례입니다. 완전히 새로운 와이어프레임 스토리보드를 만들고 새 프로토타입을 만드는 것을 두려워하지 마세요. 처음부터 다시 시작하면 이전 프로토타입에서 작업을 이동하려고 시도하는 것보다 더 나은 흐름을 만들 수 있습니다. 프로토타입일 뿐이므로 너무 소중하게 생각하지 마세요.
디자인에 만족하면 다시 테스트하고 조금 더 다듬을 수 있습니다. 프로토타입이 전혀 목표를 달성하지 못한 경우 프로젝트가 실패했다고 생각할 수 있습니다. 실제로는 그렇지 않습니다. 실제로 디자인을 빌드한 경우보다 개발 시간이 덜 소요되었을 수 있으며, 사용자의 실제 선호사항에 관해 더 많이 알 수 있습니다. 디자인 스프린트에서는 성공하거나 배우는 것이 중요하다는 철학을 가지고 있으므로 아이디어가 계획대로 작동하지 않더라도 너무 낙담하지 마세요.
만들기
아이디어를 테스트했습니다. 사용자가 좋아합니다. 이해관계자는 처음부터 참여했기 때문에 투자하고 있습니다. 이제 만들 차례입니다. 이제 무엇을 만들어야 하고 환경의 우선순위가 무엇인지 명확하게 파악했을 것입니다. 프로젝트의 각 주요 시점에서 작업을 검증하고 일정을 준수하는 데 도움이 되는 사용성 테스트를 도입하는 것이 좋습니다.
올바른 해결책이 아닐 수 있는 문제에 많은 시간과 노력을 들이기 전에 최대한 많은 정보를 파악하는 것이 얼마나 중요한지 강조할 수 없습니다.
이제 이 도움말을 통해 UX와 그 중요성에 관한 기본적인 지식을 얻으셨을 것입니다. UX는 디자이너나 연구원의 역할로 간주되어서는 안 됩니다. 실제로 프로젝트에 참여하는 모든 사람이 책임을 지므로 기회가 있을 때마다 참여하는 것이 좋습니다.