Information Architecture(IA) 정보 아키텍처 테스트 하기 2 - Tree testing 트리 테스팅

다양한 UX 리서치 방법과 왜 트리 테스팅을 선택했는지 궁금하면 🌳👌?

Information Archiecture(IA) 정보 아키텍처 테스트 하기 - UX 리서치 방법

트리 테스팅 입문 첫 글 확인하기 🌳

Information Archiecture(IA) 정보 아키텍처 테스트 하기 - Tree testing 트리 테스팅 

 

---

 

트리를 디자인할 때 몇 가지 고려할 점은:

• 트리는 모든 다루고자 하는 내용의 상위 범주 및 하위 범주를 가지고 있어야 한다.
  즉 한 섹션을 제외하면 위험한데, 사용자가 이동할 섹션을 알 수 있다고 가정하기 때문이다.
• 트리는 3, 4, 심지어 5단계의 깊이가 필요할 수도 있다. 테스트할 하위 범주의 가장 낮은 수준까지, 전체 깊이를 포함하게 디자인한다.

트리 테스팅 태스크(질문) 디자인하기:
사용자가 이 태스크를 확인하고 트리 테스팅을 진행하기에 이 태스크 디자인 또한 트리 디자인만큼 중요하다.

• 먼저 대상으로 지정할 범주와 레이블을 결정해야 한다.
• 여기서 대상이란 '정답'이라 할 수 있는 섹션과 '예상된 오답'이라 할 수 있다.
• 정답을 제공하는 용어를 사용하지 않아야 한다.

 

---

 
트리 디자인 예시

실제 NHS Digital 웹사이트 트리로 옮겨 담은 NHS Digital 웹사이트

지금 계획하고 있는 트리 테스팅을 예시로 설명하고자 한다.
실제 NHS Digital 웹사이트를 보면 직관적으로 깔끔한 화면을 가지고 있는 것을 알 수 있다. 하지만 그 정보 아키텍처를 파고들면 얼마나 복잡한지 알 수 있다. Optimal workshop 툴을 이용해서 NHS Digital 웹사이트를 트리 구조로 만든 모습이다.
 

Optimal workshop 툴로 옮겨 담은 5 단계를 가진 NHS Digital 웹사이트 트리 구조

 

테스트를 하고 싶었던 것은:

• 유서들이 첫 선택으로 'Developer'를 선택하는가? - 페이지의 제목 문제 가설 확인
• 유서들이 Documentation, guides and tutorials을 선택하여 Building healthcare software를 찾을 수 있는가? - 정보 구조에 문제 가설 확인
• 유서들이 care settings / functional areas를 잘 구분하여 최종 정보를 찾을 수 있는가? - 카테고리 이름 / 정보 구조에 문제 가설 확인

트리 노드 (tree nodes) 중 정답이 포함된 트리의 모습으로, 5단계의 깊이를 가진 트리가 되었다.
 
유의했던 / 고민했던 점:

• 정답이 속한 트리가 5단계 (2 상위 단계, 3 하위 단계)를 가지고 있어서 최대한 다른 트리 가지에도 비슷한 단계의 깊이를 지키기 위해 노력했다.
• 물론 다른 페이지에 정답으로 향하는 '링크'가 속한 페이지도 있었다. 하지만 '링크'가 범주나 내용 레이블이 될 수 있는가에 고민을 했으나 '아니요'라고 결론을 내렸다. 텍스트인 링크가 '웹사이트 구조'가 될 수 있는가를 고민하면 답이 나온다. 

정답인 링크가 포함된 페이지, 하지만 링크는 트리가 될 수 없다

• 그리고 범주나 내용 레이블로 만들기 어려웠던 웹페이지도 있었다. 구조가 분명하지 않은 웹페이지가 종종 있는데 이때 고려했던 것은 이러한 것들이 있다.
  • 이 단계의 깊이로 끝냈을 때 정답이 되는 단계의 깊이와 비슷한가?
  • 많이 선택될 오답(인기 오답)이 될 수 있는 요소가 있는가?
  • 웹사이트 구조가 될 수 있는 요소가 있는가?
    • 이 사이트를 책처럼 구조화했을 때 범주나 내용 레이블이 될만한 요소가 있는가?
    • 이 사이트의 html을 확인했을 때 범주나 내용 레이블로 만들만한 요소가 있는가?
    • 이 사이트에 브래드 크럼 (bread crumbs)이 있는가?

웹사이트 구조가 불불명한 예시 그 웹사이트를 구조화 한 예시

위는 웹사이트 구조가 불불명한 모습이다. 카탈로그 형식의 구조로 A-Z 중 첫 이니셜을 클릭하여 API를 검색하는 사이트이다. 카탈로크 설명, 필터, 검색 기능 등 다양한 기능이 있어 구조화되기에는 힘들어 보였다.
하지만 이 페이지는 특히나 내가 고려했을 때 '인기 오답'이 될 확률이 높은 페이지였다. 때문에 Developer > API catalogue로 끝나면 부족한 감이 있다. 그래서 생각했던 게 만약 이 페이지가 책 목록과 유사하다고 생각하면? 이였다. 그렇게 해서 이 페이지를 보게 되면 Developer > API catalogue > A > Access Control Service HL7 V3 API까지의 하위 노드 (내용 레이블)까지 생각해 볼 수 있다.
물론 이렇게 하는 것이 정답이라는 것은 아니다. 하지만 '정답이 되는 내용 레이블 과의 깊이 단계'와 '인기 있는 오답이 될 가능성'이 나에게 중요한 요소로 작용한 만큼 이렇게 해서 하위 노드를 만들어 냈다.

 

트리를 디자인 했다면 트리 테스크(질문) 디자인이 다음 단계! 트리 테스크 디자인하는 방법과 예시는 다음 글에서 소개하고자 한다.

Coming soon >

 

---

 
레퍼런스

Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories - Nielsen Norman Group
Information Architecture Basics - usability.gov
UX디자이너 인사이트 도출 후 정보 구조 설계 information architecture란?
Create tasks and set answers - Optimal workshop