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

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 중, 사용자가 나에게 질문을 했다.. 진행자의 대답은..?

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

유저 인터뷰: 진짜 인사이트를 끌어내는 '잘 질문하는 법'

인터뷰에서 진짜 니즈를 찾는 데 가장 중요한 건 ‘잘 질문하는 것’이다.

인터뷰를 준비하면서 잘 질문하는 법을 배우고자 유저 리서치 관련 도서인 <유저 인터뷰 교과서>와 <고작 다섯 명이 한 말을 어떻게 믿어요?> 를 읽었고, 두 책의 도움을 굉장히 많이 받았다. 이 책에서 말하는 잘 질문하는 방법을 바탕으로 실제 북카이브 인터뷰에서는 어떻게 질문했는지 사례와 함께 이야기해보려 한다.

인터뷰 진행

역할 분담

북카이브 유저 인터뷰는 PO님과 둘이서 참여했다. 우리는 메인 진행자와 서기 담당을 나눠 역할을 분담했다. 서기는 최대한 유저가 말한 그대로 로우 데이터 형태로 기록하고, 마지막에 궁금한 점이 있으면 몇 가지 질문을 던지기도 했다. 이렇게 하면 진행자는 유저와의 대화에 더 집중할 수 있고, 인터뷰 내용은 더 정확하게 빠짐없이 기록할 수 있다.

유연하게 방향 잡기

<유저 인터뷰 교과서>에 따르면, 질문지는 대본이 아니라 체크리스트일 뿐이라고 한다. 질문지를 바탕으로 유저와 이야기 하되, 방향은 이야기 흐름에 따라 유동적으로 잡아 나가야 한다.

나도 유저 인터뷰를 처음 할 때 이런 실수를 했었다. 질문지에 적힌 순서대로 해야 한다는 이상한(?) 강박이 있어 오히려 대화 흐름이 자연스럽지 않았던 순간도 있었다. 질문지 순서에 상관 없이, 상황에 따라 뱡항을 유연하게 잡아 나가야 유저가 느끼기에도 자연스럽고 더 편한 대화가 가능하다.

잘 질문하기

‘상황 / 행동과 사고 / 요구나 기대’ 바탕으로 질문하기

유저의 맥락과 니즈를 구체적으로 이해하고, 추후 아이데이션까지 이어질 수 있게 하기 위해서는 상황 / 행동과 사고 / 요구나 기대 세 단계로 질문하는 것이 도움이 된다. 북카이브 인터뷰를 예를 들면 다음과 같다.

이런 흐름으로 보면 ‘이런 때에(상황) 이런 선택을 하고(행동과 사고) 이런 점에 불만을 느끼더라(요구나 기대)’의 흐름으로 사용자 니즈를 자세하게 파악할 수 있다.

최근 경험에 대해 묻기

답하기 어려운 추상적인 질문보다는 최근 경험에 기반한 질문으로 더 구체적인 답변을 얻을 수 있고 실제 사용자 행동 기반의 ‘진짜 니즈’를 파악할 수 있다.

북카이브는 사용자가 기존에 어떤 방식으로 독서 문장을 기록하는지, 그 과정에서 불편한 점은 없는지를 알아내는 질문이 있다. 이 때 ‘기존 방식으로 기록할 때 불편한 점 없으세요?’와 같은 질문은 듣는 유저에게 너무 광범위하게 들릴 수 있고, 어디서부터 어디까지 이야기해야 하는지 고민하게 될 수 있다. 그 대신 최근 경험에 기반해 질문하면 사용자는 자연스럽고 생생하게 경험을 떠올릴 수 있다.

혹은 기록하는 방식을 알려달라고 한 뒤, 그 과정을 단계별로 쪼개 각 단계에서 유저의 경험을 물어보는 방법도 있다. 이렇게 하면 더 구체적으로 니즈 발견이 가능하고, 사용자도 정해진 범위 내에서 더 쉽게 답할 수 있다.

실제 행동에 기반하기

기능 검증을 할 때는 ‘우리 이런 기능 있는데 어떄?’와 같은 돌직구 질문보다는 실제 유저의 행동을 묻는 것이 더 정확하다. 상대에게 직접적으로 ‘음 별로 필요 없을 것 같아요’라고 솔직하게 이야기하는 경우는 많지 않기 때문이다. 더군다나 실제 경험해보지 못한 상황에 대해 이야기해야 할 경우 답변이 긍정적으로 편향될 가능성이 더 높다. 따라서 유저의 실제 니즈를 파악하기 위해서는 그 유저의 과거 행동을 살펴보아야 한다.

AI 찾기 기능에 대한 니즈를 알아보기 위해, 근본적으로 사용자가 기록한 구절을 다시 찾아보고자 하는 욕구가 있는지 확인했다. 단 이 질문에 더해 구절을 다시 찾아본 경험이 있는지, 있다면 어떤 사고의 흐름을 거쳐 어떤 방식으로 찾아 보았는지, 그 과정에 불편한 지점이 있는지, 또는 찾아본 경험이 없다면 왜인지 등 구체적인 맥락을 파악할 필요가 있다.

준비된 질문보다 중요한 꼬리질문

미리 준비한 질문보다 답변에 대한 꼬리질문이 더 가치있는 인사이트를 이끌어 낼 때도 있다. 꼬리 질문은 표면적인 답변 속에 숨겨진 니즈를 발견할 수 있는 기회이기도 하다.

여기서 이 인터뷰이는 하나의 기록 안에서도 핵심과 핵심이 아닌 세부 사항을 구분해 보기를 원한다. 기존 북카이브에서는 구절들이 단순 줄글 형태로 나열되어 더 정리가 안 되어 보이고, 기억하기 어렵다고 느낀다는 것을 알 수 있었다. 첫번째 질문에서 멈췄다면 그저 ‘정리가 되어 보이지 않는다고 느낌’이라는 결론밖에 얻을 수 없었을 것이다. 그렇게 느낀 이유와 유저가 하는 말의 구체적인 의미를 깊게 물어보면서 더 근본적인 사용자의 니즈를 확인할 수 있다.

