서비스 설계의 기초인 정보 구조도(Information Architecture) 에 대해서 알아보겠습니다.
I.A.의 기초 이론과 역할 그리고 구조도 작성법에 대해 알아보도록 하겠습니다.

I.A(정보 구조도)란?

I.A.는 간단하게 말해서 서비스의 목차 역할을 수행합니다. 

웹 혹은 어플리케이션이 어떻게 구성되는지 보여주며 어떤 기능의 화면으로 보여지는지를 전체적으로 보여주는 여기 아주 귀여운 강아지 모형이 있습니다!

이 귀여운 강아지 모형은 어떻게 구성되있을까요?

 

강아지 모형을 보면,

귀여운 머리와 둥글한 몸통으로 구성되어있습니다. 

 

조금 더 자세히 들여다 볼까요?

머리를 보면, 머리에는 눈과 코, 입 그리고 귀로 구성되어 있습니다.

몸통도 그 안을 드려다 보면 발과 팔 그리고 꼬리로 구성되어 있죠!?

 

 

여기서 조금 더 자세히 들여다 보면

눈에는 왼쪽. 오른쪽 눈이, 코에는 왼쪽, 오른쪽 코가 아니라 코는 하나죠?

이처럼 더 자세히 들여다 보면 또 다른 구성요소가 존재합니다.

 

 

 

강아지의 모형을 보고 어떠한 구조로 되어있고 

그 구조 안에 어떠한 구성요소로 만들어져 있는지 알 수 있듯

우리 서비스가 어떠한 구조로 되어있고 어떤 기능이 있으며 어떤 역할을 수행하는지

서비스에 대한 전체적인 구조를 짤 수 있는 것이 바로 I.A.입니다.

 

그렇다면 I.A.는 어떻게 작성 되어야 할까요?

 

 

I.A설계 시 기획자는 User(사용자), Contents(컨텐츠) 및 Scenario(시나리오) 3가지를 고려하여 작성합니다.

 

우선 User(사용자)에서는 크게 3가지를 고려합니다.

 

1. 사용자가 기존에 어떠한 경험을 가지고 있는가

2. 우리 서비스에 왜 방문하고 어떤것을 얻고자 하는가

3. 사용자는 이용 중에 어떠한 패턴을 보이는지

 

우선 첫번째, 기존에 사용자의 경험을 우리 서비스에 담아야 합니다. 

사용자가 우리 서비스에 들어왔다고 가정해봅시다. 그러나 우리가 구조를 설계할 때 기존 사용자가 가지고 있지 않던

새로운 구조를 가진 사이트를 기획했습니다. 완전히 새로운 배치로 새로운 구성 요소들을 배치 하였을때 사용자는 어떻게 느낄까요?

사이트가 어렵고 복잡하게 느껴질 것 입니다. 일반적인 사이트의 구조가 아닌 새로운 구조에 적응이 어렵기 때문입니다. 

따라서 우리는 기존 사용자의 경험을 분석하여 설계 해야합니다. 

또한 우리 서비스에 들어온 목적과 패턴을 분석함으로써 구성 배치를 사용자의 편의를 고려하여 설계합니다.

 

Contents(컨텐츠)에서는 두가지

 

1. 컨텐츠의 중요도가 공급자 중심인가 사용자 중심인가

2 사용자가 인지하고 있는 네이밍인가

 

우리가 구조를 짜고 컨텐츠를 구성할 때 중요한 요소가 공급자 중심인가 사용자 중심인지를 결정해야합니다.

이게 어떤 말인지 예시를 통해 알아볼까요?

 

만약 우리가 음악을 들을 수 있는 어플리케이션을 만든다면

월 구독을 통해 수익을 벌어들일겁니다. 즉 구독 서비스가 우리의 수익모델입니다.

그러면 우리는 더 많은 사용자들이 구독을 할 수 있도록 구독에 대한 알림 혹은 배너를 노출시킬 것입니다.

그러나 이러한 배너 노출은 사용자 관점에서 좋은 UX를 제공하지 못합니다. 

구독을 장려하는 배너 대신에 우리가 다른 컨텐츠 혹은 정보를 제공해준다면 사용자에게 더 좋은 가치를 제공할 것입니다.

