UX의 기초

UX 디자인의 기본사항을 단계별로 안내합니다.

이 도움말에서는 팀, 제품, 스타트업, 회사가 고객을 위한 더 나은 사용자 환경을 개발하기 위한 강력하고 의미 있는 프로세스를 만드는 데 도움이 되는 워크플로를 소개합니다. 프로세스의 여러 부분을 별도로 사용할 수 있지만 일련의 단계로 사용하는 것이 가장 좋습니다.

이 가이드는 Google 전반의 여러 팀에서 자율 주행 자동차프로젝트 Loon과 같은 문제를 해결하는 데 사용하는 디자인 스프린트 방법론을 많이 차용합니다.

Double Diamond

이 흐름 작업은 UX 업계에서 더블 다이아몬드라고 부르는 것을 기반으로 하며, 영국 디자인 위원회에서 널리 알려졌습니다. 팀이 연구를 통해 아이디어를 이해하기 위해 발산한 다음, 수렴하여 과제를 정의하고, 발산하여 개별적으로 스케치하고, 아이디어를 공유하고, 최선의 방법을 결정하고, 테스트하고 검증합니다.

프로젝트 단계에는 이해, 정의, 발산, 결정, 프로토타입, 검증이 포함됩니다.
영국 디자인 위원회가 개척한 '더블 다이아몬드' 디자인 프로세스 모델의 단계에는 프로젝트의 이해, 정의, 확산, 결정, 프로토타입, 검증 단계가 포함됩니다.

데이터 처리를 위한

가장 먼저 당면한 근본적인 문제를 파악하고 '내가 실제로 해결하려는 문제는 무엇인가?'라고 자문하면서 제안서처럼 작성합니다. 챌린지 설명은 목표를 포함하여 프로젝트에 설정하는 브리프입니다.

이 챌린지는 개선이 필요한 기존 제품 기능이나 완전히 새로운 제품을 위한 것일 수 있습니다. 어떤 작업을 하든 달성하려는 목표에 맞게 언어를 조정하면 됩니다. 이 문구는 팀 목표와 관련이 있어야 하며, 시청자에게 초점을 맞추고, 영감을 주며, 간결해야 합니다.

다음은 제가 과거에 작업한 제품의 실제 사례입니다.

  • 선천성 만곡족 환자의 치료 및 후속 관리를 위한 시스템을 설계하세요.

  • 복잡한 금융 시스템을 단순화하고 필수 요소로 축소하는 앱을 만드세요.

  • 브랜드를 희생하지 않고 다양한 플랫폼에서 일관된 모바일 앱을 디자인하세요.

챌린지 설명 업데이트

목표의 여러 변형을 작성한 후 팀에 제시하여 합의를 도출합니다. 팀이 문제에 집중할 수 있도록 기한을 포함하는 것이 좋습니다. 따라서 추가된 조정으로 위의 목록은 다음과 같을 수 있습니다.

  • 올해 1분기에 출시할 2세 미만 아동의 선천성 만곡족 치료 및 후속 관리 시스템을 설계해 줘.
  • 금융계에 대한 사전 지식 없이 버튼을 탭하여 주식을 사고팔 수 있는 간단한 금융 앱을 만들어 2017년 7월에 처음 출시합니다.
  • 올해 말까지 여러 플랫폼에서 유연하게 사용할 수 있고 각 플랫폼에서 회사의 브랜드를 효과적으로 포지셔닝하는 디자인 가이드를 제작해 줘.

챌린지 문장이 완성되면 작업하는 동안 볼 수 있도록 눈에 띄는 곳에 표시합니다. 프로젝트 전반에 걸쳐 지속적으로 참조해야 하며, 업데이트하거나 수정해야 할 수도 있습니다.

문제 확인

다음 단계는 문제를 조사하고 문제에 대해 알아보는 것입니다. 팀의 문제 이해가 타당한지 확인해야 합니다. 기술 분야에 종사하는 대부분의 사람은 실제로는 파워 사용자이며 소수의 사용자이기 때문에 문제를 자체 관점에서 바라보는 경우가 많으며 이는 위험합니다. 소수의 의견이 큰 목소리를 내는 경우도 있고, 문제가 아닌데 문제라고 생각하도록 속을 수도 있습니다.