말하지 않은 부분도 캐치하기

인터뷰 중에는 유저가 언급하지는 않았지만 중요한 정보가 숨어있는 경우가 많다. 따라서 직접 말로 표현하지 않았더라도 사용자가 이전에 했던 답변들을 기반으로 포인트를 캐치해 질문하는 것이 필요하다.

이 질문을 통해 기록을 한 곳에 깔끔하게 정리해 보고 싶어하는 유저의 니즈를 알 수 있었다. 여기서 내가 물어보기 전까지, 유저는 기록이 흩어져 있어 보기가 불편하다는 것을 직접 이야기하지 않았다. 무의식적으로 느끼던 불편함일 수도 있고, 평소에 가끔 생각은 했으나 그 순간 기억이 나지 않았을 수도 있다. 혹은 불편하다고 느끼지 않았을 수도 있다.

인터뷰 내내 유저가 한 말들과 표현, 맥락을 잘 따라가는 게 중요한 이유이다. 말로 표현하지 않았어도 맥락 상 예상되는 불편한 포인트를 발견하면 유저에게 확인해볼 필요가 있다. 때로는 유저가 직접 언급한 것보다 더 중요한 인사이트가 될 수도 있다.

행동하지 않은 것도 파보기

유저와 이야기 하다 보면 무엇을 하고 싶고, 해야 한다고 생각은 하지만 행동으로 이어지지 않는 경우도 있다. 이처럼 행동을 하지 않았다는 사실 자체도 중요한 정보가 될 수 있으니 ‘왜’를 깊게 파 볼 필요가 있다.

나는 이 유저가 구절을 복기하고 활용하고자 하는 니즈는 있으나 일일이 찾아보는 ‘실행’의 과정이 어려운 것이라는 것을 알게 되었다. 그 행동을 하지 않은 이유에는 필요성을 못 느껴서일 수도 있지만, 그 과정에 꽤 큰 불편함이 있어서일 수도 있다. 따라서 유저가 그 행동을 하지 않았다고 해서 거기서 질문을 멈추지 말고, 왜 하지 않았는지 그 이유를 파고들어 보아야 한다.

폭넓은 답변을 위한 열린 질문

<유저 인터뷰 교과서> 저자는 “닫힌 질문으로는 사용하기 쉬운지에 대해서만 이야기할 수 있지만, 열린 질문을 이용하면 사용하면서 느낀 점에 관한 폭넓은 대답을 기대할 수 있다”라고 말한다. 물론 상황에 따라 닫힌 질문이 필요한 경우도 있지만, 우리 서비스의 특정 기능이나 사용성에 대해 확인하고 싶은 경우에는 열린 질문으로 더 딥한 답변을 이끌어내는 것이 중요하다.

난 AI 찾기 기능에 대해 사용자들이 유용하다고 느끼는지를 확인하고 싶었다. 단 이 유저처럼 해당 기능을 아직 사용해보지 않은 경우도 있다. 이 때는 사용 경험 대신 처음 봤을 때의 느낌을 위주로 물었다. 사용 전 첫 인상으로 사용자의 니즈나 기대를 파악할 수 있는 좋은 방법이기도 하다.

여기서 유저는 북카이브의 AI 찾기 기능이 다른 사람들의 기록들까지 같이 검색할 수 있는 기능이라고 오해했다. 즉 사용자가 기능의 용도를 헷갈려 할 수 있다는 문제를 발견했다. 또 해당 유저는 타 유저의 콘텐츠 열람에 니즈가 있다는 것을 알 수 있었다. 특히 이 분은 마케터이다 보니 업무를 할 때 다른 마케팅 사례들을 찾아 참고하고는 하는데, 이를 통해 유저의 직종에 따라서도 니즈가 달라질 수 있다는 걸 알게 되었다.

상대방이 사용하는 말과 표현에 집중하기

인터뷰를 하다 보면 사용자가 자주 언급하는 말이나 표현이 있다. 이 때 그 표현을 잘 염두에 두어야 하는데, 자주 쓰는 말은 사용자의 진짜 생각이나 문제 인식이 가장 자연스럽게 드러나기 때문이다. 우리의 편향된 해석이 아닌, 사용자들이 진짜 중요하게 여기는 포인트를 발견할 수 있다는 중요한 단서이다.

이 유저는 인터뷰 전반적으로 ‘서론, 본론, 결론’, ‘흐름’, ‘책의 요지’ 등에 대한 언급을 많이 했다. 그러다 마지막 대화를 보면, 사용자가 북카이브의 태그 기능을 의도와 다른 형태로 사용하고 있다는 걸 알게 되었다. 북카이브의 태그는 개별 구절들을 주제별(UX 디자인, 팀 빌딩, 육아 등..)로 분류하도록 의도했지만, 이 분은 책 이름으로 태그를 설정하고 계셨다.

그 이유가 자주 사용했던 표현인 ‘흐름’, ‘책 요지’와 연관되어 있을 것 같았고, 결과적으로 한 책에서 통합된 결론을 찾는 것을 중요시하는 사람이라는 걸 알 수 있었다. 즉 구절들을 개별로 보는 게 아니라, 같은 책의 구절끼리 모아 보며 그 흐름을 파악하길 원하는 것이었다. 이 인사이트는 이후 북카이브의 분류 형태와 관련해서 구체적으로 구상할 수 있었던 좋은 계기가 되었다 (이 내용에 대해서는 추후 더 자세하게 다룰 예정이다).

