디자이너가 프로젝트에 앞서 이해관계자를 인터뷰 해야하는 2가지 이유.
by Sang-eun
2020년 12월, 가벼운 학습지 이벤트 페이지 기획&개발에 해프닝이 있었다. 기획에서 디자인 컴펌까지 걸린 시간은 총 ( 14 )일, ( 약 70 )시간 중간 피드백 요청 회수는 ( 제발 그만좀 해 할정도로 많다 ).
다들 지쳐가고, 머리가 아프고, 뭐가 문제일까? 초기 인터뷰가 이 문제를 해결해줄 수 있을까? 이해관계자를 인터뷰해야 하는 이유 2가지를 FCL의 Event page 프로젝트의 협업 히스토리를 보고 알아보자!
*이해관계자(영어: Stakeholder)는 기업·행정·NPO 등과 관련하여 직접·간접적으로 이해관계를 가지는 사람을 가리킨다.. 프로젝트에서는 같이 협업하는 모든 사람들 + 프로젝트의 일정 및 방향에 따라 직접적으로 영향받는 사람들을 떠올릴 수 있다. 디자이너, 마케터, 기획자, 개발자, 의사결정자(CEO) 등이 해당된다. 이 중 프로젝트에 관해 가장 많은 정보를 가지고 있는 분을 인터뷰하면 좋다.
1.작업 번복을 피해 ✔️ 커뮤니케이션 시간 비용을 아낄 수 있다. ✔️
우리는 대화하면서 머리속으로 서로 다른 그림을 그린다. 말을 나눠보지 않으면, 우리는 한참을 작업하다가 어느 순간 생각이 맞지 않다는 것을 확인하고 작업을 초기화한다. 그리고 다시 시작한다. 이것을 해결하는 안전장치가 초기 인터뷰다. 가볍게 대화하는 3분의 시간에서도 우리는 많은 정보를 얻을 수 있다. 지도를 가지고 길을 걷게 되는 것과 같다. 이것이 인터뷰를 해야하는 이유다.
상황
🙇 기획자A : 이벤트 페이지 만들어주세요. 디자인에 따라 기획은 수정하려고 해요.
🥴 디자이너B : 네 알겠습니다.😱 과거를 돌아보는 디자이너B : ????? 이봐, 잠깐만. 진짜 ‘알겠습니다.’ 하고 그냥 시작할거야?
- 기획서에 표현되어 있지 않은 정보, 테스트 상황, 기간 등에 의해 추후 GUI를 갈아 엎어야하는 상황이 반복되었다.
- 공동체 머리속에 있는 프로젝트의 범주, 이해관계도, 중요도, 기획의도, 디자인 방향성 등이 모두 제각기 다르다.
뭐가 문제 였을까?
우리는 같은 그림을 머리속에 그리고 있지 않았다.
왜 머리속에 같은 그림을 그리지 못했을까? 한번도 공유하지 않았기 때문이다. 기획 리뷰 없이 디자인 시작해 수정 방향성의 변동이 커졌다.
해결법 : Project 이해도를 맞추자
개발 팀장인 시우님을 통해 이벤트 페이지의 중요도를 듣고 나서 모든 것이 이해되었다. 왜 이 디자인이 만족스럽지 못한지를. 나 마저도 지금 시안으로는 안된다는 것을 알았다. 그리고 갈아 엎기로 했다. 이런건 더 수정하고 개선해 봤자 우리 목적에 부합하지 않으니까.
Tips
기획안 받았을 때 다음과 같은 항목을 꼭, 전화/화상통화로 체크할것.
- 프로젝트 시작시 인터뷰한다. 고객만 인터뷰가 필요한게 아니다. 우리끼리도 서로간의 인터뷰가 필요하다.
- 기획 계기, 전체 비즈니스내의 중요도, 기획 및 페이지의 목적, 마케팅적 요구사항 파악
- 각각의 스크럼에 어느 정도의 시간을 투자할지 정하는게 필요. 그래야 삼사주씩 늘어지는 것을 피할 수 있다.
- 변경사항을 문서화하자. 문서화 작업은 굉장히 기록을 위한 기록이지만, 의견 복구 및 히스토리 파악을 위해 남겨두는 것이 필요하다.
- 부서별로 프로젝트 내 우선순위가 다르다. 물어보자.
2. 피드백 병목 현상이 해결되고 ✔️ 각자의 역할에 집중할 시간이 생긴다. ✔️
잘 모르면 닥치는대로 하게 된다. 인터뷰는 일종의 쿠션이다. 내가 할 일을 스스로 통제하고 관리하며 사람들에게 전달할 수 있게 한다. 프로젝트를 둘러싼 환경을 이해하면 내가 할 일, 소요시간을 가늠할 수 있게 된다.
‘얼마나 걸릴까요? 어떻게 생각하세요?’이런 질문에도 답하기 쉬워지며, 함께하는 팀원들도 나에게 일을 맡기고 각자의 할 일에 몰두할 수 있게 된다.
상황
- 슬랙으로 피드백을 요청하면 하나씩 코멘트하기 편하지 않을까? 모든 부분을 놓치지 않고 소통할 수 있을거야 → 슬랙 피드가 흘러서 어느 부분을 체크했는지 하지 않았는지 확인이 어렵다. 피드백이 자주 일어나지 않고 의견 교환 또한 활발하게 이루어지지 않는다.
- 너무 정신없이 요소가 많다. 브랜드 가이드라인이 없어서 일까? 위계 순서를 따지면 모든 요소가 다 저 나름대로 중요하다. 힘을 빼고 주고 완급 조절을 해야 조화를 이루고 모든 정보가 전달된다. 그러나 이거 하나만 ‘더 잘보이게’ 수정하면 모든 게 다 잘 안보이기 시작한다.
언제쯤 피드백을 들을 수 있을까? 확인해야할 게 많은데..
파편화된 요청은 흩어지고 이내 사라진다.
뭐가 문제였을까?
1. 기획팀 업무가 얼마나 바쁜지 잊어버렸다.
기획팀은 마케팅팀, 개발팀, 콘텐츠 제작팀, 등 여러 내부 이해관계자의 요청을 수집하고 상황을 전달하고 확인해야하는 업무를 매일매일 해내고있다. 그런데 슬랙으로 질문을 쏟아댔으니, 도대체 언제 답한단 말인가?
2. UI 작업에 기능 반영만 생각했다.
마케팅팀과 기획팀은 이벤트 페이지가 아름답기를 바랐다. 그런데 그런 마음을 모르고있었다. 하나 바꾸고 피드백을 요청하고. 아무리 서로간의 이해도를 맞추고 뇌를 공유하기 위함이라지만 시간을 들여 찬찬히 살펴봐도 되었다. 빠르게 가는 줄 알았는데 느리게 가고 있었다.
3. 지엽적인 디자인 부분에 대한 피드백을 자주 요청했다.
디자인 피드백 요청이 잦아지면 다른 부서에서 업무 피로도가 올라간다. 또한, 디자이너의 판단력에 대해 신뢰도가 낮아질 수 있다. → 마이크로 매니지먼트 현상이 발생하게 된다 → 모두가 작은 것에 매몰되어 큰 흐름을 못보게 된다 → 서로간의 소통이 방어적으로 바뀐다 → 공격하기 싫고 공격받기 싫고 방어하기 지쳐서 새로운 아이디어가 흐르지 않게 된다.
해결법 : Feedback 요청은 미팅 잡고 한다.
피드백 요청을 자주 보내면 디자이너도 디자인에 집중할 시간이 없이 메세지에 답장하는 시간이 더 많아진다. 변경 사항은 한번에 모아 공유하는 것을 추천한다. 피드백 장소는 슬랙이 아니라 노션과 아사나로 옮겼다.
Tips
디자인 피드백 요청은 몰아서 할 것. 수정사항이 시시때때로 들어오는 것을 좋아하는 디자이너는 없듯이, 시시 때때로 디자인 확인을 요청을 받고싶은 클라이언트는 없다. 각 팀원이 각 분야의 책임을 지고 전문가로 일한다. 시각 위계와 디자인 방향성에 대한 디자이너 자신의 능력을 불신하지 말자. 내가 믿지 못하면 남도 믿지 못한다.
하루에 10번의 피드백을 요청했다면 1–2번으로 줄이고, 프로젝트의 스콥에 따라 달리한다.
- 7주일 프로젝트는 1–2일에 한번씩 피드백 요청
- 4일 프로젝트는 하루에 한번씩 피드백 요청
작은 피드백 요청이 능사가 아니다. 스스로 생각을 정리해야할 때가 있다. 언제까지 무엇을 할지 스스로 여유 있게 정했으니, 디자이너에게도 더 신중히 고민할 시간이 생겼다. 슬랙 메세지 20번하고 하나 고칠 것을 2분만에 찾아낼 수도 있다.
개선된 프로세스 테스트와 후기
논의할 안건과 정돈된 디자인을 모아 개발 팀장, 마케팅 팀장, 기획자, 그리고 디자이너 4명이서 회의를 진행했다. 유저인터뷰를 할 때 처럼, 어떻게 회의가 진행될 것인지 간략하게 설명했다. 그리고 전체 회의 구조에서 지금 어느 부분을 얘기하고 있는지 알 수 있게 첫번째, 두번째, 세번째, 마지막으로 번호를 매겼다.
논의해야할 부분과 확인해야할 부분이 명료하게 준비되어 있으니 다음 업무를 예상하고, 일정을 합의하기도 쉬워졌다.
가만히 있으면 누군가가 테스트가 뭔지, 무엇을 고려해야하는지 순번을 매겨 알려줄 것이라는, 진공상태의 실험실 같은 기대는 그만두자. 빠르게 변하는 조직에서는 그 무엇도 명료하지 않다. 내가 이 테스크를 진행하는데 있어 알아야하는 것이 무엇인지 스스로에게 묻고 찾아다녀야한다.
글을 리뷰해주신 FCL 개발팀 최성권님께 감사드립니다.
이미지에 사용된 3D : Figma Saly 3D illustration pack
