개발 스프린트에 UX 디자인을 통합해야 하는 이유

개발 스프린트에 

UX 디자인을 통합해야 하는 이유

출처 : https://blogs.adobe.com/creativedialogue/ko

2016년 6월 업데이트

필자가 UX 디자이너로서 첫 직장생활을 했던 회사에는 제대로 된 UX 디자인 프로세스가 없었습니다. 

일부 프로젝트 관리 지침에 따라 UX 디자인을 워터폴 모델(waterfall model)에 어떻게 통합할지 고민만 하고 있었습니다. 하지만 이제는 많은 것이 변했습니다.

애자일(Agile) 개발 방법론이 최근 몇 년간 점점 더 인기를 얻게 되면서 

필자를 비롯한 대부분 사람들은 더 이상 워터폴 개발 프로세스를 쓰던 시절로 돌아가고 싶어 하지 않습니다. 

그런데도 애자일은 UX 디자인에 대해서만큼은 해결하지 못한 과제를 안고 있습니다.

2% 부족한 애자일과 UX의 궁합

애자일 방법이 적응형 계획, 유연성 및 지속적인 개선이라는 특징 때문에 일반적인 문제 해결 방식과 잘 통할 것 같아서 애자일과 UX의 조합이 순조로울 것으로 생각할 수 있습니다. 

그러나 애자일 방법론은 특정 프레임워크가 아니라 일련의 원칙으로만 정의된다는 점에서 해석의 여지가 다분합니다.

그렇기 때문에 정해진 시간 동안 여러 번 반복되는 구조(일명 스프린트)를 바탕으로 하는 

스크럼(Scrum)이라는 애자일 소프트웨어 개발 프레임워크가 등장하게 된 것입니다. 

스크럼은 규범적인 구조를 도입하여 팀이 애자일(민첩한) 방식으로 사고하게 합니다. 

스크럼 프레임워크와 애자일 방법론을 함께 활용하면 해석의 문제를 해결할 수 있습니다.

관여하는 모든 팀의 기여도를 극대화하기 위해 스크럼은 역할을 정의하여 

모든 팀원이 서로의 역할을 이해할 수 있도록 합니다. 스크럼은 제품 책임자(product owner), 

개발 팀 및 스크럼 마스터(scrum master)를 정의하고 있지만 UX 팀을 비롯한 다른 역할에 대해서는 설명하지 않습니다.

스크럼을 활용한 애자일 개발에서의 UX 역할 정의

UX의 역할이 명확하게 정의되지 않은 점 때문에 많은 조직 내 개발 팀이 선호하는 애자일 방법에 따라 

스크럼을 채택하면서 UX 디자인을 프로세스에 통합하기 위해 고군분투하고 있습니다.

스크럼은 개발 팀을 중심으로 이루어지며, 그 외에 UX를 비롯한 다른 부서의 역할을 개발 활동에

어느 정도 기여하는 것으로만 여깁니다. UX 팀은 개발 팀이 와이어프레임과 사양을 요구할 때 지원해주는 역할 정도로만 수행하게 되는 것입니다.

보다 나은 팀 역학 관계를 위해서는 UX 팀이 개발 팀에 통합되어야 합니다. 그리고 선행적으로 프로토타입을 작성하거나 동일한 스프린트에서 개발자와 동시에 디자인할 때에도 유연하게 수행해야 합니다.

해결책이 안 될 수도 있는 개발 스프린트에서의 선행 작업

최근 UX 팀이 진행 중인 개발 스프린트보다 한두 단계 앞서 작업해야 한다는 주장에 힘이 실리고 있는 것 같습니다. 

UX 작업을 개발 팀의 스프린트 일정과 맞추어야 하는 제품 책임자의 관점에서는 일리가 있는 주장입니다. 

이렇게 하면 UX 검토 시간이 생기고 다음 개발 스프린트를 진행하기 전 

계획 세션에서 간과했던 문제를 세부적으로 조정할 수 있습니다.

그러나 UX 팀을 현재 진행 중인 스프린트보다 선행하게 되면 디자이너는 

현재 실제로 무엇이 개발되고 있는지 파악하지 못하게 됩니다. 

이러한 문제로 인해 스프린트 사이에 작은 워터폴 프로세스가 발생합니다. 

디자인을 먼저 작업한 후 검토하고, 다음 스프린트가 시작되기 전에 승인을 받기 위해 대기해야 하므로 

애자일 사고 방식은 무시되고 프로세스가 다시 워터폴 모델의 모습을 갖추기 시작하는 것입니다.

개발자가 검토 전까지 디자인 프로세스에 참여하지 않으면 사용자의 요구 사항을 이해하지 못하게 될 것이고, 

결국 담당자의 주관적인 믿음만을 반영하여 혼합된 해결책을 실행하게 될 것입니다.

디자인의 초기 단계에서 디자이너가 주인의식을 느끼지 못한다면 “스스로 해낼” 필요성이 부족하기에 

최종 결과에 부정적인 영향을 미칠 수 있습니다. 