사용자가 반복적으로 언급하는 말이 있다면 인터뷰 중간중간 잘 표시해두어야 하는 이유이다. 유저가 자주 사용하는 단어나 표현 속에는 그 유저의 숨은 심리사 니즈를 발견할 수 있고, 이는 프로덕트 개선 방향에 중요한 키가 될 수도 있다.

이해한 게 맞는지 확인할 때는 솔직한 답변 요청하기

가끔 인터뷰 중 사용자 말이 정확히 이해가 안가거나 확인하고 싶을 때가 있다. 그때 우리는 종종 “~라는 말씀으로 이해했는데 맞을까요?” 라고 되물어 봤는데, 이 질문을 할 때는 주의할 점이 있다. 바로 상대는 동의가 쉽다는 점이다. 그냥 대체로 맞다는 점에서 그렇다고 답할 수도 있고, 흐름에 따라 무심코 맞다고 할 수도 있고, 다시 설명하기 귀찮아 그렇다고 할 수도 있다.

이 부분은 인터뷰할 때 미처 고려하지 못했는데, 은연중에 우리가 해석하고 싶은 대로 유저엑 되물었을 수 있겠다는 생각이 들었다. 이럴 때는 유도 질문을 방지하기 위해 서두에 ”이게 아니라면 솔직하게 말씀해주셨으면 하는데, 즉 ~~라는 말씀이신걸까요?“라고 솔직한 답변을 요청하는 게 필요하다.

유저 인터뷰에서 중요한 건 항상 머리에 ‘물음표’를 달고 있어야 한다. 준비된 질문만 하는 게 아니라 유저의 답변, 사용하는 단어와 표현, 말투와 표정 하나하나에 물음표를 던져 깊게 파고 들어야 한다.

사실 인터뷰 초반까지만 해도 준비된 질문만 하기에 급급했다. ‘잘 질문한다는 게 도대체 뭐지?’ 감이 잡히지 않았다. 하지만 이제 인터뷰를 여러번 진행하니 알겠다. 인터뷰는 ‘조사’가 아니라 ‘대화’를 한다고 생각해야 한다.

좋은 대화를 위해서는 잘 말하는 것만큼 잘 들어주는 것도 중요하다. 다시 말해 좋은 질문은 ‘잘 듣는 것’에서 온다. 상대가 하는 말을 표면적으로 듣는 게 아니라, 이 사람은 어떤 사람이고 어떤 맥락과 생각을 가지고 이런 말을 하는 건지 물음표를 달고 경청해야 한다. 그리고 바로 이 물음표를 바탕으로 한 질문이 유저의 진짜 니즈를 발견하는 의미 있는 인사이트로 이어진다.

[EP3] “책 좋아하세요? 그럼 인터뷰좀…”

개발팀이 MVP 개발에 박차를 가하는 동안 PO님과 유저 인터뷰를 진행했다. 북카이브에서 처음으로 사용자와 직접 이야기한 첫 인터뷰였는데, 이번글에서는 인터뷰 진행 과정과 그로부터 얻은 인사이트까지의 여정을 공유해보려 한다!

인터뷰 준비: “책 좋아하세요? 그럼 인터뷰 좀…”

1. 인터뷰 목적

우선 인터뷰의 목적은 ‘이거 정말 문제가 맞아?’를 검증하는 것이었다. 북카이브가 해결하고자 하는 문제 - 기록하는 과정이 번거롭고, 저장한 기록을 꺼내보고자 하는 니즈 - 가 다른 사람들도 느끼는 불편함인지 확인하고, 더 구체적인 페인 포인트를 발견하는 것이 목표였다.

1. 인터뷰 대상 선정

우리가 인터뷰이 타겟으로 삼은 유저 프로필은 다음과 같다.

• 2030 직장인

• 평소에 책을 자주 읽고, 좋아하는 사람

• 책 문장을 자주 기록하는 사람

사실 첫 인터뷰에서는 타겟 유저를 명확하게 잡지는 못했다. 그저 일단 독서 관련 서비스이고, 문장 기록 서비스이니 책을 좋아하고 문장을 기록하는 사람을 찾자!였다(꽤 단순했다…) 그 중에서도 추후 수익화를 고려해 돈을 내고 자기계발 서비스를 사용할 만한 여력이 있는 사람을 찾고자 했고, 2030 직장인을 대상으로 하게 되었다.

1. 인터뷰이 모집

(👆무작정 스레드에 댓글달기..)

목표로 한 인터뷰이 수는 10명이었다. 지인에게 부탁하기도 했고, 나는 스레드에서 인터뷰이를 구하기도 했다. 스레드에는 독서러버가 많아 그런 분들의 스레드에 무작정(..) 댓글을 달아 인터뷰를 요청했다(감사하게도 댓글 단 7명 중 2분이 인터뷰에 응해주셨다!) 이렇게 인터뷰이를 모집한 결과 15명의 유저를 모을 수 있었다.

✏️ 모집 과정에서 회고를 해본다면..

아쉬웠던 점은 예상 타겟 유저를 더 구체적으로 잡고, 스크리닝 질문을 했어야 했다는 것이다. 인터뷰를 하다 보니 타겟에 적합하지 않은 사람들이 몇 있었다. 인터뷰 하나하나에는 생각보다 많은 리소스가 들기 때문에, 다음 인터뷰에서는 유저 프로필을 명확하게 설정하고 이를 사전에 확인할 수 있는 스크리닝 질문으로 유의미한 인터뷰를 진행하는 것이 필요하다고 느꼈다.

질문지 설계: 뭘 확인해야 할까?

질문지는 우리가 알고 싶은 화제별로 크게 네 가지 섹션으로 구성했다.

(👆우리가 썼던 유저 인터뷰 템플릿)

기본 질문

나이, 직업과 같은 기본 정보와 독서 습관에 대한 질문을 포함했다. 책을 얼마나 자주 읽는지, 어떤 장르를 즐겨 읽는지, 책을 읽는 이유 등에 대한 질문을 통해 인터뷰이의 독서 행태를 파악하고자 했다.