챌린지를 검증하기 위해 데이터를 수집하는 방법은 다양합니다. 각 방법은 팀과 사용자 액세스 권한에 따라 달라집니다. 목표는 당면한 문제를 더 잘 이해하는 것입니다.

이해관계자와의 내부 인터뷰

이해관계자와의 인터뷰는 회사 또는 팀 전체에서 유용한 정보를 발견하는 데 도움이 될 수 있습니다.
이해관계자와의 인터뷰는 회사 또는 팀 전체에서 유용한 정보를 찾는 데 도움이 될 수 있습니다.

인터뷰 과정에는 마케팅부터 계정까지 회사 내 각 팀 구성원과 이해관계자를 인터뷰하는 과정이 포함됩니다. 이를 통해 실제 문제와 잠재적인 해결책에 대한 의견을 파악할 수 있습니다. 여기서 솔루션은 기술적 솔루션이 아니라 회사 또는 제품의 최적의 시나리오와 최종 목표를 의미합니다. 예를 들어 위의 과제를 사용하여 '연말까지 의료 시설의 80% 에 클럽풋 소프트웨어 설치'를 목표로 삼는 것이 좋습니다.

한 가지 주의사항이 있습니다. 이 검증 방법은 팀 토론과 공동작업을 방해하여 조직 내에 고립된 분위기를 조성할 수 있으므로 가장 선호되지 않습니다. 그럼에도 불구하고 클라이언트와 설계 문제에 관해 놓칠 수 있는 유용한 정보를 얻을 수 있습니다.

짧은 발표

번개 토크는 몇 분 동안만 진행되는 매우 짧은 프레젠테이션입니다.
번개 토크는 몇 분 정도만 지속되는 매우 짧은 프레젠테이션입니다.

내부 인터뷰와 비슷하지만 이번에는 모든 이해관계자를 한 방에 모읍니다. 그런 다음 이러한 이해관계자(마케팅, 영업, 디자인, 계정, 연구 등) 중 5~6명을 선택하여 각자 자신의 관점에서 10분 이내로 과제에 대해 이야기하도록 합니다. 프레젠테이션에서 다뤄야 하는 주제는 다음과 같습니다.

  • 비즈니스 목표
  • 프로젝트의 관점에서 본 과제 (기술, 연구 수집, 디자인 제작 등)
  • 현재 보유하고 있는 사용자 연구

마지막 5분은 질문을 위해 남겨두고, 선출된 사람이 회의 내내 메모를 합니다. 완료되면 새로운 학습을 반영하도록 챌린지를 업데이트하는 것이 좋습니다. 목표는 제품 목표를 달성하는 데 도움이 되는 기능이나 흐름을 유도할 수 있는 글머리 기호 목록을 수집하는 것입니다.

사용자 인터뷰

사용자 인터뷰는 특정 작업에서 사용자의 고충을 파악하는 데 유용합니다.
사용자 인터뷰는 특정 작업에서 사용자의 고충을 파악하는 데 유용합니다.

이는 사용자의 여정, 고충, 흐름을 파악하는 가장 좋은 방법일 수 있습니다. 최소 5명의 사용자 인터뷰를 진행합니다. 더 많은 사용자를 인터뷰할 수 있다면 더 많이 진행합니다. 다음과 같은 질문을 해야 합니다.

  • 기존 작업을 완료하려면 어떻게 해야 하나요? 예를 들어 위의 금융 앱의 문제를 해결하고 싶다면 '현재 주식과 주식을 어떻게 구매하시나요?'라고 물어볼 수 있습니다.
  • 이 흐름의 어떤 점이 마음에 드나요?
  • 이 흐름에서 어떤 점이 마음에 들지 않나요?
  • 사용자가 현재 사용 중인 유사한 제품은 무엇인가요?
    • 고객이 원하는 것은 무엇인지,
    • 어떤 점을 싫어하나요?
  • 마법 지팡이가 있어서 이 절차에서 한 가지를 바꿀 수 있다면 무엇을 바꾸시겠어요?

인터뷰의 목적은 사용자가 겪고 있는 문제에 대해 말하도록 하는 것입니다. 이것은 여러분의 토론 주제가 아니므로 최대한 조용히 있어야 합니다. 사용자가 말을 멈추더라도 생각을 정리하고 있을 수 있으므로 항상 잠시 기다리세요. 몇 초 동안 멈춘 후에도 계속 말하는 사람이 얼마나 많은지 알면 놀라실 겁니다.

