Peter Morville & Louis Rosenfeld의 Information Architecture for the World Wide Web 세미나를 위해 정리한 것입니다. 진한 글씨는 참가자들이 토론한 것을 일부 기록한 것입니다.

내비게이션을 다룰 때에는 언제나 여러 분야를 넘나들기 마련이다. 단지 내비게이션은 좋은 정보 구조에서 나온다는 식으로 다른 분야와 선을 그을 수가 없다. 정보 설계자는 디자인도 하고, 역으로 디자이너가 정보를 설계하기도 한다.

내비게이션에서 가장 중요한 것은 바로 맥락이다. 지도에 현재 위치가 없으면 곤란하다. 주변에 눈에 띄는 지형지물이나 가게를 중심으로 현재 위치를 먼저 찾아야 한다. “현재 위치”가 없으면 길을 잃었다는 느낌을 준다. 그런데 웹에서는 맥락을 제시하는 것이 더 중요하다. 오프라인에서는 현재 위치를 짐작케 하는 증거를 쉽게 찾을 수 있지만 온라인은 그렇지 않다. 눈에 띄는 지형지물도 없고, 북쪽이나 남쪽같은 방향도 없다. 하이퍼링크를 타고 다른 웹사이트의 한 가운데로 곧장 이동할 수도 있다. 첫화면을 완전히 제끼고 그럴 수 있다. 게다가 사람들은 종종 웹페이지를 읽거나 공유하려고 인쇄하곤 하는데, 그러는 과정에서 현 위치에 대한 정보가 더 유실된다. 좋은 내비게이션은 페이지 한 가운데에 뛰어들어도 자기가 어디 있는지 잘 보여준다.

브라우저 내비게이션 기능

내비게이션을 설계할 때에는 그 체계가 어떤 환경에 존재할지도 염두에 둬야 한다. 웹에서는 웹브라우저를 쓴다. 브라우저에는 여러가지 기능들이 내장돼 있다.

이런 기능들을 위해 엄청난 연구와 분석, 실험이 있었다. 그러나 놀랍게도 이런 기능을 썩히거나 무지하게 덮어쓰는 일이 많다. 가장 흔한 범죄는

방문한 링크와 그렇지 않은 링크 색을 구분하지 않기(:visited)
뒤로 가기 버튼을 못쓰게 하기(e.g. 프레임 사용으로 인해)
북마크 기능을 못쓰게 하기(e.g. 프레임 사용으로 인해)

적당한 유연성

위계 구조는 익숙하고 굉장히 유용하지만 내비게이션으로 쓰기에는 너무 갑갑하다. 월드와이드웹의 선구였던 고퍼(Gopher)를 써본 적이 있다면 이 느낌을 잘 알 것이다. 고퍼에서는 상위 카테고리나 하위 카테고리로만 이동할 수 있었다. 심지어 이웃한 카테고리로 건너 뛰거나 여러 단계로 거슬러 올라가는 것도 불가능했다.

하이퍼텍스트는 이런 한계를 걷어내고 내비게이션에 엄청난 자유도를 선사했다. 하이퍼텍스트는 수평적 내비게이션과 수직적 내비게이션을 모두 지원한다.

그러나 이런 구조는 혼란스러움을 주기가 쉽다. 지나치게 유연해서는 안된다(그런데 지나치게 유연한 사례가 무엇인지는 이 책에서 아직 보지 못했다). 거대한 사이트에서 경직된 내비게이션을 제시하면 안되겠지만, 그렇다고 너무 많은 내비게이션 수단을 제공하면 위계를 흐리고 사용자를 압도할 수도 있다.

전역 내비게이션