기록 관련 질문

기록 섹션에서는 어떤 목적으로 문장을 기록하고 무엇을 얻고자 하는지 기록의 이유에 대해 확인하고자 했다. 또 기록하는 방식과 형태를 파악해 행동 패턴과 북카이브 솔루션의 한계를 파악하고자 했다
(+ 여기서 우리는 실제 기록한 것을 보여주실 수 있는지 여쭤봤다. 말로만 듣는 것보다 실제로 보니 더 확실하게 와닿고 인사이트를 뽑아내는 데 도움이 많이 되었다!)

복기 및 활용

이 섹션에서는 복기나 활용에 대한 니즈의 유무를 확인하고 싶었다. 기록한 것을 다시 보거나 활용하려고 한 적이 있는지에 대한 경험을 물어 북카이브의 가설을 검증하는 것이 목표였다.

기타 니즈 탐색

북카이브가 정의한 문제 외에 사용자들이 공통적으로 느끼는 페인 포인트가 있는지 확인하고자 했다.

인터뷰 결과: 그래서 북카이브가 얻은 인사이트는?

결과1) “일일이 타이핑하는 게 불편해요”

첫번째로 얻은 결과는 기록 과정에 대다수가 불편함을 느낀다는 사실이다. 인터뷰이의 약 80-90%가 기록 단계에서 불편함을 호소했고, 특히 수기로 작성하거나 핸드폰으로 타이핑하는 경우에는 그 페인을 더 크게 느꼈다.

[결론] 현재 북카이브의 기록 방식을 계속 보완해 압도적인 편리함을 주어야 한다는 방향성은 계속 가져가기로 했다.

결과2) 정리/분류 - “한 곳에 깔끔하게 정리되면 좋겠어요”

(👆실제 유저들의 기록 형태)

기록이 잘 정리되지 않는 것에 대한 페인도 있었다는 걸 알게 되었다. 앨범, 메모, 앱 등 여러 곳에 흩어져 있어 정리가 안되거나, 한 곳에 모아두더라도 의미없이 쌓이기만 해 정리가 되는 느낌을 받지 못한다. 그리고 그걸 정리하는 것 자체를 귀찮다고 느낀다.

[결론] 현재는 태그를 통해 분류해 정리할 수 있는데 이 형태가 과연 적절한 건지, 보기 편한 형태가 맞는지에 대한 의문이 들었다. 정리 형태에 보완이 필요하다고 느꼈는데, 사실 어떻게 보완해야 할지는 이 때까지만 해도 감이 잡히지 않았다. 사용자마다 정리 형태가 너무 다르기 때문에 그 기준을 잡기가 더 어려웠고, 이 부분은 유저를 더 만나보면서 찾아가기로 결론을 내렸다.

결과3) 찾기 및 활용 - 니즈는 있지만 실행이 어렵다

(👆 고민의 흔적…)

먼저 이전 기록을 찾는 과정에 페인이 있다는 것은 확실했다. 일일이 책을 훑어보거나 모든 파일을 찾아야 하는 어려움이 있는 것이다. 또 활용에 있어서도 니즈가 있다는 것을 확인했다. 책에서 얻은 인사이트를 내재화해서 진짜 내 것으로 만들고, 필요할 때 바로 꺼내 쓰고자 하는 욕구가 있었다. 그러나 그러기 위해서 어떻게 해야 할지 모르겠고, 다시 찾아서 보자니 귀찮아 실행으로 옮겨지지 않는 것이다.

[결론] 우리는 이 문제를 ‘AI 찾기’로 어느정도 해결해줄 수 있지 않을까 생각했다. 사용자가 상황과 맥락을 설명해 그에 맞는 구절을 AI가 찾아준다면 활용 측면에서 도움이 될 거라고 생각했다.

그러나 우리는 여기서 더 나아가 진짜 ‘내재화’할 수 있는 방법은 없을까를 고민했다. 가장 좋은 건 유저는 가만히 있고 우리가 떠먹여 주는 것인데, PO님이 들어주셨던 적절한 비유가 있다.

“파인애플이 있다. 파인애플을 다른 사람이 잘라주면 우리는 먹겠지만, 칼을 주고 직접 잘라 먹으라고 하면 과연 우리가 먹을까?”

즉 유저가 어떤 액션을 해야만 내재화를 할 수 있는 것이라면 과연 유저가 그걸 기꺼이 할까?라는 의문이 있었다. 그럼 여기서 문제는 ‘어떻게 떠먹여 줄 것인가’인데…이것이 가능할지 기획적으로 방향이 보이지 않았다. 그래서 좀 더 간단하게라도 해결할 수 있는 방법을 스텝바이스텝으로 고민하며 PO님과 아이데이션을 했고, 우선 ‘AI 찾기’기능으로 사용자 반응과 사용 행태를 확인한 뒤 개선해보기로 했다.

정리하면..

1. 기록/분류 부분의 완성도를 높이자

2. 인터뷰를 계속 병행하며 니즈를 더 깊게 파보자

3. 내재화를 완벽하게 도와주는 것까진 아니더라도, AI 찾기 기능으로 어느정도 필요할 때 꺼내서 활용하는 데 도움이 될 수 있는 정도로 해결해보자

인터뷰를 진행하며 나름 파고든다고는 했지만, 지금 복기해보면 ‘아 이때 이 답변에 이 질문을 했으면 좋았을텐데..’하는 아쉬움이 남는다. 정말 유의미한 인터뷰를 하고 싶다면 대상자 선정부터 질문지 설계까지 철저한 준비가 필요하다는 걸 배울 수 있었다. + 그리고 무엇보다 중요한건? 미래의 나에게 미루지 말고 그때그때 바로 인터뷰 정리하기..:)

