brunch

You can make anything
by writing

C.S.Lewis

by 박준형 Jun 25. 2016

왜 우리 Persona는 프로젝트에서 외면받을까?

Persona를 쓰려거든 Agile로 쓰세요

나의 직함인 CX 디자이너의 업무는 User 뿐만 아니라 Customer의 '총체적인 경험'을 디자인하는 사람이다. 우리 시스템을 구매하거나 사용할 사람들을 생각하면서 제품을 만든다. 그래서 우리의 모든 프로젝트는 Persona를 만드는 것으로 시작한다. 소위 사용자의 니즈를 기반으로 인사이트를 발견하여 혁신적인 경험을 제공하는 것이 우리 사명이기 때문이다. 하지만 waterfall방식의 프로젝트는 대충 이런 식으로 흘러가더라. (개인적인 경험이기에 일반화시킬 수는 없다.)

1. 프로젝트 초기, 갖가지 다양한 방법론으로 리서치한 결과를 종합. 있어 보이는 퍼소나를 만든다. 누군가에게 보여줄 중간 산출물이기 때문이며 으레 그렇게 하는 것이 'UX방법론의 출발'이기 때문이다.

2. 심혈을 기울여 만든 퍼소나가 괜찮은 반응을 얻었다. 이제 리서치는 그만하고 실제 UI 기획 단계로 들어간다. 회의 때 몇 번은 퍼소나에 대한 이야기를 하면서 그들의 니즈를 만족시키기 위한 UI를 설계한다.

3. UI 기획이 막바지에 이르렀다. 처음엔 가능할 줄 알았던 좋은 UI들이 개발팀의 반대에 부딪힌다. 기술적 제약이 있다고 한다. 또 시간 내에 만들 수 없다고 한다. 클라이언트 요구사항도 끼어든다. 점점 화면은 애초에 기획했던 것과 달라지고 있다. 이 시기가 되면, 아무도 처음의 퍼소나를 다시 꺼내보지 않는다.

프로젝트에는 해결해야 할 문제들이 시시각각으로 발생한다. 디자이너들은 그 문제를 해결하는데 집중하느라 여념이 없다. 그렇게 시간이 흘러 프로젝트 막판이 되면 이전에 심플하고 잘 정리되어있던 화면들은 어떤 이슈들로 인해 우선순위 없이 '기능 추가병'이 걸린 복잡한~~혼돈의카오스~~ 상태가 되어버리고 만다. (모두 알고 있는 당연한 사실이지만) 이런 현상을 막아줄 수 있는 것이 Persona이다.

혼돈의 카오스, 소름돋는건 우리회사에는 저런 시스템이 꽤 있다. http://www.ssw.com.au/ssw/Standards/Rules/Images/badui2.jpg

그런데 왜 우리 프로젝트에서 Persona는 중요하게 다뤄지지 못할까?

1. '리서치 기간'이 끝나면 더 이상 사용자를 만나지 않는다.

프로젝트에 할당된 예산은 한정되어있고 리서치는 비용을 발생시킨다. 왜인지는 모르겠지만 일정기간 동안 모든 자원을 투입해서 최대한 많은 정보를 밝혀내는 것이 효율적이라는 믿음이 있는 것 같다. 또 고객은 리서치에 대표성을 요구한다. 그렇기 때문에 특정 기간 동안 인터뷰를 100명씩 하는 기이한 현상이 발생한다. 보통 고객들은 그 시기가 끝난 이후에 발생하는 이슈를 해결하기 위한 리서치에 대해 추가 비용을 지불하고 싶어 하지 않는다. 예상하지 못했던, 해결해야 하는 문제들은 지속적으로 등장하는데 우리 Persona는 프로젝트가 끝나기까지 100명을 만났던 그때에 머물러 있다. 별로 도움이 되지 않는다.

2. Persona의 Detail보다 Synthesis에 집중한다.

디자인 의사결정의 보조도구로써 Persona를 사용하기 위해서는 Detail이 살아있어야 한다. 하지만 소위 Affinity diagram에 너무 깊이 몰입하게 되면 이전에 살아있는 생생한 정보들은 합쳐지고 추상화되어 일반적인 키워드만 나열되어버린다. 그런 정보들은 남에게 커뮤니케이션하기에는 더 간편하지만 디자인 작업에는 큰 영향을 끼치지 못한다.