이처럼 우리는 구조를 짤 때 우리 공급자 중심인지 혹은 사용자 중심인지를 결정해야 합니다.

또한 이 전에 설명한 것 처럼 기존 경험을 토대로 구성해야 하기 때문에 익숙한 네이밍을 사용해야합니다.

 

마지막으로 정보의 시나리오가 어떻게 전달되어야 하는지를 고려함으로써 정보 구조도를 설계합니다,

 

 

I.A.의 종류

웹 사이트 / 모바일에 따라 I.A의 기본적인 구조가 달라집니다. 

이것을 구분하기 전 I.A의 보여지는 모양에 따라 크게 2가지로 나누어집니다.

 

 

트리 구조의 I.A.

 

마인드맵이나 트리 구조 를 이용하여 고객의 동선 별 화면 구조를 정의합니다.

사실 I.A의 산출물은 대부분 엑셀 형식으로 자세히 작성하는데, 이를 작성하기 전에

조금 더 간편하고 직관적으로 구조를 작성할 수 있다는 장점이 있습니다. 이 때 우리는 한 화면 내 통합할 수 있는 기능들을 통합시키면서 구조의 깊이(depth)를 최소화 합니다.

 

 

엑셀 형식의 I.A

들어가기에 앞서 한가지 알아야할 점이 있습니다.

 

"

정보 구조도에는 정답이 없습니다.

"

 

정보 구조도의 형식과 틀은 상황에 따라 유동적으로 변하기 때문에 I.A가 무엇인지 그리고 어떠한 역할을 하는지 이해하고

상황에 맞게 짜는 것이 중요합니다.

다시 들어가 볼까요?

 

설계서 상단을 보면 도메인, 개발언어, 호스팅, 개발 기한이 적혀져 있습니다.

도메인에는 우리 웹 사이트의 주소를 작성, 어떠한 언어로 개발되며 호스팅 및 보안 서버는 어떠한 것을 이용하는지.

개발 기한이 언제인지 작성합니다. 사실 이 부분에서 간단히 프로젝트 담당자 및 프로젝트 기한, 프로젝트 명을 작성하는 경우도 있으니 참고해주세요.

 

메인으로 들어가보겠습니다. 항목별로 순서대로 좌측부터 접근하면, 

Depth(깊이), Tab/서브 플로우, Code, 페이지 정의/요구사항, 세부 사항, Page, 개발 구분, 논의 사항으로 구성됩니다.

 

우선 Depth는 서비스의 전체적인 틀과 깊이를 작성합니다, 

이 문서에서는 페이지가 최대 3개의 Depth로 구성되며

1Depth에서는 회사소개, 사업분야, 포트폴리오, 고객지원, 마이페이지, 회원가입으로 구성되어있습니다 

 

회사 소개 안에는 또 다른 Depth가 존재하며 소개, 인사말, 현역소개, 오시는 길으로 구성됩니다.

따라서 Depth에서는 문서의 깊이 별로 어떠한 구성 요소가 존재하며 Depth별로의 컨텐츠의 네이밍을 포함합니다.

 

다음은 Code입니다. 페이지명 또는 화면 코드를 작성하며 이는 규칙으로 정의, (예시 : Order001B)

화면에 대한 네이밍을 토대로 번호를 구성하여 작성합니다. 이 문서에서는 화면에 네이밍 없이 단순히 1.1, 1.2, 2.1 등으로 구성하였습니다.

 

페이지 정의/요구사항에서는 화면에 대한 설명을 작성하며 

Page에서는 그 페이지의 개수를 표현합니다. 게시판 형태라면, 몇 페이지 까지 페이지를 구성하는지 표시하는 것 처럼 이곳에서 이를 작성합니다. 그리고 개발 구분을 통해 전체적인 진척도 파악 및 개발 현황을 보여줍니다.

각 화면 요소에 대해 얼마큼 개발이 완료되는지 전체적인 프로젝트 일정 관리를 I.A를 통해서 할 수 있습니다. 

논의 사항에서는 항목 별로 상의 되어야 할 정보를 작성합니다.

 

지금까지 하나의 I.A의 예시를 바탕으로 전체적인 흐름을 설명하였습니다.