다음 편에서는 유저 인터뷰 시 ‘잘 질문하는 법’에 대해 다뤄보려 한다. 북카이브의 유저 인터뷰를 사례로 어떻게 깊게 파고들며 질문해야 할지 고민했던 지점들을 풀어볼 예정이다.

(+ 인터뷰를 마친 뒤에는 PO님과 UT를 진행했다. 인터뷰에서의 회고를 바탕으로 UT는 더욱 철저하게 준비해 진행했는데, 참여자 수는 적지만 추후 기획의 방향성을 잡을 수 있었던 굉장히 얻은 게 많은 UT였다. PO님과 열심히 준비했기에 정말 잘 한 UT라고 나름 자부할 수 있다! 과연 UT에서는 어떤 인사이트를 얻었을지는 그 다음 에피소드에서 계속!)

디자인 A와 B 사이, 어떻게 선택해야 할까?

디자인 A와 B 사이, 뭘 선택해야 할까? 디자이너라면 누구나 한 번쯤 겪어봤을 ‘선택의 순간’이 아닐까 싶다.

북카이브는 OCR로 스캔해 기록하는 기능을 UX적으로 어떻게 표현할지 고민하는 과정에서 그 선택의 순간을 직면했다. 어떤 방법이 좋을지 팀원들과 함께 이야기도 해보고 여러 레퍼런스도 찾아보며 다양한 아이디어를 구상했다. 중요한 것은 그 중 북카이브에 가장 적합한 방식을 찾는 것이었다. AB 테스트로 사용자에게 확인하는 것이 가장 바람직하겠지만, 프로덕트를 만들다 보면 일일이 테스트를 돌려보기 어려울 때가 많다. 그래서 이럴 땐 디자이너가 의사결정을 해야 한다. 

모든 의사결정에는 기준이 있어야 한다. 기준이 없으면 ‘선택’이 아니라 ‘찍기’에 가깝기 때문이다. 나는 디자인 의사결정을 할 때 핵심 목표와 리소스를 주요 기준으로 둔다. 이번 북카이브의 기록 UX를 설계할 때도 마찬가지였다. 

북카이브 기록 기능의 핵심 가치는 ‘간편함’과 ‘빠름’이다. 이전 글에서도 이야기했듯 압도적인 편리함이 중요했기 때문이다. 즉 기록하는 과정에서 가장 허들이 덜 하고 간편하게 할 수 있는 방식이 무엇일까를 고민했다. (물론 개발 리소스가 어느정도 필요하냐는 기본!)

이번 글에서는 이런 기록의 핵심가치를 기준으로 어떻게 UX 방향을 잡아 나갔는지 공유해보려 한다. 

스캔 후 문장 선택

북카이브에서는 카메라로 페이지를 찍으면, 기록하고자 하는 특정 구절을 선택해 텍스트로 변환한다. 이런 텍스트 선택 UX는 아주 다양하다. 아이폰의 기본 OCR 기능처럼 이미지 위에 바로 특정 문장을 드래그하는 방식, 실시간으로 카메라 화면에서 텍스트를 추출하는 방식(like 구글 번역기) 등.. 여러가지 방법이 있다.

우리는 여러 방법을 고민한 끝에, 문장 단위로 리스트를 보여주어 그 중 원하는 문장을 클릭하는 방식으로 표현했다. 이 결론을 내리기까지 다양한 방식의 장단점을 따져보며 ‘간편함과 빠름’이라는 핵심 가치를 기준에 어떤 것이 가장 적합할지 고민의 과정을 거쳤다.

1. 이미지에서 드래그하는 방법

가장 보편적인 방법이 아닐까 싶다. 그럼 이 이미지에서 드래그하는 방식을 사용했을 때, 어떤 장점과 단점이 있을까?

장점) 이미지 위에서 바로 조작한다

책 이미지 위에서 바로 조작하기 때문에, 내가 기록하려 했던 부분이 어디인지 비교적 찾기가 쉽다.

단점) 이미지 위에서 바로 조작하는 것이 어렵다.

이 방법의 가장 우려되었던 점은 이미지 속의 작은 텍스트 위에서 조작하는 것이 어렵다는 것이었다. 이미지에 따라 텍스트가 작게 표시될 수도 있고, 그 작은 영역을 손가락으로 드래그하는 과정이 결코 간편한 UX는 아니라고 생각했다.

2. 책 속 문장 형태를 그대로

그래서 대안으로 생각한 것이 이 두 번째 방식이었다. 문장 단위로 블록처리를 해 책 문단과 같은 모양으로 보여준다. 다시 말해 각 줄의 시작점을 책과 똑같이 맞추는 것이다. 

장점1) 방법1보다 조작(클릭)이 쉽다

장점2) 책 문단과 같은 형태이다

이 방법의 장점은 블록 형태로 제공해 방법1보다 조작이 쉬우면서, 책과 같은 형태로 보여주기 때문에 책을 보다가 폰 화면으로 시선이 이동했을 때 기록할 부분을 쉽게 찾을 수 있다.

단점1) 시각적으로 복잡하다

단점2) 개발 구현이 어렵다

그러나 문제가 있었다. 첫째는 시각적으로 복잡하다는 것이다. 책과 같은 형태로 블록을 배치하다보니 블록의 시작과 끝 지점이 불규칙해지고 정돈이 덜 되어 보였다. 정돈이 덜 되어 보이니 결국 문장을 찾는 데 시간이 더 걸렸다.

또 다른 문제는 개발 구현이 어렵다는 것이다. 줄마다 문장의 시작점을 책과 똑같이 가져가야 했는데, 작은 폰 화면에서 이를 그대로 보여주기는 쉽지 않았을 뿐더러, 해상도에 따라 다르게 보여질 수밖에 없었다. 그렇게 되면 기기마다 책 속 문단 형태와 달라져 의미가 없어져 버린다.

