구분해 보는 스토리보드와 화면 설계의 미묘한 차이에 대한 부분

앱이나 웹 개발 프로젝트에 투입되는 기획자는 보통 스토리보드 또는 화면 설계 작업을 합니다. 이 두 문서는 양식을 보면 같은 경우가 대부분입니다. 그런데 왜 스토리보드라 하고 화면 설계라고 하는 것일까요? 이 둘의 미묘한 차이를 통해 각 문서가 어떤 기획 목적을 가지는지 생각해 보겠습니다.

 

 

 

스토리보드와 화면 설계

 

스토리보드는 이름 그대로 앱 또는 웹의 이용 흐름을 기획한 문서를 의미합니다. 다양한 분야에서 활용되는 스토리보드는 같은 목적성을 지닙니다. 앱과 웹에서도 이는 같습니다.

 

어떤 분야의 스토리보드이든 이 기획 문서는 최종 제작물을 개발하기 위한 흐름을 사전에 정리한 것입니다. 그러므로 그 분야 콘텐츠/시스템/프로그램/제품 등의 개발에 필요한 기술의 적용과 작용이 설명되어 있습니다.

 

간단한 예로 많이 든 영화 '기생충' 스토리북처럼 장소, 미술, 조명, 음향, 의상, 카메라, 대사와 연기 등에 이르기까지 이어지는 영화 이야기가 관객에게 보일 내용을 스토리 흐름에 따라 정리되어 있습니다.

 

만약 '아바타' 같은 3D 영화를 개발 중이거나, '어벤저스'와 같은 SF 영화를 준비 중이라면 더 많은 컴퓨터, 시각, 데이터, 그래픽 등의 관련 기술에 대한 내용이 스토리보드에 포함될 수 있습니다.

 

이런 점은 앱과 웹 개발의 스토리보드에도 같이 적용됩니다.

 

그러므로 앱/웹 스토리보드에는 의도하는 사용자가 이용하는 앱/웹의 스토리라인이 구성될 수 있도록 프로그램과 코드, 디자인 등을 작업할 수 있도록 하는 다양한 기술적/비즈니스적/UX적 내용들을 표시되어 있습니다.

 

이를 기반으로 투입되는 개발자와 디자이너 등은 의도하는 앱/웹을 개발할 수 있게 됩니다.

 

 

이렇게 스토리보드가 스토리에 기반하여 앱/웹을 설계하고 있다면, 화면 설계는 화면에 기반하여 앱/웹을 설계하고 있는 문서입니다. 

 

화면 설계는 말 그대로 앱과 웹의 화면을 설계하는 것을 말합니다. 여기서 앱/웹 화면은 사용자가 해당 앱과 웹을 이용하면 볼 수 있는 모든 화면을 의미합니다.

 

그러므로 기본적으로 화면 설계는 각 화면의 이용과 작동을 설계하는 것이면서, 해당 앱/웹의 모든 화면을 설계하는 것을 목표로 합니다.

 

이런 이유로 화면 설계는 IA에서 파생되는 화면 정의서에 기반하여 작업되게 됩니다.

 

화면 하나하나를 설계하다 보면 앱/웹에 있는 전체 화면에서 놓치는 화면이 생기게 되기 때문입니다. '나무에 집중하다 숲을 보지 못한다'는 말처럼 이 또한 사람이 가지는 일종의 뇌 활동의 특성 때문에 발생하는 문제입니다.

 

이러한 놓치는 화면의 발생을 최소화하기 위해 화면 설계는 개발될 앱/웹의 메뉴를 기반으로, 각 메뉴에 종속되는 화면들을 정리한 후 이를 체크하면서 각 화면에 대한 설계를 진행하는 것입니다.

 

 

스토리보드와 화면 설계는 이외에도 다른 차이도 존재합니다. 앱과 웹 개발을 위한 기술적, 디자인적 요소와 UI/UX 측면에서는 다소 차이가 있습니다. 이는 스토리보드와 화면 설계가 기획을 하는 방식의 차이 때문에 발생하는 자연스러운 각 기획법의 한계 때문입니다.

 

바로 스토리보드는 UX에 비중이 더 큰 반면, 화면 설계는 UI의 비중이 상대적으로 더 클 수밖에 없습니다.

 