그러나 사실 이러한 엑셀 형식의 I.A는 모바일에서는 작성하기에 어려움이 있습니다.

 

그렇다면 모바일 서비스는 I.A를 어떻게 작성해야 할까요?

 

 

모바일을 위한 Information Architecture

 

모바일에서는 다음과 같이 서비스의 흐름 및 네비게이션 바(없으면 생략)를 포함하여 구조를 작성합니다.

앞서 설명 드린 트리 구조와 동일합니다.

 

처음부터 볼까요?

우선 어플리케이션을 처음 시작할때 보여지는 스플래쉬 화면에서 튜토리얼을 거쳐 로그인/회원가입 페이지로 넘어갑니다.

여기서 인증을 거치면 프로모션 팝업이 나타나며 홈 화면으로 넘어갑니다. 

화살표(->)를 통해 흐름을 나타내는 것을 알 수 있습니다. 

홈 화면으로 넘어가면 네비게이션 바가 보입니다. 

 

여기서 네비게이션 바는 사용자가 원하는 정보를 빠르고 정확하게 검색하고, 정보와 정보 사이의 이동을 원활 하게 돕기 위해 제공하는 것으로 검색기능, 사용자위치정보, 리스트메뉴, 탭메뉴, 토글 메뉴, 사이트맵 등의 체계를 말합니다.

 

다시 I.A.로 넘어가볼까요?

노란색 박스로 표시된 영역은 네이게이션 바의 구성 요소를 설명합니다. 

그 박스 밑에 적힌 영억은 그 화면에서 들어가는 정보들을 표시합니다.

홈 메인 화면 안에는 알림, 사용내역, 보내기, 입출금 등의 내용이 표시됩니다.

 

이 화면이 단순히 구조와 네이밍을 적고 간단한 기능을 적었다면

앱 상세 구조도를 통해 각 구성요소에 대한 자세한 설명이 포함됩니다.

 

 

전 그림에서 그린 I.A.보다 더 세부적인 내용을 포함합니다.

보내기 기능 안에서도 보안 비밀번호 등록, 이체 정보 등이 있다는 것을 자세하게 설명합니다.

 

단순히 앱 메뉴와 흐름을 설명하는 것과 비교해 더욱 자세한 내용을 포함하고 있는 것이 바로 앱 상세 메뉴 구조도입니다.

보다 상세한 내용과 서비스의 전체적인 흐름을 설명할 수 있습니다.

 

"

결국 I.A.는 개발자와 디자이너를 위한 도구이다.
"

 

I.A.를 통해 우리 서비스의 전체적인 구조를 파악할 수 있다고 말했습니다, 

디자이너는 이를 통해 우리 서비스가 어떤 구조를 가지고 있으며 각각의 뷰가 담는 정보들을 바탕으로 와이어프레임이라는 청사진을 작성하게 됩니다. 사실 와이어프레임은 기획자가 작성하는 경우가 대부분인데

디자이너보다 UX적으로 약하기 때문에 디자이너가 뷰를 보고 재수정하는 작업을 거치게됩니다.

재수정 작업에서 구조도가 없다면 정해진 틀에서 일부 배치만 수정하겠지만, 구조도를 기반으로 작성을 한다면

보다 사용자 친화적인 서비스 설계에 용이하며 새로운 틀의 서비스를 만들 수 있습니다. 

개발자 역시 I.A를 통해 서비스의 전체적인 틀을 잡으며 안에 구성된 정보들을 바탕으로 개발에 착수합니다. 

 

결국 기획자는 정확한 I.A.를 기반으로 디자이너 및 개발자와 소통해야 하며 원할한 개발 환경 조성을 할 수 있습니다. 

(스토리보드라는 설계의 최종 산출물이 있는데 이는 추후 포스팅에서 자세히 다루어보도록 해요:) )

 

 

이번 포스팅을 통해 서비스 설계의 첫 단추인 I.A.에 대하여 알아보았습니다. 

처음 접해보셨다면 당연히 어려우셨을 것이며 알고 계신 분들은 한가지 의문이 들 수 있습니다. 

나는 저렇게 안짰는데? 당연합니다.

아까 설명드렸듯이 I.A에는 정답이 없습니다. 우리 서비스 그리고 팀 환경과 역량의 설계서를 작성해야 합니다.