[7월 TIL #17] 기능의 존재를 어떻게 알릴 것인가: 3가지 기능 노출 패턴 (Implicit, Contextual, Disruptive)

7월의 랩실 교류 프로그램으로 한국생산기술연구원을 방문해 우리 제품을 자세히 소개하는 시간을 가졌다.

그곳에서 만난 우리 제품을 자주 사용해온 사용자조차 제품에 어떤 기능이 있는지 모두 알지는 못했다. 사용자분들께서 극히 일부 기능만을 쓴다는 것을 몰랐던 것은 아니었지만, 그럼에도 현장에서 직접적으로 그 모습을 마주하니까 크게 체감되었다.

이 경험을 시니어분과 나누며, 원래 대다수의 제품에서 사용자는 제품의 모든 기능을 고르게 사용하지 않고 일부 기능만 반복해서 사용한다는 이야기를 들었다. 따라서 새로운 기능을 추가하는 것뿐만 아니라, 사용자의 기존 흐름을 방해하지 않으면서 필요한 순간에 기능을 자연스럽게 경험하도록 만드는 것이 중요하다는 조언을 받았다. 예를 들어, 우리 제품에 퀴즈 기능이 별도 탭으로 마련 되어 있는데 이렇게 사용자가 필요한 순간을 직접 인지하고 기능에게 찾아가야하는 방식 말고, 논문 페이지들 사이에 자연스럽게 퀴즈가 들어가는 것처럼 맥락을 고려해 기능이 존재하는 방식을 말씀해주셨다.

이 대화를 나눈 뒤 맥락을 고려하면서도 기능 발견성을 높이는 방법이 궁금해졌다. 그래서 여러 자료를 찾아보았고, 그 중에서 흥미롭게 읽은 깃랩(GitLab)의 Pajamas Design System 내 Feature discovery 가이드라인을 정리했다.

---

새로운 기능은 사용자 경험을 향상시키고 중요한 가치를 열어줄 수 있다. 하지만 사용자의 문맥은 그들이 새로운 기능과 어떻게 상호작용하는지에 중요한 역할을 한다. FOGG 행동 모델에 따르면, 작업 완료와 관련된 사람들의 행동에 영향을 미치는 세 가지 요소가 있고, 어떤 행동이 일어나려면 다음 세 가지 요소가 반드시 같은 순간에 모여야 한다.

1. 작업을 수행할 수 있는 능력(ability).
2. 작업에 대한 동기(motivation).
3. 행동을 유발하는 프롬프트(prompt).

프롬프트(Prompt)는 단순한 '지시'나 '명령'이라기보다는, 특정 행동을 시작하게 만드는 '계기(trigger)'나 '신호(cue)'에 가깝다. 원하는 행동을 유발하는 프롬프트는 동기와 능력이 충분히 높을 때 성공한다. 발견 패턴을 사용해 사용자를 안내함으로써 작업을 수행할 수 있는 능력을 향상시키고, 작업의 가치를 명확하게 전달하여 동기를 높일 수 있다. 이러한 원칙을 염두에 두면 경험을 개선하고 사용자가 원하는 결과를 얻을 가능성을 높이는 데 도움이 된다.

기능 발견 패턴 (Feature discovery patterns)

• 암시적 발견 (Implicit discovery - 권장): 노골적인 프롬프트나 안내 없이, 사용자가 인터페이스와 상호작용하면서 자연스럽게 기능을 발견하게 된다.
  • 암시적 발견 패턴은 기능을 경험에 통합하기 위해 가장 권장되는 접근 방식이다. 기능 발견 알림을 추가하기 전에, 기능이 적극적으로 홍보되지 않는(과하지 않은 트리거) 해결책을 먼저 탐색해야 한다. 사용자가 기존 작업의 문맥 내에서 기능을 찾을 수 있을 때 집중력을 유지하고 압도당하지 않기 때문이다. 기능이 적절한 순간에 소개되고, 클릭 유도 문구(Call-to-Action)가 명확하고 이해하기 쉽도록 해야 한다. 이 방식은 사용자가 유기적으로 제품에 대한 이해를 구축함에 따라 새로운 기능에 대한 장기적인 참여를 촉진한다.
• 문맥적 발견 (Contextual discovery - 정당한 이유가 있을 때 사용): 사용자가 기능이 관련되거나 유용한 지점에 도달했을 때 문맥에 맞게 기능이 강조된다.
  • 추가 텍스트, 배지, 아이콘과 같이 주의를 끌거나 기능을 설명하는 미묘한 UI 요소다. 작업의 관련 문맥 근처에 배치되어야 하며 사용자의 작업 흐름을 방해하지 않아야 한다. 정적 알림은 사용자에게 기능을 사용하는 다른 방법을 알려주며, 기능에 클릭 유도 문구 이상의 안내가 필요할 때 유용하다.
  • 도움말 콘텐츠가 보이도록 하되, 처음부터 너무 많은 정보로 사용자를 압도하지 말고 점진적 공개(progressive disclosure)를 통해 필요할 때 더 많은 세부 정보를 제공해야 한다.
  • 사용 예시: 암시적 발견으로 충분하지 않을 때, 즉 사용자가 익숙하지 않아 추가 정보가 필요한 '복잡하거나 새로운 기능'이거나 다른 작업들에 밀려 눈에 띄지 않는 '제한된 가시성'을 가진 기능일 때 사용한다.
• 방해적 발견 (Disruptive discovery - 드물게 사용): 배너나 모달 등 사용자의 흐름을 방해하는 방식으로 기능이나 정보가 제공된다.
  • 문맥적 알림보다 더 눈에 띄지만, 알림이 방해적이고 현재 문맥과 일치하지 않으면 사용자가 무관하다고 느끼고 무시해버려 효과가 제한적일 수 있다.
  • 사용 예시: 조직 정책 준수 등 '중요한 알림', 필수 기능을 안내하는 '사용자 온보딩', 작업 흐름을 바꿀 수 있는 '상당한 변경 사항'이 있을 때 사용한다.
  • 단, 눈에 띄는 알림과 경고가 너무 많으면 사용자가 압도당하고 중요한 메시지에 둔감해질 수 있으므로 사용자의 작업 흐름에 이미 어떤 알림이 있는지 주의해야 한다.

---

잘 설계된 온보딩 프로세스는 사용자에게 새로운 기능이나 제품 단계를 소개하는 효과적인 방법이다. 하지만 주된 목표는 사용자가 이러한 기능과 단계를 통해 얻는 '가치'를 보여주는 것이다.

온보딩 경험을 위한 가이드라인 (Guidelines for onboarding experiences)

• 사용자에게 제공하려는 가치를 파악하고 이를 바탕으로 역산하라. 단순히 보여주고 싶은 기능이 있다는 것은 온보딩의 좋은 이유가 아니다. 새로운 기능이 제공하는 사용자 대면 가치는 무엇이며 어떤 이점을 얻을 수 있는지 확인해야 한다.
• 사용자가 거부할 수 있도록 "아니요, 괜찮습니다(No, thanks)" 옵션을 제공하라.

사용자의 문맥 고려하기 (Think about the user's context)

사용자가 앱의 어디에 있는지, 무엇을 하고 있는지, 소개하려는 내용에 얼마나 익숙한지 파악해야 한다. 또한 작업을 수행할 능력이나 동기가 충분한지, 부족하다면 어떻게 높일 것인지, 프롬프트가 문맥에 맞도록 어디에 배치할 것인지 고민해야 한다.

초기 프롬프트 패턴 (Patterns for initial prompts)

온보딩 흐름을 시작하기 위해 다음과 같은 초기 프롬프트 패턴을 사용할 수 있다.

• 팝오버 (Popover - 개입 높음, 효과 높음): UI에 큰 변경이 필요하지 않다. 복잡한 흐름의 중간이 아닌 시작이나 끝에 사용하며, 사용자를 다른 페이지로 안내할 때 유용하다.
• UI 수정 (UI modification - 개입 중간, 효과 중간): 재사용 가능한 컴포넌트가 아니며 UI에 상당한 변경이 필요하다 (예: 병합 요청 페이지에 파이프라인이 없을 때 빈 파이프라인 위젯 표시).

배달 앱에 처음 가입해서 주문을 하려는 상황을 가정해 보자.

원래 화면: 정상적인 상태라면 '주문하기' 화면에 내 주변의 맛집 목록이 주르륵 나와야 한다.
기능/데이터가 없는 상태: 하지만 사용자가 아직 배송지 주소를 등록하지 않아 주변 가게를 불러올 수 없다.

UI 수정 패턴 적용: 이때 화면 위에 뜬금없이 "주소를 입력하세요!"라는 경고창(팝오버)을 띄우는 것이 아니다. 가게 목록이 나와야 할 기존 화면 레이아웃 자체를 직접 수정하여, 그 자리에 귀여운 캐릭터 일러스트와 함께 "배달받으실 주소를 먼저 입력해 주세요"라는 맞춤형 안내 카드(위젯)를 화면의 일부로 직접 그려 넣는 것이다.

1) UI에 상당한 변경 필요: 화면 위에 임시 창을 얹는 게 아니라, 주소 미등록 상태일 때만 보이도록 페이지 레이아웃 구조 자체를 직접 변경해야 한다.
2) 재사용 불가능한 컴포넌트: 이 주소 설정 유도 영역은 오직 '주소 미등록 시의 주문 화면'이라는 특정 상황과 위치만을 위해 맞춤 디자인된 것이라, 앱 내의 다른 화면에 똑같이 재사용할 수 없다.

