Driver.js: 제품 투어·하이라이트·문맥적 도움을 위한 Vanilla JS 라이브러리

 (driverjs.com)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 제품 안에서 사용자를 안내해야 하는 화면에 제품 투어와 하이라이트를 붙일 수 있는 경량 JavaScript 라이브러리임
  • Vanilla JavaScript 기반으로 동작하며 의존성이 없고, 주요 브라우저와 모바일 기기를 지원함
  • TypeScript로 작성된 MIT 라이선스 오픈소스이며, 커스터마이즈와 접근성 지원을 내세움
  • 사용자 온보딩, 주의 집중, 문맥적 도움, 신규 기능 채택 유도 같은 제품 내 안내 흐름에 맞춰져 있음
  • 수백만 다운로드와 GitHub Star 26K를 보유했고, 시작 예제와 문서는 공식 문서에서 확인할 수 있음

라이브러리 성격과 지원 범위

  • Driver.js는 제품 투어, 하이라이트, 문맥적 도움으로 사용자가 제품을 이해하도록 돕는 경량 JavaScript 라이브러리임
  • Vanilla JavaScript 기반이라 별도 의존성 없이 사용할 수 있으며, TypeScript로 작성됨
  • 지원·구성 측면의 특징은 다음과 같음
    • 주요 브라우저와 모바일 기기 지원
    • 높은 커스터마이즈 가능성
    • 경량 구성과 풍부한 기능
    • MIT 라이선스
    • 사용하기 쉬운 API
    • 접근성 지원
    • 프레임워크 준비됨

제품 안에서의 활용 방식

  • 사용자 온보딩: 제품 사용법을 단계적으로 설명하고 일반적인 질문에 답하도록 안내할 수 있음
  • 주의 분산 제거: 중요한 요소를 하이라이트해 사용자의 시선을 특정 영역에 집중시킬 수 있음
  • 문맥적 도움: 제품 안에서 필요한 순간에 사용법과 도움말을 제공할 수 있음
  • 기능 채택: 새 기능을 하이라이트하고 사용법을 설명해 사용자가 놓치지 않도록 할 수 있음

