UX project life cycles — is linear or iterative better?

소개 사용자 경험(UX) 디자인은 마법처럼 일어나지 않습니다. 프로세스가 필요합니다. 방법론이 필요합니다. 디자인 및 소프트웨어 개발 프로젝트에는 수명 주기가 있습니다 . 이는 프로젝트 구상에서 완료까지 이어집니다. 그리고 가장 일반적인 두 가지 유형의 수명 주기는 선형 및 반복입니다. 선형 프로젝트는 초기 개념 개발부터 배포까지 명확한 단계로 구성됩니다. 반복적 프로젝트는 연구, 설계, 개발, 테스트와 같은 활동이 반복적으로 거의 동시에 진행되므로 훨씬 더 유연합니다. 하지만 어느 것이 가장 좋을까요? 각각의 장단점은 무엇일까요? 그리고 그것은 모두 프로젝트의 맥락에 따라 달라지나요? 두 가지 방법( 워터폴(Waterfall) 과 애자일(Agile) )을 실제로 적용하여 선형적 라이프 사이클과 반복적 라이프 사이클을 직접 비교해 보겠습니다 . 폭포수란 무엇인가? 사람들이 프로젝트를 논의하는 회의실. 두 사람이 큰 모니터 화면 옆 테이블에 앉아 있고, 두 사람이 스티커 메모가 붙은 화이트보드를 제시하고 있다. 일반적인 프로젝트 회의 설정 - Paymo 의 이미지 일반적인 폭포수 UX 디자인 프로젝트에는 다음과 같은 단계가 포함됩니다. 요구 사항 — 프로젝트 요구 사항을 도출, 분석, 우선순위 지정, 문서화 및 검증하는 비즈니스 분석 단계. 디자인 — 이 단계에서는 제품 디자인이 수행되고 프로젝트 결정권자가 승인을 내립니다. 개발 — 디자이너로부터 인계받은 후, 프로그래머가 테스트할 수 있도록 제품을 코딩합니다. 테스트 — 사용자 수용 테스트(UAT)의 한 단계는 제품이 요구 사항의 수용 기준을 통과하는지 확인하기 위해 수행됩니다. 구현 - 소프트웨어가 출시되고, 프로젝트가 종료되며, 제품이 실제로 운영에 투입됩니다. 폭포는 각 단계가 다음 단계로 흘러내리기 때문에 이름을 얻었습니다. 전통적인 폭포 접근 방식에서는 단계를 순서대로 완료 해야 합니다 . 뒤로 돌아갈 수 없습니다. 폭포수 프로세스 폭포수 프로세스 - 저자의 이미지 폭포의 장점 단순성 - 선형 프로젝트는 명확한 이정표와 함께 직관적인 단계로 구조화되고 구성되어 프로젝트에 참여하는 모든 사람이 프로젝트의 작동 방식을 쉽게 이해할 수 있습니다. 구현의 용이성 - 선형 라이프 사이클은 단일 폭포수 인증 프로젝트 관리자가 관리할 수 있습니다. PRINCE2 와 같은 프레임워크에서 프로젝트 팀의 다른 사람이 특별한 교육이나 자격증을 가질 필요는 없습니다 . 예측 가능성 - 요구 사항과 우선순위가 일찍 정해지고, 프로젝트에 참여하는 모든 사람이 최종 제품에 대한 명확한 비전을 갖게 되어 범위 확장 가능성이 줄어듭니다. 제어 - 선형 라이프 사이클은 일반적으로 광범위한 문서화를 특징으로 하며, 변경 요청 및 사용자 수용 테스트와 같은 사항에 대한 엄격하게 관리되는 프로세스를 통해 품질 보증 문제를 최소화합니다. 폭포의 단점 유연성 부족 - 요구 사항은 고정되어 있으며 프로젝트가 다음 단계로 넘어가면 변경하기 어렵습니다. 제한된 사용자 입력 - 워터폴 프로젝트에서는 고객이 수명 주기 후반부까지 테스트나 피드백을 받지 못합니다. 실패 위험 - UAT 이후 주기 후반에 필요한 요구 사항, 설계 또는 개발에 대한 주요 변경 사항은 복잡하고 비용이 많이 들기 때문에 프로젝트가 마감일을 놓치거나 예산을 초과할 가능성이 높습니다. 더 긴 타임라인 - 선형 프로젝트는 사전 계획, 문서 관리 및 각 단계의 순서대로 완료가 필요하기 때문에 상당한 시간이 소요됩니다. 애자일이란? 세 명의 UX 디자이너가 화이트보드에 붙은 다채로운 스티커 노트를 민첩하게 검토하고 있습니다. Agile 프로젝트 작업 — UX Indonesia 의 이미지 애자일 프로젝트는 여러 반복적인 단계로 구성됩니다. 폭포수형 프로젝트와 비교했을 때, 애자일 프로젝트는 선형적이라기보다는 순환적이 라고 개념화됩니다 . 폭포수와 달리 요구 사항, 설계, 개발, 테스트 및 구현을 독립된 개별 단계로 분리하지 않습니다 . 대신 이러한 활동은 각 반복 단계에서 함께 진행됩니다 . 순차적으로 진행되는 세 가지 애자일 소프트웨어 개발 스프린트를 보여주는 이미지. 이 이미지는 애자일의 순환적 특성을 강조합니다. Agile 소프트웨어 개발 - Krusche & Company 의 이미지 반복적 UX 디자인은 일반적으로 Scrum 이나 Kanban 과 같은 특정 유형의 Agile 프로젝트 관리 방법론을 사용하여 수행됩니다 . 이러한 프레임워크 간에는 미묘한 차이가 있지만 둘 다 Agile 원칙 의 챔피언입니다 . 애자일 작업을 위해서는 UX 연구자, 사용자 인터페이스(UI) 설계자, 개발자 및 기타 전문가로 구성된 소규모의 다분야 팀이 협업하여 작업해야 합니다. 타임박스 또는 스프린트 라고 불리는 각 반복 단계에서 프로젝트 팀은 요구 사항을 이끌어내고, 프로토타입을 설계하고, 피드백을 수집하여 사용자와 비즈니스 요구를 충족하는 최소 실행 가능 제품(MVP)을 개발합니다. 애자일의 장점 높은 유연성 - 반복적인 라이프 사이클을 통해 요구 사항과 우선순위를 쉽게 추가하고 변경할 수 있어 사용자 또는 비즈니스 요구 사항이 불분명한 프로젝트에 적합합니다. 조기 납품 - 반복적 라이프 사이클을 사용하면 계획할 필요성이 줄어듭니다. 반복적 프로토타입 프로세스의 일부로 요구 사항을 도출할 수 있으므로 Agile 프로젝트를 신속하게 시작할 수 있으며, 반복이 끝날 때 작동하는 소프트웨어를 생산할 수 있습니다. 낮은 위험 - 반복적 프로젝트는 사용자가 프로토타입을 일찍 테스트하고 중요한 문제를 강조할 수 있으므로 실패할 가능성이 낮습니다. 이를 통해 프로젝트 팀은 작동하지 않는 아이디어를 폐기하고 프로젝트 수명 주기 후반에 비용이 많이 들고 시간이 많이 걸리는 재설계 또는 재개발을 피할 수 있습니다. 문서화 감소 - Agile은 포괄적인 문서화보다 작동하는 소프트웨어를 선호하므로 최종 제품에 가치를 더하지 못할 수 있는 프로젝트 관리에 낭비되는 시간이 줄어듭니다. 애자일의 단점 구현의 어려움 - Agile 작업은 실제로 적용하기 어려울 수 있습니다. Agile은 여러 부서에서 자연스럽고 완벽하게 작업하는 다학제 프로젝트 팀이 필요하며, 전체 조직이 반복적 철학에 맞춰야 합니다. 예측 가능성 낮음 - 반복적 프로젝트는 최종 제품과 프로젝트 일정에 대한 비전이 덜 명확하고, 테스트를 위한 일관된 사용자 가용성에 대한 의존성 등 많은 종속성을 포함합니다. 문서화 부족 - 애자일 방식에서는 문서화보다 소프트웨어에 초점을 맞추기 때문에 각 단계와 반복 과정에서 내용이 누락될 수 있습니다. 범위 확장 가능성 - 우선순위 재지정 및 요구 사항 변경에 대한 통제력 부족으로 인해 프로젝트 범위가 쉽게 확장될 수 있으며 이를 수용할 시간이나 예산이 부족할 수 있습니다. 하이브리드 접근 방식 UX 디자이너 팀이 테이블 주위에 모여서 스티커 메모가 붙은 화이트보드 앞에 있는 대형 모니터를 함께 봅니다. 때로는 프로젝트 매시업이 필요합니다. - Jason Goodman 의 이미지 일부 UX 디자인 프로젝트에서는 다양한 방법론의 요소를 융합하여 새로운 모델을 만듭니다. 가장 일반적인 하이브리드 접근법은 워터폴과 애자일을 병합하는 것입니다. 두 가지를 결합하고 싶을 수 있는 몇 가지 이유가 있지만, 큰 동기는 종종 애자일의 가장 큰 장점인 설계, 테스트 및 개선을 위한 피드백 루프를 활용하려는 것입니다 . 예를 들어, 폭포수형을 사용하여 계획 하고 애자일로 제공할 수 있습니다 . 실제로 이는 요구 사항 엔지니어링, 계획 및 예산 책정을 순차적으로 수행하지만 설계, 개발, 테스트 및 배포는 반복적으로 수행하는 것을 의미합니다. 하이브리드 접근 방식의 예 하이브리드 접근 방식의 예 - 작성자의 이미지 참고: 워터폴-애자일 퓨전에 대한 대안은 사용자 경험의 5가지 평면 과 같은 비교적 선형적인 프레임워크를 따르는 것입니다 . 이 프레임워크는 다음 단계를 시작하기 전에 모든 단계를 완료해야 한다고 주장하지 않습니다. 이렇게 하면 완전히 반복적이지 않고도 충분한 유연성을 얻을 수 있습니다. 하이브리드의 장점 두 세계의 장점 - 워터폴과 애자일 방법론을 효과적으로 적용하면 프로젝트 관리자는 유연하고 적응력 있게 행동하고 프로젝트 요구 사항에 맞게 접근 방식을 조정할 수 있습니다. 전환이 가능합니다 . Agile은 구현하기 어려울 수 있으므로 하이브리드 방식은 조직이 학습하고 조정하는 데 있어 디딤돌 역할을 할 수 있습니다. 하이브리드의 단점 실행 불량 - 선형/반복적 혼합 방식은 실제로 효과적으로 구현되지 않는 경우가 많습니다. 완벽한 결합이 아니며 두 가지 접근 방식에 대한 지식이 있는 매우 숙련된 프로젝트 관리자가 필요합니다. 의사소통 격차 - 여러 방법론을 혼합하면 어떤 접근 방식을 따르는지에 대한 이해가 부족할 수 있습니다. 통제력 부족 - 문서화 중심 접근 방식과 가벼운 관리 스타일을 결합하면 성과물, 마감일 및 변경 프로세스가 불분명해질 수 있습니다. 제약 조건 선형, 반복 또는 두 가지의 혼합이 가장 좋은지에 대한 질문에 답하기 전에 프로젝트 제약의 개념에 대해 이야기해야 합니다. 왜 그럴까요? 올바른 라이프 사이클을 선택하기 위한 맥락을 설정하기 때문입니다. 가장 적합한 UX 디자인 프로젝트 관리 방법론은 프로젝트 제약 에 따라 크게 달라집니다 . 모든 프로젝트는 범위, 품질, 일정, 비용, 리소스 등의 제약을 받습니다. 범위, 품질, 일정, 비용 및 리소스의 고전적 제약 고전적 제약 - 저자의 이미지 범위 - 프로젝트는 요구 사항을 제공하는 데 국한되며, 요구 사항은 범위에 포함되는 것과 포함되지 않는 것을 정의합니다. 품질 - 프로젝트는 요구 사항에 대한 '완료 정의'를 제공하는 품질 수용 기준에 의해 제약을 받습니다. 일정 - 프로젝트는 시간적 제약을 받으며, 정의상 일시적이므로 시작점과 끝점이 있어야 합니다. 비용 - 모든 프로젝트는 예산에 의해 제약을 받는데, 이는 (이론적으로) 유한합니다. 리소스 - 모든 프로젝트는 기술(소프트웨어/하드웨어)과 인력(프로젝트 팀의 규모와 다양한 기술 세트)을 포함하여 이를 제공하는 데 사용할 수 있는 리소스에 의해 제약을 받습니다. 프로젝트 수명 주기와 방법론에 제약 조건을 적용하려면 삼중 제약 조건 의 개념에 대해 알아야 합니다. 이는 ' 왕좌의 게임'에서 나온 듯한 느낌의 레이블인 '철의 삼각형'으로도 알려져 있습니다. 철의 삼각형 범위 , 비용 , 시간 (일정) 의 세 가지 제약은 올바른 프로젝트 관리 방식을 선택하는 데 매우 중요합니다. 각 방법론에서 철의 삼각형은 어떻게 작동합니까? 폭포수형 - 프로젝트 범위는 고정 되어 있지만 시간과 비용은 유연 합니다. Agile - 프로젝트 범위는 유연 하지만 시간과 비용은 고정 되어 있습니다. 이 개념을 다이어그램으로 시각화하면 훨씬 더 쉽게 볼 수 있습니다. 철의 삼각형 철의 삼각형 - 작가의 이미지 기술 또는 게임 회사가 해당 산업에 적합하기 때문에 반복적/민첩한 접근 방식을 따르는 것을 종종 볼 수 있습니다. 경쟁이 치열한 시장에서 비용과 일정은 릴리스 주기를 맞추는 데 중요합니다. 그러나 마감일까지 최대한의 영향과 가치를 제공하기 위해 기능을 보다 유연하게 처리할 수 있습니다. 대조적으로, 많은 공공 부문 소프트웨어 프로젝트는 선형/폭포수 접근 방식을 따릅니다. 정부나 의료와 같은 환경에서 가장 중요한 것은 포괄적인 제품 사양 세트가 제공된다는 것입니다. 따라서 요구 사항은 잠기지만 허용 범위는 비용과 일정에 내장되어 있어 필요한 경우 프로젝트가 예산을 초과하고 마감일을 넘길 수 있습니다. 그렇다면 어떤 접근방식이 가장 좋은가? 간단히 말해서, 서로 다른 UX 프로젝트 수명 주기와 관리 방법론은 서로 다른 유형의 프로젝트에 적합합니다. 폭포수형과 같은 선형적 접근 방식을 선택하든, 애자일과 같은 반복적 접근 방식을 선택하든, 그것은 업계, 조직 문화, 프로젝트의 맥락에 따라 달라집니다. 폭포형은 다음과 같은 경우에 가장 적합합니다. 범위는 고정될 수 있으며 변경될 가능성이 낮습니다. 최종 제품에 대한 확신도가 높습니다 예측 가능한 프로젝트와 비즈니스 환경이 있습니다 엄격한 통제, 테스트 및 문서화가 필요합니다. 예산과 일정을 초과하는 것에 대한 허용 범위가 있습니다. Agile은 다음과 같은 경우에 가장 적합합니다. 범위가 불분명하고 변경될 가능성이 있음 프로젝트는 시간과 예산 내에서 제공되어야 합니다. 예측할 수 없는 프로젝트와 비즈니스 환경이 있습니다 교차 기능 작업이 가능합니다. 요구사항에 대한 반복적이고 유연한 관리에 대한 찬성이 있습니다. 하이브리드 프로젝트는 두 가지 장점을 모두 얻을 수 있는 잠재력을 가지고 있지만, 명확한 제어와 커뮤니케이션이 있는지 주의해야 합니다. 그렇지 않으면 프랑켄슈타인의 괴물과 같은 UX 문제가 생길 수 있습니다.