전체적으로 메모를 하고 놓친 부분을 파악할 수 있도록 대화를 녹음하는 것이 좋습니다. 목표는 챌린지를 수집한 사용자 통계와 비교하는 것입니다. 일치하나요? 챌린지 설명을 업데이트하는 데 도움이 되는 내용을 알게 되었나요?

민족지학 현장 연구

자연스러운 환경에서 사용자를 관찰하면 사용자가 자신의 문제를 어떻게 해결하는지 파악하는 데 도움이 됩니다.
사용자가 자연스러운 환경에서 자신의 문제를 해결하는 방식을 파악하는 것이 좋습니다.

이 단계에서는 사용자가 쇼핑하는 방법, 출퇴근하는 방법, SMS 메시지를 보내는 방법 등과 같은 작업을 할 때 현장에서 사용자를 관찰합니다. 그 이유는 사람들이 듣고 싶어 하는 내용을 말하는 경우가 있기 때문입니다. 하지만 사용자가 직접 작업을 수행하는 것을 지켜보면 유용한 정보를 얻을 수 있습니다. 기본적으로 방해하지 않고 관찰하면서 쉽거나 어려운 점, 놓친 점을 기록합니다. 목표는 사용자의 환경에 몰입하여 사용자의 고충에 더 잘 공감하는 것입니다.

이 기법은 일반적으로 장기간에 걸쳐 수행되는 작업을 포함하며 연구자가 프로젝트의 이 부분을 주도해야 합니다. 하지만 자연스러운 환경에서 연구 대상인 그룹을 볼 수 있으므로 가장 통찰력 있는 방법일 수도 있습니다.

모두 모으기

프로젝트의 학습 단계를 완료한 후에는 과제를 마지막으로 살펴봐야 합니다. 올바른 길을 가고 있나요? 조정해야 할 사항이 있나요? 배운 내용을 모두 적고 카테고리로 그룹화합니다. 해결하려는 문제에 따라 기능이나 흐름의 기반이 될 수 있습니다. 또한 챌린지를 업데이트하고 수정하는 데 사용할 수도 있습니다.

충분한 피드백과 통계를 확보했다면 이제 그 지식을 활용하여 프로젝트 지도를 만들 차례입니다.

프로젝트 지도

해결하려는 문제는 일반적으로 프로젝트 흐름에 이해관계가 있는 다양한 유형의 사람 (또는 플레이어)으로 구성됩니다. 학습한 내용을 바탕으로 가능한 플레이어를 나열해야 합니다. 사용자 유형이나 이해관계자일 수 있습니다(예: '선천성 만곡족을 치료하는 의사', '선천성 만곡족 환자', '환자를 돌보는 간병인' 등). 종이의 왼쪽이나 화이트보드에 각 플레이어를 적습니다. 오른쪽에는 각 플레이어의 골을 적습니다.

마지막으로 각 플레이어가 목표에 도달하는 데 필요한 걸음 수를 적습니다. 예를 들어 '선천성 내반족을 치료하는 의사'의 목표는 '선천성 내반족 환자 치료'이므로 단계는 '시스템에 환자 등록', '의료 계획 시작', '의료 건강 검토 주기 생성', '의료 절차 수행'이 될 수 있습니다.

프로젝트 맵은 흐름에 있는 각 사용자 또는 플레이어의 주요 단계를 표시합니다.
프로젝트 맵은 흐름에 있는 각 사용자 또는 플레이어의 주요 단계를 표시합니다.

결과는 프로세스의 주요 단계가 포함된 프로젝트 맵입니다. 세부정보가 너무 많지 않은 프로젝트 개요라고 생각하면 됩니다. 또한 팀원이 지도가 챌린지 설명과 일치하는지 판단할 수 있습니다. 나중에 각 단계를 분석할 때 더 자세한 내용이 표시됩니다. 하지만 현재 프로젝트 지도는 사용자가 최종 목표를 달성하기 위해 거치는 단계를 개략적으로 보여줍니다.

와이어프레임 및 스토리보드

Crazy 8s

