유저 데이터가 없을 때는 어떻게 해결책을 찾을까?

UT 이후 우리가 풀어야 할 핵심 문제는 '더 쉽게 꺼내 쓸 수 있는 정리 형태’를 찾는 것이었다. 그동안 북카이브는 간단한 태그를 활용해 정보를 분류해왔지만, 타겟 유저(비문학파)에게 이 방식은 충분하지 않다는 걸 알게 되었다. 그들이 느끼는 정리와 활용에서의 문제를 해결해 줄 수 있는 형태로 개선이 필요했다.

문제인 건 알겠는데, 그래서 어떻게 해야 하지?

그럼 어떻게 개선해야 할까? 개선이 필요하다는 건 알지만, 구체적으로 어디를 어떻게 디벨롭해야 할지 감이 잡히지 않았다.

타겟 유저를 더 만나보면 되겠지만 당장 유저 인터뷰를 할 수 있는 리소스도 없었고, 유의미한 정량 데이터도 없는 상황이었다. 여러 서비스를 탐색하며 레퍼런스를 찾아보기도 했지만 마땅한 개선 방향을 찾기는 어려웠다.

나는 본질을 제대로 이해하고 있나?

나는 다시 근본적인 질문을 던지며 처음부터 차근차근 생각해 봤다.

“북카이브가 제공하고자 하는 핵심 가치는 뭐지?”

북카이브가 궁극적으로 추구하는 가치는 ‘지식 관리’이다. 줄곧 ‘지식 관리’라는 말을 써왔지만, 정작 난 이 개념에 대해 깊이 이해하고 있지 않다는 걸 깨달았다. 심지어 분류학(Taxonomy)이라는 학문이 따로 있을 정도로 딥한 영역인데, 우린 그 영역에 익숙하지 않았다.

북카이브의 본질적 개념을 제대로 알지 못하는데, 아무리 유저를 만나거나 데이터를 본다고 뭐가 달라질까?라는 생각이 들었다. 나부터 이 개념을 제대로 알고 이해해야 할 필요가 있다고 느꼈다.

그러던 중 마침 ‘세컨드 브레인’이라는 책을 알게 되었다. 세컨드브레인(Second Brain)이란, 지식, 아이디어, 생각 등 정보를 체계적으로 기록하고 정리해 나의 두 번째 뇌처럼 활용하는 지식관리 시스템을 말한다.

북카이브가 추구하는 ‘지식 관리’와 맞닿아 있는 개념이었고, 더 깊이 공부할 수 있을 것 같아 이 책을 읽기 시작했다.

책에서 얻은 힌트

이 책은 세컨드 브레인 개념을 다루는 책으로, 세컨드 브레인 구성 과정인 CODE 프레임워크를 소개한다.

CODE는 Capture(수집) - Organize(정리) - Distill(추출) - Express(표현) 네 단계로 이루어져 있다. 이는 곧 북카이브 유저들이 책에서 유용한 정보를 발견하고 기록하는 과정과도 자연스럽게 연결된다. 각 단계에서 설명하는 포인트들이 북카이브 사용 경험과 연관된 것이 많아 개선 방향을 잡는 데 많은 힌트를 얻을 수 있었다.

01 Organize - 활용 단위의 분류

Organize 단계를 읽으며 북카이브의 태그를 어떻게 활용해야 할지 감이 잡혔다.

[힌트]
정보는 자신의 우선순위와 목표에 따라 융통성 있게 정리되어야 한다.

책에 따르면 사람들은 대부분 듀이십진분류법에 따라 정보를 정리하는 경향이 있다고 한다. 즉 책으로 따지면 과학, 경제, 인문학처럼 장르별로 구분을 하는 것이다. 하지만 이는 실제로 그 정보를 활용하는 데에는 효과적인 방식이 아니라고 한다. 자신의 우선순위와 목표에 따라 당장 활용할 수 있는 단위로 정리되어야 융통성 있게 정보를 꺼내 쓸 수 있게 된다.

[인사이트]
일상 속 구체적인 활용 단위로 태그를 분류할 수 있도록

이전에는 태그를 ‘이렇게 쓰면 좋다’라는 방향 없이 단순히 구절을 나누는 용도 정도로 생각했다. 하지만 이 부분을 읽고 명확해졌다. 북카이브로 저장한 정보를 잘 써먹을 수 있게 하려면, 일상 속 활용 맥락을 기준으로 태그를 사용하는 것이 중요하다.

예를 들어 ‘브랜딩 사례’, ‘팀 빌딩’, ‘문제 해결’ 등 현재 업무에 바로 적용 가능한 키워드로 태그를 사용하는 것이다. 물론 사용자들이 태그를 듀이십진분류법이 아닌 활용 단위로 잘 사용할 수 있도록 자연스럽게 인지하고 유도하는 장치가 필요할 것이다.

02 Organize - 태그의 ‘연결’과 2뎁스 구조

[힌트]
개인 지식 관리는 기억 - 연결 - 창조 세 단계를 거쳐 이루어진다. 서로 관련 없는 정보들 간 연결이 만들어질 때 새로운 아이디어가 창조된다.

책에서는 ‘연결’을 통한 지식 창조와 활용을 강조하는데, 이를 통해 북카이브의 태그가 분류 그 이상의 역할을 할 수 있다는 것을 깨달았다. 서로 다른 책에서 수집한 정보이거나, 관련이 없는 분야라고 하더라도 태그를 통해 그 인사이트 간 뜻밖의 연결성을 발견할 수도 있게 된다.

[인사이트]
태그 안에 2뎁스 구조 나누기

어떻게 태그를 연결의 수단으로 잘 쓸 수 있게 만들까? 더 섬세한 연결을 할 수 있도록 하려면 태그로 쉽게 필터링해 볼 수 있어야 하지만, 현재 북카이브는 태그들이 수평 나열되어 있어 개수가 늘어날 경우 필터링해 보기가 불편해진다. (실제로 꽤 많은 유저가 표했던 우려)

그래서 우리는 태그에 상위-하위의 2 뎁스 체계를 생각해냈다. 예를 들어 ‘팀 빌딩’, ‘문제해결’ 등의 하위 태그들은 ‘창업’이라는 상위 태그로 한 번 더 묶일 수 있는 것이다. 이렇게 하면 정보들을 더 큰 범위로 묶어 볼 수도, 쪼개어 볼 수도 있어 인사이트 간 ‘연결’을 더 입체적으로 만들 수 있을 것이라고 판단했다.

03 Distill - 핵심 추출

[힌트]
아이디어를 연관 짓는 과정을 촉진하는 효과적인 방법은 핵심(essence)만 남을 때까지 추출하는 것이다. 만약 내가 과거에 쓴 메모를 봤을 때 이해할 수 없거나 읽어 볼 엄두조차 나지 않는다면 그 메모는 쓸모 없는 것이다. 미래의 자신에게 찾기 쉽고 이해하기도 쉬운 지식을 선물한다고 생각해야 한다.

이 부분을 읽고 깨달았다. 북카이브의 정리 형태가 좋은 방식은 아니라는 것을. 당시에는 저장한 기록이 그대로 줄글 형태로 저장되어 쌓이는 형태였다. UT에서 홈 화면에 대한 첫 인상에 대해 ‘정리가 잘 안 되어 보인다’라는 의견이 몇 있었는데, 이 문제가 원인일 수 있겠다는 생각이 들었다.

[인사이트]
AI가 생성해준 제목으로 핵심 보여주기

여기서 힌트를 얻어 AI 제목 생성이라는 다음 피쳐를 고안했다. AI가 구절 맥락에 맞는 핵심 포인트를 제목으로 만들어주는 것이다. 태그로 필터링해 본다고 해도 각 구절들의 핵심을 바로 파악하기가 어려우면 꺼내 쓰는 과정에 허들이 될 수 있다. AI가 요약해준 한 줄 핵심을 제목으로 보여준다면 구절들을 일일이 읽어볼 필요 없이 제목만 보고 필요한 구절인지 아닌지를 파악할 수 있다.