또한 스토리 기반 설계라는 점에서 스토리보드는 화면과 서버의 인터페이스에 대한 내용이 더 포함되고, 화면 설계는 화면 중심 설계라는 점에서 화면과 사용자의 인터페이스 내용이 더 포함되게 됩니다.

 

디자인적 부분도 앱과 웹이 각 화면을 세부적으로 설계하는 화면 설계에서 디테일하게 적용된다면, 스토리보드에서는 앱/웹 디자인의 통일성과 차이점을 중심으로 사용자 이용 흐름에서 형성될 경험(각 앱과 웹이 가지는 고유의 느낌과 감성)을 중심으로 적용되게 됩니다.  

 

 

 

정적 설계, 동적 설계

 

스토리보드는 스토리에 기반한 기획이므로 동적 설계라 할 수 있습니다. 그러므로 스토리보드는 사용자의 이용 흐름에 따라 발생하는 앱과 웹에서의 이벤트와 이 이벤트를 형성하기 위한 기능의 작동에 포커스 됩니다.

 

그러면 당연히 세부 디자인적 부분은 다소 부실해질 수 있습니다. 상당수 부분을 연결되는 흐름과 기능에 대한 내용을 우선순위로 넣다 보면 자연스럽게 디자인 설명이 적게 표시되기 때문이기도 하고, 문서 특성상 세부 디자인을 넣기에 맞기 않기 때문이기도 합니다.

 

이를 화면 설계를 통해 보완하게 됩니다.

 

그러나 대부분의 프로젝트 기획 기간과 R&R은 이렇지 않다는 데에서 문제가 생기게 됩니다.

 

스토리보드와 화면 설계 문서는 거의 같지만 때에 따라서는 다를 수 있습니다. 그런데 이 차이는 개발에 있어 큰 차이가 됩니다. 이 차이는 바로 화면 흐름의 표시 여부입니다. 물론 화면 설계 시에도 화면 흐름을 넣는다면 문서의 형식 차이는 줄어들 것입니다. 

 

 

화면 설계에서 작업 중인 화면의 사용자의 이동/도착 흐름을 넣지 않는 이유는 이 기획 문서가 정적 설계 문서이기 때문입니다.

 

여기서 정적 설계 문서라는 의미는 설계 시 해당 화면에 집중하여 기획된다는 말이 됩니다. 그러므로 이 화면을 어떻게 오게 되는지, 이 화면을 통해 어떤 화면으로 이동하는지에 대한 설명은 최소화됩니다. 그리고 많은 부분을 각 화면 컴포넌트와 UI, 디자인적 내용이 차지하게 됩니다.

 

지금 기획자가 작업하고 있는 화면이 앱과 웹에서 어디에 위치하고 있는지는 IA와 화면 정의서를 통해 파악됩니다. 그리고 화면 아이디를 통해 화면 정의서와 화면을 매핑하게 됩니다.

 

화면 아이디로 인해 기획자는 흐름이나 위치 생각하지 않고 화면만 설계하면 자연스럽게 전체 앱/웹 화면 중 하나에 맵핑되게 됩니다.        

 

그런데 공통 화면이 때로는 문제가 될 수 있습니다. 예를 들면 구매 프로세스 화면 같은 것입니다.

 

쿠팡과 같은 종합 이커머스 앱/웹의 경우 수많은 상품을 판매합니다. 이 때문에 카테고리도 많고 화면도 조금씩 다른 화면도 여러 유형이 존재할 수 있게 됩니다.

 

그러나 이 화면은 모두 구매를 목적으로 합니다. 그리고 사용자가 수많은 상품 카테고리 및 개발 상품 판매 화면에서 하는 최종 행동은 구매로 같습니다.

 

최종 행동 '구매' 이후에는 공통의 구매 프로세스가 나타나게 됩니다.

 

이 공통인 구매 프로세스에서 나오는 화면을 모든 개발 상품 페이지에 다 넣는 것은 비합리적입니다. 그리고 화면 정의서에 표시할 같은 화면이 너무 많아집니다. 

 

