그동안 IA를 그리는 게 어려웠던 이유

그동안 IA를 그리는 게 어려웠던 이유

Summary:

이 글을 읽기보다 아래 4개 아티클을 읽는 게 더 도움이 될지도 모르겠습니다.


IA..?

  1. 사이트의 전체 구조가 예쁘고 깔끔하게 그려지지 않았다.
  2. 화면들이 어떻게 연결된건지, 이 화면이 어느 화면에 포함되어 있는지의 관계가 뚜렷하게 나타나지 않았다.
  3. 알 것 같다가도 모르겠다. 원래 이렇게 하는건지 내가 부족한건지 구분이 되지 않았다.

지금까지 정보구조(IA, Information Architecture)를 그리면서 뭔가 잘못되었다는 생각이 가시지 않았던 3가지 이유다. 이런 생각을 한 데에는 몇몇 시행착오가 있었다.

(시행착오 1) 웹페이지 IA는 화면 단위면 안되나요? 사이트맵이랑 달라야 하나요?

몇 달 전 서비스 중인 웹페이지의 현황을 파악하기 위해 IA를 그리는 임무를 맡은 적이 있다. 그리고 보니 사이트맵과 거의 똑같았다. 그 때 받은 피드백은 화면 단위로 IA를 그리면 사이트맵과 똑같으니 기능 단위로 정보구조를 재설계해보라는 것이었다. 검색, 정보성 콘텐츠, 커뮤니티 게시판 등의 단위로 정보구조를 설계하는 것이 사이트 구조를 파악하기 용이하다고 했다.

근데 그 때의 나는 ‘화면 안에 기능이 들어있으니 둘이 결국 같은 말이 아닌가?’, ‘IA가 사이트맵이랑 꼭 달라야 하나?’ 하는 생각들을 했다. 피드백대로 IA를 다시 짜고 프로젝트를 계속했지만 보고서를 고치면서도 찜찜한 마음이 계속 남아있었다.

(시행착오 2) 계층 구분을 어떻게 하는 게 맞는거죠?

몇 달이 지나 네이버뮤직 IA를 짰는데 이 때도 찜찜했다. 각 요소 별 계층 구분이 모호하다는 생각에서였다. ‘메인홈’에 있는 한 플레이리스트와 ‘메인홈 - 카테고리 - MUSICNS - HOT - JAMM’에 있는 한 플레이리스트가 내용은 같은데 IA를 그리고 보면 계층이 다르게 나온다. ‘같은 콘텐츠라면 계층이 같아야 하는 것 아닌가?’ 하는 생각에 답답했다.

(시행착오 3) 제가 하고 있는게 도대체 뭘까요?

사실 이 때의 경험이 IA와의 첫번째 만남이었고 시행착오의 시작이었다. 작년 이맘때 쯤 프로젝트 관리학 전공수업에서 IA라는 용어를 처음 접했다. 그 때 IA를 그려오라는 과제에서 C를 받았던 게 IA와의 악연의 계기였던 것 같다. 정말 열심히 공부하고 찾아보고 며칠에 걸쳐 고민한 뒤 제출한 과제였기에 더 속상했다.

Depth의 기준, 정보라는 것의 정체(화면? 기능? 콘텐츠?), IA와 플로우차트의 차이(‘기능의 수행=행동’이니까 IA와 플로우차트는 화살표가 있고 없고의 차이일까? 아닌데? IA 예시에도 화살표가 있던데?) 등의 모호함, 책마다 다른 정의와 활용예시로 인해 머릿속은 온통 뒤죽박죽이었다.


이번에도 대충 이해하고 넘어가면 앞으로 IA에 대해 계속 애매하고 찜찜한 기분이 남아있을 것 같았다. 문득 이번만큼은 그러려니 하지 말고 제대로 알고 넘어가고 싶은 마음이 들어 공부를 더 해봤다.


결론부터!

“모든 IA가 계층구조를 갖는 건 아니다.”

내가 자꾸 헷갈리고 답답했던 건 ‘IA=계층구조’라는 전제를 모든 웹/앱 서비스에 적용하려 했기 때문이다. 계층별로, 단계별로 정보들이 착착 정리되어야 한다고 생각했다.

이제와서 되돌아보면, 과거에 제작된 웹들은 계층구조를 따르는 게 대부분이었지만 최근 웹이나 모바일앱들은 깔끔하고 보기좋게 정리되지 않기 때문에 IA를 그리는 게 어려웠던 것 같다. 계층구조는 IA의 패턴 중 하나일 뿐인데, 또 IA도 서비스를 설계하기 위한 보조도구일 뿐인데, 방법론에만 너무 매달렸다.