04 Express - 가공의 중요성

[힌트]
개인적이고 구체적이며 검증된 정보는 실제로 사용할 때에 비로소 ‘지식’이 된다. (중략) 알고 있는 것이 효과가 있다는 것을 알게 되어야 자신감을 얻는다. 그 전까지는 이론에 불과하다. 소비보다 창조하는 일에 시간과 노력을 더 많이 투자하라

책에서는 지식이 단순 저장을 넘어 가공의 단계를 거쳐 표현되거나 쓰일 때 내재화가 된다고 말한다.

이는 실제로 인터뷰를 통해 관찰한 유저 행동 및 말과도 일치했다.

[실제 유저의 말]
“기본 메모앱에 책 문장을 그대로 일단 적어둬요. 그리고 시간이 날 때 한 번 다듬어서 블로그에 올려요. 가공해서 블로그에 올리지 않으면 메모장에 마구잡이로 저장해둔 러프한 글들이 그대로 남게 되고, 그럼 다시 보지 않게 되더라구요.”

[관찰한 유저 행동]
독서 모임 참여, 글을 정리해 블로그에 업로드, 구절에 대한 내 생각 적기 등

이처럼 책에서 얻은 정보를 다듬거나 공유하는 경우가 많았다. 이 글을 읽고 나서야 그 행동들이 곧 정보를 글 또는 말로 다시 표현함으로써 진짜 내 것으로 만들기 위함이었다는 것을 알게 되었다.

[인사이트]
정보 내재화를 위한 가공 단계 추가하기

현재 북카이브는 구절을 있는 그대로 저장만 할 수 있다. 하지만 여기서 얻은 힌트를 통해 앞으로는 저장을 넘어 이를 바탕으로 가공해 지식을 내재화할 수 있도록 디벨롭 할 예정이다. 현재는 간단하게는 내 생각 적기부터 다른 사용자와의 소통까지 내재화를 돕는 다양한 가공의 형태를 고민하고 있다.

이 외에도 책을 통해 얻은 크고 작은 인사이트와 아이디어들이 정말 많았다. 하지만 당연하겠지만 책의 모든 것을 그대로 반영하지는 않았다. 예를 들어 책에서는 가장 효과적인 분류법으러 ‘PARA 분류법’에 대해 이야기하지만, 이 방법은 복잡도가 높아 북카이브에는 적합하지 않다. 대신 그 구조에서 일부 아이디어를 차용해 북카이브에 더 잘 맞는 방식으로 발전시켜 나가려 한다.

책을 읽으며 흥미로웠던 점은, 책에서 이야기한 몇 가지 인사이트들이 사실은 유저 인터뷰에서 언급된 내용과 맞닿아 있었다는 점이다. 당시에는 그 중요성을 인지하지 못하고 지나쳤지만, 책을 읽고 나서야 그것이 북카이브의 핵심 가치에 있어서 중요한 부분임을 깨달았다.

물론 책에서 얻은 이 인사이트들을 곧바로 적용하는 것이 아니라 반드시 유저들을 만나 검증하는 과정이 필요하다. 실제로도 책을 통해 구상한 위 아이디어들 바탕으로 추가 유저 인터뷰를 진행하며 그 방향이 적합한지 아닌지를 확인해 나갔다. 결국 답은 책이 아닌 유저에게서 찾아야 하기 때문이다.

하지만 당장 유저를 만날 수 없거나 데이터가 부족한 상황에서는 다른 방식의 접근도 필요하다. 문제의 근본을 더 깊이 이해하고 사용자에게 이를 전달하는 데 있어서 중요한 것을 알아야 한다.

해결책의 방향을 찾지 못할 때, 때로는 유저나 레퍼런스 외에도 다양한 관점에서의 탐색을 통해 그 실마리의 단초를 얻을 수 있다.

UX딜레마: 사용자 습관을 유지할 것인가, 바꿀 것인가

프로덕트를 만들다 보면 사용자가 가진 기존 습관이 있고, 우리는 그와 다른 새로운 가치를 제공해야 할 때가 있다. 그럴 때 우리는 사용자가 그 습관을 조금 더 편하게 할 수 있도록 해야 할까? 아니면 새로운 가치를 학습시켜야 할까?

북카이브를 만들면서 이런 딜레마 속에서 고민을 많이 했었는데, 바로 책별분류와 태그분류 사이에서의 고민이었다.

사용자의 습관: “책별로 보고싶어요”

(건의함에 들어온 의견 일부)

사실 이런 요청은 건의함에서도 그렇고 이전에도 조금씩 들려왔던 요청이었다. 난 처음에는 단순히 기존 습관에 의한 관성이라고 생각했다.

북카이브가 궁극적으로 추구하는 모습은 결국 ‘지식 관리 서비스’였기에, 지식을 효과적으로 관리하고 활용하기 위해서는 정보들을 주제별로 관리하고 서로 ‘연결 짓는 것’이 중요했다 (그 이유는 추후 ‘세컨드 브레인’ 관련 글에서 자세히 다룰 예정이다). 이는 추후 필요할 때 다시 꺼내보는 상황에서도 더 편리한 방법이다.

우리는 사용자들의 기존 습관을 더 쉽게 이행할 수 있도록 해주는 게 중요할지, 아니면 새로운 방법이지만 활용에 더 효과적인 방법을 학습시키는 게 맞을지 고민이었다. 난 ‘유저가 평소에 그렇게 해왔으니까 여기서도 할 수 있게 해주자’라고 결정하는 것은 장기적으로 봤을 때 프로덕트에게도, 유저에게도 좋은 선택은 아니라고 생각했다. 그래서 초반에 책별 분류를 넣으려다가도, 책뷰가 필요한 명확한 이유가 없다고 생각해 계속 미뤄 왔었다.

습관 속 숨겨진 이유 찾기

CBT 인터뷰 결과, 사실상 인터뷰한 모든 유저가 기존에 책별로 구절을 분류하고 있었다. 주로 페이지 하나를 파서 책 제목으로 해두고, 그 책에서 발견한 모든 구절들을 해당 페이지에 넣어두는 방식으로 정리를 하고 있었다. 그래서 인터뷰를 통해 사용자들이 기존에 책별로 분류하는 이유를 더 깊게 파악해보려고 했고, 분석을 하고 나니 왜 사용자가 책별 분류를 원했는지 이해할 수 있었다.

01  책이라는 틀을 벗어나기는 어렵다

기존에 책별로 분류하는 형태에 대해 이야기를 나눌 때, 공통적으로 다음과 같은 단어가 많이 언급되었다.

"책의 요지", "책의 맥락", "흐름" …

그제야 알게 되었다. 문맥을 알아야 그 문장을 이해할 수 있다는 것.

우리는 태그를 활용해서 책 밖에서 인사이트들을 연결해주는 방식을 생각했지만, 사람들은 구절들이 책 안에서 어떻게 연결되는지도 파악하고 싶어했다. 책의 맥락이 함께 기록되어야 그 하나하나의 구절의 의미를 제대로 이해할 수 있다고 느끼기 때문이다.

따라서 아무리 태그를 활용해 주제별로 분류하는 방법이 다시 꺼내 보는 데 도움이 될지는 몰라도, 그 ‘책’이라는 틀을 벗어나기는 어렵다. 사람들에게 ‘책’이라는 것은 단순한 분류 기준이 아니라 구절의 의미와 문맥을 함께 기록하는 정보 구조의 하나였던 것이다.

이는 심리적인 것과도 연관되어 있다고 느꼈다. 같은 책에서 나온 같은 맥락의 구절들이 한 데 모아지지 않고 흩어진다는 느낌이 불안감으로 다가왔을 수 있겠다는 생각이 들었다.

사용자들은 책별 분류와 함께 페이지를 표시할 수 있으면 좋겠다는 의견을 공통적으로 이야기하기도 했는데, 그 이유도 위의 니즈와 연결된다.

한 유저가 했던 말이 기억이 난다.

“언젠가 그 책을 다시 보게 되어있어요.”