이 때문에 화면 설계 시 이런 공통 화면은 따로 정리합니다. 화면 정의서에도 공통 화면으로의 연결되는 화면이라는 점만 표시할 뿐, 공통 화면을 일일이 다 표시하지는 않습니다.   

 

물론 화면 정의서의 어느 한 부분에 공통 화면은 화면 아이디를 따서 정리해 놓기는 합니다. 앱/웹을 이용하면 사용자가 보게 될 화면이기 때문입니다.

 

이러한 공통 화면에 대해서는 스토리보드를 통해 보완을 할 수 있습니다. 구매 프로세스는 스토리(흐름) 기반이기 때문입니다.   

 

 

 

스토리보드와 화면 설계의 기획 목적 

 

스토리보드는 앱/웹 사용자 UX, 화면 설계는 앱/웹 사용자 UI 기획을 목적으로 한다고 할 수 있습니다.

 

일반적으로 화면 설계에서도 UI/UX라고 하기에 이 말의 의미는 다소 의아할 수 있습니다. 그러나 지금까지 이 글을 읽어 왔고, 또 이 글의 제목에 있는 '구분해 보는 미묘한 차이'라는 표현을 보면 의아함은 줄어들 것이라 생각 듭니다. 

 

 

스토리보드는 이름 그대로 앱/웹 사용자 이용 스토리를 기획하는 것입니다. 그런데 왜 스토리를 기획하는 것일까요? 이는 앞서 '기생충' 스토리북에서 답을 찾을 수 있습니다.

 

바로 사용자가 느끼는 앱/웹 이용 시 경험을 위한 스토리라는 점입니다. 이를 위해 코딩, 디자인, 퍼블 등이 작업되는 것입니다.

 

그리고 바로 스토리를 통해 제공하려는 경험을 UX라 하기 때문에, 스토리보드를 앱/웹 사용자 UX 기획을 목적으로 한다고 말한 것입니다.

 

 

화면 설계는 이름 그대로 앱/웹의 화면을 설계하는 기획하는 것입니다. 그런데 왜 화면을 설계하는 것일까요? 화면을 디자인하는 것과 화면을 설계하는 것의 차이는 무엇일까요?

 

여기서 UI에 대한 기능적 가치를 통해 화면 설계와 디자인의 차이가 만들어지게 됩니다. 

 

만약 화면 설계자가 단순히 화면을 그리는 수준이라면 디자인과 크게 다를 것이 없게 됩니다. 그러기에 디자인 툴인 피그마가 국내에서는 기획 툴이 된 것입니다.

(사실 해외에서는 국내에서와 같은 화면 설계자가 없습니다. 화면 설계는 개발자 또는 디자이너가 합니다. 디자이너가 화면 설계를 할 경우 피그마는 화면 설계의 중요한 툴이 됩니다. 그냥 디자인 툴이 화면 설계 툴이 되는 것입니다.)

 

화면 설계는 사용자와 화면이 인터페이스 되는 사항을 정의함으로써 코딩도 아니고, 디자인도 아닌 영역의 기술을 형성했습니다. 

 

이런 모호함이 프로젝트에 따라 개발자나 디자이너 요구에 따라 화면 설계가 되기도 하고, 화면 설계 기획자의 요구에 따라 개발이나 디자인이 변경되기도 하는 현상이 발생합니다.

 

 

첨가하여 말하자면, 화면 설계가 UI는 효과적으로 기획할 수 있으나, UX를 기획하는 데는 한계가 있는 것은 바로 UX와 화면 설계의 특성 때문입니다.

 

UX(유저 경험)는 상호 작용의 연속에서 오는 결과입니다.  그러나 화면 설계는 앞서 이야기했듯이 각 화면에 대한 설계이므로 상호 작용의 연속성이 제한될 수밖에 없습니다. 이 특성 때문에 정적 설계라고 한 것입니다. 물론 UX 프로세스에 화면이 포함됩니다. 그래서 일정 부분 화면 설계가 UX에 영향을 미치기는 합니다. 그래서 제한적이라 한 것입니다.    

 

화면 설계가 UI 기획은 효과적이라 한 것은 앱/웹 사용자와 인터페이스 되는 사항은 화면 단위로 세세히 기획할 수 있기 때문입니다.