모든 페이지에 나오는 내비게이션
사이트 어느 곳에서든 핵심 페이지나 기능에 바로 접근하게 함
모든 페이지에 나타나므로 사용성에 미치는 영향이 크다.
현재 위치를 표현하지 않으면, 맥락을 표현해야하는 부담이 지역 내비게이션으로 이전되고 이것은 비일관성으로 이어곤 한다.
메인 페이지에서는 무엇이 전역 내비게이션인지 식별하기가 어려운 경우가 많다. 어떤 경우에는 메인 페이지에서 사이트의 구조를 드러내려고 전역 내비게이션처럼 생긴 것을 둔다. (그런데 이 책에서는 이것이 좋다 안좋다 말이 없다. 어떻게 봐야 할까? 전역 내비게이션에 있는 것을 혹은 거기에 있을 만한 것을 메인 페이지에서 중복해서 표현하는 것은 좋지 않다)

지역 내비게이션

전역 내비게이션을 보조해서 인접한 페이지를 탐색하게 해줌
전역 내비게이션과 통합된 경우도 있다. e.g. 전역 내비게이션에서 같은 영역에 속한 서브 페이지 목록을 같이 보여줌.

지역 내비게이션 체계가 완전히 다른 사이트의 영역 서브사이트라고 한다. 서브사이트가 존재하게 되는 이유 두가지

사이트 나머지 부분과는 다른 내비게이션 체계가 필요해서
거대 조직의 탈중앙적 성격, 별도 조직

나쁜 사례들은 조직내 다른 팀들이 따로 놀아서 생기곤 한다. 얼마나 통일성을 강제할 것인지는 쟁점이다.

서브사이트가 필요할 때는 언제인가? 그냥 성격이 다르면 별도로 사이트를 만들지 않나? 삼성 전자 사이트와 삼성 그룹 사이트가 따로 있는 것처럼. 내비게이션의 발전(메가 드롭 다운 메뉴 등) 때문에 지금도 지역 내비게이션이 의미가 있을지는 의문이 든다.

맥락적 내비게이션

특정 페이지나 문서 등에 한정된 내비게이션. e.g. “See Also” 링크
기존에 알지 못했던 콘텐트의 연관을 새로 알게 해준다.
보통은 저자나 편집자, 주제 전문가가 링크를 정한다. 그러다보면 본문에 줄글 링크가 생기곤 한데, 중요한 링크는 이렇게 처리하면 안된다. 사용자들이 놓친다. 정말로 중요한 링크는 그에 맞는 시각적 컨벤션을 적용해야 한다.
역시 여기에도 항목이 너무 많으면 역효과가 난다.

맥락적 내비게이션을 설계할 때에는 각 페이지가 독자적인 메인 페이지 혹은 포털, 인터페이스라고 생각해보자. 그러나 검색 엔진 등으로 메인 페이지를 건너뛰고 올 경우에도 다음 스텝을 규정하는 데에서 중요한 역할을 하는 것은 전역 내비게이션이 아닐까?

내장형 내비게이션의 구현

유연성을 적당히 추구해야 한다. 위에서 언급했지만 ‘지나친 유연성’의 사례가 제시되 있지는 않아서 잘 이해는 안된다. 어쨋든 책에서 나오는 설명은 사용자에게 너무 많은 선택지를, 특히 위계 구조에서 벗어나는 선택지를 너무 많이 제시해서는 안된다는 것이다.
전역, 지역, 맥락적 내비게이션을 구분할 줄 알아야 한다.
셋은 함께 설계해야 한다. 따로 설계하다보면 지나치게 많은 영역을 차지하게 되고 콘텐트를 압도할 수도 있다.

무엇이 좋을까?

