assis art design - by Anderson Assis
Workish - Como transformei o bom em ótimo!
Background
Workish é um sistema de controle de ponto a ser integrado ao aplicativo Teamish com a missão de ser otimizado, simples e menos burocrático.
Ele vem com a ideia de ser um módulo do Teamish ou um produto comercializado separadamente, ampliando o público alvo.
Minha participação
Pesquisa: entender os objetivos do projeto e o sentimento dos usuários em relação a isso.
Análise: pesquisar forças e fraquezas de concorrentes e cruzar esses dados com o depoimento dos usuários.
Desenvolvimento visual: construção dos fluxos, padrões e identidade visual do app.
Testes: validar as hipóteses e validar os fluxos.
Desafio
Os usuários já faziam uso do serviço de uma plataforma a qual eles estavam satisfeitos, portanto, o Workish tinha o desafio de ser ainda melhor do que o concorrente atual.
Além disso, o Workish deveria seguir os padrões de design do Teamish, mas o Design System ainda estava em desenvolvimento, fazendo disso um trabalho simultâneo.
O começo de tudo
Quando eu inicio um projeto do zero, gosto de estabelecer desde o começo um ponto de partida com o que eu já sei e um ponto de chegada. Isso me ajuda a escolher quais ferramentas e técnicas eu usarei para o projeto ou caso específico.
Para conduzir essas descobertas foi utilizado a ferramenta de planilhas do Google para montar uma Matriz CSD. Ela me ajuda a entender melhor o projeto, eliminando os “achismos” e conduzindo a colheita de dados, as ideias e decisões do projeto de uma forma mais acertiva.
Este quadro muda durante toda a jornada do projeto.
Nada se cria, tudo se copia
Os usuários da demanda inicial faziam uso do app Pontomais, portanto ele foi o ponto focal para benchmark uma vez que tinha acesso na plataforma e suas funcionalidades, porém outros players do mercado também receberam atenção neste momento, ajudando na comparação e no levantamento de hipóteses.
Como o acesso a todas estas ferramentas são mediante contato com a empresa, foi necessário descobrir o que os usuários pensavam das funcionalidades deles. Essa busca por informação foi feita através de resenhas através do Google e com outros conhecidos.
O que foi colhido de feedback precisava ser refinado, então coloquei em forma de texto no chat-GPT e pedi para me retornar os termos que mais se repetiam afim de ter um resultado otimizado.
Buscando o ususário
Após as comparações e o levantamento de algumas hipóteses, foi feito uma pesquisa qualitativa com 25 usuários para validar essas hipóteses além de colher feedbacks afim de obter informações detalhadas facilitando os insights.
De todos estes usuários, foi selecionado uma quantidade menor para uma entrevista com o objetivo de ter respostas com maior qualidade, principalmente das sugestões e opiniões mais complexas.
Estabelecendo as prioridades
A partir da pesquisa, foram encontrados os seguintes pontos a respeito do concorrente:
– Não há dificuldades em usar o atual app.
– O sistema Web também é usado com frequência.
– Os usuários gostam da objetividade do app.
– O sistema Web conta com alguns bugs.
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.
Personas
O produto precisa criar soluções de ponta-a-ponta, e não somente para o usuário final, dessa forma, inspirado na base de usuários já existente e nos resultados da pesquisa e com uma ferramenta gratuita online, foi possível criar 3 personas, aumentando o entendimento e a empatia, identificando diferentes perfis de usuário e resolvendo os problemas tanto desses usuário finais quanto o do usuário gestor.
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, formando um MVP.
Primeiramente fiz um rascunho de próprio punho da tela principal, para garantir de que os 4 pontos de convergência pedidos estivessem lá.
Após a aprovação, desenhei um wireframe usando a ferramenta Mockflow para um mínimo produto viável, ou seja, cobrindo o mínimo de funcionalidades necessárias para que o produto funcione.
Hora de colocar cada um no seu quadrado
Após entender quais as principais atividades que o produto precisa ter para cumprir sua função básica com o mínimo de recurso possível, foi necessário organizar 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.
Jornadas do 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 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."
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.
Dando um passinho para trás
A partir de todos os caminhos possíveis mapeados, foi o momento de representar as telas em um protótipo de baixa fidelidade e submeter o fluxo para teste.
Para fins de documentação e seguir um processo já definido e confortável para a empresa, nesta etapa eu desenvolvi o fluxo com o Adobe XD.
Neste protótipo foi contemplado a validação facial, que seria uma integração de um sistema já desenvolvido e consolidado da empresa, porém nos testes, houve a decisão de que seria melhor essa parte não fazer parte do MVP e portando, descartada no momento.
Dando dois passos para frente
Após o teste e aprovação do protótipo de baixa fidelidade, foi ilustrado um fluxograma das telas em alta fidelidade, para uma apresentação juntamente com o protótipo de alta fidelidade, submetendo o fluxo para mais um teste, com a aprovação e satisfação da maioria dos usuários convergindo de que preferiam usar este novo app do que o concorrente.
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
