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

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

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

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

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

트리 테스팅 - 트리 디자인 방법이 궁금하면 🌳?

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

---

이전 글에서 어떻게 트리 테스팅 태스크(질문)를 디자인하는지 recap을 하자면

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

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

트리 테스팅 태스크 디자인 예시

트리 테스팅 태스크(질문) 디자인에 상당한 시간과 정성을 들였다. 유서 리서처로서 생각해 낼 수 있는 질문의 한계가 있기에 같은 팀에 있는 콘텐츠 디자이너 분의 도움을 많이 받았다. 그 과정을 설명하자면:

 

1. 내가 우선적으로 정답으로 삼고 싶은 페이지를 정한다.

이때 고려했던 것이 문제의 난이도였다. 쉬운 선택지인 페이지 (Building healthcare software)와 더 어렵고 디테일한 페이지 (이 페이지의 세부 페이지들) 간에 고민을 많이 했던 거 같다. 사실 질문은 여러 가지 만들 수 있기에 고민하지 않아도 되는 부분일 수 있다. 하지만 Optimal workshop에서는 같은 레벨의 노드만 정답으로 만들 수 있기 때문에 한 가지를 선택해야 했다.

Optimal workshop에서 왜 상위 노드를 정답으로 만들 수 없는가에 대해 설명했는데, 상위 노드가 정답이면 사용자의 전체 경로를 볼 수 없어 그들의 경험과 분석 결과가 단순해지기 때문이다. 대신 상위 노드가 정답으로 생각될 때 몇 가지를 수정 방안을 제안했다.

• 정답이 되는 상위 노드의 하위 노드(child)가 모두 정답이었을 때, 한 가지 해결책은 모든 하위 노드를 제거하고 상위 노드를 정답으로 만들거나 트리 테스팅 태스크(질문)를 더 구체적으로 바꾸는 것이다.
• 다른 예시로는, 상위 노드에 정답이 포함되어 있지만 정답이 아닌 하위 노드 있는 경우이다. 일반적으로 노드가 다른 페이지의 추가 콘텐츠에 연결되는 랜딩 페이지 (landing page, 쉽게 설명하자면 검색 엔진, 광고 등을 경유하여 접속하는 이용자가 최초로 보게 되는 웹페이지) 일 경우이다. 이럴 경우 정답이 포함되어 있지만 하위노드가 있어 시스템 상 정답으로 설정되지 못하다. 해결책은 이 정답을 '헤더' 노드(상위 노드)의 리프 하위 항목(하위 노드)으로 포함하는 것이다.
  • 예: 이메일 > 리즈 오피스, 런던 오피스 일 때 정답을 리즈 오피스의 이메일로 설정하고 싶을 경우. 이메일 > 리즈 오피스 > 이메일, 이메일 > 런던 오피스 > 이메일로 만들어서 헤더 노드 (리즈 오피스, 런던 오피스)에 리프 하위 항목 (이메일)을 넣는 것이다.

이렇게 고민한 결과 나는 트리 테스팅의 태스크(질문)를 더 구체적으로 바꾸었다. Building healthcare software페이지에 속한 care settings / functional areas 카테고리를 사용자가 구분할 수 있는지 궁금했기 때문이다.

 

2. 정답으로 삼고 싶은 페이지를 정했다면, 그다음은 그 정답 페이지의 내용을 숙지하고 사용자 입장에서 생각하는 자세를 가지는 것이다. 사용자는 '이런 상황에서 이런 정보를 찾고 싶다'라는 니즈(needs)로 부터 시작해서 정보를 검색하기에 이 가정을 잘 세우고 질문으로 바꾸는 것을 팁으로 삼고 싶다. 

예: 그래서 질문의 시작을 'Suppose you're a user looking for' 등 상황을 가정해서 질문을 던지는 방식으로 디자인했다.

 

3. 질문에 너무 정답을 노출시키지 않았는지 유의한다.

리서처의 딜레마... 편하게 갈 것인가 아니면 더 고려를 할 것인가...

예: NHS Digital > Developer > Documentation, guides and tutorials > Building healthcare software > Guides for functional areas > Clinical coding, classifications and terminology를 정답인 경로로 생각하고 있다. 이미 콘텐츠 디자이너가 이 가이드에 대한 한 줄 설명을 페이지의 부제목으로 사용하고 있어서 이 내용 그대로 질문으로 삼고 싶었으나 너무 정답을 명시하고 있기에 이 내용을 돌려 질문으로 만들어야 하는 고난이 있었다. 그래서 처음 만든 질문은 'Suppose you're a user looking for a non-technical guide to building software that deals with clinical coding, classifications and terminology within the NHS in England'. 에서 'Suppose you're a user looking for a non-technical guide describing which APIs support classifications that provide specific codes for diseases. Which section of the NHS Digital website would you expect to find this information in?'으로 바꾸었다.

 

4. 다른 리서처/디자이너의 도움을 받는다.

본인이 속한 회사에 다른 유서 리서처나 디자이너가 있다면 언제나 그들에게 도움을 요청하는 것이 좋다. 다행히 내가 있는 팀에는 스스로 technical author라 칭하는 존경하는 콘텐츠 디자이너님이 있어 그분에게 많은 도움을 받았다. 

예: 나는 단순히 'a non-technical guide on classifications that provides specific for groups of illness, symptoms, or procedures'로 질문을 만들었다면 그는 이 질문이 너무 일반적이다라고 피드백을 주었다. 'you should be asking where to find a non-technical guide that explains what APIs deal with classifications that provides specific codes for groups of illnesses.' 감사합니다...

 

이렇게 대장정의 트리 테스팅 디자인 과정을 소개했습니다. 제가 이 테스트를 디자인할 때 고민하고 유의했던 부분이 도움이 되었길 바랍니다. 혹 공유하고 싶은 팁이 있으시다면 댓글로 남겨주시면 감사하겠습니다 :)

다음 리서치 관련 글을 가지고 돌아오겠습니다. Cheerios!

---

 
레퍼런스

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