텍스트 vs 그래픽
- 그래픽이 보기엔 좋다.
- 그래픽은 속도를 저하시키고 디자인과 유지 보수 비용이 더 크다
- 그래픽으로 할 경우 접근성을 고려해야 한다.
텍스트 vs 아이콘
- 텍스트가 더 분명하고 만들기도 쉽다.
- 아이콘은 텍스트를 보충하는 용도로는 좋다. 나중에 사용자들이 익숙해지면 글자를 읽을 필요가 없어져서 항목을 빨리 찾는데 도움이 된다. 그러나 제이콥 닐슨에 따르면 사용자들은 그림이 아니라 위치로 기억한다.
DHTML? 롤오버 메뉴?: 만들거면 잘 만들어라.
프레임: 안좋다.
- 웹은 고유한 URL을 가진 페이지를 기본으로 한다.
- 유용한 웹브라우저 기능을 마비시킨다: 방문 페이지 구분, 북마크, 뒤로가기, 새로고침, 인쇄 등 …

보조적 내비게이션

(검색도 여기에 포함되지만 따로 다룬다)

분류법만 좋으면 모든 수요가 충족된다? 사용성 전문가들의 판타지: 사이트맵, 색인, 가이드, 검색은 분류법이 먹히지 않을 때에만 사용된다. 현실: 내장 내비게이션이 언제나 상당수 사용자들에게 잘 작동하지 않는다.

위계적 구성의 비중이 큰 사이트에서 자연스럽게 쓰이는 내비게이션. 작은 사이트에선 사이트 맵보다 색인이 더 좋다. 작은 사이트에도 불필요한 것 아닌가?
작은 사이트에선 불필요하다.
디자인이 사용성을 좌우한다. 디자이너는 다음 규칙을 지켜야 한다.
1. 위계를 강조한다. 정보 구조에 빠르게 익숙해지도록
2. 자신이 원하는 바를 아는 사용자들이 금방 콘텐트를 찾을 수 있어야 한다.
3. 너무 많은 정보를 제시하지 않는다.

사이트 색인

사이트 맵보다 평면적. 기껏해야 2-3단계 깊이.
자기가 찾고자 하는 항목의 이름을 아는 사람에게 유용.
큰 사이트는 사이트 맵과 사이트 색인, 검색 기능이 모두 있어야 한다.
위계를 제끼고 아는 것 찾기(known-item-finding)를 돕는다.
색인 단위의 크기를 고민해야한다: 색인 대상은 페이지? 문단? 개념? 페이지 묶음? 사용자가 찾으려는 용어 무엇인지를 기준으로 판단해야 한다. 특히 논문처럼 긴 글이 실리는 사이트에서 문제가 된다. 검색 엔진을 적용할 때에도 마찬가지
만드는 법
- 수동(작은 사이트)
- 제어 어휘(분산 콘텐트 관리를 하는 거대 사이트).
순열치환(term rotation): 사용자가 취할 어휘를 고려하여 어순을 바꾼 항목도 추가하기. e.g. “refund, IRS”와 “IRS refund”. 이 방법을 모든 용어에 적용하면 안된다.
이 책에서 제시된 사례는 종이 책에 나오는 색인과 비슷한 것을 웹사이트에서 구현한 것인데, 우리가 웹상에서 실제로 그런 페이지를 접하거나 사용한 적은 없다. 아마 제한적인 분야에서만 그런 색인이 실제로 쓰이지 않을까 싶은데, 종이 책 색인으로 상상력을 제한하지 않는다면 카테고리별 목록 페이지 같은 것도 “색인”이라는 범주에 든다고 볼 수도 있겠다.
개인 블로그 같은 데 있는 태그 목록 페이지가 이 책에 제시된 사례에 가장 근접한 것일텐데, 경험적으로 태그 목록 페이지가 쓸모 있었던 적은 없었다. 물론 이것은 태깅을 제대로 관리하지 않아서 생긴 문제이긴 하겠지만 말이다

안내

새 방문자에게 콘텐트와 기능을 소개하는 데에 유용하다. 즉 쓰는 사람은 거의 없을 것이고 한 번 이상 쓸 일도 거의 없을 것이다. 일상적 웹사이트 이용에 있어서 비중이 크지 않다.
보통은 선형적으로 안내를 보게 되지만 하이퍼텍스트를 추가해서 유연성을 키울 수도 있다.
디자인 시 가이드라인
- 짧아야 한다.
- 언제 어디서든 빠져나올 수 있어야 한다. **어떤 전자상거래 앱에서 사용법 안내를 중간에 끄지 못하게 한 경우가 있었음