문서와 프로젝트 정보

  • 더 많은 예제와 시작 방법은 문서에서 제공됨
  • GitHub 저장소는 kamranahmedse/driver.js이며, GitHub Star는 26K로 표시됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 아니, 제품은 처음 봐도 이해되게 설계해야 함
    Apple은 iPhone에서 이런 걸 거의 하지 않는 것으로 유명한 반면, Sony는 새 기기마다 이런 절차를 강요함
    온보딩이 사용성을 밀어붙이는 장치가 되게 해야지, 이건 보조 도구가 아니라 더 나쁘고 해로운 것임

    • “Apple은 iPhone에서 이런 걸 거의 하지 않는다”는 말은 오히려 제품 둘러보기가 필요하다는 쪽에 가까움
      iOS의 사용성은 엉망이고, 행동 유도성이 부족하며, 발견 가능성도 낮음
      아무도 알려주거나 검색하지 않으면 모르는 입력 방식, 주로 제스처가 너무 많고, 앱마다 심지어 Apple 기본 앱끼리도 일관되지 않음
      어떤 때는 “행을 왼쪽으로 밀기”가 “삭제”이고, 어떤 때는 “추가 작업”이라 그냥 뒤죽박죽임
      비기술 사용자가 iPhone을 쓰는 모습을 보면 가능한 기능의 절반도 모르는 경우가 많음. 예를 들어 “흔들어서 실행 취소”를 쓰는 사람을 본 적이 있나?
    • 그래서 iPhone 사용자 절반이 아직도 키보드나 스페이스바를 길게 눌러 커서 제어를 할 수 있다는 걸 모르는 것일 수도 있음. 이건 한 가지 예일 뿐임
    • 모든 것에 이 방식이 실용적인 건 아님. 휴대폰은 직관적이어야 하고, 더 중요하게는 처음부터 모든 동작 방식을 알 필요가 없으며 시간이 지나며 익힐 수 있음
      하지만 최근 CRM으로 HubSpot에 가입해 보니, 전체적으로 잘 정리되고 직관적인 제품이라고 느끼면서도 스마트폰만큼 직관적으로 만들기는 어렵거나 불가능에 가까움. 이런 경우 제품 둘러보기가 꽤 도움이 됨
    • 사용성과 발견 가능성을 항상 원한다는 데는 동의함. 하지만 모든 것을 언제나 그냥 발견할 수 있어야 한다는 주장은 전설 속의 충분히 똑똑한 컴파일러 논의처럼 들림
      현실에 존재하지 않는 달성 불가능한 이상에 가깝다는 뜻임
      현재 사용자 경험 수준에서 제품 둘러보기, 문서, 동영상 튜토리얼 등이 전혀 필요 없는 UI를 만들 수 있다고 확신하기 어렵고, 적어도 어느 정도 복잡한 제품부터는 더 그렇다
    • 소비자용 앱이라면 대체로 맞는 말이라고 봄
      하지만 제품 데모 튜토리얼이 주로 쓰이는 B2B 앱은 다름. 좋은 제품 튜토리얼은 영업 담당자가 고객에게 앱을 안내하며 잠재 고객에게 제대로 판매하는 데 유용함
      계약 규모가 수만~수십만 달러이고 제품도 꽤 복잡하다면, 영업·지원 인력이 계속 불을 끄듯 대응하는 것보다 나은 해법임

  • 이런 것들을 최대한 빨리 닫아버리면서 짜증 난다고 투덜대는 게 나뿐인가?

    • 나도 그렇지만, 공평하게 보자면 HN에 있는 우리 같은 기술 사용자가 이런 걸 통합한 제품의 주 대상 사용자는 아닐 가능성이 큼
    • 건너뛸 수 있고 나중에 다시 할 수도 있다면 괜찮다고 봄
      보통 건너뛰기는 가능하지만, 앱을 제대로 배워보겠다고 마음먹은 뒤에 다시 시작하는 방법은 거의 찾기 어려움
    • 사용 사례에 따라 다름. 사용자를 온보딩할 때 기본적인 작업을 어떻게 해야 할지 몰라서 오는 지원 메일을 줄여줌
      또 메인 화면 공간을 차지할 정도는 아니지만 요청이 있었던 새 기능을 보여주는 데도 좋음
      뻔한 걸 가리킬 때만 짜증남
    • 보통은 나쁜 설계를 보완하는 목발처럼 느껴지지만, 어떤 제품은 어쩔 수 없이 복잡도가 있음
    • UI 개념에서 이런 것, 앱 다운로드 팝업, 메일링 리스트 팝업, 또 앱 다운로드, 소셜 미디어 팔로우, 또 앱 다운로드 같은 걸 몇 번 잔소리라고 부르는 걸 봤음. 아마 “엿 먹어”라고 부르기엔 글자가 너무 많아서일 것임
      도움이 되는 것과 적대적인 것 사이에는 미세한 선이 있는 게 아니라, 번쩍이는 불빛과 사이렌이 달린 크고 뚜렷한 선이 있음

  • 제품 사용자로서는 제품 둘러보기를 싫어하지만, 제품 개발자로서는 항상 오픈소스 대안을 바라게 됨
    이 라이브러리는 효과가 매끄러워 보여서 꽤 멋짐
    개인적으로 몇몇 제품을 만들며 봤을 때, 가장 잘 설계된 제품 둘러보기조차 중소기업·소비자 제품에서는 90% 정도가 닫혀버림

  • 이런 기능은 조금은 좋아함
    새 사용자에게 강요하지 말고 둘러볼지 물어보면 됨
    앱에 새 기능, 버튼, 변경사항이 추가됐을 때만 아껴서 쓰고, 세션당 한 번만 보여주며, 프롬프트는 “닫기/둘러보기” 선택지면 좋음
    앱의 사용자 경험이 직관적인 편이 더 낫지만, 강제하지 않는 둘러보기는 도움이 될 수 있음
    기능 발표용 로그인 중간 화면보다는 낫다

    • 제발 괜찮은 문서와 둘러보기를 다시 실행할 기회를 담은 도움말 메뉴를 어딘가에 제공해 줬으면 함
      많은 디자이너가 내가 앱을 열 때 “오늘 이 멋진 사람들이 어떤 즐거움을 준비했을까?”라고 생각하며 시간이 남아도는 줄 아는 것 같음
      실제로는 지금 당장 특정한 일을 끝내려고 앱을 여는 경우가 대부분이고, 그 순간은 누군가가 자기 제품 자식 사진을 들이밀며 “네, 정말 예쁘네요”라고 말하게 만드는 데 가장 덜 수용적인 때임
      내가 실제로 둘러보기에 열려 있는 시점은 작업을 끝낸 뒤이거나, 하려는 일을 어떻게 해야 할지 모르겠다는 걸 막 깨달았을 때임

  • 제품 둘러보기가 항상 나쁜 건 아니지만, 사용자에게 의미 없는 단계가 너무 많아 구현이 서툰 경우가 흔함
    내장형 팁처럼 맥락에 맞거나, 페르소나별 맞춤 온보딩처럼 관련성이 있거나, 체크리스트처럼 행동 지향적인 온보딩이 대체로 더 나음
    Dropbox에서 온보딩과 앱 내 교육 팀을 이끈 뒤 Dopt [0]를 시작했는데, 이건 둘러보기뿐 아니라 내장형 팁과 체크리스트처럼 더 맥락적이고 덜 방해되는 온보딩 경험을 쉽게 만들기 위한 React 컴포넌트 라이브러리와 SDK임
    Dopt로 필요한 경우에는 새 기능 소개용 2단계 둘러보기 같은 것도 만들 수 있지만, 모든 종류의 온보딩과 교육을 위한 더 크고 나은 도구상자를 제공하고 싶음
    [0] https://dopt.com/

    • 왜 웹사이트에서 쿠키를 수집해야 하는지 궁금함. 처음 마주치는 게 쿠키 알림 화면이라 무엇을 추적하는지 의문이 듦
      그리고 “Hybrid work”도 궁금함
      겉으로 보기엔 미리 명시한 건 좋지만, 100% 원격 근무가 더 생산적인 직원으로 이어진다는 연구[0]가 있는 상황에서 왜 하이브리드를 해법으로 정했는지 궁금함
      [0]: https://thehill.com/business/4110598-remote-employees-work-l...

  • 좋아 보임. Shepherd[0]와 비교해 무엇이 다른가?
    [0]: https://github.com/shipshapecode/shepherd

  • 이런 식의 둘러보기 문제는 짧은 시간에 너무 많은 정보를 얼굴 앞에 들이밀고 사라진다는 데 있음
    몇 분 뒤 사용자는 “이 구역이 뭐 하는 곳이었지?”라고 묻게 됨
    예전에 드론 조종 플랫폼을 만들 때 써봤는데, 대시보드가 복잡해서 어떤 구역은 조종용이고 어떤 구역은 영상 피드용이라 클릭하기 전에 알아야 했음
    그런데 사용자들은 읽지도 않고 고개를 끄덕이며 다음만 누르기 일쑤였고, 결국 제거한 뒤 각 구역에 정보 아이콘을 달아 마우스를 올리면 설명을 볼 수 있게 바꿨음

  • Redux 앱에서 비슷한 작업을 하려고 https://github.com/Evernote/Aquaman 라이브러리를 만들었음. React context용으로도 같은 걸 만들었지만 오픈소스로 공개되지는 않았음
    여기서 빠진 점은 1) 앱 상태가 가이드형 둘러보기를 트리거해야 할 수 있고, 2) 언젠가는 여러 단계 흐름이 필요할 가능성이 높으며, 3) 그 흐름의 상태 변경 로직은 렌더링 로직과 분리되어야 한다는 것임
    흐름의 모든 단계는 함께 있어야 함. Aquaman으로는 그걸 구현할 수 있었음

  • 사용자로서는 싫지만, 개발자로서는 제품팀 요구를 만족시키기 좋은 라이브러리임

  • 오늘 다른 제품용 Walnut.io [1] 데모를 봤는데, 대부분 건너뛰었고 제품에 대해서도 거의 이해하지 못했음
    도구 자체보다 제품 둘러보기 구성을 누가 어떻게 하느냐에 달려 있다고 봄
    어떤 제품은 복잡해서 설명이나 솔루션 엔지니어, 계정 담당자의 안내가 필요할 수 있음. 도움이나 제품 둘러보기가 전혀 필요 없을 만큼 놀라운 제품은 없음
    [1] https://walnut.io

답변달기