Agile과 UCD (User Centered Design)

일반적으로 사용자 중심 디자인(UCD, User Centered Design)은 개발에 들어가기 전, 사용자 연구 등을 통해 필요한 사항(Requirement)과 전략을 명확히 하면 할 수록, 개발 비용도 줄고 과업의 성공 확률도 높다고 주장하고 있다. 이에 따르면 하나의 단계가 끝나고 또 다른 단계를 진행하는 전통적인 폭포수 진행법(Waterfall Process)이 적합해 보인다.
그런데 개발에 있어서 폭포수 진행법이 공격을 받으면서, 빠르게 개발하는 다양한 방법(Agile Process)이 개발자들에게 인기를 점차 얻게 됨에 따라 사용자 중심 디자인에 익숙해져 있던 전통적인 UI 디자이너들도 이에 대응할 필요가 생기게 되었다.
과연 1주에서 2주 내에 빠르게 제품을 만들어 (어떤 부분이든 돌아가게) 빌드하고, 릴리스하면서 제품의 문제점을 빠르게 보완해 가는 반면 전통적인 요구사항(Requirement)이란 실패의 지름길이라고 여기는 이 애자일(Agile) 방법론에서 UI 디자이너들은 어떤 태도를 취해야 할까? 우리 나라에도 제법 사례가 있을텐데 구글신께서 알려주질 않으니 알 도리가 없고, 해외 사례들을 가지고 찾아보았다.

우선, Agile 용어가 낯선 분들 위해 간략하게 무엇인지 알아보면,
http://j.mp/gSrMYc (위키피디아)
http://xper.org/wiki/xp/AgileMethodology

그런데 왜 이것이 UCD와 문제가 되는가?에 대해 기초적인 포스팅은,
http://www.boxesandarrows.com/view/bringing-user인데,
대체로 이 포스팅에서 Agile 환경에서 문제점을 지적하길, 1. 디자인의 역할이 불명확하거나 아예 없다. 2. 요구사항 단계도 없고, 자유로운 컨셉 탐색 단계도 없다. 3. 미완성에서 안정화보단 기능추가 욕구가 더 생긴다.4. 결과적으로 품질 문제가 생긴다. 그래서 개선에는 도움이 되지만 맨 처음 만들 때는 도움이 안된다(Agile is good for refining, not defining.)고 말한다. 따라서 Agile 하게 진행하고 싶으면, 프로젝트 초반에 '컨셉' 혹은 '전략' 잡는 단계를 두고, 그 뒤에 Agile하게 진행하는 것이 좋다는 결론이다.

또 다른 글에서도 역시 비슷한 지적을 하고 있다.
http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
Agile 에서 성공하려면, 프로젝트 초반에 '최소한의' 사용자 조사와 모델링을 하라는 것이다.(Research, model, and design up front - but only just enough) 이 글에서는 이를 포함하여 총 12가지의 Agile 환경에서 성공하기 위한 방법을 설명하는데, 예를 들면 디자이너들이 개발팀의 일부가 되어야 한다, 계속 사용자 테스트를 하기 위한 사용자 풀이 있어야 한다, 개발과 병행하여 사용자 연구를 계속해야 한다, 프로토타입(low fi)을 계속 만들고 이를 요구사항으로 여겨야 한다는 등의 조언을 하고 있다.

대부분의 사람들처럼 갑자기 들이닥친 Agile 환경에 대응하여 실패에서 성공으로 이끈 사례를 발표한 슬라이드
http://www.slideshare.net/jgothelf/beyond-staggered-sprints-integrating-user-experience-and-agile
에서는 첫번째 단계에서 실패하고 두 번째, 세 번째, 네 번째 점점 더 나아져 결국 성공하게 되었는데, 우선 쉽게 가져다가 쓸 수 있는 풍부한 라이브러리(스타일 가이드, 혹은 패턴 라이브러리)가 갖추어지고, 프로토타입을 계속 만들어가면서 개발팀 전체가 같이 디자인하는 식으로 일하면서 계속 User Test를 해 나가면 성공할 수 있다는 것이다.

프로젝트가 시작되면, 일주일 혹은 이주일 단위로 테스트하고 수정해야하는데,
http://agile2010.agilealliance.org/files/agile_2010_Cindy_McCracken.pdf
에서 보는 것처럼 기존의 긴 기간 하던 몇 가지 방법들을, 기간이 짧아지고 계속 반복해야하는 만큼 수정해야할 필요가 있다. 예를 들면 테스트 리포트 같은 경우에도 과정을 하나씩 나열하고 결론을 쓰는 것이 아니라, 신문 기사처럼 가장 중요한 것을 두괄식으로 쓰는 것이다.

자, 이제 요약하면,
1. 디자인팀이 전체 개발팀과 완전히 한 팀이 되어야 한다.
2. 프로젝트 초반에 최소한의 사용자 조사와 모델링을 한다.
3. 부지런히 베껴서 빨리 프로토타입을 만들고 반복하여 테스트한다.

정도로 요약해 볼 수 있다. 자! 이제 우리도 시작해보자.

1. Agile Persona
시간이 없다는 개발팀을 설득하고 설득하여 약 3주간의 리드 타임을 확보하였다.
이를 위하여 pxd에서는 여러 차례 적용하였던 빠른 user research 기법을 사용하였는데, 이 기법의 핵심은 모든 것을 거꾸로 하는 것이다. 즉 전통적으로 user interview ->modeling(critical characteristics)->persona->strategy 순서로 진행했다면, 이번에는

