iHelp

Software CRM

CRM via Whatsapp: Chat de conversa do WhatsApp da empresa com o cliente CRM via Whatsapp: Sicronizando dados CRM via Whatsapp: Todas o histórico de conversas da empresa com cliente CRM via Whatsapp: Filtro de conversas entre empresa e cliente CRM via Whatsapp: Responsável pelo atendimento, atendente ou departamento ou ambos CRM via Whatsapp: Novo atendimento/Nova conversa no WhatsApp CRM via Whatsapp: Agendar o envio de uma mensagem no WhatsApp CRM via Whatsapp: Fluxo de Robô de atendimento automática CRM via Whatsapp: Minha conta CRM via Whatsapp: Controle financeiro do atendimento

iHelp

Software CRM

Habilidades utilizadas

Ferramentas

  • Figma

  • ClickUp

  • Miro

  • Metodologia Scrum

UI Design

  • Princípios do design

  • Design system

  • Wireframe

  • Responsive design

  • Tailwind Framework

UX Design

  • Design Thinking

  • UX Research

  • Emotional Design

  • User Flow

  • StoryBoard

  • Pesquisa de usuário

  • Análise de dados UX

  • Accessibility Design

  • Hierarchy Architecture Information

  • Taxonomic Architecture Information

  • Dev Experience

Descrição

Resumo

O iHelp é um software CRM por meio do WhatsApp. O projeto existe desde 2022 e, quando eu ingressei em julho de 2023, pude perceber várias oportunidades de negócios para o produto, como: desenvolvimento de funcionalidades que agregariam valor ao usuário, redesign do produto como um todo e otimizações no produto com base em feedbacks do usuário e acessibilidade digital.
Fui peça-chave no desenvolvimento do produto da empresa, desde pesquisas com usuários, desenvolvimento da interface e boas práticas na consolidação do processo interno de desenvolvimento do produto.
Ao longo da minha participação na equipe, pudemos notar melhorias em KPIs relevantes da empresa que estão intrinsicamente ligados àusabilidade do produto e experiência do usuário, como:

  • NPS - Aumento de 9,41% no Net Promoter Score (NPS), uma métrica que mede o quanto um cliente estaria disposto a recomendar um produto ou serviço para outra pessoa.

  • Base de usuários - Aumento de 18,95% na base de usuários do iHelp. Graças ao desenvolvimento de novas funcionalidades, melhorias constantes no produto e aumento do NPS.

Aprendizado:

Durante 9 meses contribuindo e trabalhando no desenvolvimento do produto do iHelp, aprendi coisas muito importantes, como:

  • Coesão - Um dos desafios em trabalhar num produto grande é manter a coesão do design. Há momentos em que queremos criar uma nova solução de design para uma funcionalidade, sendo que provavelmente já temos algo pronto para apenas adaptar.

  • Organização - Documentação do processo, informações relevantes e objetivos claros são de extrema importância para uma entrega que respeita prazos com a qualidade requisitada.

  • Alinhamento - Ao participar de uma equipe multidisciplinar, pude entender o quão importante é estar alinhado com as expectativas e também esclarecer as minhas próprias expectativas. Isso corrobora para um ambiente de trabalho confortável, eficiente e dinâmico.

UX Research:

O processo de UX Research fazia parte de qualquer novo projeto do iHelp. Era muito importante garantir que o resultado final seria coeso, estaria dentro das expectativas do nosso usuário e de acordo com o modelo de negócios. O processo:

  • Desk Research:

  • Entender User Flow - A primeira coisa era identificar como determinada funcionalidade se encaixava/encaixaria no fluxo do usuário.

  • Pesquisa de usuário - Após o User Flow, entender quais pontos positivos e quais atritos o usuário teria era muito importante para mitigar riscos e entender oportunidades. Para entender o usuário, havia o seguinte processo:

  • Entrevista com o usuário - Falar com o usuário diretamente e levantar dados a partir de suas respostas.

  • Análise de dados de UX - Utilizávamos ferramentas que metrificavam como o usuário interage com o produto. Ferramentas como Google Analytics medem quais funcionalidades o usuário mais acessa, mapas de calor (onde o usuário mais clica), tempo de usabilidade etc.

  • Conferir documentações anteriores - Tudo era documentado no ClickUp, então era muito útil conferir documentos de projetos parecidos com o que estávamos desenvolvendo.

  • Benchmark - Pesquisar sobre concorrentes diretos e indiretos e a relação deles com o público contribui com as tomadas de decisões de negócios no produto.

  • Discovery - Nessa etapa, era feita uma reunião de alinhamento sobre quais oportunidades de negócios iríamos explorar. Nessa reunião, juntamente com a equipe de dev e marketing, eram apresentadas as funcionalidades que iríamos desenvolver e a motivação para isso.