** * 안내 내비게이션의 위치가 일정해야 한다. * 물음에 답하는 안내여야 한다. * 스크린샷은 또렷한 이미지여야 하고, 중요한 것은 확대해서 보여준다. * 페이지가 많으면 독자적 목차가 있어야 한다.

고급 내비게이션

기본적인 내비게이션을 반드시 마스터하고 써야하는 위험한 요소들. 사실상 사용을 삼가야 하는 것들

개인화와 커스터마이징

개인화: 사용자가 원하는 바를 추측
커스터마이징: 사용자가 원하는 바대로 구성

소프트웨어 업체들과 컨설턴트의 약팔이 때문에 그 효과가 과정된 면이 있다. 현실에서 개인화와 커스터마이징은

중요하지만 제한된 구실만 한다.
탄탄한 구조를 바탕으로 해야 한다.
제대로 하기 정말로 어렵다

마케팅 계에서는 Don Peppers와 Martha Rogers의 ‘The One to One Future’라는 책 때문에 개인화와 커스터마이징이 각광을 받았다.

아마존은 개인화에 성공한 사례로 가장 자주 언급된다. 실제로 아마존은 매우 가치있는 일을 했다. 이름과 주소, 크레딧 카드를 기억해주는 것은 좋다. 그러나 주문 내역을 바탕으로 책을 추천하면서 환상을 깬다. 예를 들어 아마존에서 주문하지는 않았다는 이유로 이미 가지고 있는 책을 추천할 수 있다. 사용자들은 시스템에게 그런 사실을 알려줄 시간이 없거나 사생활을 보여주기 싫어한다. 이것은 예외적 상황이 아니라 일반적 상황이다. 사용자가 내일 무엇을 배우거나 구매하기를 예측하는 것은 매우 어려운 일이다. 따라서 개인화는 매우 제한적인 조건에서만 성공할 수 있다.

커스터마이징도 비슷한 기대를 주고 비슷한 위험성이 있다. 디자인 문제를 사용자에게 위임한다라. 얼마나 그럴듯한가. 그러나 현실에서 사람들은 그런 데에 시간을 쓰려하지 않는다. 인트라넷은 공개 웹사이트보다는 사정이 나을 수도 있다. 자기 업무와 관련된 것이면 시간을 투자할테니

그러나 사용자들 자신도 자신이 내일 무엇을 알고 무엇을 할 지 언제나 알지 못한다. 커스터마이징은 좋아하는 야구팀 점수를 추적하거나, 자기가 소유한 주식의 가치를 추적할 때에는 도움이 되지만 더 광범위한 뉴스나 연구와 관련된 수요에는 결코 부합하지 않는다.

시각화

웹이 등장한 이래로 웹사이트 탐색 경로를 더 시각적으로 현란하게 표현하는 도구를 만드려는 시도가 계속 있어왔다. 처음에는 은유를 기반으로한 시도가 있었고(박물관, 도서관, 쇼핑몰 등) 그 다음에는 페이지와 웹사이트의 관계를 보여주는 동적인 사이트맵이 등장했다. 폼도 나고 상상력도 자극한다. 그러나 어느 것도 쓸모 있는 것으로 입증되지 않았다. 흥미로운 시도는 많지만 아직 우리는 냉소적이다.

가장 간단한 사례는 “인기 기사” 목록. 이것은 아마 점점 널리 사용되지 싶다. **<노동자 연대=""> 사이트에서는 쓸 일이 없을 것 같다. 기사의 중요도가 기사의 인기와 언제나 일치하는 것은 아니기 때문에 사용자들에게 그릇된 인상을 줄 수도 있다.