3. 그럼 문장을 리스트로 보여주면?

결국 최종 선택된 방법으로, 문장들을 리스트 형태로 나열해 보여주는 방식이다.

장점1) 클릭이 쉽다

장점2) 정돈된 형태로 시각적 복잡도가 덜하다

블록을 리스트 형태로 보여주니 2번 방법에 비해 시각적 복잡도가 훨씬 덜하다. 또 문장별 조작 영역이 넓어져 빠른 조작이 더 쉽다는 장점이 있다.

단점) 책과 같은 형태가 아니다

그러나 책 문단과 같은 형태가 아니라는 점이 가장 고민이었다. 이렇게 되었을 때, 결국 책을 읽다가 마음에 드는 부분을 발견하고 → 북카이브를 켜서 스캔하고 → 문장을 선택할 때, 스크롤하며 기록할 부분을 찾아야 한다. 그럼 이 과정에서 시간이 소요될 수밖에 없다.

4. + 그럼 영역을 지정할 수 있게 하자!

3번의 방법에서 어떻게 하면 문장을 찾는 수고로움을 덜 수 있을까 고민했다.

어찌되었든 책 문단과 똑같은 형태로 보여주는 것은 개발적으로 불가능하기 때문에, 문장을 선택하는 단계에서 기록할 부분을 찾아야 하는 것은 어쩔 수 없는 과정이었다. 그럼 그 문장 리스트 속에서 어떻게 하면 스크롤을 덜하면서 내가 원하는 부분을 빠르게 찾을 수 있을까?

바로 스캔 단계에서 영역을 지정할 수 있게 하는 것이다!

문장 리스트에서 기록할 부분을 찾기가 어려운 이유는 책과 같은 모양이 아니기 때문이기도 하지만, 한 페이지 안의 수많은 문장 블록들이 수직으로 나열되기 때문이기도 하다. 만약 기록하고자 하는 부분이 페이지의 아래쪽에 있다면, 계속 스크롤을 하며 찾아야 하는 것이다.

하지만 스캔 단계에서 영역을 미리 지정하면, 나열되는 문장 블록의 개수가 훨씬 적어지면서 비교적 찾기가 쉬워진다. 아니, 사실 거의 찾을 필요도 없게 되는 것이다! 

그럼 이제 이 영역지정을 어떻게 시각적으로 표현하면 좋을까?

이미지 위에서 네 개의 꼭짓점을 조정해 영역을 지정하는 UX는 일반적이지만, 이것처럼 카메라 화면에서 세로 영역을 조정하는 것은 익숙하지 않은 기능이다. 따라서 가장 직관적이고 평소 사용자들에게 익숙한 형태로 제공하고 싶었다.

그래서 카메라가 아니더라도 드래그해서 영역을 키우고 줄이는 UX가 무엇이 있을지 고민해보았고, ‘핸들’이 생각이 났다. 특히 바텀시트 상단에서 이 핸들을 드래그해 세로 영역을 조절하는 것은 많은 사용자에게 익숙한 UX다. 그 방식이라면 충분히 이해할 수 있을 거라고 생각해 이미지와 같이 핸들을 이용해 시각적 단서를 주었다. 

이 영역지정 UX는 문장 리스트 방식의 단점을 보완해주는 가장 중요한 부분이었는데, 실제로 이후 UT에서 영역지정을 사용했을 때 사용자들이 간편함을 훨씬 크게 느꼈다.

디자인을 하다보면 여러가지 시안이 떠오를 때가 있다. 그리고 그 시안들은 각각 장단점이 있기 때문에 이 방법도 좋은 것도 같고, 저것도 좋은 것 같고..그 사이에서 갈팡질팡 할 때가 있다. 나는 그 장단점들 사이 우선순위가 희미할 때 갈팡질팡이 발생한다고 생각한다.

이 기능 혹은 우리 프로덕트의 핵심 가치 및 목표는 무엇인지 명시하고 시작한다면 우선순위가 명확해지고, 가장 최적의 시안을 선택할 수 있게 된다.

물론 사용자를 대상으로 검증한 것이 아니기 때문에 그게 무조건 좋은 디자인이라고 할 수는 없다.(북카이브도 이후 UT를 진행하며 부족한 부분들을 많이 발견했기 때문..)

그러나 선택하는 과정에서 드는 시간적 리소스와 잘못된 시안을 선택하는 리스크를 최소화할 수는 있다. 그냥 ‘최선’이 아니라, ‘우리 프로덕트에 최선'인 디자인을 선택하기 위한 방법인 것이다.

[EP2] 북카이브의 MVP, 어떻게 보여줘야 할까?

“OCR로 간편하게 기록하고, 태그 분류로 쉽게 꺼내쓰는 서비스”로 북카이브의 MVP 범위는 정해졌다.
북카이브의 MVP는 두 부분으로 나뉘어진다.

1. OCR로 간편한 기록

2. 태그 분류로 쉽게 꺼내 활용

여기서 북카이브의 가장 핵심은 2번인 ‘활용’에 있다고 볼 수 있다.

이유는 OCR을 활용한 간편한 기록은 다른 서비스에서도 제공되는 가치로, 북카이브만의 차별 포인트라고 보기는 어렵기 때문이다. 반면 저장한 기록을 ‘잘 꺼내쓸 수 있게 하는 것’은 북카이브만이 제공할 수 있는 고유한 가치라고 판단했다. MVP단에서는 우선 태그를 활용해 기록들을 정리하고, 비교적 쉽게 꺼내볼 수 있게 하는 것이 목표였다. (시장을 살펴 보아도, 저장한 독서 문장 기록들을 잘 정리하고 분류해 볼 수 있는 서비스는 없다)

그럼 이제 이 MVP 핵심 기능을 구체적으로 어떤 형태로 제공해야 사용자에게 효과적으로 전달될 수 있을까?

