- É uma biblioteca JavaScript leve que permite adicionar tours de produto e destaques a telas em que é necessário orientar usuários dentro do produto
- Funciona com base em Vanilla JavaScript, não tem dependências e oferece suporte aos principais navegadores e dispositivos móveis
- É um projeto open source sob licença MIT, escrito em TypeScript, com foco em customização e suporte à acessibilidade
- É voltada para fluxos de orientação dentro do produto, como onboarding de usuários, foco de atenção, ajuda contextual e incentivo à adoção de novos recursos
- Tem milhões de downloads e 26K estrelas no GitHub; exemplos iniciais e documentação podem ser consultados na documentação oficial
Natureza da biblioteca e escopo de suporte
- Driver.js é uma biblioteca JavaScript leve que ajuda usuários a entender um produto por meio de tours de produto, destaques e ajuda contextual
- Por ser baseada em Vanilla JavaScript, pode ser usada sem dependências adicionais e foi escrita em TypeScript
- As características em termos de suporte e configuração são as seguintes
- Suporte aos principais navegadores e dispositivos móveis
- Alto nível de customização
- Estrutura leve e recursos abrangentes
- Licença MIT
- API fácil de usar
- Suporte à acessibilidade
- Pronta para frameworks
Como pode ser usada dentro do produto
- Onboarding de usuários: permite orientar passo a passo sobre como usar o produto e responder a perguntas comuns
- Eliminação de distrações: destaca elementos importantes para concentrar a atenção do usuário em áreas específicas
- Ajuda contextual: permite oferecer instruções de uso e ajuda no momento em que são necessárias dentro do produto
- Adoção de recursos: destaca novos recursos e explica como usá-los para que os usuários não os deixem passar
Documentação e informações do projeto
- Mais exemplos e a forma de começar estão disponíveis na documentação
- O repositório no GitHub é kamranahmedse/driver.js, e o número de estrelas exibido no GitHub é 26K
1 comentários
Opiniões no Hacker News
Não, o produto deve ser projetado para ser compreensível mesmo à primeira vista
A Apple é famosa por quase não fazer esse tipo de coisa no iPhone, enquanto a Sony obriga esse processo em todo dispositivo novo
O onboarding deveria servir para impulsionar a usabilidade; isso não é uma ferramenta auxiliar, é algo pior e prejudicial
A usabilidade do iOS é uma bagunça, falta affordance e a descobribilidade é baixa
Há formas demais de entrada que você não conhece se ninguém contar ou se não pesquisar, principalmente gestos, e elas não são consistentes entre apps, nem mesmo entre os apps nativos da Apple
Às vezes “deslizar uma linha para a esquerda” significa “excluir”, outras vezes significa “mais ações”; é tudo uma confusão
Quando você vê usuários não técnicos usando um iPhone, muitas vezes eles não conhecem nem metade das funções disponíveis. Por exemplo, você já viu alguém usar “agitar para desfazer”?
Mas recentemente me cadastrei no HubSpot como CRM e, embora no geral eu tenha achado o produto bem organizado e intuitivo, é difícil, ou quase impossível, torná-lo tão intuitivo quanto um smartphone. Nesses casos, tours pelo produto ajudam bastante
Ou seja, parece mais um ideal inalcançável que não existe na realidade
Com o nível atual de experiência do usuário, é difícil acreditar que seja possível criar uma UI que não precise de tours pelo produto, documentação, tutoriais em vídeo etc.; e isso é ainda mais verdadeiro a partir de produtos com alguma complexidade
Mas é diferente nos apps B2B, onde tutoriais de demonstração de produto são usados com mais frequência. Um bom tutorial de produto é útil para que vendedores conduzam o cliente pelo app e consigam vendê-lo corretamente a potenciais clientes
Se o tamanho do contrato é de dezenas a centenas de milhares de dólares e o produto também é bastante complexo, é uma solução melhor do que equipes de vendas e suporte ficarem apagando incêndios o tempo todo
Sou só eu que fecho essas coisas o mais rápido possível e resmungo de irritação?
Normalmente dá para pular, mas quase nunca é fácil encontrar como começar de novo depois que você decide aprender o app direito
Também é bom para mostrar novos recursos que foram solicitados, mas que não justificam ocupar espaço na tela principal
Só irrita quando aponta para coisas óbvias
Entre o que ajuda e o que é hostil não existe uma linha tênue, mas uma linha grande e clara com luzes piscando e sirenes
Como usuário de produtos, odeio tours pelo produto, mas, como desenvolvedor de produto, sempre acabo querendo uma alternativa open source
Esta biblioteca parece bem legal, pois os efeitos são suaves
Pessoalmente, pelo que vi ao criar alguns produtos, mesmo os tours de produto mais bem projetados são fechados por cerca de 90% das pessoas em produtos para PMEs e consumidores
Gosto um pouco desse tipo de recurso
Não force em usuários novos; basta perguntar se eles querem fazer o tour
Use com parcimônia apenas quando houver um novo recurso, botão ou mudança no app, mostre só uma vez por sessão, e seria bom se o prompt tivesse as opções “fechar/fazer tour”
É melhor que a experiência do usuário do app seja intuitiva, mas um tour não obrigatório pode ajudar
É melhor do que uma tela intermediária de login para anunciar recursos
Muitos designers parecem achar que, quando abro um app, estou pensando “que alegria será que essas pessoas maravilhosas prepararam para mim hoje?” e que tenho tempo sobrando
Na realidade, na maioria das vezes abro o app porque quero concluir uma tarefa específica agora, e esse é o momento em que estou menos receptivo a alguém me enfiando fotos do seu filho-produto na cara e me fazendo dizer “sim, é muito bonito”
O momento em que eu realmente estou aberto a um tour é depois de terminar a tarefa, ou quando acabei de perceber que não sei como fazer o que estou tentando fazer
Tours pelo produto nem sempre são ruins, mas é comum que sejam mal implementados, com etapas demais que não significam nada para o usuário
Onboarding contextual, como dicas incorporadas, relevante, como onboarding personalizado por persona, ou orientado à ação, como checklists, costuma ser melhor
Depois de liderar a equipe de onboarding e educação dentro do app no Dropbox, fundei a Dopt [0], que é uma biblioteca de componentes React e um SDK para facilitar a criação não só de tours, mas também de experiências de onboarding mais contextuais e menos intrusivas, como dicas incorporadas e checklists
Com a Dopt, quando necessário, também dá para criar coisas como um tour de 2 etapas para apresentar um novo recurso, mas queremos oferecer uma caixa de ferramentas maior e melhor para todos os tipos de onboarding e educação
[0] https://dopt.com/
E também fico curioso sobre “Hybrid work”
Por fora, é bom que isso esteja explicitado de antemão, mas, havendo estudos[0] mostrando que trabalho 100% remoto leva a funcionários mais produtivos, fico curioso sobre por que decidiram que o híbrido é a solução
[0]: https://thehill.com/business/4110598-remote-employees-work-l...
Parece bom. O que há de diferente em comparação com o Shepherd[0]?
[0]: https://github.com/shipshapecode/shepherd
https://devboard.gitsense.com/shipshapecode/shepherd
https://devboard.gitsense.com/kamranahmedse/driver.js
A popularidade do driver.js cresceu bastante nas últimas semanas, mas não sei bem o motivo
Para referência, essa é uma ferramenta que eu criei
O problema com tours desse tipo é que eles jogam informação demais na sua cara em pouco tempo e depois somem
Alguns minutos depois, o usuário acaba perguntando: “para que servia mesmo esta área?”
Usei isso uma vez ao criar uma plataforma de controle de drones; como o dashboard era complexo, era preciso saber antes de clicar quais áreas eram de controle e quais eram para o feed de vídeo
Mas os usuários muitas vezes nem liam, só assentiam com a cabeça e clicavam em próximo; no fim, removemos isso e colocamos ícones de informação em cada área, para que a explicação aparecesse ao passar o mouse
Criei a biblioteca https://github.com/Evernote/Aquaman para fazer algo parecido em apps Redux. Também fiz algo igual para React context, mas não foi publicado como open source
O que falta aqui é que 1) o estado do app pode precisar disparar um tour guiado, 2) em algum momento provavelmente será necessário um fluxo com várias etapas, e 3) a lógica de alteração de estado desse fluxo deve ser separada da lógica de renderização
Todas as etapas do fluxo precisam ficar juntas. Com o Aquaman, dava para implementar isso
Como usuário, eu não gosto, mas, como desenvolvedor, é uma boa biblioteca para atender às demandas da equipe de produto
Hoje vi uma demo do Walnut.io [1] para outro produto; pulei a maior parte e entendi quase nada sobre o produto
Acho que isso depende mais de quem monta o tour do produto e de como ele é montado do que da ferramenta em si
Alguns produtos são complexos e podem precisar de explicações ou da orientação de um engenheiro de soluções ou de um gerente de conta. Não existe produto tão incrível que não precise de nenhuma ajuda ou tour do produto
[1] https://walnut.io