검색

검색이 필요한가?

정보 탐색을 지원하는 다른 수단도 많다. 검색 엔진 만으로 모든 정보 수요를 충족시키려 해서는 안된다. 다음과 같이 자문해본다.

컨텐츠가 충분히 많은가?: 표준화된 수치는 없다. 평균 사용자의 정보 수요 유형이 더 중요하다. e.g. 특정한 정보를 염두에 두고 사람들이 방문하는 기술 지원 사이트는 온라인 뱅킹 사이트보다 검색 엔진이 필요할 가능성이 높다. 비용 대비 사용자들의 수혜도 고려해야 한다.
더 유용한 것에 집중해야 하지 않을까?: 덜떨어진 내비게이션과 정보 구조를 검색으로 때우려는 건 아닌지. 그런 경우라면 먼저 그것들을 고치고 검색 엔진을 달아라. 이런 체계가 잘 잡혀 있어야 검색도 더 잘된다. 이것이 조직내 알력 다툼으로 엉망이 된 경우에는 차선책으로 검색을 택할 수도 있다.
검색 시스템에 투자할 시간이 있는가? 최적화하는 요령을 터득했는가? 검색 엔진을 설치하고 기본 설정으로 그대로 둔 채 잊어버리는 개발자들이 많다. 검색 엔진을 제대로 세팅하기 위해 상당한 시간을 들여야 한다는 것을 몰랐다면 결정을 재검토해보시라.
다른 대안이 있는가? 가령 사이트 인덱스도 많은 것을 할 수도 있다. 수동으로 관리할 경우 HTML만 알면 누구나 관리할 수도 있다.
사용자들이 검색을 하려 들까?

웹사이트란 언제나 구현을 할 때만큼 세부적인 계획이 사전에 나오지 않는다. 웹사이트는 마치 유기체처럼 성장한다. 콘텐트와 기능이 우후죽순으로 늘어나면서 악몽이 시작된다. 검색 엔진의 필요성을 보여주는 징후는 다음과 같은 것들이 있다.

정보가 너무 많을 때: 야후의 사례. 태초에는 모든 것이 찾기 쉬웠다. 웹은 작았으니까. 야후는 주제를 위계로 구분해서 수백개 정도의 사이트들을 연결해줬다. 시간이 흐르고 야후는 회원들이 자기 사이트를 스스로 등록할 수 있게 했다. 그러자 매일매일 기하급수적으로 늘어나는 사이트의 양을 감당할 수 없게 됐고 결국 야후 메인 페이지에는 주제별 인덱스가 사라져 버렸다. 이처럼 콘텐트의 양이 일람 체계의 수용량을 넘어섰을 때, 엄청나게 긴 카테고리 페이지가 생겼을 때 검색 엔진이 필요하다.
부서별 사이트가 지나치게 파편화 됐을 때. 검색이 모든 문제를 해결해주지는 않지만 우선순위를 높여서 검색 엔진을 달아야 한다. 당신이 정보 구조를 파악하는 데에도 도움이 될 것이다.
사용자가 당연히 검색을 기대할 때.
역동성을 길들여야 할 때. 예를 들어 신문 사이트.

검색 엔진은 개발자의 전유물이 아니다

서버를 세팅하고 구동하는 것은 개발자가 해야 한다. 그런데 검색 엔진을 써서 사용자들이 어떤 득을 보냐는 별개 분야다. 사용자들이 어떤 득을 보는지, 메타데이터가 검색에 어떻게 도움이 되는지, 검색 인터페이스를 어떻게 개선할지, 어떻게 일람과 통합할지 IA는 개발자보다 더 잘 알아야 한다.