MVP 1) 기록 단계에서의 압도적 편리함

북카이브는 문장을 기록하는 과정에서 다른 서비스에 비해 압도적인 편리함을 주는 것이 중요했다.

핵심은 ‘활용’에 있다고 했는데, 왜 기록에서의 압도적 편리함이 필요했을까?

바로 태그 분류를 통한 활용의 가치는, 사용자들이 서비스를 여러 번 사용했을 때 체감할 수 있기 때문이다. 태그 분류로 ‘오 깔끔하게 정리가 되네?’, ‘쉽게 찾아볼 수 있겠네?’라는 인상을 받기 위해서는 북카이브로 저장한 기록들이 어느정도 쌓여야 하기 때문이다. 즉 사용자들이 그 가치를 느끼기까지 지연이 생길 수밖에 없다.

따라서 그 과정에서 이탈률을 줄이기 위해 앞단에서 AHA MOMENT를 제공해야 했고, 기록 단계가 다른 서비스들보다 훨씬 간편해야 한다는 결론이었다. 그래서 우리는 다양한 레퍼런스를 참고하며 가장 편한 기록 UX를 고민했다. 그러나 문제는…그 압도적 편리함을 위해서는 개발적으로 까다롭고 시간도 오래 걸릴 수밖에 없었다. 즉 개발 리소스와 UX를 적절히 고민하며 최선의 형태를 고민할 수밖에 없었는데, 자세한 이야기는 다음 편에서 다뤄볼 예정이다!

MVP 2) AI를 활용한 태그 분류

태그 분류는 MVP에 맞게 최소 단위로 형태를 구상했다. 말 그대로 '저장한 기록에 태그를 붙일 수 있게 하자 + 홈 화면에서 바로 태그별로 분류해 볼 수 있게 하자'였다.

우선 태그는 AI를 활용해 더 편리하고 빠르게 설정할 수 있게 했다. 위에서 말한 것처럼 ‘기록에서의 압도적 편리함’이 중요했는데, 여기서 ‘기록’은 스캔 과정뿐만 아니라 태그를 설정하는 과정까지 포함된다. 그 과정에서 ‘이 구절은 어떤 태그로 해야 할까..’ 고민에 시간을 쓸 필요 없이, AI가 구절의 맥락을 파악해 적절한 태그를 추천해주는 형태를 고안했다.

AI 추천 태그는 (1) 새로운 태그를 추천해주는 것과 (2) 기존에 있던 태그 중 해당 구절과 연관이 있는 것 이렇게 두 종류를 보여준다. 처음 태그를 생성할 때는 AI의 새로운 태그 추천이 유용하겠지만, 나만의 태그 체계가 쌓였을 때는 새로운 태그를 계속 추가하기 보다 가장 연관성 높은 기존 것을 선택하는 것이 좋다. 유저의 분류 맥락에 맞는, 일관성 있는 분류가 가능하기 때문이다. 이 두 가지를 직관적으로 구분하기 위해 새로운 태그와 기존 연관 태그의 UI에 차이를 두었다.

그렇게 MVP 개발은 무사히 진행되었다. 개발팀이 MVP 개발에 힘을 쏟는 동안, 기획단에서는 유저 인터뷰를 진행하며 유저의 문제와 니즈를 파악해 나갔다.

과연 북카이브가 해결하고자 하는 문제는, 다른 유저들도 느끼고 있는 문제였을까?

유저 인터뷰를 통해 어떤 문제점들을 뽑아냈고, 어떤 새로운 고민거리가 주었는지는 다음 에피소드에서 계속! >>

[베타 테스터 모집] 책 속 문장, 간편하게 기록하고 꺼내쓰고 싶다면?

책 속 문장, 간편하게 기록하고 꺼내쓰는 나만의 독서 인사이트 창고 북카이브✨

안녕하세요, 북카이브가 베타 테스터를 모집합니다!

3주 동안 자유롭게 북카이브로 독서 문장 기록하고, 특별한 혜택도 받아보실 수 있어요

(* iOS 유저를 대상으로 해요)

🗓️ 모집 기간

• 4월 15일 (화) ~ 5월 15일(목)

👥 모집 인원

• 선착순 50명

👀 이런 분들을 찾고 있어요!

• ‘바빠도 독서는 포기할 수 없어’..독서를 좋아하시는 2030 직장인

• 문학보다는 비문학을 좋아하시는 분

• 책을 읽고 마음에 드는 구절을 자주 기록하시는 분

• 책을 통해 자기계발, 커리어개발을 목표로 하시는 분

• 쌓인 기록들에 대한 분류, 정리, 활용에 불편을 겪고 계신 분

✨ 테스터만이 받을 수 있는 혜택

1. 북카이브 유료 플랜 도입 시 3개월 무료 이용권 제공

2. 북카이브를 가장 먼저 써볼 수 있는 기회

3. 나의 의견이 서비스에 직접 반영될 수 있는 특별한 기회

   (베타 테스터 분들의 의견을 우선으로, 추후 서비스 개선 시 반영될 수 있어요)

작은 의견들도 북카이브에게 큰 도움이 되니, 많은 관심 부탁드려요 :)

👇신청하러 가기

https://tally.so/r/npZ0NP

[EP 1] "그냥 만든 거 아니고, 정말 ‘쓰고싶은 서비스’를 만들고 싶었어요" - 북카이브의 시작

‘사용자에게 실제로 가치를 줄 수 있는 서비스를 만든다’

북카이브는 이 하나의 공통된 목표를 가진 사람들이 모여 만들게 된 사이드프로젝트 서비스로, 2월 말 즈음 시작해 지금까지도 열심히 디벨롭하며 현재 진행형 중인 프로젝트이다.

