Workish - Como transformei o bom em ótimo!

Background

Workish é um sistema de controle de ponto projetado para ser integrado ao aplicativo Teamish.

Com uma proposta de ser otimizado, simples e menos burocrático, ele poderia tanto ser um módulo do Teamish quanto um produto comercializado separadamente, ampliando o alcance para um novo público.

Minha participação

Pesquisa: Compreendi os objetivos do projeto e o sentimento dos usuários em relação às suas necessidades.

Análise: Avaliei as forças e fraquezas dos concorrentes, cruzando esses dados com os depoimentos dos usuários.

Desenvolvimento Visual: Criei os fluxos, padrões e a identidade visual do app.

Testes: Validei as hipóteses e ajustei os fluxos com base nos resultados.

Desafio

Os usuários já estavam satisfeitos com o serviço oferecido por uma plataforma concorrente, o que significava que o Workish precisava ser significativamente melhor para conquistar seu espaço.

Além disso, o design do Workish precisava seguir os padrões do Teamish, mas o Design System ainda estava em desenvolvimento, o que exigiu um trabalho simultâneo de criação e padronização.

O começo de tudo

Ao começar qualquer projeto do zero, gosto de estabelecer um ponto de partida claro com base no que já conheço e definir um ponto de chegada. Isso me ajuda a escolher as ferramentas e técnicas mais adequadas para cada caso.

Usei a Matriz CSD em uma planilha do Google para estruturar minhas descobertas, eliminando suposições e guiando o processo de coleta de dados e tomada de decisões de forma mais assertiva. Essa matriz foi ajustada ao longo da jornada do projeto conforme novos insights surgiam.

Matriz CSD

Nada se cria, tudo se copia

Sabendo que os usuários já utilizavam o Pontomais, ele foi o ponto de partida para o benchmarking. Comparei suas funcionalidades com outros players do mercado para levantar hipóteses e entender melhor as expectativas dos usuários.

Coletar feedback de plataformas com acesso restrito foi um desafio, então recorri a resenhas no Google e a contatos pessoais para obter informações. Refinando esses dados no chat-GPT, consegui identificar termos e temas recorrentes que guiaram a próxima fase da pesquisa.

Conectando com os Usuários

Após as comparações e o levantamento de algumas hipóteses, realizei uma pesquisa qualitativa com 25 usuários para validar hipóteses e coletar feedback detalhado, gerando insights valiosos. 

De todos estes usuários, selecionamos um número menor para entrevistas mais aprofundadas, buscando captar sugestões e opiniões mais complexas.

anotações da pesquisa

Estabelecendo as prioridades

Ao longo do processo, recebi feedback contínuo de usuários, stakeholders e equipe de desenvolvimento. Com base nesse feedback, iteramos as soluções para melhor atender às necessidades dos usuários e alinhar com os objetivos do negócio.

Comparando o resultado das pesquisas, houveram 4 grandes pontos de convergência:

– Banco de horas explícito na tela principal.
– Apenas os registros do dia explícitos na tela principal.
– Alerta de pendências explícito na tela principal.
– Acompanhemanto fácil do total de horas.

Compreendendo melhor o público-alvo

Com base nos resultados da pesquisa e usando uma ferramenta online gratuita, criei três personas que ajudaram a aumentar o entendimento e a empatia pelos diferentes perfis de usuários, tanto finais quanto gestores.

Rabiscando o futuro

A partir da coleta, do refinamento das informações até agora e da eliminação das hipóteses, foi possível conceber a ideia visual da tela principal do app e um wireframe das principais funcionalidades do sistema.

Primeiramente fiz um rascunho de próprio punho da tela principal, para garantir que os 4 pontos de convergência pedidos estivessem lá.

Após a aprovação, desenhei um wireframe usando a ferramenta Mockflow, cobrindo o mínimo de funcionalidades necessárias para que o produto funcione ou seja, para um mínimo produto viável.

Hora de colocar cada um no seu quadrado

Após entender as principais atividades que o produto precisava ter para cumprir sua função básica com o mínimo de recurso possível, organizei as funcionalidades, para depois explorar novas soluções e possibilidades dentro disso. Para ilustrar a arquitetura da informação eu utilizei a ferramenta online e gratuita Draw.io, estabelecendo uma base sólida para a próxima fase.

Arquitetura da informação

Percorrendo o caminho com o usuário

Com o fluxo geral bem definido, agora o objetivo é compreender os passos que o usuário precisará percorrer para executar as tarefas, identificando possíveis oportunidades de melhoria e diferencial para cada ação da jornada.

Nessa etapa eu decidi ilustrar a jornada do usuário com o Figma. Nesse projeto a equipe tinha disponível o Adobe XD, porém, eu estava com o objetivo de apresentar a ferramenta Figma para passar a usá-la futuramente e esta foi a oportunidade que encontrei para apresentá-la à empresa.

"Como usuário do Workish eu preciso fazer o meu primeiro acesso para que eu possa usufruir do aplicativo plenamente."
Jornada do usuário

Verificando as pontas soltas

Sabendo dos passos do usuário, a próxima etapa foi traçar um fluxo identificando as tomadas de decisão e possíveis caminhos alternativos para cada caso de uso, para que o fluxo não tenha nenhum ponto cego. Novamente usei o Draw.io para me auxiliar nesta etapa.

Superando quebras de expectativa

Durante a etapa de prototipagem, desenvolvi um fluxo de baixa fidelidade no Adobe XD para representar os caminhos mapeados e submeter o processo a testes. Nesse protótipo, incluí uma funcionalidade de validação facial, que seria uma integração com um sistema já consolidado na empresa. No entanto, eu acreditava que essa funcionalidade não deveria fazer parte do MVP.

Essa decisão gerou divergências significativas com os stakeholders, que queriam a inclusão da funcionalidade. Para persuadi-los, colaborei estreitamente com as equipes de desenvolvimento do Workish e do sistema de reconhecimento facial. Descobrimos que o app de reconhecimento facial não atendia completamente às necessidades dos stakeholders e que seria necessário um ajuste significativo, o que demandaria mais tempo e recursos de ambas as equipes que poderia a chegar em até um terço a mais do tempo e atraso no projeto da outra equipe.

Protótipo de baixa fidelidade

Com base nessas informações, apresentei um argumento sólido em uma nova reunião e consegui convencer os stakeholders a manter a validação facial fora do MVP mantendo o planejamento do projeto e desonerando a outra equipe de um possível remanejamento de recursos e prazos.

Dando dois passos para frente

Com o protótipo aprovado, avancei para a criação de um protótipo de alta fidelidade, submetendo-o a novos testes e apresentações, com aprovação da maioria dos usuários que preferiram o novo app em relação ao concorrente, validando o sucesso do projeto.

O que aprendi

– Quando se tem oportunidade de fazer um bom trabalho de pesquisa e entrevista com os usuários, o fluxo da jornada inteira percorre de maneira mais suave e ágil.
– Realizar os fluxogramas ajudam muito nos testes, principalmente os que envolvem fluxo.

Próximos passos

Após a construção do fluxo, existiram alguns insights que podem ser considerados:
– Não precisar esperar 24h para ajustar ponto.
– Poder cancelar a solicitação quando feita de forma incorreta.
– Comentário opcional para justificar horas, pontos, abonos.
– Automatização de folga compensada a partir do banco de horas.
– Partir para a outra ponta do negócio (usuário gestor).

Gostou desse caso? Então você também pode gostar destes aqui

Diagnóstico temporal: como dividir o projeto em passado, presente e futuro
A arte de dividir para conquistar
assis art design - by Anderson Assis