이 주제에 대한 더 자세한 글들을 올리게 될 것이다. 그렇지만 오늘 친구의 질문에 대한 대답을 간단히 정리하면 이렇다. 친구의 질문은 디자인을 하는 방법이나 로직이 있나 하는 것이다. 짐작했겠지만 이놈은 공돌이이고 개발쪽을 주로 해왔던 (중간에 보험 영업도 했지만) 친구이다.
디자인은 결국 무엇을 어떻게 보여줄까에 대한 문제이다. 전자는 기획적인 부분이고, 후자는 화면의 디자인에 대한 부분이다. 나는 편의상 전자를 UX기획, 후자를 UI디자인이라고 이야기한다. 물론 두가지를 칼같이 나눌 수 있는 것도 아니고 오버랩 되는 부분들이 존재하며, UI디자인을 하면서 앞에서 정의했던 사용자가 수행하는 태스크나 기능의 목록이 수정되기도 한다. (주로 상세 기능이 추가되는 것이어야겠지만) 다시 ‘무엇’이라는 것은 크게 정보와 조작이라는 두 가지의 요소를 포함한다. 화면에는 사용자가 참고해야 하는 정보를 제공하며, 그 정보를 확인한 후 사용자가 어떤 조작 (액션)을 하는 과정이 뒤따른다. 정보를 제공하고 사용자가 조작을 하면 또다른 정보를 제공하고 또다른 액션으로 이어진다. 이것이 결국 인터랙션이라고 이야기하는 과정이다.
UX 기획과 서비스 기획은 무엇이 다른가? 일반적으로 기획자라고 한다면 서비스 기획 (또는 제품 등의 기획)을 하는 사람들을 이야기한다. 서비스 기획자는 말 그대로 서비스를 기획하는 사람이다. 서비스에 대한 구체적인 주제를 정하고, 다른 서비스들과의 차별화 방법을 고민하고, 이것을 어떻게 제공할 것인가, 매출과 비용을 산출하여 수익을 계산하고 마케팅을 어떻게 할 것인지 등에 대한 사업 기획을 하는 사람이다. (물론 큰 회사의 경우 수익이나 금전적인 논의를 하는 다른 사람이 있기도 하다) 서비스를 보여주는 과정에서 기획자들이 이용하는 도구가 스토리보드이다. 많은 사람들이 스토리보드를 UI 디자인을 한다고 이야기하는데, 엄밀히 말하면 스토리보드와 UI 디자인은 다르다. 첫째로 이 도구를 사용하는 목적 자체가 다르고 (서비스를 설명하기 위한 목적인가, 사용자가 이용하는 구체적인 디자인을 하는 목적인가), 머리속에 떠올리는 대상이 다르다 (서비스 중심인가 사용자 중심인가). 물론 디자인에 대한 디테일한 수준 역시 상이하다 (디테일한 설계로 들어가게 되면 첫 화면부터 달라져야 할 수도 있다).
무엇을 보여줄 것인가를 정하는 문제는 약간의 도움이 되는 방법론이 있긴 하지만 정말 답이 없다. 서비스 기획자가 기획서를 작성하는 팁이나 생각을 정리하는 방법들, 기획서의 큰 틀 등이 있기는 하지만 결국 그 내용을 채워넣는 일이 핵심인 것과 마찬가지이다. 무엇을 보여줄것인가를 정하기 위해서 가장 먼저 정의해야 하는 것은 해당 서비스에 대한 이해와 요구사항에 대한 분석이다. 일단 서비스에 대하여, 그 서비스의 본질에 대하여 정확하게 이해해야 한다. 본인이 이미 오랫동안 다루었던 내용이라면 조금은 수월할 수 있겠지만 그 본질에 대한 것까지 이해를 하고 있어야 한다. 그리고 요구사항을 이해해야 한다. 사용자 중심의 디자인이 목적이기는 하지만 디자인을 위해서는 사용자의 요구사항 뿐 아니라 비즈니스의 목적 및 사업 측면의 요구사항도 이해해야 하며, 우리가 구현할 수 있는 기술 구현 가능성 및 일정 안에 구현 가능한 수준에 대한 이해도 중요하다. 이러한 서비스의 본질과 요구사항을 이해한 후 사용자 측면에서 어떤 가치를 갖는가, 어떤 유용함을 사용자에게 제공할 수 있는가에 대한 방향을 세워야 한다. 이것이 UX 전략이다.
UX 전략을 수립한 후에는 범위를 정해야 한다. 서비스 기획자가 서비스 레벨의 큰 기능을 정의했겠지만, 사용자 레벨에서의 디테일한 기능을 정의해야 한다. 이 기능에 따라서 무엇을 보여줄 것인가가 결정된다. 이를 위하여 디자인에서는 페르소나(persona)라는 대표 사용자를 정의하고, 이 대표 사용자들이 어떤 작업을 하는가에 대한 태스크(task)를 분석한다. 이 태스크에 사용자와 작업에 대한 맥락 (주변 환경 및 상황 등을 포함하는, context)을 포함하여 기술하는 것이 시나리오이다. 크게 이러한 방법론을 이용하여 태스크를 나열하고 중요한 태스크와 제공하지 않을 태스크를 정리하게 된다. 마지막으로 걸러진 태스크는 세부적인 기능으로 변환되어 상세 기능 목록이 작성된다.
상세 기능 목록이 작성된다면 서비스의 (웹 또는 앱) 전체 구조를 그려야 한다. 사용자가 첫 화면에서 무엇을 확인하고 어떤 동작을 하도록 할 것인가, 각 기능을 어떻게 접근하고 어떤 과정으로 조작을 하여 태스크를 완성하도록 할 것인가에 대한 고민을 하게 되며 이것이 전체적인 구조를 잡는 과정이다. 구조라는 것은 메뉴 구조를 생각할 수도 있는데, 어느정도는 맞는 이야기일 수 있지만 단지 메뉴를 정하는 일 만으로 앱의 구조를 설명하기는 어렵다. 메뉴를 통하지 않고도 사용자는 작업을 수행할 수 있기 때문이다 (가장 중요한 태스크의 경우 메뉴를 거치지 않고 정말 빠르게 작업을 할 수도 있어야 하기 때문이다).
앱의 구조를 잡는 과정에서 각 태스크별로 사용자의 작업 과정을 고민하게 되며, 어떤 화면들을 거쳐야 하는지에 대한 결과가 그려진다. 이것이 화면 플로우(flow)이며, 궁극적으로 이때 도출된 화면별로 세부적인 그림을 그리는 것 (이쁘게 컬러를 사용하여 그리는 것이 아니라)이 상세 UI 디자인을 하는 과정이다. 상세 UI를 디자인하면서 구조를 바꿔야 할 수도 있고, 생각하지 못했던 기능을 추가해야 할 수도 있다. 어느 경우 태스크나 전략을 수정해야 할 수도 있는데 (앞에서 사용자 입장에서의 디테일한 사항까지 고민하지 못했을 경우) 가급적 이런 일은 벌어지지 않아야 할 것이다.
상세 UI 설계를 하기 위해서는 결국 각 화면에서 어떤 정보를 제공할 것이며, 어떤 조작(액션)을 하도록 할 것인가를 결정한 후 각 정보를 어떠한 형태로 제공할 것인가(정보 요소의 정의), 조작을 위한 컨트롤을 어떤 형태로 제공할 것인가(UI 컴포넌트의 정의), 이 정보와 컨트롤을 어느 위치에 제공할 것인가(화면 레이아웃의 정의)를 결정하는 과정이다. 물론 화면 내에서 조작하는 과정 역시 함께 고민해야 한다. 이 과정에서 고려해야 하는 것이 기본적인 디자인 원칙이며 (단순성, 직관성, 일관성 등), 이를 위하여 애플, 안드로이드 등에서 UI 디자인 가이드라인을 제공하고 있다. 기본적인 디자인 원칙을 알려줄 뿐 아니라 자세한 UI 컴포넌트의 사용 방법 등을 가이드하고 있으며, 이는 자신들의 서비스에 대한 전체적인 일관성을 유지하기 위하여 필요하기 때문이다.
와이어프레임 형태의 상세 설계를 완료한 후에는 그래픽 디자이너가 화면을 이쁘게 디자인한다(visual design). 이 과정에서 UI 디자이너는 개발자와 구현 가능성에 대한 자세한 협의를 진행하게 된다. 개발에서 구현할 수 없다면 (기술적이기 보다 기간 안에 구현할 수 있어야 하기 때문이다. 개발자들은 세상에 구현할 수 없는 기술은 없다고 이야기한다. 다만 시간이 오래 걸릴 뿐이라고…). 결국 UI 디자이너는 기술 수준과 개발 일정을 감안하여 디자인을 해야 한다는 의미이다. 개발팀과 협의 결과에 따라서 UI 디자인 결과는 지속적으로 수정된다. 뿐만 아니라 UI 디자이너는 본인의 디자인을 검증하고 문제점을 개선하는 노력을 기울이게 된다.
이것이 대략적인 디자인을 어떻게 하는가에 대한 대답이다. 친구에게 이야기를 하고 나서 바로 정리하느라 정말 보기 어려운 글이 되었다(UX관점에서 엉망인 ㅡㅡ). 이 글도 정리좀 해야겠다. 그리고 앞으로 각 과정에 대한 조금 더 자세한 이야기를 하도록 하자.