Elaine McVicar는 UX BOOTH 기고문에서 “과거의 해결책이 항상 모든 서비스에 적용되는 건 아니다”고 했다. 그렇다. 결론부터 들으면 당연히 끄덕거릴 얘기다. 근데 난 또 놓치고 있었다.

It’s extremely important that we, as designers, follow a user-centered design process to arrive at our solutions. The only problem is that our traditional best practices may not always apply.


모바일에서의 정보 전달 방법과 IA

전통적인 웹사이트와 다르게 모바일앱은 반응형 사이트, 네이티브 앱, 하이브리드 앱 등정보 전달 방식이 다르다. 이 방식에 따라 정보구조 또한 다르게 설계될 수 있다. 예컨대 반응형 사이트는 IA 표준(계층형)을 잘 따르지만 네이티브 앱은 네비게이션형 구조에 더 적합하다.

모바일 웹/앱을 설계하기에 최고의 방법은 없다. 각 특성에 따라 그에 맞는 정보구조 패턴을 적용시키면 된다.

1. Hierarchy Pattern

pic1

By Dennis Kardys


계층형 패턴은 IA의 표준이라 할 수 있다. 인덱스 페이지와 여러 개의 서브페이지로 구성된다. 데스크톱 웹사이트 구조를 따라 모바일앱 구조를 설계한다면 계층형 IA를 택하는 것이 적합하다. 하지만 여러 화면이 있는 네비게이션 위주의 서비스에 계층형을 적용하면 작은 화면에서 정보를 찾아가기에 힘들 수 있다.

2. Hub-and-spoke (or Daisy) Pattern

pic2

By Dennis Kardys


중심부에 인덱스 페이지를 두고 사용자가 각 요소를 선택하여 다른 화면으로 빠져나갈 수 있도록 설계하는 허브앤스포크 방식이다. 아이폰의 기본 패턴으로 잘 알려져 있다. 중심 화면(Hub) 없이 다른 화면(Spoke) 사이를 오갈 수 없다(=멀티태스킹 불가)는 단점이 있지만 동시에 사용자가 지금의 TASK에 집중할 수 있도록 돕기 때문에 결제 과정 등 모바일앱에서 자주 사용되고 있다.

3. Nested doll Pattern

pic3

By Dennis Kardys


Nested doll 패턴은 사용자가 일직선상에서 세부 콘텐츠로 접근하도록 유도한다. 사용자가 서비스를 잘 모를 때 길 안내를 해주기에 좋다. 사용자가 현재 어떤 화면에 접근해있는지, 전후화면이 무엇일지를 인지시키는 데 최적의 방법이다.

주로 Hierarchy나 Hub-and-spoke의 하위 페이지로 사용되지만 사용자가 섹션 사이를 오갈 때 빙 돌아가야하기 때문에 콘텐츠를 탐험하는데 오히려 장애물이 될 수 있다.

4. Tabbed view Pattern

pic4

By Dennis Kardys


pic4

by Elaine McVicar


대부분 모바일앱이 따르는 패턴이다. 섹션들이 툴바 메뉴로 묶여 있어서 사용자가 앱을 켠 뒤 빠르게 서비스를 스캔하는 데 도움을 준다. 단, 복잡한 서비스에는 적합하지 않다. 간단한 콘텐츠 구조에 최적인 IA이다.

그 외 패턴들

Information architecture patterns from Donna Spencer

잊지 말자

이렇게나 IA의 형태가 많다. 계층을 나누는 것에만 매몰되어서는 안 되는 거였다. 본질은 뎁스(Depth)를 구분하자는 게 아니다. 정보의 위계질서를 잡기 위해 IA를 그리는 게 아니고, 서비스의 특성에 따라 정보를 잘 정리하여 고객에게 보여주기 위한 방법론 중의 하나가 IA일 뿐이다. 따라서 IA가 꼭 특정 형태일 필요는 없다.

현재 서비스의 IA를 분석하는 이유도 사용자가 실제로 콘텐츠를 어떻게 사용하는지 이해하고, 이를 원활하게 하기 위해 앱 구조가 어떻게 기능해야 더욱 논리적이고 전달력이 좋을 수 있을지 알아내기 위함이다.

방법론에 얽매이지 말고 목적을 기억하자. 우리는 IA의 기본 설계 원칙을 이해함으로써 서비스를 쉽게 접근할 수 있고 사용될 수 있도록 만들 수 있다.


Hyeyeon

A Blog about E-Commerce and Product Management

comments powered by Disqus

    rss facebook twitter github youtube mail spotify instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora