Contexto
Após quase um ano desde o projeto Chronos ter sido criado durante o curso da Awari, comecei a revisá-lo com base em novos conhecimentos e experiências que adquiri durante este tempo. Iniciamos com uma reunião com os stakeholders debatendo possíveis pontos para melhorias:
• Será utilizado o framework Flutter para codificar o aplicativo;
• Adequar o layout seguindo o estilo do Material Design para facilitar a construção das telas e componentes;
• Revisar fluxos e funcionalidades, com novos testes de protótipo;
• Adequar o layout seguindo o estilo do Material Design para facilitar a construção das telas e componentes;
• Revisar fluxos e funcionalidades, com novos testes de protótipo;
• Tornar o aplicativo ainda mais prático;
Como podemos aprimorar e simplificar o lançamento de horas?
As duas formas de marcar horas são fáceis de entender o suficiente?
Recapitulando o Projeto
Persona
Focamos em atender os colaboradores que utilizam atualmente a plataforma web na nossa empresa, QWA. Mas também pode se encaixar em usuários de empresas pequenas de tecnologia.
Um dos principais objetivos é trazer praticidade e comodidade para marcar horas
User Story Mapping
Listamos as principais funções que imaginamos para a primeira versão do aplicativo como uma base. Durante a reunião, discutimos sobre a parte de relatórios e como isso poderia ser uma funcionalidade futura.
Fluxograma
Focamos nos dois tipos de fluxos referentes o lançamento de horas:
Marcando por etapas (durante o dia)
Para a primeira Entrada, apenas é necessário selecionar o horário.
Quando se adiciona uma Saída, também é necessário relatar as horas trabalhadas em um projeto.
Na segunda Saída, é possível preencher as horas restantes automaticamente em um projeto existente; editar as horas no projeto atual ou adicionar um segundo projeto.
Marcando a jornada completa (ao final do dia)
Selecionando a opção "Marcar jornada inteira" na tela de 1ª Entrada, o usuário pode marcar todos os períodos de uma vez só.
Problemas e soluções
Analisando as telas antigas, alguns problemas foram notados:
Tela inicial: antes e depois
A- Existe o problema de diferenciar as duas formas de lançamento de horas: por etapas durante o dia e marcando a jornada inteira ao final do dia. Os dois botões ( "+" e "+1") não estão muito claros.
Solução: adicionamos a opção ”marcar jornada inteira” na tela seguinte após o clique no botão e deixamos apenas um botão na tela inicial.
B- O layout atual dos dias limita o espaço para informações.
Solução: mostramos apenas o dia atual, que engloba a tela inteira possibilitando scroll e mais espaço para informações.
Tela de lançamento: antes e depois
C- O usuário deve clicar input por input e preencher manualmente os horários, o que não é muito prático.
Solução: substituímos os inputs por um componente o qual o usuário possui mais costume no celular, o time wheel, em etapas (1ª Entrada, 1ª Saída, 2ª Entrada, 2ª Saída…).
Tela inicial preenchida: antes e depois
D- O botão de adição é substituído pelo de edição, o que pode causar certa confusão ao usuário.
Solução: adicionamos a opção de edição do dia no menu superior.
Teste de Usabilidade
Com as alterações no layout e fluxo, criamos um protótipo de alta fidelidade no Figma para testar as diferentes funções:
• Validar as duas formas de marcar horas
• Edição e exclusão de items
• Marcar horas em um dia passado
Todos os testes foram feitos em uma sala de reunião do Google, onde o participante compartilhou sua tela ao executar as atividades no protótipo. Iniciamos perguntando ao participante de que forma ele costuma marcar as horas, durante o dia ou ao final deste.
Cenário: Hoje é segunda-feira, dia 8 de fevereiro.
Tarefa 1: “Vamos supor que você terminou seu dia de trabalho e precisa marcar 8 horas no projeto Chronos."
Tarefa 2: "Como você editaria o primeiro horário de 8:00 para 9:00?"
Tarefa 3: "Como você faria para excluir os dois primeiros horários? a 1ª entrada e a 1ª saída."
• Agora, excluir o projeto?
• Por fim, você deseja excluir o dia inteiro.
Tarefa 4: "Você esqueceu de marcar no dia 29 de Janeiro, você precisa marcar 8 horas de trabalho, em dois projetos: Chronos e Marketing (cada um com 4 horas)."
Resultados
• Deletar horários separados não é algo utilizado, além de não ser prático
• Sugestão: deletar períodos
• Ter o app sugerindo as horas para marcar no projeto é bom
• Opção "Preenchimento automático" é eficiente
• Um dos participantes não viu a opção de "jornada inteira"
• Dúvida: como seria caso tivesse que marcar um período extra?
• Marcar as horas por etapas é interessante e pode levar o participante a marcar durante o dia ao invés de no final deste
• Ao testar com alguém de fora da empresa, a pessoa conseguiu executar as tarefas sem dúvidas
Alterações após feedback
Telas: 2ª Saída e 3ª Entrada
Período extra no fluxo de jornada inteira
Na última tela das etapas dos dois períodos (a tela de 2ª Saída), ao selecionar a opção "Adicionar período extra" o usuário é levado para o início do terceiro período (3ª Entrada).
Na última tela das etapas dos dois períodos (a tela de 2ª Saída), ao selecionar a opção "Adicionar período extra" o usuário é levado para o início do terceiro período (3ª Entrada).
Comparação: Antes e Depois
Deletando horários → Deletar períodos
Anteriormente era necessário clicar em cada input e deletar individualmente os horários para conseguir deletar um período inteiro. Foi adicionado um ícone de exclusão para cada período.
Anteriormente era necessário clicar em cada input e deletar individualmente os horários para conseguir deletar um período inteiro. Foi adicionado um ícone de exclusão para cada período.
Próximos Passos
Após estas alterações, serão feitos novos testes de usabilidade com outros usuários para validar os fluxos e também conversar sobre alguns pontos que foram observados:
“Como é marcar as horas de um dia passado? Como identificam este dia no calendário?”
“Qual seria a melhor forma de solucionar este problema?Notificação no próprio aplicativo ou e-mail?”
“É comum os usuários deletarem a jornada inteira?”
“O quão frequente é agora marcarem mais de dois períodos? Quantos?”
Equipe
UX / UI Designer: Jennifer Tamochunas
Stakeholders: Ricardo Okura & Carolina Querino
Participantes dos testes: Hélio Carvalho, Murilo Henrique, Carlos Henrique Alves, Jonas Tamochunas, Rainnyro Villarroel (teste externo)