즉 어떤 구절을 찾아볼 때, 같은 책의 다른 구절들을 함께 찾아보고자 하는 니즈가 있다. 이것 또한 같은 맥락에서 연결되는 구절들을 함께 보아야 그 의미를 종합적으로 이해할 수 있기 때문이다. 이런 이유로 나중에 다시 찾아보기 쉽도록 페이지를 적고자 했던 것이었다.

02  구절을 다시 찾아보는 두 가지 사고 흐름

위와 유사한 맥락이지만, 사용자의 사고 흐름도 이유 중 하나였다. 필요할 때 특정 구절을 다시 찾아보는 상황에서의 생각의 흐름을 분석한 결과, 두 가지로 나뉘는 것을 발견했다.   

1. 키워드를 떠올리는 경우: ‘ux의사결정 관련된 구절이 뭐가 있었더라?’
2. 책을 떠올리는 경우: ‘ux의사결정 관련된 그 책을 한 번 찾아봐야겠다’

이 두 가지 케이스는 어느 하나가 더 빈번하거나 하지 않았고, 상황에 따라 두 경로로 떠올리고 구절을 찾아보게 된다.

키워드를 떠올리는 경우, 현재 북카이브에서는 태그를 통해 해결이 가능하지만 2번처럼 책을 먼저 떠올리는 경우에는 북카이브를 통해 해결하기 어려웠다. 그래서 이 두 가지 케이스를 모두 커버하기 위해 책별 분류가 필요했다.

기존 습관과 새로운 가치: 균형 찾기

그럼 북카이브는 책별 분류만 제공하면 되는 걸까?

하지만 책별 분류에도 명확한 문제점이 있었다. 북카이브에서의 “분류”는 나중에 필요할 때 더 쉽게 찾아보고 꺼내 쓸 수 있도록 도와주는 장치이다. 하지만 책으로만 분류했을 때 다시 꺼내보는 과정이 불편한 경우가 많았다. 실제로 인터뷰 결과 구절을 다시 찾아볼 때 책별로 나눈 페이지를 하나하나 들어가 확인하고, 이에 불편함을 느끼는 경우가 많았다.

사용자들이 불편함을 느끼는데도 분류 형태를 그대로 유지한 이유는 무엇일까? 이유는 태그를 활용한 주제별 분류를 어떻게 해야 할지 잘 몰랐기 때문이다. 수기로 노트에 기록하는 경우 주제별 분류가 더 어려울 수밖에 없고, 또 아예 주제별로 분류할 수 있다는 생각을 하지 못하고 “그것도 좋은 방법인 것 같네요”라고 말한 사용자도 있었다. 그러다 보니 사용자들은 기존 습관대로 책별로만 분류를 해왔던 것이다.

그래서 우리는 태그 분류에 대한 니즈를 ‘잠재적 니즈’라고 판단했다. 사용자들이 불편함을 느끼고는 있지만, 스스로 인지하지 못하거나 그 방법을 모르는 니즈였던 것이다.

태그 분류 & 책별 분류

결론적으로 우리는 책별 분류와 태그 분류를 함께 제공하기로 했다.

책에서 얻은 인사이트 간 연결은 책 밖에서도, 책 안에서도 모두 가능해야 진짜 활용을 도울 수 있다고 판단했다. 태그로 인사이트를 분해해 보고, 책으로 그것을 다시 통합해 볼 수 있는 형태인 것이다. 그래서 우리는 책별로도, 태그별로도 모아볼 수 있도록 업데이트를 마친 상태이다.

이제는 ‘태그 분류’라는 가치를 더 효과적으로 전달하기 위해서 사용자들에게 어떻게 학습시킬지를 고민하는 것이 필요하다.

기존 습관 vs 새로운 가치 

기존 습관 ↔ 새로운 가치

책별 분류는 사용자들이 가진 단순한 습관이 아니었다. 정보를 해석하는 사용자들의 사고 구조가 반영된 행위였던 것이다.

사용자들의 기존 습관과 다른 형태의 가치를 제공해야 할 때, 무작정 새로운 가치를 보여주기보다 사용자의 기존 습관을 파악하는 것이 중요하다. 나는 단순히 ‘습관에 의한 관성일거야’ 라고 생각했었는데, 이 또한 공급자 관점이라는 걸 느꼈다. 우리가 주는 새로운 가치에 매몰되어 사용자의 사고 방식을 깊게 들여다 보지 못했던 것이다.

그렇다고 기존 습관의 이유를 잘 이해하지 않고 무작정 넣는 것도 좋은 방법은 아니다. 기존 습관이 큰 문제를 일으키는 경우에는 이를 새로운 방식으로 전환시키는 것이 더 좋을 수 있다. 따라서 우리 프로덕트와 사용자의 특성, 습관의 원인이 무엇인지에 따라서 적절한 선택을 해야 할 것이다.

기존 습관과 새로운 가치는 양자택일이 아니다. 기존의 사고방식을 반영하면서도 새로운 가치를 적절히 전달하는 균형을 찾는 것이 중요하다.

초기 B2C 프로덕트가 정성 데이터 수집하는 법

사용자가 없는 초기 프로덕트는 정성 데이터를 어떻게 수집할 수 있을까?

MVP를 만들고 나면 ‘우리 이런 거 만들었는데 어때? 왜?’의 질문에 답을 찾아가야 한다. 사용자들이 좋아해준다면 베스트겠지만 처음부터 그런 경우는 드물다. 우리 서비스를 쓰지 않는다면 왜 쓰지 않는지, 어디를 어떻게 개선해야 하는지 알아내는 것이 중요하다.

이런 인사이트를 얻을 수 있는 지표로는 크게 정량 데이터와 정성 데이터가 있다. 다만 북카이브 같이 충분한 사용자가 없는 초기 프로덕트의 경우, 모수가 부족해 정량 데이터로 유의미한 인사이트를 얻기 힘들다. 따라서 정성 데이터를 수집하는 것이 무엇보다 중요하다.

그렇다면 아직 우리 서비스를 쓰는 사용자가 없는 상황에서 정성 데이터는 어떻게 모아야 할까? 북카이브는 여러 고민 끝에 다음과 같은 방법을 생각했다.

[방법1] 회원가입 정보 수집? : B2C와 B2B의 차이

의미 있는 정성 데이터를 모으기 위해서는 사용자를 직접 만나 이야기를 나누는 것이 가장 좋은데, 이전처럼 매번 지인에게 부탁할 수도 없고..그렇다고 타겟에 맞는 사람을 어디서 어떻게 찾을 것이냐가 문제였다.

그러다 내 이전 프로젝트(B2B SaaS)에서 회원가입 단계에서 연락처 정보를 받고, 직접 연락해 인터뷰를 진행했던 것이 떠올랐다. 당시 나름 응답률이 나쁘지 않았던 기억이 있어 우리도 해보면 어떨까 제안했고, 그렇게 진행해보기로 했다.

그러던 중 문득 이게 북카이브와 맞는 방법일까 의문이 들었다. 내가 만약 어떤 앱이 흥미로워 보여서 다운받고 한 번 써봤는데 갑자기 그 서비스 담당자에게 문자나 전화가 온다면? 이상하고 거부감이 들 것 같았다.

이것이 B2B와 B2C의 차이라는 걸 느꼈다.

B2B

1. 고객 LTV가 크고, 한 명 한 명과의 ‘관계’가 중요

B2B는 기업 고객 한 명 또는 한 팀의 계약으로 몇 천만 원의 매출이 나올 수 있는 구조이다. 또 B2C에 비해 더 좁은 범위를 타겟하기 때문에 고객의 수가 적다. 따라서 한 명 한 명과 라포를 형성헤 관계를 맺는 것이 중요하고, 전화나 메일 한 번으로 충분한 ROI를 얻을 수 있다.

2. 뚜렷한 사용자의 문제 인식과 니즈

B2B의 유저들은 B2C처럼 일상 속 작은 불편함보다는 업무 효율과 생산성 향상과 같은 명확한 목적이 있다. 따라서 연락처를 통한 인터뷰나 세일즈 연락에 상대적으로 열린 태도를 가질 가능성이 높다.