예상하지 못한 문제가 발생하는 경우, 

개발 프로세스를 주시하고 리서치 또는 좋은 디자인 작업 방식과 관련된 질문에 대답할 수 있는 

UX 디자이너가 아무도 없다면 담당자가 선호하는 방식에 치우쳐서 임의로 해결하게 될 것입니다.

결국 디자이너가 다음 단계의 작업을 수행하는 동안 전달될 실제 결과물이 

디자인 팀에서 승인한 것과는 다른 것이 될 수도 있는 것입니다. 

또한 검토 단계에서 이러한 문제를 발견하여 수정해야 한다면 대부분의 경우 마감일을 엄수해야 하는 상황에서 

막대한 대가를 치러야 합니다.

현재 진행 중인 개발 스프린트보다 앞서 UX 작업을 수행하는 애자일 팀의 경우 

다음의 문제가 주로 발생합니다.

• 디자인 팀과 개발 팀 간의 의사소통 부재로 인해 디자인과 실제 결과물 사이에 격차를 초래합니다.

• 이 접근 방식의 경직성은 스프린트 간에 작은 워터폴 프로세스를 생성합니다. 그리고 프로세스의 민첩한 특성이 혼란과 불만으로 이어지도록 야기합니다.

• 사용자 경험에 대하여 디자이너와 개발자 간에 공동으로 합의된 주인의식이 없습니다. 개발 팀이 UX 의사 결정의 가치를 인지하지 못한다면 실제 결과물에 부정적인 영향을 미칠 수 있습니다.

UX 팀과 개발 팀의 협업 필요

협업을 위해서는 스크럼 역할을 하는 개발 팀이 UX 디자이너를 같은 위치로 받아들여 동등하게 임해야 합니다. 

개발 작업을 시작하기 전에 전체 솔루션을 디자인하지 못하는 관행은 많은 UX 디자이너에게 어렵게 다가올 수 있지만 민첩한 작업을 위하여 변화에 빠르게 대처하는 역량을 갖추어야 합니다. 

UX를 스프린트에 앞서 완료해야 한다는 생각을 바꿈으로써 개발 프로세스는 다양한 측면에서 향상될 것입니다.

 

통합된 애자일 팀으로 작업 시 얻을 수 있는 이점

• 작업에 참여하는 모든 구성원이 문제를 이해하여 해결책을 모색할 수 있습니다. 해결책을 함께 모색하므로 팀 전체가 디자인에 대한 주인의식을 공유하게 되면서 변경 사항을 적용하고 실수를 수정하는 데 필요한 전체 시간을 단축할 수 있습니다.

• 변화하는 요구 사항에 유연하고 빠르게 대처할 수 있어 전체 프로세스를 훨씬 수월하게 수행하고 이해할 수 있습니다. 스프린트 동안 발생한 모든 디자인 문제는 발생 즉시 해결할 수 있으므로 향상된 최종 결과를 얻을 수 있을 뿐만 아니라 스프린트를 일정대로 진행할 수 있습니다.

• 디자인 문제를 위해 발견한 해답은 오류 발생률이 낮고 더 많은 사용 사례까지 해결해 줍니다. 여러 측면에서 문제를 분석함으로써 팀은 다양한 시나리오에 대처할 수 있고 디자인 문제를 효과적으로 해결할 수 방법을 찾을 수 있습니다.

언제든지 발생할 수 있는 과제

애자일 프로세스는 UX 팀이 개발 팀이 진행하는 현재 스프린트보다 앞서 작업을 진행하거나

현 스프린트에 맞춰 작업을 진행하건 상관없이 많은 과제를 던지고 있습니다. 

디자인 작업과 개발 작업을 완벽하게 수행할 수 있도록 100%를 보장하는 방법은 없습니다. 

공동 작업은 팀의 경험과 신뢰에 달려 있기 때문입니다. 

이러한 맥락에서 디자인을 먼저 수행해야 하건 그렇지 않건 상관없이 서로 밀접하게 협업하고 

최종 결과물에 필요한 이해를 공유하기 위해 노력하는 것은 팀 전원에 달려있습니다.

UX 팀은 사용자, 비즈니스 및 개발 팀을 이어주는 연결 고리 역할을 해야 합니다. 

또한 개발 팀에게 사용자의 요구 사항에 대하여 코치해가며 UX 팀을 지원할 수 있도록 만들어야 합니다. 

이렇게 해야 최종 고객에게 훌륭한 사용자 경험을 제작하여 전달함으로써 얻을 수 있는 가치를 

개발 프로세스에 참여하는 모든 구성원이 이해할 수 있게 됩니다.

 

Project Comet is now Adobe XD. A new experience in user experience.

프로젝트 코멧이라 불리던 새로운 UX 디자인 및 프로토타입 솔루션인 어도비 XD의 프리뷰 버전이 공개되었습니다. 현재 어도비 XD는 맥 OS에서 사용이 가능하며 어도비 ID만 있으면 무료로 다운로드 받을 수 있습니다.

https://creative.adobe.com/products/download/experience-design