기획자로서 나는 뭘 해야 할까?
웹사이트 구축 프로젝트와 기획자
안녕하세요! 제가 플러스엑스에서 UX 디자이너(기획자)로 일한 지 거의 1년 반이 되었는데요.
아직 '애송이' 냄새를 풀풀 풍기며 한창 배우는 중이지만, 오늘은 그동안 일하며 기획자라는 포지션에 대해 많은 생각을 하게 했던 웹사이트 구축 과정과 기획자의 롤에 대한 글을 써볼까 합니다.
(*본 글은 그냥 주니어가 아닌 '매우 주니어'가 쓴 글이니, 가볍게 봐주셨으면 좋겠습니다)
먼저, 웹사이트 구축 프로젝트는 기획자, 디자이너, 퍼블리셔, 개발자들이 함께 고객이 원하는 웹사이트를 만드는 것을 목표로 커뮤니케이션하며 협업하는 프로젝트입니다.
웹사이트 구축 과정은 크게 제안과 구축으로 나뉩니다.
우선 프로젝트 킥오프 미팅 이후에 고객사의 요구사항이 정리된 RFP 문서를 전달받습니다. 그 내용을 기반으로 고객사 인터뷰를 시행하여 해당 프로젝트 목적과 니즈를 더 명확히 하고 그에 맞는 전략과 디자인 시안을 준비합니다.
1. 웹사이트 제안 단계
Photo by Campaign Creators on Unsplash1-1. 킥오프 미팅
1-2. 웹사이트 목표 설정
1-3. 리서치 (인터뷰, 시장 조사, 벤치마킹 등등)
1-4. 웹사이트 기능 정의
1-5. IA 구성
1-6. 설계 Mock-up 제작
1-7. 웹사이트 제안 디자인 시안 제작
1-8. 제안 산출물 전달
이후 제안 과정의 산출물을 클라이언트가 받아들이면 본격적으로 웹사이트 구축을 하게 되며, 실제 구축 과정을 나열하면 다음과 같습니다.
2. 웹사이트 구축 단계
Photo by Campaign Creators on Unsplash2-1. 웹사이트 구축 프로젝트 WBS 설정 및 관리
2-2. 웹사이트 기획 및 설계
2-3. 웹사이트 디자인
2-4. 퍼블리싱 & 개발
2-5. QA (QA에 관한 글은 저희 팀 Yunnie님께서 아주 잘 써주셨습니다. 꼭 봐주세요!)
2-6. 오픈
2-7. 웹사이트 운영 가이드 작성 및 완료 보고서 작성
2-8. 최종 산출물 전달
이 과정 속에서 기획자인 나는 뭘 해야 할까?
위에서 잠깐 언급하긴 했지만, 웹사이트 구축 프로젝트에는 기획자/디자이너/퍼블리셔/개발자가 참여합니다.
기본적으로 각자의 역할을 순서대로 나열하자면 다음과 같습니다.
1. 기획자는 요구사항에 대한 전략을 구축하고 이에 필요한 밑그림(기능 정의, IA 구성, 스토리보드)을 디자이너에게 전달합니다.
↓
2. 디자이너는 기획자가 구축한 전략에 맞는 디자인 콘셉트를 세우고 다양한 디자인 소스를 통해 화면을 디자인하여 퍼블리셔에게 전달합니다.
↓
3. 전달받은 디자인을 퍼블리셔가 HTML 페이지로 만들고 개발자는 HTML 페이지에 기능을 구현시킵니다.
기획자는 메인으로 앞단을 담당하고, 또한 1→2→3번의 단계를 넘어가는 사이마다 관여해야 하는 일이 많아 사실상 프로젝트의 중심에 기획자가 있다고 봐도 무방합니다.
거기다가 커머스와 같이 특정한 기능을 수행해야 하거나, 복잡도가 높은 웹사이트의 경우에는 정리해야 할 것도 많고 전문 지식이 필요한 경우가 많아 기획자의 역할이 매우 커집니다.
그래서 프로젝트에 투입되면 정말 모든 부서에서 기획자아아~!!! 하면서 찾고, 거의 모든 미팅에 콜 되기도 하고 스스로 미팅 자리를 만들기도 합니다.
(*물론 진짜 "기획자아아~!!!" 하고 찾으시는 분은 없습니다. 그냥 OO니이이임! 하고 이름을 부르죠...)
But! 기획자의 역할이 축소되는 경우도 있습니다.
사실 오늘 이 글을 쓴 목적은 바로 이런 경우 때문입니다.
특정한 기능 없이 기업 또는 브랜드를 소개하는 것에 목적은 둔 웹사이트들은 사이트 방문자들의 이목을 한 번에 확 끌면서 원하는 정보를 전달하는 것이 주목적이기에 모션을 포함한 화려한 시각적 디자인 요소가 더욱 중요합니다.
그래서 UI 디자이너와 프론트엔드 개발자의 퍼포먼스가 더 중요하기에, 투입되는 리소스도 기획 파트 보다 시각적인 작업에 더 할당되는 편입니다.
거기다가 만약 고객사에서 이미 상위 기획을 끝낸 상태로 프로젝트를 준다면 기획자가 해야 하는 일의 범위는 더 축소되게 됩니다.
결국 이런 경우엔 고객사와 디자이너, 퍼블리셔, 개발자 사이에서 각자가 필요한 정보를 정리하여 전달하고 단계별 산출물을 전달하는 Messenger 역할을 수행해야 할 수도 있는 것이죠...
그래서 이제부터 본 글의 목적이자 주 내용인 기획자로서의 역활이 축소된 상황에서 내가 '강한 기획자' 이자 '좋은 Messenger' 가 되려면 어떻게 해야 하는지 말씀드리겠습니다.
(*물론 후술할 내용이 기획자로서 역할이 축소되었을 때만 한정되는 것은 아닙니다!! 어찌 보면 기획자로서 갖춰야 하는 기본적인 소양인데, 축소된 역할을 잘 수행하려면 결국 기본을 잘하는 것이 중요하기 때문에 말씀드리는 거예요)
Messenger여도 '좋은 Messenger' 가 되려면?
단순한 정보든, 문서, 콘텐츠 전달이든 '그냥 전달'만 하는 것은 좋지 않습니다.
정보를 주는 입장에서든 전달받는 입장에서도 그걸 바라는 것만은 아닐 테니까요.
의도와 목적을 담아 커뮤니케이션하고 전달받는 정보는 받는 직군에서 웹사이트 구축에 활용이 용이하도록 가공하는 것이 필요합니다.
그러려면 기획뿐만 아니라 디자인, 퍼블리싱, 개발 및 웹 서비스 산업에 대한 이해와 학습이 많이 필요합니다.
그리고 프로젝트에 참여하는 이해관계자들의 환경 및 상황을 수시로 파악하는 것도 중요하고요.
자, 그럼 이제 어떤 마인드를 가지고 어떻게 프로젝트에 임해야 하는지 말씀드리겠습니다.
1. 웹이든 앱이든... 투입된 프로젝트의 환경을 잘 이해하자
http://www.evolutionoftheweb.com요즘에는 앱 위주로 UXUI를 배우다 보니, 웹에 대해 잘 모르는 상황이 꽤 많습니다.
웹이라는 환경에 대한 특성과 구조 및 한계 등을 이해하지 않은 채 투입되면, 웹 접근성을 전혀 고려하지 않고 구조를 뒤죽박죽 설계하거나 반응형이 뭔지 제대로 몰라 적응형의 구조를 설계하는 일들이 일어나곤 하죠.
저도 제품 디자인에서 UX 디자인으로 전향하고 나서 초반에는 어떻게 구조를 잡아야 PC와 모바일 뷰의 전환이 쉬울지 판단하는 것도 어려웠습니다...
"이거... 버튼이 고정되어 있다가 모바일로 바뀌면 플로팅으로 할 수 있나...?"
이런 고민을 하며, 친한 개발자님 혹은 사수님께 헬프를 많이 치기도 했습니다...
그러니 웹을 이루는 기술이 어떠한 것들인지, 그것들을 통해 무엇을 할 수 있는지 그리고 구조나 콘텐츠의 선형화가 어떻게 되는지 기본적으로 알아둡시다
일단, 구축될 웹이 반응형이든 적응형이든 일단 어느 디바이스까지 지원할지 우선 고민해야 합니다.
기본적으로 피씨와 모바일을 가져가면서 중간에 태블릿 사이즈도 지원할지도 체크하면 되며, 대응할 해상도 설정 및 (반응형일 경우) 브레이킹 포인트는 디자인 쪽에서 잡아주기에 그다음 우리는 구축할 웹 환경에 맞게 설계되고 디자인되고 있는가를 틈틈이 확인하면 됩니다.
추가로 솔루션을 쓰는 경우엔 기획한 기능에 대응되는 API 지원 여부, 스킨 가공을 어디까지 할 수 있는지, CMS 추가 개발이 필요한가? 등의 사항까지 퍼블리셔, 개발자들과 잘 얘기해서 미리 파악해두는 것도 좋습니다
더 나아가 HTML, PHP 코드도 읽고 약간의 수정이 가능한 단계까지 배워두시면 더 강한 기획자가 될 수 있습니다.
2. 히스토리를 늘 남기고 최대한 객관화하자
저희가 하는 커뮤니케이션의 기반은 전부 기록에서부터 시작됩니다.
먼저 미팅이 잡히면 '회의록은 내가 쓰는 거다'라고 생각하시고 늘 회의록을 남기는 것이 좋습니다.
회의록에는 미팅 장소, 시간, 참석자, 주요 안건을 먼저 기재하고 그다음에는 안건마다 나온 피드백 혹은 의견들을 화자 별로 묶어주면 추후에 정리하기 편합니다.
미팅이 끝난 뒤에는 적은 회의록을 다시 정리해서 미팅에 참석했던 이들에게 메일로 전송해야 합니다.
여기서 참석자의 이름을 잘못 적거나 맞춤법 오류가 있으면 안 되므로 맞춤법 검사를 꼭 해주시는 것이 좋습니다. 그리고 내용 정리를 할 때 자기 주관을 섞어 미팅 내용이 왜곡되게 하면 절대 안 됩니다.
만약 회의록도 적고 정리도 다 했는데, 뭔가 불안하고 자신이 없다면 꼭 무조건 회의에 참석한 상급자 혹은 사수에게 컨펌을 받고 메일을 전송합시다!
그리고 프로젝트에 관련된 정보를 구두로 전달받거나, 메신저로 전달받을 때도 텍스트로 정리해서 기록을 남겨두는 것이 좋습니다.
의외로 이렇게 가볍게 전달된 정보들이 프로젝트 참여자 전원에게 전달되지 않고 중간에 누락되기 쉬워 나중에 프로젝트에 구멍이 생깁니다.
(*에버노트, 노션, Coda 같은 툴을 사용해서 프로젝트 위키를 만들듯이 아카이빙 해놓으시면 더 좋습니다)
3. 스케줄 관리를 위한 끊임없는 체크 업
고객사에서 요구하는 대부분의 요구사항은 기간과 리소스의 문제가 있을 뿐, 아예 불가능한 것은 그렇게 많지 않습니다.
보통 도저히 불가능한 것들은 제외되고 남은 요구사항들을 반영하는데, 사실 그렇다 하더라도 늘 어느 프로젝트든 예상치 못한 변수가 있어 일정과 리소스가 여유로울 순 없습니다.
물론 전체적인 프로젝트 스케줄은 PM이, 각 팀의 스케줄은 그 팀의 PL들이 관리하지만, 서로 톱니바퀴처럼 업무가 맞물려있기 때문에 한쪽에서 업무 진행에 차질이 생기면 전체적인 일정이 조금씩 흔들립니다.
그래서 우리 기획자들은 각 팀의 업무 진행 상황을 늘 수시로 체크해야 하고 문제가 있다면 무엇이 문제가 되는지 파악해야 합니다. 그래야 그 문제를 해결하기 위한 도움을 줄 수 있으니까요.
데이터 수급의 문제로 디자인 일정이 늘어지는 경우를 예로 들면, 공급처로부터 언제까지 데이터를 받기로 했고 어떤 채널로 어떤 형식으로 받기로 했는지, 그리고 공급처는 어떤 이슈로 제때 데이터 수급을 못 해주고 있는지 등의 내용을 파악하여 데이터를 빨리 수급해달라고 공급처에 푸시하거나 내부 스케줄 조정 같은 방안을 찾아볼 수 있죠.
(*물론 이런 사항은 미리 파악한 상태면 더 원활하게 대응할 수 있습니다)
4. 주도적으로 움직이자
위에서 말씀드린 부분과 이어지는 사항입니다.
프로젝트에 PL과 함께 투입되면 대부분의 의사결정과 이슈는 PL 분들이 해결해주실 수도 있지만, 지금껏 PE였던 내가 홀로 투입된다면...?
그럼 PL 마인드를 가지고 주도적으로 움직여야 합니다.
(*제가 처음 홀로 프로젝트에 투입되었을 때, 어버버 하면서 수동적으로 임했더니 동료 디자이너분들이 많이 고생하셨던 것이 아직도 죄송스럽습니다 ㅜㅜ)
주기적으로 각 팀 상황을 체크하는 것은 물론이고, 이슈 대응 요청이 나에게 오지 않더라도 도와줄 일은 없는지, 혹시 프로젝트 진행하면서 놓치고 있는 디테일한 사항들은 없는지, 프로젝트에 필요해 보이는 정보 혹은 자료 먼저 챙기기 등의 액션을 취해준다면 프로젝트 진행에 더 도움이 될 수 있습니다.
위에 말씀드린 이 4가지를 잘 해낼 수 있다면 분명 우린 '강한 기획자' 이자 '좋은 Messenger' 가 될 수 있습니다.
저도 아직은 계속 헤매면서 여러 작은 사고도 치고 있지만... 이제는 이런 것들을 내가 해야 하고 배워야 한다는 것을 깨달아가며 성장하고 있습니다.
이 글이 도움이 되길 바라며 글을 마칩니다.
감사합니다.