3. 개인정보 허들이 낮음

기본적으로 업무용 이메일을 사용한다. 또 나의 업무에 관련된 영역이기 때문에 연락처로 인터뷰를 요청하는 것에 대한 거부감이나 민감도가 비교적 낮고, 때로는 그것이 자연스럽다고 느껴지기도 한다.

B2C

1. 고객 단가가 낮고 수가 많음

B2B에 비해 광범위한 사용자를 타겟으로 하므로 그 수가 더 많다. 또 고객 단가가 상대적으로 낮기 때문에 사용자에게 일일이 컨택하는 건 비용 대비 효율이 낮다.

2. 개인 프라이버시에 민감

전화번호 제공 자체에 민감할 수 있다. 특히 북카이브의 경우 전화번호가 필요한 특정 기능이 없기 때문에 정보 제공 자체에 거부감이 커지고 서비스에 대한 신뢰도가 낮아질 위험이 있다. 사용자 입장에서는 앱 하나 설치했다고 메일이나 전화를 받는다면 스팸으로 의심해 반감을 느낄 수도 있다.

3. 사용자 여정이 짧고 충동적

B2C 제품은 호기심으로 한 번 설치해보고 그만두거나, 아주 짧은 판단으로 이용하는 경우가 많다. 때문에 개인 연락처로 정성 피드백을 수집한다고 하더라도 이탈이나 사용 이유를 명확히 알기 어렵고, 더 구체적으로 파고들기 어렵다. 또 그런 허수로 인한 리소스 낭비 문제로 이어질 수 있다.

이와 같은 이유로 B2C인 북카이브에서는 회원가입으로 연락처를 받아 데이터를 수집하는 건 무리라고 판단했고, 대신 다른 방법을 더 고민해보기로 했다.

[방법2] 건의함: 간단하게 사용자 의견 수집하기

우리가 생각해낸 다른 방법은 앱 화면에 ‘건의함’을 두는 것이다. 건의함은 앱 내에 사용자들이 자유롭게 의견을 남길 수 있도록 하는 장치로, B2C 앱 서비스에서 흔하게 볼 수 있다. 건의함으로 정성 데이터를 수집할 때는 다음과 같은 장단점이 있다.

장점

1. 접근성이 좋음

앱 화면 내에 배치되어 있어 사용자가 불편을 느끼는 즉시 쉽고 빠르게 의견을 남길 수 있다.

2. 실제 사용 맥락 반영

서비스에서 행동 직후의 생생한 피드백을 받을 수 있어 컨텍스트가 살아있는 의견을 모을 수 있다.

3. 부담이 적음

인터뷰나 UT처럼 시간을 들이지 않아도 되니 메이커 입장에서 더 효율적으로 사용자 목소리를 수집할 수 있다. 또 사용자 입장에서도 부담 없이 원할 때 바로 의견을 남길 수 있다. 

단점

1. 수동적 피드백으로 인한 한계

건의함과 같은 방식은 휴먼 터치가 없어 직접 요청하는 것에 비해 효과가 떨어질 수 있고, 수동적으로 피드백을 받는 방식이기 때문에 불충분한 의견이 모일 수 있다.

2. VoC 품질의 문제 (부족한 구체성)

단편적이고 짧은 텍스트 기반의 피드백으로, 대부분 맥락이 부족하다. 충분한 정보 없이 ‘이게 불편해요’, ‘이런 기능이 있으면 좋겠어요’ 정도의 피상적인 수준으로 끝나는 경우가 많아 깊이 있게 파고드는 것이 어렵다. 

그럼 건의함은 어떻게 설계해야 할까?

건의함의 주요 목표는 사용자들이 빠르고 쉽게 의견을 남길 수 있도록 하는 것이라고 생각한다. 최대한 이탈 없이 다양한 의견을 모으는 것이 중요하기 때문에 퍼널이 길어서는 안 된다. 나는 다음과 같이 건의함을 만들었다.

1. 사용자 언어를 활용한 카피라이트로 관심 유도

단순히 ‘여러분의 소중한 의견을 들려주세요’와 같이 일반적인 문구를 사용하고 싶지는 않았다. 서비스를 사용하면서 사용자들이 느끼는 실제 사고의 흐름을 반영해 관심을 유도하고자 했고, ‘이렇게 개선되면 좋겠어요’와 같이 사용자 생각과 언어를 반영한 카피를 활용했다.

2. 시선을 유도하되 앱 사용 방해 최소화

북카이브는 마이페이지가 없어 건의함을 홈 화면에 배치할 수밖에 없었다. 더 노출이 잘 된다는 장점은 있지만 그만큼 피로도를 높일 위험이 있다. 그래서 최대한 미사여구 없이 컴팩트하게 서비스 사용 및 시각적 방해를 최소화했다.

3. 객관식 + 주관식(선택)

우리는 객관식과 주관식 혼합형으로 설계했다. 객관식은 주요 플로우를 단계별로 나눠 옵션으로 제공했고, 주관식은 더 자세한 의견을 작성하는 칸으로 선택사항으로 두었다. 객관식은 줄글로 쓰기 귀찮은 경우에 간단하게나마 의견을 남길 수 있도록 어느 단계에서 불편함을 느꼈는지를 표시할 수 있다. 우리는 이 데이터를 통해 사용자들이 어느 부분에서 공통적으로 불편함을 느끼는지를 확인할 수 있다.

초기에는 더 구체적으로 작성한 옵션을 제공할까 생각했었다. 예를 들어 ‘스캔 인식의 정확도가 낮아요’라던가 ‘문장을 선택하는 부분이 불편해요’ 처럼 줄글 형태의 옵션 5-6개를 제공하는 방법을 고려했다. 하지만 문장 형태로 제공하면 일일이 읽는 것 자체로 번거로움이 커지고, 구체성이 있어 사용자 의견에 편향을 줄 수도 있다고 생각해 위와 같은 객관식 형태로 만들게 되었다.

(실제로 받은 건의함 의견들. 우리는 베타 기간동안 약 50건의 의견을 수집했다)

건의함을 사용하면 이렇게 간단하고 효율적으로 사용자의 생생한 피드백을 수집할 수 있지만, 여전히 인터뷰만큼의 깊이 있는 정보를 얻기는 힘들다. 따라서 건의함은 보조적인 수단 정도로 적합하다고 판단했고, 깊이 있는 인터뷰를 할 수 있는 다른 방법을 찾아야 했다.

[방법3] 클로즈 베타 테스트: 정성 피드백 풀 확보하기

그 다음 생각해낸 방법은 클로즈 베타 테스트(CBT)이다. 
클로즈 베타 테스트(CBT: Closed Beta Test)란, 신제품이나 신규 기능 공식 런칭 전 일부 사용자에게만 제한적으로 공개하고 피드백을 받는 테스트 단계를 말한다. CBT는 다양한 이점이 있지만, 그 중 초기 프로덕트 팀이 정성 피드백을 수집할 수 있는 좋은 경로가 되기도 한다.

CBT를 통해 모집한 테스터들은 일정 기간 동안 서비스의 베타 버전을 사용한 뒤, 메이커에게 사용 경험을 공유한다. 이 과정에서 건의함에서는 부족했던 깊이 있는 정성 데이터를 수집할 수 있다. CBT를 통해 VoC를 수집할 때 다음과 같은 이점이 있다. 

1. 자연스러운 인터뷰 요청과 높은 수용성

위에서 말한 회원가입 방식과 달리, 사용자들이 자발적으로 참여한 베타 테스트라는 점에서 자연스럽게 인터뷰를 요청할 수 있다. 또 베타 테스터 참여자로서 해야 할 하나의 의무라는 인식을 주어 인터뷰 참여도를 높일 수 있다.

2. 빠르고 밀도 높은 피드백 루프

소수의 사용자와 가깝게, 반복적으로 소통할 수 있어 피드백 주기가 짧고 '제품 개선 → 피드백' 이터레이션의 선순환이 가능하다.

