[7월 TIL #8] growth.design 온보딩 케이스 스터디: How to Craft OnboardingSurveys Users Love

이 글은 growth.design의 인터랙티브 케이스 스터디 How to Craft Onboarding Surveys Users Love를 보고 정리한 공부 기록이다. growth.design은 UX 사례와 심리학을 인터랙션으로 풀어주는 사이트다. 앞쪽은 사례가 짚는 심리 법칙을 위키처럼 정리했고, 뒤쪽 TIL에 왜 이걸 공부했고 무엇을 느꼈는지를 덧붙였다.

가입하자마자 나오는 그 설문

새 서비스에 가입하면 본격적으로 쓰기 전에 설문부터 나오는 경우가 많다. 팀 규모가 어떻게 되는지, 어떤 목적으로 쓰는지 몇 문항을 묻는 온보딩 설문이다. 대부분은 빨리 넘기고 싶어서 대충 답하거나 건너뛴다.

growth.design은 Grammarly의 온보딩 설문을 예로, 유저가 기꺼이 답하고 싶은 설문은 어떻게 설계되는지, 그리고 잘 만든 설문이 어디서 무너지는지를 심리 법칙으로 뜯어본다.


케이스 스터디 스토리 속 주인공은 원래 Grammarly를 개인용으로 쓰던 사람이다. 팀 전체가 일관된 브랜드 보이스로 글을 쓰면 좋겠다는 생각에 팀(비즈니스) 플랜 가입을 시작한다. 그 첫 관문이 바로 온보딩 설문이다. 아래는 이 설문이 짚는 심리 법칙을, 유저가 설문을 따라가는 순서대로 정리한 것이다.

온보딩 설문을 5가지 원칙으로 뜯어보는 케이스 스터디. 개인 유저가 팀 플랜으로 넘어가는 장면에서 출발한다.

1. Framing Effect (프레이밍 효과) — 그리고 스파크 효과

설문의 첫 질문은 팀 구조처럼 짧고 쉬운 것이다. 팀 규모가 어느 정도인지, 무슨 일을 하는지 정도를 묻는다. 이렇게 가볍게 답할 수 있는 질문부터 꺼내는 게 스파크 효과(Spark Effect)다. 처음에 작은 행동 하나를 하게 만들면 그다음 행동으로 이어지기 쉽다는 것이다. 부담스러운 질문을 먼저 던지면 유저는 시작도 하기 전에 창을 닫는다.


프레이밍 효과는 같은 정보라도 어떻게 제시하느냐에 따라 사람의 결정이 달라진다는 원리다. Grammarly는 이 질문을 건너뛰는 버튼을 그냥 "건너뛰기"가 아니라 "개인화 건너뛰기(Skip personalization)"로 보여준다. 건너뛰면 단순히 질문 하나를 넘기는 게 아니라 나를 위한 맞춤 경험을 포기하는 것처럼 느껴지게 만든 것이다. 답할 이유를 유저 쪽 이득으로 바꿔 붙인 셈이다.

건너뛰기 버튼을 "개인화 건너뛰기"로 프레이밍한 화면. 넘기는 것이 곧 손해처럼 보이게 만든다.

2. Personalization (개인화) — 하고 있으면서 티를 안 낸다

유저가 답을 마치면 Grammarly는 그 답을 바탕으로 맞춤 목표를 보여준다. 문제는 이 목표들이 유저 눈에는 다소 뜬금없어 보인다는 점이다. 실제로는 앞서 답한 내용에 맞춰 골라준 것인데, 그게 내 답에서 나온 결과라는 게 전달되지 않는다.


케이스 스터디가 짚는 핵심은 이렇다. 사람들은 개인화된 경험을 선호하지만, 개인화를 해놓고 그걸 제대로 알리지 않으면 차라리 개인화를 안 한 것만 못할 수 있다. 유저 입장에선 "내가 답을 줬는데 왜 반영이 안 된 것 같지?"가 되기 때문이다. 개인화는 하는 것 못지않게, 하고 있다는 걸 보이게 만드는 게 중요하다.

답변을 바탕으로 맞춤 목표를 보여주지만, 그게 내 답에서 나왔다는 신호가 약한 화면.

3. Personalized Paywall (개인화된 페이월)

설문이 끝나면 유료 플랜을 권하는 화면, 즉 페이월이 나온다. Grammarly는 여기서 유저의 답을 근거로 플랜을 추천한다. growth.design에 따르면 이렇게 목표에 맞춘 개인화된 페이월은 실제 테스트에서 업그레이드 전환율을 10% 넘게 끌어올렸다.

답변을 근거로 플랜을 추천하는 개인화된 페이월. 전환율을 10% 넘게 끌어올린 장치다.

개인화된 페이월의 공식은 세 단계다. 먼저 유저의 목표를 이해했다는 걸 보여주고, 그다음 그 목표를 채워줄 기능을 보여주고, 마지막에 그에 맞는 업그레이드 경로를 제안한다. 그런데 Grammarly의 실제 흐름에서는 이 개인화된 제안이 눈에 잘 안 띄어서 유저가 그냥 지나칠 뻔한다.


그래서 케이스 스터디는 세 가지 개선을 제안한다.

1. Pseudo-Set Framing (유사 집합 프레이밍): 플랜 선택을 온보딩을 완성하는 한 단계처럼 넣어서, 끝까지 채우고 싶은 심리를 건드린다.
2. Personalization (개인화): 이 추천이 왜 나왔는지, 즉 "당신이 이렇게 답했기 때문에 이 플랜"이라는 근거를 분명히 보여준다.
3. Salience (현저성): 유저의 답과 맞는 플랜을 눈에 확 띄게 강조해서 놓치지 않게 한다.

세 가지 개선을 반영한 페이월. Business 플랜을 먼저, "당신이 말한 세 가지 목표를 커버한다"는 근거와 함께 눈에 띄게 보여준다.

4. Conway's Law (콘웨이의 법칙) — 조직의 틈이 온보딩의 틈으로

결제를 마친 유저는 이제 스타일 가이드나 브랜드 보이스를 설정할 차례라고 기대한다. 그런데 결제 이후에 또 다른 온보딩 구간이 나오고, 여기서 앞서 이미 답한 것과 겹치는 질문을 다시 묻는다.


콘웨이의 법칙은 "조직의 구조가 그 조직이 만든 제품에 그대로 드러난다"는 원리다. Grammarly의 온보딩이 매끄럽지 않은 건 실력이 아니라 구조 때문이라는 것이다. 서로 다른 팀이 각자 자기 구간의 온보딩을 따로 만들다 보니, 이어 붙였을 때 질문이 중복되고 흐름에 틈이 생긴다. 유저는 같은 질문에 또 답하는 걸 귀찮아하고, 그렇게 답한 결과도 결국 메뉴를 뒤져야 나오는 일반적인 프로필 정도에 그친다.

결제 이후 다시 등장하는 온보딩 구간. 팀별로 따로 만든 조각들이 이어지며 질문이 중복된다.

5. Reciprocity Principle (상호성의 원리) — 주면 받길 기대한다

상호성의 원리는 "유저가 무언가를 주면, 그만큼 돌려받길 기대한다"는 것이다. 설문에 시간과 답을 들인 유저는 그 대가로 자기에게 맞춰진 경험을 기대하게 된다. 온보딩 설문은 이렇게 유저의 기대치를 끌어올리는 장치이기도 하다.


그래서 케이스 스터디의 제안은, 결제 이후의 일반적인 설정 단계를 유저가 이미 답한 설문 내용으로 채운 개인화된 셋업으로 바꾸라는 것이다. 유저가 준 답을 곧바로 눈에 보이는 결과로 돌려줘서, 우리가 당신 말을 듣고 있다는 걸 초반부터 자주 보여주라는 것이다.

상호성의 원리. 유저가 설문에 답을 주면, 그만큼 돌려받길 기대한다.

설문 답변으로 채운 개인화된 셋업 제안. "당신의 목표를 바탕으로 이렇게 시작해보라"며 유저가 준 만큼을 결과로 돌려준다.

케이스 스터디가 정리한 5가지

growth.design은 마지막에 좋은 온보딩 설문의 원칙을 다섯 가지로 정리한다.

1. 쉬운 질문부터 던진다.
2. 각 질문이 유저에게 어떤 도움이 되는지 보여준다.
3. 유저의 목표를 초반에 물어서, 관심 있다는 걸 보여준다.
4. 앞선 답을 활용해 이후 질문을 개인화한다.
5. 팀 간의 틈이 온보딩의 틈이 되지 않게 한다 (콘웨이의 법칙).

다섯 장치가 가리키는 한 방향

쉬운 질문으로 시작을 열고, 왜 묻는지를 유저 이득으로 보여주고, 받은 답을 눈에 보이게 돌려준다. Grammarly 설문을 뜯어보면 원칙은 여러 개지만 방향은 하나다. 설문은 유저에게서 정보를 받아내는 창구가 아니라, 받은 만큼 더 나은 경험으로 돌려주는 교환이다. 잘 만든 설문과 그렇지 못한 설문의 차이도 결국 그 교환이 지켜지느냐에서 갈린다.

---

온보딩은 항상 중요하다고 생각했지만, 제품 전체에서 우선순위가 밀리면서 계속 뒤로 미뤄왔다. 그나마 내가 온보딩을 깊게 신경 쓰지 못할 때 제품 관점에서 함께 고민해주던 분이 있었는데, 그분은 원래 ML 엔지니어였다. 본인의 역할과 직접적으로 연결되지 않는 영역임에도 엔지니어링 역량을 사용자 경험 개선에 적극적으로 활용했고, 그 과정을 즐기는 사람처럼 보였다. 덕분에 여러 온보딩 플로우를 함께 설계했고, 나는 그 위에서 UI를 다듬는 역할을 하는 경우가 많았다.

이제는 그분이 설계했던 온보딩과 실험들을 우리가 이어가야 하는 상황이다. 단순히 마음대로 바꾸는 것이 아니라, 이전에 어떤 가설과 데이터를 바탕으로 설계되었는지 이해한 뒤 그 연장선에서 실험을 해야 한다. 그래서 방향성을 고민할 것도 많고, 자연스럽게 손대는 일이 어려워졌다. 중요하다는 걸 알면서도 쉽게 시작하지 못하는 이유도 여기에 있는 것 같다.

다행히 이번에는 제품의 핵심 UI/UX를 어느 정도 기본값으로 정리해두었기 때문에, 이제는 다시 온보딩을 본격적으로 점검해야 할 시점이라는 생각이 든다. 무엇을 실험할지에 대한 아이디어도 필요했고, 관련 자료를 보면서 생각보다 적용해볼 만한 포인트가 많다는 걸 느꼈다.

특히 최근 건국대를 방문하면서 ‘전공별 사용자 특성’이 생각보다 훨씬 중요하다는 점을 실감했다. 우리는 컴퓨터사이언스 사용자가 많다 보니 수식이나 복잡한 피겨를 쉽게 이해하도록 돕는 기능에 집중해왔다. 논문를 읽는 사람들이 전공마다 다를 것이라는 사실은 알고 있었지만, 실제로 그 차이가 제품 경험에 어떤 영향을 주는지는 깊이 고민해본 적이 없었다.

그런데 심리학 전공 대학원생들을 만나 보니 상황이 전혀 달랐다. 그들은 논문 자체를 읽는 데는 큰 어려움을 느끼지 않았다. 이미 대학원 과정에서 자주 사용하는 통계 기법과 연구 프레임워크를 충분히 익혔기 때문이다. 오히려 어려워하는 부분은 논문을 작성하기 위해 자신의 연구 결과를 통계적으로 유의미하게 검증하거나, 정성 인터뷰 내용을 체계적으로 정리하고 분석하는 과정이었다.

결국 우리는 지금까지 사용자마다 연구 방식과 어려움이 다르다는 점을 충분히 고려하지 못한 채, 모두에게 동일한 온보딩 경험을 제공해왔던 것 같다. 온보딩의 본질은 화면 몇 개를 보여주는 것이 아니라, 이 사용자가 앞으로 우리 제품을 어떻게 사용할 사람인지를 가장 빠르게 파악하고 그에 맞는 출발점을 만들어주는 과정이다.

오늘 관련 내용을 공부하면서 다시 한번 느낀 것은, 첫 만남이 생각보다 훨씬 중요하다는 점이다. 좋은 온보딩은 단순히 기능을 설명하는 것이 아니라, 사용자의 맥락을 이해하고 그 사람에게 맞는 제품 경험을 시작하게 만드는 과정이라는 생각이 들었다. 굿..!