이를 위해 종이를 두 번 접어 8개의 패널이 나오도록 하는 크레이지 8s라는 방법을 추천합니다. 그런 다음 각 패널에서 지금까지 배운 내용을 바탕으로 아이디어를 도출합니다. 8개 패널을 모두 채울 아이디어를 떠올리는 데 10분을 할애하세요. 20분 이상 시간을 주면 미루기 시작하고, 커피를 만들고, 이메일을 확인하고, 팀과 일반적인 대화를 나누고, 기본적으로 작업을 피하게 될 수 있습니다. 이 단계에서는 긴박감을 조성하는 것이 좋습니다. 그래야 더 빠르고 효과적으로 작업할 수 있기 때문입니다.

팀과 함께 작업하는 경우 모든 팀원도 자신의 작업을 수행하도록 합니다. 이 과정을 통해 두뇌를 활성화하고 과제에 대해 생각할 수 있습니다. 일반적으로 스케치는 인터페이스 디자인 와이어프레임입니다.

그런 다음 나와 팀의 모든 구성원이 그룹에 아이디어를 발표합니다. 모든 참가자는 8가지 아이디어를 각각 자세히 설명하고 특정 경로를 선택한 이유를 설명해야 합니다. 각 팀원에게 학습 내용을 아이디어의 근거로 사용하도록 상기시킵니다. 모든 사람이 발표를 마치면 아이디어에 투표할 시간입니다. 각자 스티커 2개를 받아 아이디어에 투표할 수 있습니다. 정말 마음에 드는 아이디어가 있다면 두 표를 모두 한 아이디어에 줄 수 있습니다.

Crazy 8s는 모든 아이디어를 한 페이지에 담는 좋은 방법입니다.
Crazy 8은 모든 아이디어를 한 페이지에 모으는 좋은 방법입니다.
이제 학습한 내용을 바탕으로 자세한 설계를 해야 합니다.
이제 학습한 내용을 바탕으로 자세한 설계를 해야 합니다.

디자인 수정

투표가 끝나면 가장 많은 표를 얻은 아이디어를 선택하여 최종 아이디어를 스케치합니다. 동료로부터 들은 다른 아이디어를 차용할 수도 있습니다. 이 작업을 완료하는 데 10분을 더 할애하세요. 완료되면 이전과 같이 팀에 아이디어를 발표하고 투표합니다.

아이디어 스토리보드

스토리보드는 스케치와 아이디어를 포괄적인 흐름으로 결합하는 작업입니다.
스토리보드는 스케치와 아이디어를 결합하여 포괄적인 흐름을 만드는 과정입니다.

디자인이 준비되면 사용자와의 상호작용을 스토리보드로 만들 차례입니다. 이 시점에서는 사용자가 취하는 다양한 단계를 이미 생각해 보셨을 것입니다. 동료의 디자인을 흐름에 통합하는 것도 흔한 일입니다. 사용자가 다를 수 있는 지점이 포함된 명확한 단계별 프로세스를 원합니다. 프로젝트 지도를 다시 참조하여 목표에 맞게 설계를 검증합니다.

프로토타입 만들기

프로토타입을 만드는 것은 완벽한 코드를 만드는 것이 아니라 누군가가 사용할 때 믿을 수 있는 것을 만드는 것입니다. 프로토타입을 만드는 데 사용되는 도구는 사람마다 다릅니다. 흐름을 생각하게 하고 디자인 세부정보를 생각하지 않아도 되는 Keynote나 PowerPoint를 선호하는 사람도 있습니다. Balsamiq, Marvel, Framer와 같은 도구를 학습하는 데 시간을 투자하면 동작을 더 세밀하게 제어할 수 있습니다. 어떤 도구를 사용하든 흐름에 집중하고 실제처럼 보이는 도구를 사용하세요. 실제 사용자를 대상으로 프로토타입을 테스트해야 하므로 최대한 사실적으로 만들어야 하지만, 동시에 만드는 데 몇 주가 걸려서는 안 됩니다.

프로토타입은 신뢰할 수 있을 만큼 실제와 유사해야 합니다.
프로토타입은 신뢰할 수 있을 만큼 실제와 유사해야 합니다.

프로토타입을 만드는 것은 시간과 현실 사이의 균형을 맞추는 것이므로 어느 한쪽으로 너무 치우치지 않도록 주의하세요. 어떤 경우든 시간을 낭비할 수 있습니다.

