Driver.js: biblioteca de Vanilla JS para tours de producto, resaltado y ayuda contextual

 (driverjs.com)
4 puntos por GN⁺ 2023-07-25 | 1 comentarios | Compartir por WhatsApp
  • Es una biblioteca ligera de JavaScript que permite añadir tours de producto y resaltado en pantallas donde necesitas guiar a los usuarios dentro del producto
  • Funciona con Vanilla JavaScript, no tiene dependencias y es compatible con los principales navegadores y dispositivos móviles
  • Es un proyecto open source con licencia MIT escrito en TypeScript, con énfasis en la personalización y el soporte de accesibilidad
  • Está orientada a flujos de guía dentro del producto como onboarding de usuarios, enfoque de atención, ayuda contextual e impulso a la adopción de nuevas funciones
  • Cuenta con millones de descargas y 26K estrellas en GitHub; los ejemplos iniciales y la documentación pueden consultarse en la documentación oficial

Naturaleza de la biblioteca y alcance de soporte

  • Driver.js es una biblioteca ligera de JavaScript que ayuda a los usuarios a comprender el producto mediante tours de producto, resaltado y ayuda contextual
  • Al estar basada en Vanilla JavaScript, puede usarse sin dependencias adicionales y está escrita en TypeScript
  • Sus características en términos de soporte y configuración son las siguientes
    • Compatibilidad con los principales navegadores y dispositivos móviles
    • Alta capacidad de personalización
    • Estructura ligera y funciones abundantes
    • Licencia MIT
    • API fácil de usar
    • Soporte de accesibilidad
    • Lista para frameworks

Formas de uso dentro del producto

  • Onboarding de usuarios: permite explicar paso a paso cómo usar el producto y guiar para responder preguntas comunes
  • Eliminación de distracciones: permite resaltar elementos importantes para enfocar la mirada del usuario en un área específica
  • Ayuda contextual: permite ofrecer instrucciones de uso y ayuda justo en el momento necesario dentro del producto
  • Adopción de funciones: permite resaltar nuevas funciones y explicar cómo usarlas para que los usuarios no las pasen por alto

