프로토타이핑 툴 써야 할까?
결론부터 이야기하면 ‘쓰는 것이 좋다’.
파워포인트로 기획을 시작하면서 불편한 점이 한두개가 아니었다.
대표적인 불편함을 꼽아보자면
1. 길거나 큰 화면을 그릴 때
길거나 큰 화면을 그릴 때 파워포인트로는 그릴 수 없는 한계가 명백히 존재한다. 덕분에 글씨와 사이즈는 자꾸 작아지고, 공통 영역의 잦은 생략 등으로 인해 한번에 알아보기 힘든 기획서가 만들어진다.
2. 디스크립션은 왜 이리 긴지
생소한 화면이나 설명을 많이 요하는 화면의 경우에는 파워포인트 우측에 주석과 같은 디스크립션을 종종 달게 되는데 작은 글씨로 무언가를 빽빽하게 채워 넣는 작업은 쓰는 사람에게나 읽는 사람에게나 모두 상당히 고역이다.
3. 인터렉션은?
웹 기획, 소프트웨어 기획에서 가장 핵심이 되는 데이터 요소 정의 이외에 중요한 것이 각 요소 간 상호작용을 표현하는 것이다. 파워포인트에서는? 이 버튼을 클릭 시 알럿 창이 출력된다. 이 버튼을 클릭하면 어떤 페이지로 이동한다. 이 인터렉션에서는 어떤 기능들을 제공한다 등 대부분의 인터렉션을 글로 설명할 수밖에 없고 이는 높은 확률로 미스커뮤니케이션을 야기한다. 심지어 기획자 자신마저도 많은 양의 기획서를 작성하다 보면 인터렉션 간의 논리의 충돌을 발생시키는 경우가 빈번하다. 이런 경우는? 당연히 욕을 먹는다.
4. 타 부서와의 소통은?
복잡한 웹 용어와 다양한 와이어프레임 요소, 디스크립션이 혼합된 200페이지짜리 파워포인트 기획서를 비 IT부서에 전달했다고 가정하자. 그들이 이해하는 것과 우리가 이해하는 것이 같다고 보장할 수 있는가? 심지어 한 기획서를 두고서 기획자들끼리도 서로 이해하는 부분이 상충되는 일도 빈번히 발생한다.
어도비 XD, 프레이머, 인비전, axure, 발사믹 목업과 같은 프로토타이핑 툴을 이용하게 되면 위와 같은 이슈는 상당 부분 해결할 수 있다.
물론 파워포인트 기획서만의 장점도 존재한다.
1. 익숙하다.
파워포인트로 스토리보드를 주고받는 일 처리 방법은 웹 개발, 소프트웨어 개발 분야에서 상당히 보편화된 방식이라고 볼 수 있다. 소프트웨어 개발 방법론처럼 모두에게 딱 정형화된 프로세스까지는 아니더라도 상당 부분 전국의 기획자들끼리 공유하고 있는 일련의 웹 기획 서술방식이 존재한다.
2. 사내 보안 이슈에서 강점이 있다.
은행, 보험 등 금융권 웹 기획 개발에서는 외부 개발 소프트웨어 도입을 엄격히 제한하는 경우가 많다. 즉, 어도비 XD가 아무리 유용하다고 한들, 내부 규정으로 인해 해당 소프트웨어를 사용하지 못하게 되는 경우가 있다. 파워포인트는 전 세계적인 문서 작성 툴로서 인정받고 있으므로 이러한 이슈에서 자유롭다고 볼 수 있다.
3. 문서 형태로 저장이 용이하다.
즉, 기획서를 회사의 자산으로 계속 남겨둘 수 있다. 프로토타이핑 툴 같은 경우는 문서 저장 시 당연하게도 해당 툴 고유 확장자로 저장되는데, 타 부서, 혹은 같은 기획자라 할지라도 해당 소프트웨어가 깔려있지 않으면 문서를 수정하거나 열람하는데 어려움을 겪을 수 있다. 즉, 전임 기획자가 열심히 프로토타이핑 작업을 해둔 후 홧김에 퇴사를 해버리면 회사 입장에서는 기획 히스토리를 알 수 없는 문제가 발생할 수 있다.
4. 비용의 문제
특정 프로토타이핑 툴은 사용하는데 비싼 비용을 요구하기도 한다. 알다시피 파워포인트는 저렴한 비용 혹은 어둠의 경로를 통해 무료로 이용이 가능하다. (어둠의 경로보단 정당한 대가를 지불하고 쓰는 것이 좋습니다.)
그렇다면 선택은?
어떤 툴을 사용하든 그 나름의 장단점이 존재한다. 회사의 입장, 개인의 입장, 부서의 입장을 모두 고려하여 적절한 방안을 마련하는 것이 좋겠다.
이렇게만 결론을 지으면 너무 무책임하기 때문에 내 사례를 곁들여 설명한다면…
나의 경우도 파워포인트 기획서의 한계를 느끼고 프로토타이핑 툴 axure의 도입을 팀에 강력히 요청했다. 하지만, 세상 일이 참 쉽지 않아서 개발팀원들이 기존의 방법을 버리고 axure를 도입했을 때 기존의 업무 방식이 틀어지는 것을 원치 않아서 설득하는데 굉장히 어려움을 겪었는데, 결론적으로 팀과 내가 결정한 방식은 아래와 같다.
1. 기본 밑 작업은 프로토타이핑 툴로 진행한다. 이때 프로토타이핑 작업물은 외부 비 IT 부서 사람들과 리뷰를 할 때도 활용한다.
2. 프로토타이핑으로 전체적인 밑그림을 완성한 후에는 익숙한 파워포인트로 작업물을 옮긴다. 요소를 새로 그리는 것이 아닌 복사 붙여 넣기 방식을 사용하기 때문에 작업시간이 그리 오래 걸리지 않는다.
이런 방법을 차용했을 때 장점은
1. IT를 잘 모르는 사업 부서와의 의사소통이 엄청나게 편해졌다. 실제 웹사이트 혹은 소프트웨어와 유사한 형태의 프로토타입을 통해 시연 리뷰를 하면 본인의 원했던 것과 서비스 기획의 의도가 맞는지를 즉시 판단할 수 있기 때문에 이른바 일을 두 번 해야 하는 경우 (개발이 완료된 후 작업물이 의도한 바와 달라서 재개발해야 하는 경우)가 없어졌다.
2. 기존의 ppt 작업 방식의 프로세스를 준수하기 때문에 개발자와도 큰 부딪힘 없이 일을 진행할 수 있었다. 오히려 인터렉션이 이해가 안 되거나 설명이 필요한 부분은 프로토타입을 보면서 같이 의사결정을 할 수 있으니 업무 진행이 한결 편해졌다.
나의 경우는 상당 부분 사내에 프로토타입을 통한 업무 진행 방식을 도입하였고, 결론적으로는 다양한 부서를 만족시킬 수 있었다고 생각한다. (물론, 진짜 속사정이야 내게 이야기를 해주지 않으니 알 수 없지만)
본문에서도 이야기하였듯이 프로토타이핑 툴을 반드시 도입해야 하는 것은 아니지만, 분명히 ‘실물’과 가까운 ‘시안’으로서 미스커뮤니케이션을 방지하는 용도의 프로토타이핑 작업은 회사의 비용을 감소시키는 데 큰 도움을 준다고 할 수 있다. 하지만 선택은 각자의 몫이다. 이전에 없던 새로운 것을 도입한다는 것은 모두에게 부담을 줄 수 있다. 비즈니스가 as usual 하게 잘 돌아가고 있는 집단이라면 꼭 도입할 필요에 대해서 많은 사람이 의문을 가질 수 있다. 결국 모든 일은 사람이 하는 일이기 때문에 잘 설득하고 잘 공감해서 서로가 만족할 수 있는 범위에서 일을 하는 것이 좋을 것이다.