3. 깊이 있는 사용 경험 탐구

유저 인터뷰를 통해 건의함 데이터만으로는 부족했던 Why와 How를 구체화할 수 있다. 특히 베타 테스터라는 점에서 우리 서비스에 관심도가 높은 사용자들이기 때문에, 적극적인 피드백으로 사용 경험을 더 심층적으로 분석할 수 있다.

4. 초기 사용자 확보

베타 테스터 모집 그 자체로도 홍보 효과를 얻을 수 있다. 초기 베타 테스터로 참여한 사용자와 지속적인 피드백을 주고 받으면서, 단순 유저에서 공동 제작자의 인식을 심어줄 수 있다. 그렇게 피드백 루프를 확보하면서 충성도 높은 초기 유저를 만들 수 있다. 

단 CBT는 적지 않은 리소스를 들여야 한다는 단점이 있다. 하지만 개인적으로는 제대로 된 정성 데이터를 수집하는 데 그정도의 리소스를 투입하는 건 낭비가 아니라고 생각한다. 그만큼의 이점이 크기 때문이다.

그렇게 우리는 지금까지 건의함 + CBT 인터뷰 데이터를 바탕으로 서비스를 개선 중에 있고, 특히 CBT를 통해 유의미한 정성 데이터를 많이 얻을 수 있었다.

초기 정성 데이터를 수집해 나가는 과정은 북카이브에게 단순 태스크가 아닌, 제품의 정체성을 찾아가는 여정인 것 같다. 아마 많은 초기 프로젝트나 스타트업도 마찬가지이지 않을까 싶다. 정성 데이터를 수집할 수 있는 다양한 경로가 있겠지만, 결국 각자의 제품과 팀에 맞는 방식을 찾아가야 한다. 우리는 앞으로도 어떻게 우리만의 방식으로 사용자와 더 가까워질 수 있을지 다양한 방법을 고민하고 실험해 볼 예정이다!

자세한 CBT 이야기는 다음 글에서 계속 >>

북카이브 첫 UT 2탄: 5명이어도 괜찮은 이유

1탄 👉 북카이브 첫 UT: 설계부터 진행까지

[UT 결과 1] 기록 과정, 보완이 필요하다 

먼저 UT로 얻은 인사이트는 두 가지가 있다.

첫째는 5명을 대상으로 UT의 목적이었던 기록의 간편함을 테스트한 결과, 보완이 필요하다는 결론이었다.

가장 큰 문제는 텍스트 인식 정확도가 낮다는 점이었다. 정확도가 낮으니 문장 선택 단계에서 원문장과 형태가 다르게 나오고, 그러다보니 사용자들이 저장하고자 하는 부분을 찾는 데 시간이 걸렸다. 또 형태가 다르니 다음 단계에서 문장을 수정하는 데도 꽤 긴 시간이 걸린다는 걸 발견했다.

영역 지정 UX를 통해 문장을 찾은 부분은 어느정도 보완했지만 여전히 인식 정확도를 높이는 문제는 기술적으로 한계가 있었다.

또한 인식 정확도의 문제뿐만 아니라 다양한 유즈 케이스로 인한 문제도 있었다. 현재는 온점 단위, 즉 한 문장씩 선택이 가능하다. 하지만 UT 결과 문장의 중간 부분만 저장하는 등, 문장을 기록하는 데는 생각보다 여러 케이스가 있다는 걸 알게 되었다.

이런 문제들을 발견하면서, 점점 근본적으로 문장단위 리스트로 보여주는 형태가 정말 편한 것일까 하는 의문이 들었고, 다른 방식으로 바꾸는 게 맞을지 많은 고민을 했다. 결론적으로 우선 그대로 가져가기로 했는데, 그 이유는 두번째 발견과 연결된다.

[UT 결과 2] 우리는 ‘비문학파’를 타겟으로 한다 

이번 UT의 가장 큰 수확은 북카이브의 뾰족한 타겟을 찾을 수 있었다는 것이다. UT를 진행하며 사용자들의 특성을 분석한 결과 두 가지 부류로 나뉘어진다는 걸 알게 되었다. 우리는 그 부류를 ‘문학파’와 ‘비문학파’로 나눴다. 

문학파 (5명 중 3명)

[특징 1] 시나 소설 등 문학을 주로 즐겨 읽는다

[특징 2] 문장 수집 목적: 오래 기억하기 위함

[특징 3] 감성, 심미성이 중요하다

[특징 4] 체계적인 정리나 분류가 중요하지 않다

이들은 공통적으로 시나 소설에서 읽은 인상 깊은 구절을 오래 기억하기 위해 기록하고 수집한다.

기억과 간직이 주 목적이다 보니 이를 체계화해서 꺼내 쓸 수 있게 활용하고자 하는 욕구가 적고, 정리나 분류 대신 서비스 자체의 심미적인 요소나 감성이 중요한 편이다.

- “홈 화면에 디자인적 요소가 더 있으면 좋겠어요”
- “아카이브 상세 화면에서 배경 이미지를 바꿀 수 있으면 좋겠어요.”
- “그 문장을 읽었을 때의 감정을 기억하기 위해 당시 책이나 주변 사진을 찍어둬요”

[특징 5]SNS를 통해 타인과 문장을 공유하고 소통하는 것을 즐긴다

- “인스타그램 스토리에 올리면 ‘아 이 친구들도 내가 올린 문장이 좋았구나’를 느낄 때 기분이 좋아요”
- “감명 받았던 문구들을 다른 사람과 공유하는 게 좋아요”

[특징 6] 북카이브의 기록 과정에 불편함을 더 크게 느꼈다

문학파의 경우 문장을 저장하는 과정에서 다른 사람들보다 불편함을 더 크게 느꼈다. 왜일까?

이들에게는 문장을 나중에 “꺼내 써서 활용”하는 것보다, 그 “기록” 행위 자체가 목적이다. 따라서 기존 독서 서비스와 비교했을 때 기록의 간편함에 대한 기대 수준이 훨씬 높다.

즉 정리해보면, 이들은 전형적인 기존 독서 서비스의 타겟이라고 볼 수 있다. 

비문학파 (5명 중 2명)

[특징 1] 비문학을 주로 즐겨 읽는다 (인문학, 사회과학, 자기계발서, 업무 관련..)

[특징 2] 문장 수집 목적: 실생활에서의 문제 해결을 위해 (자기계발, 커리어개발 등..)

[특징 3] 체계적인 분류와 정리에 니즈가 있다

[특징 4] 나만의 지식 데이터베이스를 구축하고, 관리하고, 실제고 꺼내 쓰고싶어 한다

[특징 5] 문학파에 비해 북카이브 기록 과정에 불편함을 덜 느낀다

[특징 6] 북카이브의 태그 분류, AI 찾기에 긍정적인 반응을 보인다

비문학파는 감성이나 오락 보다는 ‘정보 수집’이 목적이다. 그래서 이들에게 심미적 요소보다는 체계성이 더 중요하다. 단지 기억에서 끝나지 않고 그 정보를 필요할 때 꺼내 쓸 수 있어야 하기 때문에, 다시 찾아보기 편리하도록 체계적으로 분류하고 관리하고자 한다.

또 이들은 북카이브로 기록하는 과정에 불편함을 크게 느끼지 않는다. 이들에게는 기록도 기록이지만, 정리와 분류가 더 골치 아픈 문제이기 때문에 현재 북카이브의 기록 단계에 어느정도 만족한다는 걸 알 수 있었다.

이런 특성을 가진 비문학파가 북카이브가 추구하는 방향성에 더 적합하다고 생각했고, 이들을 뾰족한 타겟으로 잡고 가기로 했다.

그래서 그 비문학파가 누군데?

비문학파를 타겟으로 잡았으니, 구체적으로 이들의 특성을 정의해 유사한 사람들을 더 찾아보기로 했다. 우리가 정의한 비문학파는 다음과 같다.