Documentación e información del proyecto

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-07-25
Opiniones en Hacker News

  • No, los productos deberían estar diseñados para entenderse aunque sea la primera vez que los ves.
    Apple es famosa por casi no hacer esto en el iPhone, mientras que Sony obliga a pasar por este proceso con cada dispositivo nuevo.
    El onboarding debería ser algo que impulse la usabilidad; esto no es una herramienta de apoyo, sino algo peor y dañino.

    • Decir que “Apple casi no hace esto en el iPhone” más bien apunta a que hace falta un recorrido del producto.
      La usabilidad de iOS es un desastre, tiene poca affordance y baja descubribilidad.
      Hay demasiadas formas de entrada, sobre todo gestos, que no conoces si nadie te las dice o no las buscas, y no son consistentes entre apps, ni siquiera entre las apps básicas de Apple.
      A veces “deslizar una fila hacia la izquierda” significa “eliminar”, y otras veces “más acciones”; es un caos.
      Cuando ves a usuarios no técnicos usando un iPhone, muchas veces no conocen ni la mitad de las funciones disponibles. Por ejemplo, ¿alguna vez has visto a alguien usar “agitar para deshacer”?
    • Por eso quizá la mitad de los usuarios de iPhone todavía no sabe que puede mantener presionado el teclado o la barra espaciadora para controlar el cursor. Y eso es solo un ejemplo.
    • Este enfoque no es práctico para todo. Los teléfonos deben ser intuitivos y, más importante aún, no hace falta conocer desde el principio todas las formas de interacción; puedes aprenderlas con el tiempo.
      Pero hace poco me registré en HubSpot como CRM y, aunque en general me pareció un producto bien organizado e intuitivo, hacerlo tan intuitivo como un smartphone es difícil o casi imposible. En casos así, un recorrido del producto ayuda bastante.
    • Estoy de acuerdo en que siempre queremos usabilidad y descubribilidad. Pero afirmar que todo debería poder descubrirse siempre por sí solo suena como el debate del mítico compilador suficientemente inteligente.
      Es decir, se parece a un ideal inalcanzable que no existe en la realidad.
      Con el nivel actual de experiencia de usuario, me cuesta creer que podamos crear una UI que no necesite en absoluto recorridos del producto, documentación, tutoriales en video, etc., al menos a partir de productos con cierta complejidad.
    • Creo que en general eso es cierto para apps de consumo.
      Pero es distinto en las apps B2B, donde suelen usarse tutoriales de demo del producto. Un buen tutorial de producto le sirve al vendedor para guiar al cliente por la app y venderla bien a un prospecto.
      Si el contrato es de decenas o cientos de miles de dólares y el producto es bastante complejo, es una mejor solución que tener al equipo de ventas y soporte apagando incendios constantemente.

  • ¿Soy el único que cierra estas cosas lo más rápido posible mientras se queja de lo molestas que son?

    • Yo también, pero siendo justos, es muy probable que los usuarios técnicos como nosotros en HN no sean el público principal de los productos que integran estas cosas.
    • Si se pueden omitir y también volver a hacer más tarde, me parece bien.
      Normalmente se pueden omitir, pero casi nunca es fácil encontrar cómo reiniciarlas cuando uno decide que sí quiere aprender bien la app.
    • Depende del caso de uso. Al hacer onboarding de usuarios, reduce los correos a soporte de gente que no sabe cómo hacer tareas básicas.
      También sirve para mostrar funciones nuevas que fueron solicitadas, pero que no ameritan ocupar espacio en la pantalla principal.
      Solo molesta cuando señala cosas obvias.
    • Normalmente se siente como una muleta para compensar un mal diseño, pero algunos productos inevitablemente tienen complejidad.
    • En conceptos de UI he visto que a estas cosas —popups para descargar la app, popups de listas de correo, otra vez descargar la app, seguir en redes sociales, otra vez descargar la app— las llaman nagging unas cuantas veces. Probablemente porque “vete al diablo” tiene demasiados caracteres.
      Entre lo útil y lo hostil no hay una línea fina, sino una línea grande y clara con luces intermitentes y sirenas.

  • Como usuario de productos odio los recorridos del producto, pero como desarrollador de productos siempre termino queriendo una alternativa open source.
    Esta biblioteca se ve bastante genial porque los efectos parecen fluidos.
    Por lo que he visto personalmente al crear algunos productos, incluso los recorridos de producto mejor diseñados se cierran alrededor del 90% de las veces en productos para pymes y consumidores.

  • Me gustan un poco estas funciones.
    No las impongas a los usuarios nuevos; pregúntales si quieren hacer el recorrido.
    Úsalas con moderación solo cuando se agregue una función nueva, un botón o un cambio en la app; muéstralas solo una vez por sesión, y que el prompt tenga opciones de “Cerrar/Recorrer”.
    Es mejor que la experiencia de usuario de la app sea intuitiva, pero un recorrido no obligatorio puede ayudar.
    Es mejor que una pantalla intermedia durante el inicio de sesión para anunciar funciones.

    • Por favor, ojalá ofrecieran en algún lugar un menú de ayuda con buena documentación y la posibilidad de volver a ejecutar el recorrido.
      Muchos diseñadores parecen creer que cuando abro una app pienso “¿qué delicia habrán preparado hoy estas personas tan geniales?” y que me sobra el tiempo.
      En realidad, la mayoría de las veces abro la app porque necesito terminar algo específico ahora mismo, y ese es el momento en que estoy menos dispuesto a que alguien me ponga enfrente fotos de su hijo-producto y me haga decir “sí, qué bonito”.
      El momento en que de verdad estoy abierto a un recorrido es después de terminar mi tarea, o justo cuando acabo de darme cuenta de que no sé cómo hacer lo que quiero hacer.

  • Los recorridos del producto no siempre son malos, pero es común que estén mal implementados, con demasiados pasos que no significan nada para el usuario.
    En general, es mejor un onboarding contextual, como tips integrados; relevante, como onboarding personalizado por persona; u orientado a la acción, como checklists.
    Después de liderar en Dropbox el equipo de onboarding y educación dentro de la app, lancé Dopt [0], que es una biblioteca de componentes React y un SDK para crear con facilidad experiencias de onboarding más contextuales y menos intrusivas, como tips integrados y checklists, no solo recorridos.
    Con Dopt también puedes crear, cuando haga falta, algo como un recorrido de 2 pasos para presentar una función nueva, pero queremos ofrecer una caja de herramientas más grande y mejor para todo tipo de onboarding y educación.
    [0] https://dopt.com/

    • Me pregunto por qué el sitio web tiene que recopilar cookies. Lo primero que aparece es una pantalla de aviso de cookies, así que me hace preguntar qué están rastreando.
      Y también me da curiosidad lo de “Hybrid work”.
      A primera vista está bien que lo hayan indicado de antemano, pero existiendo estudios[0] que muestran que el trabajo 100% remoto lleva a empleados más productivos, me pregunto por qué decidieron que el modelo híbrido era la solución.
      [0]: https://thehill.com/business/4110598-remote-employees-work-l...

  • Se ve bien. ¿Qué lo diferencia de Shepherd[0]?
    [0]: https://github.com/shipshapecode/shepherd

  • El problema con estos recorridos es que te ponen demasiada información frente a la cara en muy poco tiempo y luego desaparece
    Unos minutos después, el usuario termina preguntando: “¿para qué era esta sección?”
    Lo usé hace tiempo cuando estaba creando una plataforma de control de drones; el dashboard era complejo, así que había que saber antes de hacer clic qué sección era para pilotaje y cuál para el feed de video
    Pero los usuarios muchas veces ni leían, solo asentían y apretaban Siguiente; al final lo quitamos y pusimos íconos de información en cada sección para que pudieran ver la explicación al pasar el mouse

  • Creé la librería https://github.com/Evernote/Aquaman para hacer algo parecido en una app con Redux. También hice lo mismo para React context, pero no se publicó como open source
    Lo que falta aquí es que 1) el estado de la app puede tener que disparar un recorrido guiado, 2) tarde o temprano es muy probable que se necesite un flujo de varios pasos, y 3) la lógica de cambios de estado de ese flujo debería estar separada de la lógica de renderizado
    Todos los pasos del flujo deben estar juntos. Con Aquaman se podía implementar eso

  • Como usuario no me gusta, pero como desarrollador es una buena librería para satisfacer requisitos del equipo de producto

  • Hoy vi una demo de Walnut.io [1] para otro producto; me salté la mayor parte y casi no entendí el producto
    Creo que depende más de quién y cómo arma el recorrido del producto que de la herramienta en sí
    Algunos productos son complejos y pueden necesitar explicación, o la guía de un ingeniero de soluciones o un ejecutivo de cuenta. No existe un producto tan increíble que no necesite ningún tipo de ayuda o recorrido
    [1] https://walnut.io