디자인의 사용성 테스트

테스트 실험실이 있으면 좋습니다. 사용자의 집중을 방해하지 않는 편안한 환경을 조성하는 데 유의한다면 만드는 것은 어렵지 않습니다. 테스트에는 일반적으로 사용자 1명과 팀원 2명이 참여하며, 한 명은 메모를 하고 다른 한 명은 질문을 합니다. 행아웃과 같은 앱을 사용하여 사용자의 작업을 녹화하는 것이 좋습니다. 다른 방에서 팀원들이 관찰하도록 하려는 경우에도 유용합니다. 앱 제작자로서 디자인이 실제로 사용되는 것을 보면 꽤 무서울 수 있습니다. 상쾌하면서도 진지한 경험이 될 수 있습니다.

스토리보드는 모든 스케치와 아이디어를 종합적인 흐름으로 통합하는 작업입니다.
스토리보드는 모든 스케치와 아이디어를 종합적인 흐름으로 통합하는 작업입니다.

질문

디자인을 테스트할 때는 사용자에게 앱에서 작업을 수행하도록 요청하고 사용자가 무엇을 하고 있는지, 왜 하고 있는지를 소리 내어 말하도록 합니다. 이상한 일이지만 상대방이 생각하는 것을 듣는 데 도움이 됩니다. 막혔을 때 방해하거나 어떻게 해야 하는지 알려주지 마세요. 고객이 완료한 (또는 완료하지 않은) 후 특정 흐름을 선택한 이유를 물어보면 됩니다.

확인해야 할 사항은 다음과 같습니다.

  • 프로토타입에서 마음에 드는 점은 무엇인가요?
  • 프로토타입에서 마음에 들지 않는 점은 무엇인가요?
  • 고충은 무엇인가요?
    • 흐름이 작동한 이유
    • 흐름이 작동하지 않은 이유
  • 무엇을 개선하고 싶어 하나요?
  • 전반적인 디자인/흐름이 사용자의 요구사항을 충족하나요?

설계 및 추가 테스트 검토

의견이 반영된 작동하는 프로토타입이 있습니다. 이제 디자인을 수정하고 효과가 있었던 부분과 그렇지 않았던 부분을 분석할 차례입니다. 완전히 새로운 와이어프레임 스토리보드를 만들고 새로운 프로토타입을 만드는 것을 두려워하지 마세요. 이전 프로토타입에서 항목을 이동하려고 하는 것보다 처음부터 다시 시작하는 것이 더 나은 흐름을 만들 수 있습니다. 프로토타입일 뿐이므로 너무 소중하게 여기지 마세요.

디자인에 만족하면 다시 테스트하고 좀 더 다듬을 수 있습니다. 프로토타입이 전혀 적중하지 못한 경우 프로젝트가 실패했다고 생각할 수 있습니다. 실제로는 그렇지 않습니다. 실제로 디자인을 빌드한 경우보다 개발 시간을 적게 사용했을 가능성이 높으며 사용자가 실제로 좋아하는 것에 대해 더 잘 알 수 있습니다. 디자인 스프린트에는 승리하거나 배우는 철학이 있으므로 아이디어가 계획대로 작동하지 않더라도 너무 자책하지 마세요.

만들어 보세요.

아이디어를 테스트했습니다. 사용자가 좋아합니다. 이해관계자는 처음부터 참여했기 때문에 투자를 받습니다. 이제 물건을 만들 차례입니다. 이제 무엇을 만들어야 하고 환경의 우선순위가 무엇인지 명확하게 파악해야 합니다. 프로젝트의 각 주요 시점에서 유용성 테스트를 도입하여 작업을 검증하고 진행 상황을 추적할 수 있습니다.

올바른 솔루션이 아닐 수도 있는 문제에 많은 작업, 시간, 에너지를 쏟기 전에 최대한 많은 정보를 파악하는 것이 얼마나 중요한지 강조해도 지나치지 않습니다.

이제 이 도움말을 통해 UX와 그 중요성에 대한 기본적인 이해를 얻으셨을 것입니다. UX는 디자이너나 연구원의 역할로 간주해서는 안 됩니다. 실제로 프로젝트에 참여하는 모든 사람의 책임이므로 기회가 있을 때마다 참여하는 것이 좋습니다.