User Flow (UX Design):

Nessa etapa, seria traçado o plano para o desenvolvimento do projeto. Tendo em vista o objetivo, os dados coletados e as funcionalidades.

  • Brainstorm - Uma reunião para definir os principais pontos do fluxo do usuário e como ficaria cada funcionalidade do fluxo.

  • Documentação do User Flow - Uma documentação do fluxo para começar a desenvolver os wireframes.

  • Alinhamento - Uma reunião para alinhar as expectativas e definição do prazo para entrega com base na documentação do user flow.

Desenvolvimento da interface do usuário (UI):

Na etapa final de desenvolvimento do projeto, nós utilizávamos o Figma, ClickUp, Miro e a metodologia Scrum. As etapas serão listadas abaixo:

  • Wireframes - Com base na documentação do fluxo do usuário, seriam desenvolvidos no Figma os primeiros wireframes das funcionalidades.

  • Alinhamento - Com os Wireframes prontos, era feita uma reunião para validar como seriam as funcionalidades do projeto. Caso fosse necessária alteração, seria feita e apresentada no alinhamento novamente. Após a aprovação, o projeto iria para a etapa de "Em produção".

  • Em produção - Utilizando os wireframes como base, era iniciado o desenvolvimento das funcionalidades e o completo fluxo de usuário do projeto.

  • Design system - Era de extrema importância seguir o design system do projeto, visando manter a coesão.

  • Decisões de design - Todas as tomadas de decisões no desenvolvimento da UI (cores, tipografia, arquitetura de informação, layout, storyboard etc.) eram feitas com base em boas práticas de UX, acessibilidade, dados da UX Research e User Flow.

  • Conclusão - O projeto seria transferido para a etapa de aprovação do PO/PM e Tech Lead.

  • Aguardando aprovação - Uma reunião de apresentação das funcionalidades e do user flow do projeto. O PO/PM e o Tech Lead fariam análise e forneceriam o feedback sobre o resultado final. Caso fossem necessárias alterações, o projeto voltaria para "Em produção" até que fosse aprovado e então enviado para a etapa de fluxo definido.

  • Fluxos - Aqui é a etapa de "passagem de bastão" para os programadores. Era muito importante adaptar a entrega pensando na Dev Experience, ou seja, o arquivo precisava estar organizado e intuitivo para os programadores entenderem o que desenvolver. Aqui seria um ambiente no Figma para os programadores desenvolverem o projeto.

  • Apresentação - Uma reunião entre Tech Lead, equipe de Front-end, PO/PM e o Product Designer (eu) para explicar sobre o fluxo e apresentar todas as funcionalidades do projeto.

  • Alinhamento - Era feito um alinhamento de expectativas e prioridades no produto final entre a equipe de produto e de programadores.

  • Entrega - Fazíamos a entrega do projeto para os programadores e ficávamos acompanhando o progresso do desenvolvimento.

  • No ar - Quando o projeto ficava acessível para o usuário, o projeto que estava em fluxo passaria para o arquivo do Figma "No ar", que funcionava como um repositório.

  • Rollout progressivo - O projeto era entregue aos poucos para a base de usuários. Exemplo da progressão: Primeiro era mostrado para 5% dos usuários, depois para 10%, depois para 20% e assim por diante. A cada etapa da progressão, analisávamos os dados da UX e fazíamos entrevistas com os usuários e, dependendo do resultado dessa pesquisa, eram feitas otimizações e ajustes no projeto.