1. peer interview (2~4) -> 2. persona assumption -> 3. questionnaire(critical characteristics) -> 4. user interview

즉 아주 짧은 peer interview를 한다. peer interview란 프로젝트를 함께 진행하는 구성원들간에 '너는 어때?'하고 물어보는 것이다. 물론 정말 시간이 없으면 1번도 하지 않겠지만, 그럴만큼 급한 경우는 없다. 1-2시간에 끝나기 때문이다.

그리고 그것을 통해 대략 퍼소나에 대한 감을 잡은 후,퍼소나를 구분할 수 있는 설문지를 만든다. 이것도 1-2시간안에 끝난다. 설문지는 key critical characteristics를 구별할 수 있는 4-7개의 문항으로 2-3분 내에 끝나게 만든다. 전통적인 설문지가 상호 배타적인 보기(라디오)로 이루어져 있어서 무엇과 무엇 중에 선택을 해야한다면, pxd에서 사용하는 설문지는 모든 문항이 체크로 이루어져 있어 응답자들이 머리를 텅 비우고 답할 수 있게 만들어져 있다. 또한 이 설문지의 모든 보기는 critical char.의 구성 요소가 되도록 만들어져 있기 때문에, 응답자의 대답을 보는 즉시 퍼소나 패턴을 판별할 수 있도록 되어 있다.

이렇게 설문지를 계속 돌리면서 궁금한 패턴이 나타나는 사람들을 불러서 질문한다. 이 작업은 주어진 시간이 될 때까지 한다. 그렇게 하기 위해선 아는 사람들에게 설문지를 돌리고, 궁금한 사람들을 즉시 부르거나 전화로 물어볼 수 있어야 한다. 당연히 필요하면 설문지도 계속 수정한다. 필요하면 persona assumption도 바꾼다. Agile하게! 대략 하루-이틀 정도 걸린다.

첫 번째 주- 일주일만에 user research와 persona & strategy building을 마치고

2. Framework Sketch Workshop
5명의 프로젝트 외부 구성원을 초청하여 1시간동안 프로젝트 개요를 설명한 뒤, 본 프로젝트팀원 포함하여 8명이 각자 프레임웍 두 개씩 그려오기를 두 시간 동안 진행한 뒤, 각자 발표 시간을 가졌다. 거기서 가장 뚜렷한 방향을 가진 프레임웍 3개를 골라서

-퍼소나의 잡을 가장 잘 해결한 프레임웍
-안정적이고 익숙한 구조를 가진 프레임웍
-서비스의 고유한 컨셉을 가장 잘 시각적으로 보여주는 프레임웍

본 프로젝트 구성원 3명이 각각 발전시키기로 하고, 하루동안 작업한 후, 이를 다시 두 개로 통합하여 정리하고, 고객에게 제시하기 위한 준비를 마쳤다.

두 번째 주-일주일만에 프레임웍 15개 그려보고, 3개 골라 발전시키고, 결국 2개로 통합하여 정리

3. Rapid Design Styling
GUI 팀은 프레임웍 워크샵에서부터 참여하기 시작한 사람과 주 중반에 프레임웍이 3개 혹은 2개로 골라지는 시점에 참여하는 사람 등을 포함하여 초기부터 스타일링 작업을 시작하고 2주차 후반에 시안 작업을 시작하였다.

세 번째 주-고객과 최종 프레임웍 결정하고 디자인 시안 완성하여 3주 마지막에 디자인 결정하는 것이 목표 (진행중)

---------

이렇게 만들어진 최소한의 사용자 조사, 모델링, 전략을 가지고 개발에 들어가며, 개발이 Agile 하게 진행되는 경우 2주에 한 번씩 프로토타입을 만들고 테스트할 계획이다. (이렇게 준비했는데 개발이 agile하게 안 할 가능성 발생 ㅠㅠ)

여전히 Agile 프로세스에 앞서 약간의 waterfall을 하는 것이라 완전한 agile 주장자들에겐 변칙으로 보일 가능성도 있고, 또 매우 성급한 결론을 역으로 적용시키는 방식이라 전통적인 UCD 지지자들에게는 날림으로 보일 가능성이 있다. 그러나 Agile 개발 환경이 점점 더 필요하고 늘어나는 것이 대세가 된다면, 분노하고 거부하는 것만이 답은 아니라고 많은 사람들이 문헌에서 밝히고 있다.

그런데 이러한 방법을 진행하기 위하여 매우 중요한 부분이 하나 있다. 이렇게 진행하려면 프로젝트를 진행하는 사람이 매우 경험이 많아야 오류나 우왕좌왕을 피할 수 있다는 것이다. 사용자 조사 경험이나 사용자 인터페이스 설계 경험도 풍부해야겠지만, 도메인 지식도 풍부해야한다. 이 부분이 많은 문헌에서 간과하고 있지만, 필자가 생각하기에 가장 중요한 부분이다.

--------
참고 문헌 포인트로 Keywon Chung & Amy Chung 두 분이 도와 주셨다.
http://ux.stackexchange.com/questions/1919/resources-for-building-a-ui-ux-team-and-process/1940#1940

[참고##Lean UX##]