• 배너 (Banner - 개입 낮음, 효과 낮음): 기본 요소의 배치 변경 등 UI에 상당한 변화가 필요할 수 있다. 

모달(Modal)이나 팝오버(Popover)는 원래 화면 레이아웃 위에 둥둥 떠 있는 '오버레이(Overlay)' 방식이라 기존 요소를 건드리지 않는다. 반면, 배너는 페이지 상단이나 특정 영역 사이에 직접 끼어 들어가는(Inline) 방식이다. 따라서 배너가 나타나면 기존에 배치되어 있던 화면의 기본 구성 요소들이 아래나 옆으로 물리적(혹은 시각적)으로 밀려나게 된다.

• 빈 상태 (Empty state - 개입 낮음, 효과 높음): 표시할 콘텐츠가 없기 때문에 방해가 되지 않아 훌륭한 온보딩 출발점이 된다. 문맥을 제공하고 가치를 설명하며 클릭 유도 문구(CTA)를 제공할 수 있다.

[예시] '할 일 관리(To-do)' 앱을 처음 켰을 때
문서에 제시된 가이드라인에 따라 이 빈 화면을 설계해 보면 다음과 같다.
❌ 나쁜 빈 상태 설계 (피해야 할 방식)
텍스트: "등록된 할 일이 없습니다."
버튼: [추가하기] (사용자가 얻을 가치가 전혀 느껴지지 않는 불친절한 방식)
✅ 좋은 빈 상태 설계 (Pajamas 추천 방식)
1) 이유(맥락) 제공: "아직 오늘 해야 할 일을 등록하지 않았다." (왜 이 화면이 비어 있고 가이드가 뜨는지 설명)
2) 가치 설명: "여기에 오늘 마칠 핵심 작업 3가지만 적어두어도 업무 효율이 2배로 올라간다." (이 기능을 쓰면 사용자에게 어떤 이득이 있는지 명시)
3) 가치 중심의 CTA(버튼): [오늘의 첫 할 일 등록하기] (단순히 '추가하기' 같은 기계적인 문구 대신, 사용자가 얻을 가치와 행동을 구체적으로 연결)