- 비문학을 즐겨읽고
- 커리어 개발에 특히 니즈가 있는
- 성장 욕구가 높은 2030 직장인!

일상 속 고민(육아나 인간관계 등..)을 해결하기 위한 경우도 포함이지만, 우선 커리어개발 니즈가 높은 사람들이 북카이브의 활성 사용자가 될 가능성이 더 크다고 생각했다. 업무와 관련된 ‘책임’의 영역이기 때문에 정보와 인사이트를 수집하고 잘 활용하고자 하는 니즈가 더욱 강할 것이라는 가설을 세웠다.

이들은 다시 말해 “커리어 관련 정보를 많이 수집하고 활용하고자 하는 갓생러”라고 볼 수 있다.

꼭 책이 아니더라도 서핏이나 롱블랙 등의 뉴스레터나 아티클을 즐겨 읽는, 커리어 개발에 진심인 모든 사람들이 타겟이 되고, 우린 이들을 찾아 북카이브로 데려오는 것이 목표이다.

그 사람들이 느끼는 문제는 뭔데?

이들이 겪는 주요 문제를 한마디로 정리하면, 독서 인사이트를 넣고 꺼내는 문제, 즉 input과 output이 어렵다는 것이다. 

Input 문제 (넣기)  

• 타이핑해서 기록하는 게 번거롭다

• 특정 키워드/폴더로 분류할 때 이 구절은 어디에 넣어야 할지 고민된다

• 기록이 흩어져 있고 정리가 잘 되지 않는다

Output 문제 (꺼내쓰기)  

• 필요한 상황에서 필요한 구절을 빠르게 찾아 활용하고 싶다

• 하지만 현재 구조는 빠르게 찾아 활용할 수 있는 구조가 아니다

• 그리고 그걸 어떤 형태로 구조화해야 좋을지 모르겠다

비문학파는 책에서 얻은 인사이트(구절)를 편하게 넣고, 필요할 때 바로 꺼내 활용하고 싶어하는 니즈가 있다. 하지만 현재 그들의 정리 형태는 빠르게 찾아 꺼내 쓰기에 적합한 구조가 아니고, 그런 ‘적합한 구조’를 찾는 데 어려움을 겪고 있다. 너무 체계화를 하자니 복잡해지고, 단순화를 하자니 정보가 흩어지는 느낌이기 때문이다. 따라서 북카이브가 이 문제를 해결해주는 것이 중요하다.

이제 앞으로 해야 할 일은?

UT 결과와 비문학파가 느끼는 문제를 종합적으로 정리해 앞으로의 방향성을 잡았다. 크게 두가지로 요약할 수 있다. 

북카이브에 적합한 분류 체계를 찾자

비문학파가 느끼는 가장 큰 문제인 인풋과 아웃풋의 문제를 해결하는 것이다. 그래서 적절한 뎁스로 복잡하지 않으면서, 빠르게 필요한 정보를 꺼낼 수 있는 분류 형태를 찾아가는 게 중요하다. 이를 위해 우리는 더 많은 비문학파를 만나보면서 구체적으로 니즈를 파악하고 다른 비문학파 사용자의 특성도 확인해야 한다.

앞서 ‘문학파’는 기존의 다른 독서 서비스의 전형적인 타겟이라고 했다. 이 서비스들의 특징은 보통 읽은 책 자체를 기록하고, 추가로 구절을 기록하는 형식이다. 게이미피케이션으로 독서를 장려하거나 시각적으로 성취감을 주고, 읽은 책들을 트래킹할 수 있다.

하지만 북카이브는 다른 컨셉으로 가기로 했다. 우리는 ‘책’ 기준이 아니라 ‘인사이트’를 기준으로 가는 것. 그래서 현재 북카이브에서는 다른 서비스와 달리 책이라는 시각적 형상을 볼 수 없는 이유이다.

우리는 단순히 책을 많이 읽는 것을 장려하는 서비스가 아니라, 그 책에서 얻은 인사이트들을 잘 정리해 묵혀두지 않고 써먹을 수 있도록 도와주는 인사이트 창고와 같은 포지셔닝으로 가기로 했다.

기록 인식 정확도를 개선하자

팀원들과 논의 결과, 기록 방식 자체를 바꾸기 보다 현재 방식에서 약간의 개선 정도로만 가자는 결론이 나왔다. 주요 타겟인 비문학파가 현재 북카이브의 기록 방식에 큰 불편함을 느끼지 않았기 때문이기도 하고, 기록 방식 자체를 바꾸려면 기획 및 디자인적인 고민과 개발 리소스가 많이 필요하기 때문이었다. 이런 이유로 우리는 인풋보다는 아웃풋(분류) 솔루션의 우선순위를 높여 가기로 했다.

비문학파가 북카이브의 기록 방식에 큰 불편함을 느끼지는 않았지만 인식 정확도 측면에서의 개선은 여전히 필요했고, 개발측에서 가능한 수준까지는 인식 성능을 높여 불편함을 최소화하는 게 중요했다.

(다행히 성능 개선 작업을 거친 뒤, 현재는 이전에 비해 인식 정확도가 눈에 띄게 높아졌다! 물론 아직 보완해야 할 부분도 많고 기술 자체의 한계로 인한 문제도 있지만, 이전에 비해 인식 정확도로 인한 불편함을 크게 호소하는 사용자들은 많이 줄었다.)

5명이라는 적은 인원으로 진행한다는 점에서 걱정이 없었다면 거짓말이다. 처음에는 너무 인원이 적은 게 아닌지, 이 결과가 신뢰할 만한 지표가 될 수 있을지 의문이 있었다. 하지만 <고작 다섯명이 한 말을 어떻게 믿어요> 책에서도 말했듯, 정성 데이터는 ‘양’보다 ‘깊이’가 중요하다.

이번 UT를 통해 확실히 체감할 수 있었다. 적은 인원이었지만 그만큼 깊이 있는 조사를 진행했고, 단순 사용성을 테스트를 넘어서 북카이브 가치 자체에 대한 사용자의 구체적인 생각을 들을 수 있었다. 깊이 있게 파고드니 패턴이 보였고, 뾰족한 타겟을 설정할 수 있었다.

물론 앞으로 검증을 더 거쳐야 겠지만, 소수를 대상으로 한 리서치로도 가치있는 인사이트를 얻을 수 있다는 걸 느낀 좋은 기회였다!

북카이브 첫 UT: 설계부터 진행까지

유저 인터뷰 진행 후 얻은 인사이트를 바탕으로 MVP 구축을 거의 완료해 갈 무렵, 기획단에서는 PO님과 함께 UT를 진행했다. 결론부터 말하자면 이번 UT는 매우 유의미한 정보를 얻을 수 있었고, 추후 로드맵 설정에 좋은 이정표가 되었다. 이번 글에서는 UT를 어떤 과정을 거쳐 준비하고 진행했는지 공유해보려 한다.

[UT 준비]

이번 UT, 왜 진행하는걸까?

본격적인 마케팅 홍보에 앞서 확실히 해두고 싶은 것이 있었다. 바로 북카이브의 핵심 가치가 ‘쓸 만한 수준인가’를 확인하는 것. 마케팅에는 적지 않은 리소스가 투입되기 때문에, 그 전 우리 서비스가 최소한의 가치를 전달하는 수준인가를 알고 싶었다.

이번 UT에서는 세 가지를 확인하는 것이 목표였다.   

- 메인) 기록하는 과정이 만족스러운가
- 서브) 태그로 분류 및 정리되는 형태가 만족스러운가
- 서브) AI 검색 기능은 만족스러운가

여기서 가장 메인이 되는 건 첫 번째였다. 분류나 AI 찾기는 서비스를 여러 번 사용하고 기록이 충분히 쌓였을 때 제대로 활용이 가능하기 때문에 1회성에 그치는 UT에서는 정확히 파악하기가 어렵다고 판단헀다. 그래서 이번 UT에서는 기록 과정의 간편함을 확인하는 데 집중했다.

누구를 대상으로 할 것인가?

