UX 디자인의 기본 사항에 대한 단계별 안내입니다.
이 문서에서는 팀, 제품, 스타트업, 회사에서 고객을 위해 더 나은 사용자 환경을 개발하기 위한 강력하고 의미 있는 프로세스를 만드는 데 도움이 되는 워크플로를 소개합니다. 프로세스의 여러 부분을 개별적으로 사용할 수도 있지만, 일련의 단계로서 가장 효과적으로 작동하는 것이 가장 좋습니다.
이 가이드에서는 Google의 여러 팀에서 자율주행 자동차 및 Project Loon과 같은 문제를 해결하고 해결하는 데 사용하는 디자인 스프린트 방법론을 많이 차용합니다.
더블 다이아몬드
이 흐름 작업은 UX 서클의 이중 다이아몬드를 기반으로 합니다. 이 이중 다이아몬드는 British Design Council에서 인기를 얻은 것으로, 팀은 연구를 통해 아이디어를 이해한 후 서로 모여 문제를 정의하고, 아이디어를 개별적으로 스케치하고, 아이디어를 공유하고, 가장 적합한 방법을 결정하고, 테스트하고, 검증합니다.
데이터 처리를 위한
먼저 당면한 근본적인 과제부터 시작하여 '내가 실제로 해결하려는 문제가 무엇인가?'라고 자문해 보는 식으로 내용을 작성합니다. 과제 설명문은 목표를 포함하는 프로젝트의 계획서입니다.
개선이 필요한 기존 제품 기능이 문제일 수도 있고, 완전히 새로운 제품일 수도 있습니다. 어떤 작업이든 달성하려는 목표에 맞게 언어를 조정하면 됩니다. 팀 목표와 연결되고 청중에 중점을 두고 영감을 주고 간결해야 합니다.
다음은 이전에 작업했던 제품의 몇 가지 실제 사례입니다.
클럽발 환자의 치료와 후속 치료를 관리하기 위한 시스템을 설계합니다.
복잡한 금융 시스템을 간소화하고 필수적인 요소로 축소하는 앱을 만듭니다.
브랜드 가치를 해치지 않고 다양한 플랫폼에서 일관된 모바일 앱을 디자인합니다.
과제 설명문 업데이트
목표의 변형을 여러 개 작성한 후에는 팀원들에게 이를 제시하여 동의를 얻습니다. 팀이 문제에 집중할 수 있도록 기한을 포함하는 것이 좋습니다. 여기에 조정을 추가하면 위의 목록이 다음과 같이 될 수 있습니다.
- 올해 1분기 출시를 목표로, 만 2세 미만 내반족 환아의 치료와 후속 간호를 관리하기 위한 시스템을 설계합니다.
- 2017년 7월에 최초 출시된 금융 세계에 대한 사전 지식 없이 버튼을 탭하여 주식을 사고팔 수 있는 간단한 금융 앱을 만듭니다.
- 올해 말까지 여러 플랫폼에서 유연하게 사용할 수 있고 각 플랫폼에서 회사의 브랜드를 효과적으로 포지셔닝하는 디자인 가이드를 제작합니다.
과제 설명문이 완성되면 작업하는 동안 볼 수 있도록 눈에 잘 띄는 위치에 표시합니다. 이를 지속적으로 다시 참조해야 하며 프로젝트 진행 중에 업데이트하거나 수정할 수도 있습니다.
문제 검증
다음 단계는 도전과제를 조사하고 문제에 대해 알아보는 것입니다. 따라서 팀이 문제를 제대로 이해하고 있는지 확인해야 합니다. 우리는 종종 각자의 관점에서 문제를 바라봅니다. 이는 대부분의 기술자가 실제로 파워 유저이고 사실상 소수 사용자이기 때문에 위험합니다. 우리는 목소리만 큰 소수이므로 실제로는 문제가 되지 않는데 문제가 있다고 착각할 수 있습니다.
문제를 검증하기 위한 데이터 수집 방법은 다양합니다. 각 방법은 팀과 사용자 액세스 권한 여부에 따라 다릅니다. 목표는 당면한 문제를 더 잘 이해하는 것입니다.
이해관계자와의 내부 인터뷰
면접 프로세스에는 마케팅에서 계정에 이르기까지 회사의 각 팀원 및 이해관계자와의 면담이 포함됩니다. 이렇게 하면 그들이 생각하는 실제 과제가 무엇인지, 잠재적 해결책이 무엇이라고 생각하는지 찾는 데 도움이 됩니다. 여기서 말하는 솔루션은 기술 솔루션이 아니라 회사 또는 제품의 최선의 사례 시나리오와 최종 목표입니다. 예를 들어 '올해 말까지 의료 시설의 80% 에 내반족 소프트웨어를 배포'하는 위의 도전과제를 사용하는 것은 훌륭한 목표가 될 수 있습니다.
한 가지 주의할 점이 있습니다. 이러한 검증 방법은 팀 토론과 공동작업을 방지하여 조직에 고립된 분위기를 만들 수 있으므로 가장 바람직하지 않습니다. 그럼에도 불구하고 이러한 방법을 사용하면 다른 방법으로는 놓칠 수 있는 클라이언트 및 디자인 과제에 대한 몇 가지 유용한 정보를 얻을 수 있습니다.
짧은 발표
내부 인터뷰와 유사하지만, 이번에는 모든 이해관계자를 한 곳으로 모이게 됩니다. 그런 다음 마케팅, 영업, 디자인, 계정, 리서치 등 5~6명의 이해관계자를 선출하여 각자의 관점에서 챌린지를 최대 10분 동안 집중적으로 설명합니다. 프레젠테이션에서 다루어야 하는 주제는 다음과 같아야 합니다.
- 비즈니스의 목표
- 개발자의 관점에서 본 프로젝트의 과제 (기술, 연구 수집, 디자인 제작 등이 될 수 있음)
- 현재 진행 중인 사용자 연구
마지막에 5분 동안 질문을 하고 선출된 담당자가 전체 내용을 기록해 둡니다. 작업을 마쳤으면 새로 알게 된 내용을 반영하여 과제를 업데이트할 수 있습니다. 제품 목표를 달성하는 데 도움이 되는 기능이나 흐름을 이끌 수 있는 글머리 기호 목록을 수집하는 것이 목표입니다.
사용자 인터뷰
사용자의 여정, 고충사항, 흐름을 파악하는 가장 좋은 방법일 것입니다. 최소 5개의 사용자 인터뷰를 준비하고, 액세스할 수 있다면 더 많이 준비합니다. 다음과 같은 종류의 질문을 포함해야 합니다.
- 기존 작업을 어떻게 완료하나요? 예를 들어 위의 금융 앱에 대한 과제를 해결하고 싶다고 가정해 보겠습니다. '지금은 주식과 주식을 어떻게 사나요?'
- 이 흐름의 어떤 점이 마음에 드나요?
- 이 흐름에 대해 마음에 들지 않는 점
- 사용자가 현재 사용하고 있는 유사한 제품은 무엇인가요?
- 고객이 원하는 것은 무엇인지,
- 무엇을 싫어하나요?
- 만약 '마법 지팡이'가 있어서 이 과정의 한 가지를 바꿀 수 있다면 어떻게 해야 할까요?
면접의 개념은 사용자가 자신이 겪고 있는 어려움에 대해 이야기하도록 하는 것입니다. 토론의 장이 아니기 때문에 최대한 말을 아끼지 말아야 합니다. 이는 사용자가 말을 멈출 때도 마찬가지입니다. 항상 사용자가 의견을 수집할 수 있도록 잠시 기다립니다. 몇 초 동안 멈춘 후에도 계속 말을 많이 하는 사람에게 놀랄 것입니다.
전체 내용을 메모하고 놓쳤을 수 있는 내용을 포착할 수 있도록 가능한 경우 대화를 녹음합니다. 수집한 사용자 통계와 과제를 비교하는 것이 목표입니다 의견이 일치하나요? 과제 설명문을 업데이트하는 데 도움이 되는 점을 알게 되었나요?
민족학 분야 연구
사용자가 쇼핑하는 방식, 출근하는 방식, SMS 메시지를 전송하는 방법 등을 맥락에 두고 현장에서 사용자의 상황을 관찰합니다. 그 이유는 사람들이 듣고 싶어 한다고 생각하는 내용을 말하는 경우도 있기 때문입니다. 하지만 사용자가 스스로 행동과 작업을 수행하는 것을 관찰하는 것이 도움이 될 수 있습니다 기본적으로 여러분은 간섭하지 않고 관찰하면서 사용자가 쉽거나 어렵다고 느끼는 점과 놓쳤을 수도 있는 부분을 기록합니다. 사용자의 고충에 보다 잘 공감할 수 있도록 사용자의 환경에 몰입하는 것이 목표입니다.
이 기법은 일반적으로 장기간에 걸쳐 수행되는 일부 작업을 수반하며 연구원이 프로젝트에서 이 부분을 주도해야 합니다. 하지만 자연스러운 환경에서 공부하는 사람들의 그룹을 볼 때 가장 큰 통찰력일 것입니다.
종합적으로 분석한 결과
프로젝트의 학습 단계를 완료하면 과제를 마지막으로 한 번 더 검토해야 합니다. 잘하고 있나요? 조정해야 할 사항이 있나요? 알게 된 모든 내용을 기록하고 카테고리로 분류합니다. 이러한 자료는 해결하려는 문제에 따라 기능이나 흐름의 기반이 될 수 있습니다. 과제를 업데이트하고 수정하는 데 사용할 수도 있습니다.
의견과 통찰력이 충분하다면 이제 이 지식을 적용하여 프로젝트 맵을 만들 차례입니다.
프로젝트 맵
해결하려는 문제는 일반적으로 각자 프로젝트 흐름에서 이해관계가 있는 다양한 유형의 사람 (또는 플레이어)으로 구성됩니다. 학습한 내용을 바탕으로 가능한 플레이어를 나열해야 합니다. 예를 들어 '내반족을 치료하는 의사', '만곡족 환자', '환자를 돌보는 간병인' 등 사용자 유형이나 이해관계자가 될 수 있습니다. 각 선수를 종이 왼쪽이나 화이트보드에 적습니다. 오른쪽에는 각 참가자의 목표를 적으세요.
마지막으로, 각 참가자가 목표를 달성하는 데 필요한 단계의 수를 기록합니다. 예를 들어 '내반족을 치료하는 의사'의 목표는 '내반족 환자 치료'이고, 단계는 '시스템에 환자 등록', '의료 계획 시작', '의료 건강 검토 주기 만들기', '의료 시술 수행'이 될 수 있습니다.
그 결과로 프로세스의 주요 단계가 표시된 프로젝트 맵이 생성됩니다. 프로젝트 개요라고 생각해 보세요 또한 팀원들이 맵이 과제 설명문과 일치하는지 판단할 수 있습니다. 나중에 각 단계를 분석하면 더 자세한 정보를 얻을 수 있습니다. 하지만 지금은 프로젝트 맵을 통해 사용자가 최종 목표를 완료하기 위해 거쳐야 하는 단계를 개략적으로 확인할 수 있습니다.
와이어프레이밍 및 스토리보드
크레이지 8
이를 위해 종이를 두 번 접어 8개의 패널이 되도록 하는 crazy 8s라는 방법을 사용하는 것이 좋습니다. 그런 다음 각 패널에 지금까지 배운 모든 것을 바탕으로 아이디어를 그리세요. 10분 동안 여덟 개의 패널을 모두 채울 아이디어를 떠올려보십시오. 스스로에게 20분 넘게 시간이 걸릴 경우, 미루기 시작하고, 커피를 마시고, 이메일을 확인하고, 팀과 일반적인 대화를 나누고, 본질적으로 업무 수행을 피하게 될 수 있습니다. 이 단계에서는 더 빠르고 효과적으로 작업할 수 있도록 긴박감을 조성하는 것이 좋습니다.
팀으로 작업하는 경우 모든 팀원들도 각자 팀으로 일할 수 있게 하세요. 이 과정을 통해 두뇌가 시작되며 도전과제에 대해 생각하게 됩니다. 일반적으로 스케치는 인터페이스 디자인 와이어프레임입니다.
이후에 여러분과 모든 팀원이 각자의 아이디어를 그룹에 발표합니다. 모든 사람이 8가지 아이디어를 각각 자세히 설명하고 특정 과정을 선택한 이유를 설명해야 합니다. 각 팀원에게 학습 내용을 바탕으로 자신의 아이디어에 대한 근거를 제시하도록 안내합니다. 모든 사람이 발표를 마쳤으면 아이디어에 투표할 차례입니다. 각 참가자는 스티커 2개를 받게 되고 원하는 아이디어에 투표할 수 있습니다. 정말 마음에 들면 한 아이디어에 두 표를 모두 투표해도 됩니다.
디자인 다듬기
투표 후 가장 많은 표를 얻은 아이디어를 바탕으로 최종 아이디어를 구상합니다. 동료에게서 들은 다른 아이디어에서도 빌릴 수 있습니다. 이 작업을 완료하는 데 10분 더 걸릴 수 있습니다. 완료되면 다시 팀원에게 아이디어를 발표하고 이전과 같이 투표하세요.
아이디어를 스토리보드로 만들기
디자인을 통해 사용자 참여를 스토리보드로 만들 차례입니다. 이제 사용자가 취하는 다양한 단계에 대해 이미 생각해 보셨을 것입니다. 동료가 설계한 것 중 하나를 흐름에 통합하는 것도 매우 일반적입니다. 사용자가 갈라질 수 있는 일부 지점이 있는 명확한 단계별 프로세스가 있어야 합니다. 프로젝트 맵을 다시 참조하여 디자인이 목표에 부합하는지 확인하세요.
프로토타입 만들기
프로토타입을 만드는 것은 완벽한 코드를 만드는 것이 아니라 누구나 사용할 수 있을 정도로 믿을 수 있는 무언가를 만드는 것입니다. 프로토타입을 만드는 데 사용되는 도구는 사람마다 다릅니다. Keynote나 PowerPoint와 같은 도구는 디자인 세부 사항이 아닌 흐름에 대해 생각하도록 만드는 도구입니다. Balsamiq, Marvel, Framer와 같은 더 많은 동작 컨트롤을 제공할 수 있는 학습 도구에 시간을 투자하는 것이 좋습니다. 어떤 도구를 사용하든 흐름에 집중하고 실제 모습이 보여야 합니다. 실제 사용자를 대상으로 프로토타입을 테스트해야 하므로 가능한 한 믿고 쓸 수 있어야 하지만 동시에 만드는 데 몇 주가 걸리지 않습니다.
프로토타입을 만드는 것은 시간과 현실의 균형을 잘 맞춰야 하므로 어느 한쪽으로 너무 치우치지 않도록 주의하세요. 어떤 방법을 사용하든, 결국 시간 낭비가 될 수 있습니다.
디자인의 사용성 테스트
테스트 실험실이 있으면 좋을 것 같습니다. 그렇지 않은 경우 사용자를 위해 방해되지 않는 쾌적한 환경을 조성하는 데 주의를 기울인다면 새로 만드는 것이 어렵지 않습니다. 테스트에는 보통 사용자와 팀원 2명이 참여하며, 한 명은 메모하고, 다른 한 명은 질문을 합니다. 행아웃과 같은 앱을 사용하여 활동을 기록하는 것이 좋습니다. 이렇게 하면 나머지 팀원이 다른 방에서 관찰할 때도 편리합니다. 이는 앱 제작자가 현장에서 설계하는 것을 볼 때 매우 두려운 일일 수 있습니다. 상쾌하고 냉정한 경험이 될 수 있습니다.
질문
디자인을 테스트할 때는 사용자에게 앱에서 작업을 실행하고 수행 중인 작업과 이유를 소리내어 말하도록 요청합니다. 이상하게 보이긴 하지만, 그러면 그들의 생각을 듣는 데 도움이 됩니다. 학생이 막힐 때 끼어들거나 어떻게 해야 하는지 알려주지 마세요. 특정 흐름을 따랐거나 완료하지 않은 이유를 물어보기만 하면 됩니다.
알아야 할 사항은 다음과 같습니다.
- 프로토타입의 어떤 점이 마음에 드나요?
- 사용자가 프로토타입에 대해 마음에 들지 않는 점
- 어떤 고충이 있나요?
- 흐름이 효과가 있었던 이유
- 흐름이 작동하지 않는 이유
- 어떤 점을 개선하려고 하나요?
- 전반적인 디자인/흐름이 사용자의 요구를 충족하나요?
디자인 재검토 및 테스트 한 번 더 진행
제대로 작동하는 프로토타입이 있고 의견이 있으면 이제 디자인을 수정하고 효과가 있었던 부분과 그렇지 않은 부분을 분석할 차례입니다 완전히 새로운 와이어프레임 스토리보드를 만들고 새 프로토타입을 만드는 것을 두려워하지 마세요. 처음부터 다시 시작하면 이전 프로토타입을 변경하려고 하는 것보다 나은 흐름을 만들 수 있습니다. 프로토타입일 뿐이므로 너무 아끼지 마세요.
디자인이 만족스러우면 다시 테스트하고 좀 더 미세 조정할 수 있습니다. 프로토타입이 목표를 전혀 달성하지 못했다면 프로젝트가 실패했다고 생각할 수 있습니다. 실제로는 그렇지 않습니다. 실제로 설계한 경우보다 개발 시간이 적고 사용자의 실제 취향을 더 잘 알 수 있습니다. 디자인 스프린트를 통해 얻는 철학이 우승자가 되거나 배움을 얻는다는 철학이 있습니다. 그러니 아이디어가 계획대로 되지 않았다고 해서 너무 자책하지 마세요.
도전해 보세요!
지금까지 아이디어를 테스트했습니다. 사용자가 마음에 들어 합니다. 이해관계자는 처음부터 함께해 왔기 때문에 투자되는 것입니다 이제 뭔가를 만들어 낼 차례입니다. 이제 무엇을 만들어야 하고 환경의 우선순위를 명확하게 할 수 있을 것입니다. 프로젝트의 각 주요 시점에서 작업을 검증하고 순조롭게 진행하는 데 도움이 되도록 사용성 테스트를 도입하는 것이 좋습니다.
올바른 해결책이 아닐 수도 있는 일에 많은 업무와 시간, 노력을 쏟기 전에 최대한 많은 정보를 파악하는 것이 얼마나 중요한지 말씀드릴 수 없습니다.
이제 이 글을 통해 UX와 그 중요성에 대한 기본적인 내용을 이해하실 수 있을 것입니다. UX는 디자이너나 연구자의 역할로 여겨져야 하는 것이 아닙니다. 사실 프로젝트에 참여하는 모든 사람의 책임이므로 기회가 있을 때마다 적극적으로 참여하는 것이 좋습니다