문구 작성 및 문맥 제공 권장 사항 (Recommendations for writing copy and providing context)

• 초기 프롬프트가 표시되는 이유를 항상 설명하라 (예: "코드 품질을 확인하기 위한 파이프라인이 없습니다. 빠르게 설정하는 방법을 알려드릴 수 있습니다.").
• 사용자가 얻게 될 가치가 무엇인지 설명하라 (예: "코드를 더 안전하고 견고하게 만들어 줄 것입니다.").
• '시작하기'나 '방법 보기' 같은 일반적인 클릭 유도 문구(CTA)는 피하라. 대충 읽더라도 무엇을 하고 어떤 결과를 얻을지 알 수 있도록 사용자가 얻을 가치를 알려주는 구체적인 문구(예: '코드 보안 적용하기')를 사용하라.

후속 프롬프트 (Follow-up prompts)

온보딩 흐름이 여러 페이지에 걸쳐 진행될 때는 팝오버 컴포넌트를 사용하여 사용자가 올바른 경로를 유지하도록 하라. 팝오버가 눈에 띄도록 페이지가 로드된 후 짧은 지연 시간을 두고 애니메이션과 함께 나타나도록 할 수 있다.

몇 단계로 구성해야 하는가? (How many steps?)

온보딩 흐름이 여러 단계(및 페이지)로 확장될 때는 3단계를 목표로 하고, 최대 5단계를 넘지 않아야 한다. 더 많은 단계가 필요하다면 여러 개의 작은 흐름으로 나누는 것을 고려하라. 단계가 많을수록 사용자가 완료할 가능성이 줄어든다.

---

아무리 혁신적인 기술과 기능이라도 사용자가 그 존재를 모르거나 사용법이 너무 복잡하다면 결국 가치를 잃고 만다. 하지만 더 큰 문제는 '자랑하고 싶은 공급자의 조급함'이 사용자의 화면을 방해적인 알림으로 가득 채워 피로감을 줄 수 있다는 것이다. 가장 훌륭한 온보딩은 사용자가 도중에 하던 일을 멈추거나 방해받지 않고도, 서비스 안에서 유기적으로 가치를 찾아내게 돕는 것이다. 사용자의 문맥에 부드럽게 스며드는 친절한 안내판을 제공하여 사용자가 제품의 진정한 가치를 스스로 발견하는 것이 지속 가능한 제품 성장을 이끄는 UX 설계의 지향점이라는 생각이 든다. 굿!