UT 대상자는 유의미한 인사이트를 얻을 수 있는, 북카이브에 적합한 타겟으로 설정했다.

참여자 선정 기준은 다음과 같다.   

- 한 달에 한 권이상 독서를 하는 사람
- 한 책에서 평균 10개 이상의 구절을 기록하는 사람
- 책을 읽는 목적이 정보를 얻고, 그 정보를 바탕으로 나의 행동변화/커리어개발/자기 계발 중 하나 이상인 사람

우리 서비스는 독서 문장을 기록하고 활용하는 걸 도와주는 서비스이기 때문에, 단순히 책을 많이 읽고 기록을 많이 하는 것만으로는 충분하지 않았다. 책에서 인사이트를 얻고자 하는 확실한 목표가 있고, 저장한 기록을 다시 찾아 꺼내 쓸 니즈가 있는 사람이 필요했다.

테스터 모집: 적합한 타겟인지 확인하기

목표 인원은 최소 5명이었다. 테스터는 유저 인터뷰에 참여해주셨던 분들과 에브리타임 커뮤니티를 통해 모집했다. UT는 대면으로 인터뷰보다 더 긴 시간 진행될 예정이었기 때문에 커피 기프트카드를 사례로 걸고 모집했다.

이전 인터뷰에서의 회고를 바탕으로, 이번에는 일정 확정 전 간단한 스크리닝 질문을 통해 적합한 대상인지 먼저 확인했다. 위에서 정한 세 가지 기준에 부합하는 확인한 후 UT 일정을 확정했다.

테스트 설계: 무엇을 확인할 것인가?

UT는 태스크 시나리오 기반으로 설계했고, 크게 사전 질문, 태스크 수행, 후속 질문 세 섹션으로 구성했다. 태스크는 총 3개로, 다음을 확인하는 활동이었다.   

태스크: 사용자가 기존에 사용하던 방식으로 기록 vs 북카이브로 문장을 기록 → 두 방식을 비교
(참여자에게는 사전에 책 한 권과 기록하고 싶은 구절 두 가지를 준비해 오도록 요청했다.)

UT의 목적이 북카이브 기록의 간편함을 확인하는 것이었기 때문에, 기록하는 데 걸리는 시간을 측정하려 했다. 하지만 소요 시간이 짧다고 해서 반드시 간편하다고 보기는 어렵다고 판단해, 간편함에 대한 주관적 인식을 5점 척도로 함께 평가하는 정성 지표도 함께 활용했다.

[UT 진행]

사전 질문: 유저 이해하기

테스트를 시작하기 전, 팀 소개와 리서치 관련 안내를 드리고 사전 질문을 통해 사용자의 기본 정보와 독서 관련 기본 습관을 파악했다.

사전 질문으로는 나이와 직업같은 기본정보와 함께 다음과 같은 내용을 포함했다   

- 책을 읽는 빈도
- 문장을 기록하는 빈도
- 문장 기록을 하는 이유
- 책을 읽는 목적
- 기록한 내용을 활용하려고 했던 경험 등

스크리닝을 통해 타겟에 맞는 사람인지 간단하게 확인했지만, 사전 질문을 통해 더 구체적으로 평소 습관이나 행동, 관점을 파악하고자 했다.

둘러보기: 서비스 첫인상 파악하기

본격적인 태스크 진행 전, 북카이브 첫인상을 확인했다. 먼저 아무런 조작을 하지 않은 상태에서 홈 화면을 보고 드는 느낌이나 생각, 가장 시선이 가는 부분에 대해 물었다. 그 다음에는 자유롭게 서비스를 둘러보며 전반적인 인상이나 궁금한 점을 공유해달라고 요청했다.

‘둘러보기’를 통해 사용자가 북카이브를 처음에 어떻게 인식하는지를 알 수 있었다.   

- "책 중심이 아니어서 저랑은 맞지 않을 것 같다는 느낌이 드네요"
- "태그로 정리되는 게 좋아 보여요"
- "현재는 태그만 있고 구절이 리스트로 쭉 나열되어 있어 조금 평면적인 느낌이 드네요. 분류가 조금 더 입체적이면 좋겠다는 생각이 들어요."
- "보자마자 태그 분류 부분이 가장 관심이 갔어요. 평소에도 이걸 어떻게 시스템화하고 분류할지에 대한 생각이 많은 편이라서 눈길이 간 것 같아요."

이러한 첫인상 피드백은 유저가 우리 서비스를 어떻게 이해하고 있는지, 의도한 대로 인지하는지, 어느 부분에 관심을 갖는지(어떤 기대를 가지고 있는지) 등을 확인하는 데 도움이 되었다.

태스크 사전 안내: 날 것의 반응 끌어내기

태스크에 들어가기 앞서, 태스크에 관련해 안내를 드렸다.   

1. 자연스러운 사용과 솔직한 피드백 요청

- 사용자 평가가 아니라 서비스 평가가 목적임을 강조

”참여자님이 얼마나 저희 서비스를 잘 사용하시는지를 보는 것이 아닌, 저희 서비스가 정말 쓰기 편한지를 확인하는 것이니, 편안하게 써보시면 됩니다.” 

- 자연스러운 사용 유도
”평소대로 저희가 여기 없고 집에서 혼자 사용하고 있다고 상상하시면서 편하게 써주시면 돼요.” 

- 솔직한 피드백 요청 
”무엇보다 솔직한 의견 부탁드릴게요. 부정적인 의견이 저희에게 더욱 도움이 되니, 솔직하게 공유해주시면 감사하겠습니다.”  

특히 부정적 피드백의 경우, 이렇게 말씀을 드려도 에둘러 말하거나 긍정적으로 포장하려는 경우가 많았다. 그래서 우리는 일부러 과장(?)해서 ‘0점 주셔도 되니 솔직한 답변 부탁드려요’라고 솔직한 피드백을 강조했다.

2. Think-aloud 요청

Think aloud는 서비스를 사용하면서 보고 있는 것이나 드는 생각, 느낌을 입 밖으로 표현하는 것이다. 비언어적인 행동만으로는 파악이 어려운 경우에 사용자의 생각을 파악할 수 있다.

UT 사용자 모두에게 Think aloud를 요청드렸는데, 아무래도 혼잣말을 하는 게 어색하다 보니 한 두분 빼고는 적극적으로 해주시는 분은 없었다. 그럴 땐 중간중간 어떤 부분을 보고 계신지, 어떤 생각을 하고 계신지 질문하며 확인할 수도 있다.

실제로 이 Think aloud에 굉장히 적극적으로 참여해주신 분이 있는데, 확실히 사용자 생각의 흐름이나 관점을 파악하는 데 도움이 되었다.   

(실제 UT 중 사용자의 Think aloud)

“스캔이 완벽하지 않네..문장 당연히 수정할 수 있겠지?”
“아 인식할 때 들여쓰기 반영이 안되네!! 들여쓰기 중요한데..!!”
“오 태그명이 딱 내가 생각한 대로 추천되네 좋다”

3. 녹화 안내

마지막으로는 영상 녹화 안내를 드렸다. 서비스를 사용하는 손과 폰 화면 위주로 영상 녹화를 할 것임을 설명하고 미리 양해를 구했다.

첫 번째 태스크: 북카이브로 처음 기록해보기

첫 번째 태스크는 북카이브를 이용해 준비해온 구절 중 하나를 기록하는 것이었다. 이 때는 동작 방법을 알려주지 않은 상태에서 사용자가 직접 탐색하며 사용하도록 했다.

이 태스크에서는 다음과 같은 항목을 주의깊게 관찰했다.   

- 사용자가 헤매는 부분이 있는지, 있다면 어느 부분인지
- 어디를 터치하는지, 잘못된 부분을 클릭하지는 않는지
- 태그를 어떤 식으로 설정하는지

이 첫 번째 태스크는 사용자가 북카이브를 처음 사용하는 단계이므로, 날 것 그대로의 사용성 문제를 확인할 수 있다. 관찰 뒤에는 어려움이나 불편함은 없었는지 첫 북카이브 기록 경험에 대해 질문했다.

