UI.UX / 화면 설계서 이야기. 1
PART.1 메인 업무에 대한 고찰
IT 업계에서 UI/UX 기획, 서비스 기획일을 하다 보면 주로 어떤 일을 많이 하게 될까?
이것저것 다양한 일을 많이 한다는데, 메인이 되는 일은 무엇일까.
서비스 개발의 기초가 되는 일이며, 기획자의 실력을 가장 잘 드러낼 수 있는 메인 업무는 분명 '화면 설계서'를 작성하는 업무일 것이다. 글쓴이는 웹기획자로 불리는 시절부터 서비스 기획자로 불리는 현재까지 '화면 설계서'를 작성하는 일을 단 한 번도 손에서 놓아본 적이 없으며, 일과에 7할 이상 '화면 설계서' 작업에 시간을 들이는 듯하다. 이번 글에서는 서비스 기획자에게서 떼려야 뗄 수 없는 '화면 설계서'에 대한 이야기와 실제 작성하는 방법까지 여러 파트에 걸쳐서 이야기하고자 한다.
'화면 설계서'란 무엇일까?
화면 설계서는 회사마다 프로젝트마다 부르는 다양한 명칭들이 있는데 보통은 스토리보드(SB), 화면 정의서, UI정의서, 화면 설계서로 불려지곤 한다. 화면 설계서는 말 그대로 각종 디바이스의 화면을 설계한 문서라고 볼 수 있는데, 디바이스란 대체적으로 PC웹, 모바일, 태블릿 PC, tv 등이 해당된다. 서비스 기획자는 이러한 디바이스에 들어가는 소프트웨어의 화면, 애플리케이션, 웹사이트의 화면을 기획하고 그리는 작업을 하며 각종 정책과 화면이 구동되는 정의까지 필요한 모든 것을 화면 설계서에 담아낸다.
'화면 설계서'가 중요한 이유
글쓴이는 화면 설계서의 작성 능력을 아주 중요하게 생각하는데, 이유는 다음과 같다.
1. 화면 설계서는 이해관계자들이 서로 지키기로 합의한 문서.
프로젝트를 하게 될 경우 대체적으로 짧은 시간 내에 많은 조직들이 다양한 의견으로 의사결정을 하게 되는데 이때 시각적으로 명확하게 보여줄 수 있는 것이 화면 설계서이다. 보통은 화면 설계서에 정의된 내용을 토대로 각 협업 파트는 일정을 산정하기도 하며, 필요시 설계 수정 요청을 하기 때문에 화면 설계서가 갖고 있는 약속의 효력은 상당히 크다고 볼 수 있다. 또한 서비스 개발이 완료된 이후 누락된 기능이 간혹 생기기도 하는데 이때 마지막으로 협의된 화면 설계서의 내용을 토대로 해당 기능의 개발 여부가 결정된다. 때문에 '화면 설계서'는 계약의 관계에 있어서도 중요한 근거 자료 역할을 하기도 한다.
2. 화면 설계서는 서비스 제품 개발을 위한 설계서.
혹자는 '화면 설계서'를 커뮤니케이션 수단의 정도로만 여기는 경향도 있다. 부분적으로는 동의하지만, 커뮤니케이션의 수단으로만 여긴다면 추가 및 보완되는 기능과 정책들이 이곳저곳 산재되어, 개발이 완료된 후에도 누락되는 경우가 많이 발생한다. 더불어 '화면 설계서'는 말 그대로 '설. 계. 서'의 기능을 충족시킬 수 있어야 한다. 즉 '화면 설계서'만 있어도 충분히 서비스 제품을 개발 가능해야 한다는 의미이다. 물론 완벽할 수는 없다. 기획자는 개발자가 아니므로 개발에서 필요한 요소를 완벽하게 넣을 수 없으며, 또한 넣는다 하더라도 그것이 전문적인 지식이 아니기 때문에 오히려 잘못된 내용으로 개발함에 있어 역효과를 불러올 수 있기 때문에 개발자가 필요한 요소를 완벽히 넣을 수는 없는 것이다. 그럼에도 불구하고 사용자 입장에서 기획자가 정의할 수 있는 부분은 세심하게 정의하여, 개발자가 상상으로 코딩을 하지 않도록 설계서 다운 설계서를 작성해야 한다.
※ 디자이너, 퍼블리셔, 개발자와 더 나은 커뮤니케이션을 하고 싶다면 화면 설계서부터 제대로 작성하자.
화면 설계서만 잘하면 되는 것인가?
그렇지는 않다. 기획자는 본인의 서비스의 문제점을 발견하는 능력 (데이터 기반의 문제점 발견 및 의사결정), 각 협업 파트와 원활한 커뮤니케이션을 할 수 있는 능력, 태스크들의 우선순위를 선정하고 배포 시까지의 일정을 관리하여 원활하게 서비스가 배포될 수 있도록 하는 매니징 능력 등 다양한 업무 역량을 요구한다. 이렇게 다양한 업무의 역량을 요구하더라도 '화면 설계서' 작성은 기획자의 기획력을 반영한 문서이기 때문에 계속해서 중요하다고 강조하는 이유이다.
화면 설계서의 작성 방법
글쓴이가 항상 믿고 있는 부분이 있다. 세상에는 '원래'라는 것은 존재하지 않는 것. '원래 이렇게 했다.' '원래 이게 맞다.'라는 말은 마치 그것이 정답이고 그렇게 하지 않으면 잘못된 것으로 생각하는 부분인데, 그것은 본인이 직접 '경험이 없다.', '새로운 것에 대한 공부를 하지 않는다.' '더 나은 방향을 찾기 위해 노력하지 않는다.'라고 직접 말하는 것 과 같다. 서비스 또는 프로젝트는 살아있는 유기체와 같다고들 한다. 주어진 시간, 인력, 환경에 따라서 일의 방식은 효율적으로 변경될 수 있기 때문이다. (관례처럼 하던 것을 생략하거나, 하지 않았던 것을 추가하는 방식)
이런 말을 갑자기 언급하는 이유는 화면 설계서 또한 원래 이렇게 했다는 것은 없으며, 혹시나 작성 자체의 정석을 찾으려고 애를 쓰지 않았으면 하기 때문이다. 주어진 환경과 상황에 따라서 기존에 사용하던 방식 (툴과 구성 요소)을 변형할 수도 있으며 때로는 완전히 다른 방식으로 진행할 수도 있기 때문이다. 다만 여태껏 선배들이 해온 방식을 계속 발전하여 현재 상황에 맞게 그리고 더 효율적인 방법을 찾아서 하는 것 일 뿐 '1+1=2'인 것처럼 정답이 있는 것은 아니다.
작성 방법을 알려드리기 전에 이렇게 밑밥을 까는 이유는, 지금부터 알려드릴 작성방법에 대해서 의심을 갖지 말고 또 다른 기획자는 이렇게 '화면 설계서'를 작성하는구나. '참고할 부분은 참고하자'라는 넓은 마음으로 바라봤으면 한다.
'화면 설계서' 작성 툴
글쓴이가 10년 전 기획자로 일을 시작할 때부터 불과 1년 전 (2021년)까지 만하더라도 국내에서는 화면 설계서는 '파워포인트'를 주로 사용하여 일을 해왔지만, 근래에는 파워포인트 만이 아닌 '피그마'를 통해 많이 작성을 하는 추세이다. 각각 장단점은 추후에 설명하기로 하며, 본질은 '툴은 거들뿐'이기 때문에 툴에 연연하지 않고, 본인의 설계가 얼마큼 설득력이 있는지, 설계서로써의 역할을 충분히 하고 있는지에 대한 고민을 많이 하자.
그럼 다시 본론으로.
화면 설계서는 작성 과정은 크게 아래와 같다.
1. 플로우 차트 작성
2. 키스크린 작성
3. 영역 별 노출 또는 예외 케이스 및 CTA 트리거 정의 작성 (사용자별, 데이터 존재 유무별 등)
4. 밸리데이션 정의 및 디스크립션 상세화 (벨리데이션 정의는 3번에서도 포함 가능)
5. 수정 > 보완 > 수정 > 보완 (오픈 시까지 반복)
위 과정은 실제 기획 영역에서 메인 UI/UX 컨셉과 공통 UI가 어느 정도 이루어진 다음에서 진행되는 큰 단계라고 볼 수 있겠다. 물론 회사마다 또는 기획자마다 작성의 방식과 순서는 다를 수 있지만, 1-5번은 겪어본 프로젝트에서는 빠짐없이 작성했던 내용이므로 어느 정도 신뢰성은 있다고 생각한다. 우선 1-5번을 상세하게 설명하기 전에 다음 파트에서 메인 UI/UX 컨셉과 공통 UI 어떻게 만들어지며, 해당 컨셉이 실제 화면 설계서에 반영은 어떻게 되는지 알아보고 나서 1-5번에 대한 내용을 순차적으로 이야기하겠다.
그럼 이만.