이런 북카이브가 어떻게 탄생하게 되었고, 어떤 고민을 거쳐 발전해 나가는지 그 여정을 기록해 보려 한다!

👥 우연히 모인 북카이브 팀

우리팀은 PO, 디자이너, 프론트, 백엔드 한 명씩 이루어진 작은 팀이다.

그 시작은 ‘비사이드 - 네이버 AI 포텐데이’였는데, 수많은 참가자들 사이에서 우리는 우연히 서로를 발견해 팀을 꾸리게 되었다. 운이 좋게도 좋은 팀원들을 만나게 되었고, 포텐데이가 끝이 난 지금까지도 각자의 자리에서 열심히 프로젝트를 이끌고 있다!

온라인 팀빌딩을 완료하고 그 주 주말 대면 밋업을 하게 되었다. 처음에는 매우 어색했지만…함께 스몰톡을 나누며 아이스브레이킹을 했고, 본격적으로 프로젝트에 대해 이야기를 나누었다.

🎯 우리팀의 목표: 뭘 어떻게 만들고 싶은데?

먼저 팀의 목표와 그라운드룰을 정했다.

비대면으로 진행되는 사이드프로젝트인 만큼 서로의 관점과 목표를 얼라인하는 것이 중요했다. 그래서 우리는 프로젝트를 통해 각자 이루고자 하는 목표와 만들고 싶은 서비스, 지켰으면 하는 기본 룰에 대해 함께 이야기했다.

함께 이야기를 나눈 끝에, 공통점들을 바탕으로 팀 미션과 비전을 뽑았다.

MISSION: 유저의 일상 속 가치를 주는 서비스를 만든다

우선 우리 팀원은 모두 ‘유저의 일상 속 불편함을 해소해주는 서비스’를 만들고 싶어 했다. 특수한 케이스나 유저에게만 적용되기 보다는, 모두의 일상에 스며들 수 있는 서비스를 만드는 것이 팀의 목표였다.

VISION: 단순 프로젝트용 서비스가 아닌, 실제로 '쓰고 싶은' 서비스를 개발 및 운영해본다

1. 사람들에게 실제로 가치를 주고, 그 사람들이 정말 쓰고 싶어 하는 서비스를 만든다

2. 포텐데이 기간 이후에도 출시 및 운영을 한다

이 두가지였다.

포텐데이는 기본 10일 + 고도화 트랙 추가 10일이라는 짧은 기간 동안 이루어지는 사이드프로젝트이지만, 우리는 그 기간 이후에도 서로 뜻이 맞는다면 꾸준히 디벨롭해 실제로 ‘쓰이는 서비스’를 만들고자 했다.

📏 그라운드룰: 비대면 사이드프로젝트에서 지켜야 할 것들

그라운드 룰은 팀원들이 프로젝트를 진행하며 꼭 지켰으면 하는 기본적인 규칙을 말한다.

우리는 4개의 룰을 선정했는데, 요약하자면 투명하게 공유하고 적극적으로 의견을 주고받되, DRI가 최종결정권을 가지고 업무를 진행한다는 것!

‘공유’가 주가 되는 것 같은데, 앞서 말했던 것처럼 비대면 사이드프로젝트이다 보니 그만큼 진행상황을 촘촘하게 공유하는 게 중요하다고 생각했다.

😱 북카이브의 탄생: 독서 문장 기록 불편하지 않아? 기록해도 까먹지 않아?

↑ 아이템 후보들...

이후 아이템 선정을 위해 여러 아이데이션을 거쳤다. 다양하고 재밌는 아이디어들이 많았는데, 아이템을 선정할 때 우리는 다음과 같은 기준을 두었다.

1. 앞서 언급한 우리팀의 목표와 일치하는가

2. 기술적으로 10일 안에 구현 가능한가

3. 다른 사람들도 느낄 수 있는 불편함인가

이에 모두 부합하는 아이템이 ‘북카이브’였고, 최종 아이템으로 선정하게 되었다!

북카이브 초기 아이템은 PO님의 아이디어에서 시작되었다.

독서하다가 마음에 드는 문장을 일일이 타이핑하는 것이 너무 불편하고, 기록한다고 해도 다시 보지 않아 얻었던 인사이트들을 까먹게 된다는 것이다.

나도 그 부분에 매우 공감했다. 특히 후자에 더 공감이 되었다. 디자인 관련 서적을 읽고 좋은 내용들은 메모장에 기록해 두었지만, 막상 실제 디자인 작업할 때 써먹으려니 기억이 나지 않았던 경험이 있었기 때문이다. ‘아 분명 책에서 읽은 좋은 정보가 있었는데..’ 생각만 할 뿐이었다.

그래서 우리는 이 문제를 해결해 줄 수 있는 서비스인,

“OCR로 빠르게 기록하고, 효과적인 복기 및 활용을 도와주는 북카이브”를 만들기로 했다.

PO님께서 이전에 같은 아이템을 랜딩페이지를 이용해 검증했었고, 그 덕에 이 문제에 대한 니즈가 있다는 것을 미리 알 수 있었다. 다만 복기 및 활용의 경우, 이를 확실하게 해결하기 위해서는 더 탄탄한 기획이 필요했고 10일 내로 개발하기에는 쉽지 않았다. 따라서 ‘태그 분류’를 활용해 깔끔하게 정리하고 찾기 쉽게 만들어 복기 및 활용의 문제를 간단하게 해결하고자 했다.

이를 바탕으로 MVP의 틀이 정해졌다: OCR로 사진을 찍어 기록하고, 태그로 분류한다.

이제 구체적으로 MVP의 범위를 정하고, 어떤 형태로 핵심 기능을 제공할 것인지를 고민할 차례다.

하지만 MVP를 정했다고 모든 것이 순탄히 흘러 가지만은 않았는데...

MVP를 좁혀가는 과정은 다음 편에서 계속! >>