두 번째 태스크: 기존 방식대로 기록해보기

이번에는 북카이브가 아닌 유저가 기존에 사용하던 방식대로 다른 구절을 기록하는 것이었다. 컴퓨터로 기록하는 사람, 아이패드에 수기로 작성하는 사람, 다른 앱 서비스를 사용하는 사람 등 다양한 방식을 볼 수 있었다.

이 때는 다음을 중점적으로 관찰했다.   

- 어떤 내용들을 어떤 형태로 기록하는지
- 전체적인 기록 과정과 순서

이후에는 분류 및 정리 방식, 기존 방식에서의 어려움 등에 대해 구체적으로 질문했다.

세 번째 태스크: 사용법 학습 후 북카이브 다시 써보기

마지막으로는 두 번째 태스크에서 사용한 같은 구절을 북카이브를 이용해 다시 한 번 기록하도록 했다. 목적은 기능 동작에 숙지가 된 상태, 즉 미숙 변수가 제거된 상태에서 어떻게 사용하는지를 확인하는 것이었다.

여기서는 첫 번째 태스크에서 어려워 했던 부분을 잘 학습하고 이용하는지, 혹은 여전히 어려움을 겪는지를 위주로 관찰했다.

태스크 진행 시 고려해야 할 점

태스크를 진행하면서 유저들의 실제 생각과 경험을 최대한 그대로 파악하기 위해 다음과 같은 사항들을 신경 썼다.

1. 세심하게 관찰하기

UT의 가장 기본이 아닐까 싶다. 사용자의 어투나 표정, 손가락의 움직임 등 언어적/비언어적 행동을 세심하게 관찰하는 것이 중요하다.

우리 팀은 진행자와 서기로 역할을 분담했는데, 진행자가 유저와 이야기하며 놓칠 수 있는 부분을 서기가 집중적으로 관찰했다. 진행자는 사용자와 마주보고 앉아 원활히 이야기할 수 있도록 하고, 서기는 사용자 옆 자리에 앉아 서비스를 사용하는 모습을 가까이서 관찰했다.

(실제 관찰하며 적은 기록들)

2. 중간중간 질문하기

만약 사용자가 멈칫거리거나 생각하는 모습을 보인다면 ‘지금 무슨 생각을 하고 계세요?’라고 질문해볼 수 있다. 또는 사용자의 특정 언어적/비언어적 행동을 보고 이유를 물어봄으로써 서비스 사용 과정 속 생생한 느낌을 확인할 수 있다.   

사례 1

     사용자: (아카이브 상세 화면을 보며) 오..ㅎㅎ

인터뷰어: 방금 ‘오..ㅎㅎ’하며 살짝 웃으셨는데, 어떤 것 때문에 그러셨을까요?

     사용자: 아 감성 자극하는 UI여서 살짝 좋았어요. 저는 다시 봤을 때 마음에 드는 게 중요한 사람이어서요. 그래서 필사 템플릿을 쓰고 있기도 하구요. 배경 색이나 이미지를 바꿀 수 있으면 더 좋을 것 같아요.

사례 2

사용자: (구절 스캔 후 태그를 고를 때 살짜 머뭇거림)

인터뷰어: 아까 태그 고르실 때 머뭇거리시던데, 어떤 이유였을까요?

     사용자: 아..태그가 많으면 애매하고 귀찮겠구나 라는 생각이 순간 들어서 그랬던 것 같아요

3. 사용자 질문에 역질문하기

사용자가 “이건 어떻게 해요?” 혹은 “이건 뭐예요?” 등의 질문을 하는 경우가 있다. 이 때는 바로 답을 알려주지 않고 ‘어떻게 생각하세요?’ / ‘지금 혼자 계시다면 어떻게 하시겠어요?’로 역질문을 한다. 이렇게 하면 단순히 ‘아 이 부분이 이해가 어렵구나’라는 피상적 발견을 넘어, ‘사용자는 이걸 이렇게 이해하네, 이런 이유 때문에 그런 오해가 생기는구나’ 처럼 더 구체적인 문제를 파악할 수 있다.   

사례

사용자: 전체 태그랑 연관 태그는 어떻게 다른 거예요?

나: 어떻게 다른 것 같다고 생각하세요?

사용자: 음..연관은 AI가 추천해주는 거고 전체 태그는 내가 만든 건가요?

나: 네 맞아요. 어떤 점이 헷갈리셨어요?

사용자: 단어가 조금 헷갈려서 그런 것 같아요. AI가 추천해준다라는 느낌이 잘 안 느껴지는 것 같기도 해요.

후속 질문: 종합적인 경험 평가하기

태스크를 완료한 후에는 북카이브 전체적인 사용 경험에 대한 후속 질문을 했다. 기존 방식과 비교했을 때 얼마나 간편하다고 느끼는지 5점 척도로 점수를 매겨달라고 요청했고, 그 점수를 준 이유에 대해 물었다.

만약 3점이라면 왜 3점인지, 나머지 2점을 주지 않은 이유는 어떤 이유인지 구체적으로 질문해, 서비스에 대한 사용자의 경험과 기대를 더 명확하게 파악했다.

[UT 이후]

UT 결과 정리: 개발자와 경험 공유하기

UT 결과 정리하기

UT가 끝난 후에는 바로바로 노션에 결과를 정리했다. 처음에는 현장에서 로우 데이터처럼 작성하고, 이후 그날 서기 담당이 주요 내용을 다시 정리했다.

유저의 기본 정보, 기존 기록 방식, 북카이브 핵심 가치에 대한 반응과 니즈, 그리고 기타 사용성 문제를 각각 섹션별로 정리하고 핵심 니즈를 요약했다.

개발자와의 얼라인

UT 과정에서 중요하게 생각했던 또 하나는 개발자 분들과의 공감대 형성이었다. PO님과 나는 직접 UT를 진행하며 유저의 반응을 생생하게 경험했지만, 개발자분들은 그만큼 체감하기 어렵기 때문이다.

따라서 맥락을 효과적으로 공유하고 개발자들도 유저 경험에 공감할 수 있도록 하기 위해 녹화한 UT 영상의 주요 부분을 편집해 짧은 클립으로 만들어 공유했다. 텍스트가 아닌 영상으로 공유하니, 실제로 개발자분들도 유저의 실제 사용 모습을 볼 수 있어 더 와닿고 이해가 잘 된다는 피드백을 주셨다.

이렇게 결과를 공유하는 건 얼라인에도 좋지만, 사용자를 직접 만나기 어려운 개발자 분들의 동기 부여에도 효과적이라는 걸 많이 느꼈다.

(일정 잡는 것부터 쉽지 않았던...)

UT를 일주일 내로 완료하는 것이 목표였어서 하루에 두 분을 진행하기도 했는데, 지역이 모두 멀어 체력적으로 굉장히 지쳤던 기억이 난다.. 그렇지만 사용자들이 서비스를 사용하는 모습을 보고 우리가 예상하지 못했던 점들을 하나씩 발견해 나가는 즐거움은 어떤 피로감보다 값진 경험이었다. UT가 끝날 때마다 PO님과 머리 싸매며 고민했던 게 지금도 생생하게 떠오른다 ㅎㅎ

5명이라는 적은 모수를 대상으로 진행한 UT였지만, 인사이트를 정리한 결과 굉장히 유의미한 발견을 할 수 있었다. 크고 작은 사용성 문제 발견부터 북카이브 방향성을 다시 확실히 할 수 있었던 기회였다.

과연 어떤 발견을 하게 되었는지는 다음 글에서 계속! >>

출처

[UX리서치/UXR] 정성 사용성 평가(UT/Usability Testing) :: 정성스럽게 태스크 시나리오 준비하기

[UX리서치/UXR] 사용성 테스트(UT), 참여자에게 꼭! 전달해야 할 7가지 정보

[UX리서치/UXR] UT 중, 사용자가 나에게 질문을 했다.. 진행자의 대답은..?

<고작 다섯 명이 한 말을 어떻게 믿어요?> 송라영 저