검색 엔진은 복잡한 기술이고 개발자는 그 중의 일부를 맡을 뿐이다. IA는 기꺼이 개발자와 동등한 책임을 자임해서, 어떤 개발자가 선호하는 언어로 쓰이고, 그가 선호하는 플랫폼에서 돌아가는 검색엔진이 아니라 사용자에게 득이 되는 검색 엔진을 선택해야 한다고 주장해야 한다.

무엇을 검색할 것인가?

검색 구역

나머지 콘텐트와 분리해서 색인하는 사이트의 일부분. e.g. 물리적으로 각기 다른 서버에 대해 생성한 색인
이상적으로는 각 구역이 사용자의 수요에 걸맞게 설정된다.
검색의 성능이 향상된다. e.g. 물리적으로 다른 서버에 있는 것은 검색하지 않으므로.
가능한 구분 기준: 콘텐트 유형, 청중, 주제, 위치, 시간대, 저자, 부서별
검색 구역 설정은 양날의 검이다. 사용자의 상호작용에 복잡성이 증가한다. 많은 사용자들은 검색 구역에 신경을 쓰지 않을 것이다.

다음은 유용한 구역 설정들

내비게이션 페이지와 목적 페이지(실제 정보가 담긴 페이지)를 구분하고 목적 페이지만 색인한다. 당연히 검색 기능 사용자는 목적 페이지를 기대한다. 물론 내비게이션 페이지냐 목적 페이지냐가 불분명한 경우도 존재한다. 그럴 경우 사용자 테스트를 하는 수 밖에 없다.
청중에 따른 구분. 사례: 미시건 도서관 청중은 세 부류다: 미시건 입법부 사람들, 사서, 미시건 시민. 이 청중들은 대출 정책이 모두 다르다. 그래서 네가지 색인을 만들었다. 각 청중에 해당하는 정보만 모은 색인 세개, 모든 정보를 모은 색인 하나. “대출”이라고 검색하면 전체 색인에선 문서가 40건 나오고, 입법기관 용은 18개, 사서용은 24개, 시민용은 9개가 나온다. 검색 결과 양이 55%, 40%, 78%로 줄었다. 좋은 성과다. 10-20% 정도의 차이라면 굳이 이렇게 색인을 만들 필요는 없다.
주제별 구분: 사례: 아메리프라이즈 금융 사이트에서 연금 상품을 검색할 때 “개인”을 미리 선택하면 검색 결과가 580개에서 85개로 줄어든다.
최근 콘텐트

어느 부위를 색인할 것인가?

사용자들이 콘텐츠의 특정 부위만 검색할 수 있게 하라
검색하길 원할 수도 있는 부위: 제목, 저자, 이미지 캡션, 링크, 키워드 등
검색하길 원치 않는 부위: 카테고리 목록 등

검색 알고리듬

알고리듬은 도구고, 각 도구는 거기에 맞는 필요가 있다. 만능인 도구는 없다.

패턴 일치 알고리듬

사용자가 쓴 검색어가 포함된 문서 찾기.

회수율: 회수율이 높으면 검색 결과는 많지만 연관성은 상이함
정확도: 정화도가 높으면 검색 결과는 적지만 연관성은 뚜렷함

높은 회수량과 높은 정확도는 동시에 추구할 수 없다. 예컨대 강한 자동 파생(automatic stemming) 알고리듬을 사용하면 파생어도 함께 검색하므로(e.g. “compute”, “computers”, “computation”, “computational” …) 회수율은 높아지지만 정확도는 떨어진다. 역으로 약한 자동 파생 알고리듬을 쓰면 정확도는 높아진다. 특정 필드 검색도.

다른 검색 기법

문서 유사성: 문법적 단어(“the”, “is”, “he”와 같은 것)를 걷어내면 의미가 많이 스며들어 있고 문서의 대략적인 뜻을 대표하는 단어들만 남을 것이다. 그러면 이것들을 검색어로 전환해서 비슷한 문서를 찾는 방법.

To be continued…

정보 구조(Information Architecture) 세미나(3)

내비게이션