3. Persona가 공유되지 않는다.

UX 디자이너가 가장 많이 사용하는 단어를 꼽으라면 단연 '사용자'(혹은 유저)일 것이다. 미화씨, Berkel씨와 같이 우리 Persona의 이름이 그 단어를 대체해야 한다. 그리고 나면 우리 사용자가 누구인지 전체에게 공유되어야 한다. Persona_최종.pptx 파일을 보내라는 이야기가 아니다. 디자이너끼리만 알고 있는 Persona여선 안된다. 고객, 개발자, PM 모두가 우리 고객이 어떤 사람인지 함께 고민하는 자리를 만들어야 한다.

단절된 리서치, 디자인 프로세스가 결국 죽은 퍼소나를 만든다.

Lean+Agile 프로세스가 이 문제를 해결해 줄 수 있다. 항상 퍼소나를 디자이너 곁에 두고 프로젝트가 끝날 때까지 계속 업데이트해줄 수 있기 때문이다. 우리 팀에서는 다음과 같이 Persona를 만들고 활용한다.

1. 아주 간단한 Persona로 시작한다.

우리 팀에서 처음 Persona를 만들 때는 Sprint의 핵심 질문을 만들 수 있는 수준으로만 정의한다. 현재 사용자의 가장 큰 문제에 집중하는 것이다. 누가 봐도 이 사람들이 겪고 있는 문제가 무엇이고 뭘 해결하고 싶어 하는지만 명확하게 기술한다. 연령이나 성별 같은 요소는 프로젝트에 따라 완전히 무시하고 시작할 수도 있다. 그래서 처음에는 우리 Persona가 간신히 머리가슴배로 구분되는지, 사지가 있는지, 꼬리가 달렸는지 구분할 수 있는 정도밖에 안된다. 하지만 Sprint가 지나갈수록 점점 살이 붙으면서 진짜 생명체가 된다. 그렇게 복권 긁듯이 사용자를 조금씩 알아가는 재미(?)가 생긴다.

2. 매 Sprint 디자인 리뷰에 Persona를 활용한다.

디자이너 이외의 사람들에게 Persona를 주입시키는 가장 좋은 방법은 "왜 저렇게 디자인했나요?"라고 물어보게 하고 대답을 Persona를 이용하여 하는 것이다. 그래도 해결되지 못한 질문은 Sprint 내 검증하여 업데이트한다. 게다가 이렇게 Persona가 만들어지는 것 차체가 일종의 스토리가 되어 디자이너뿐만 아니라 다른 역할자들의 이해도를 높일 수 있다.

결론 - 악플보다 무서운 건 무플

예술가와 디자이너의 차이에 관한 김태훈님의 글을 읽어보면 가장 큰 차이는 창작활동의 근원이 '나'로 부터이냐 '남'으로 부터이냐가 그 시작인 것으로 보인다. 따라서 그 '남'을 제대로 정의하는 것은 디자인의 시작이 며, 제대로 정의되지 못했을 경우 완전히 실패한 디자인이 될 가능성이 매우 높다. 그렇기 때문에 퍼소나가 쓸모없다는 사람들의 이야기에도 불구하고 다시 한 번 Persona는 중요하다고 말하고 싶다.

사실 디자이너만 이것을 중요하다고 아무리 외쳐봐야 바뀌는 것은 없다. 전체적으로 프로젝트의 방향성을 결정할 수 있는 사람이 가치를 느끼는 것이 선행되어야 한다. 고객의 요구사항에도 과감하게 우리 Primary Persona의 가치를 손상시키는 것을 배제하고 최대한 숨기는 용단을 내릴 수 있는 PM이 없다면 공들여 만든 Persona는 물에서 건진 고등어처럼 금방 죽어버릴 것이다. 물론 악플보다 무플이 더 무섭다고, PM과 Dev들이 우리 Persona에 대해 이야기를 나누고 함께 만들어 갈 수 있는 환경을 만드는 것은 디자이너의 몫이기도 하다.

요약하면, "강한 놈이 살아남는 것이 아니라 살아남은 놈이 강한 것이다"

우리의 Persona도 오래 살려보자.

keyword