CASAL
Sala de Situação
Sistema de monitoramento de indicadores relacionados ao abastecimento de água no estado de Alagoas
Visão geral
Após a criação do aplicativo para informar a situação do abastecimento de água nas cidades, foi necessário um sistema para visualizar os dados informados junto com alguns outros indicadores, para que a tomada de decisão pudesse ser tomada a partir desses dados.
Recebemos uma demanda para desenvolver um sistema para visualizar os dados de abastecimento e fazer os relatórios por computador, como era feito no aplicativo mobile, o sistema tinha que ser feito com urgência, em um curto espaço de tempo, nos obrigando a criar algo sem caso estudo e foi minimamente viável.
Após a finalização do sistema e meses de uso, surgiu uma demanda de implementarmos outras funcionalidades dentro do sistema, então aproveitamos para realizar alguns estudos, pesquisas e melhorar a estrutura do sistema, realizando um processo de redesenho e reestruturação do código.
Baixe este arquivo em PDF:
Minha função
Minha função principal era como Designer UI/UX, mas também ajudava com CSS.
O Problema
O sistema que tinha sido criado apresentava alguns problemas tanto a nível de layout como de código, o sistema funcionava lentamente, não respondia e alguns bugs que aconteciam demoravam muito a corrigir.
Novas demandas surgiram para o sistema, essas demandas incluíam:
- Novas funcionalidades que devem ser implementadas;
- Novos setores devem ser atendidos (sem informações definidas);
- Possibilidade de download de dados para consulta offline ou para impressão.
Além das demandas, havia ainda mais problemas técnicos como:
- Bugs;
- Problemas de usabilidade;
- Design não responsivo;
- Sistema lento;
- Falta de padrão visual;
- Melhor gerenciamento dos papeis.
A Solução
Para resolver os problemas técnicos decidimos que o mais viável era refatorar o código frontend e backend, redesenhar todo o sistema e mudar algumas tecnologias. Com essas mudanças já conseguimos atender as novas demandas e sanar os problemas que existem atualmente no sistema.
Entrevista do usuário
Como o sistema já estava em uso e algumas de nossas funcionalidades eram as mesmas do aplicativo mobile supply, nossas entrevistas focaram em validar e melhorar o que já existia.
Fizemos entrevistas qualitativas com alguns gestores para entender melhor seu processo de trabalho, quais indicadores utilizavam e um feedback do sistema que já estava em produção, para saber quais eram as maiores dores e dificuldades. Obtivemos os seguintes resultados:
- As ações só seriam realizadas em caso de abastecimento ruim;
- Eles visualizavam os dados em uma planilha Excel que podia ser impressa para acesso offline;
- Eles realizaram a contagem de cada cidade, separando por estado;
- Os indicadores foram atualizados em dias diferentes, podendo sofrer atrasos;
- As pessoas que não trabalham no setor devem poder acessar o sistema para visualizar dados específicos;
- Era difícil clicar nas cidades menores, principalmente ao usar o smartphone.
Uma curiosidade que eles nos passaram foi sobre as cores usadas, perguntamos sobre as cores das regiões e o estado das cidades serem muito parecidos, eles nos disseram que preferiam assim, pois já trabalhavam com essas cores antes de usar um sistema web.
Metas
Com os resultados obtidos, definimos que:
- Mudaríamos a biblioteca de componentes de interface do usuário;
- Adicionaríamos um menu lateral;
- O sistema teria um painel gráfico comparando cidades e indicadores;
- Cada novo setor seria adicionado no menu lateral;
- O arquivo com os dados do abastecimento seria um PDF com filtro por localidade e período;
- O mapa teria controles de zoom in e zoom out.
fluxo de usuário
Criei um userflow com o objetivo de apresentar e validar o fluxo do sistema, minimizando as etapas para que os usuários concluam um objetivo.
Wireframes
Criei alguns wireframes com o objetivo principal de discutir com a equipe as informações que estariam ali presentes e validar como ficaria o fluxo do sistema através das telas de baixa fidelidade.
Como o mapa era o foco do sistema, não mudaria muito em relação ao fluxo existente, a única coisa que alterei foi a edição de comentários que antes era realizada no próprio mapa e agora só poderia ser feita na tela de relatórios.
Protótipo de alta fidelidade
Após a criação e validação dos wireframes com a equipe de desenvolvimento, comecei a criar os protótipos de alta fidelidade, usei o figma porque já tinha um certo domínio da ferramenta e porque a equipe podia acompanhar o desenvolvimento em tempo real, fazendo comentários e fazendo algumas perguntas sobre coisas que tinham dúvidas.
Optei por criar protótipos de alta fidelidade antes de fazer os testes de usabilidade, e sem criar protótipos de média fidelidade, pois já conhecíamos nosso público, então achei mais viável pular essa etapa e só fazer testes com telas mais reais. Também propus manter a opção “novo relatório” no menu lateral, apesar de fazer parte dos relatórios, era a principal funcionalidade para os chefes de abastecimento, embora já existisse um aplicativo para eles, alguns não conseguiram usar por problemas ou falta de compatibilidade em seus dispositivos.
Usamos como base o material.ui, uma biblioteca de componentes ui no react.js, na versão anterior havíamos utilizado a biblioteca antdesign, não tivemos problemas com a biblioteca anterior, mas optamos por um visual diferente e aproveitamos a oportunidade conhecer uma nova biblioteca.
antes e depois
Embora novas páginas tenham sido desenhadas, algumas passaram apenas por um processo de redesign, como nos exemplos a seguir:
Testes e feedback
Após a apresentação das novas telas, realizamos alguns testes de usabilidade com os funcionários, utilizando os protótipos de alta fidelidade, vimos que todas as demandas foram atendidas, os usuários não tiveram dificuldades em realizar as tarefas atribuídas e o sistema ficou visualmente muito mais atrativo.
Algumas das tarefas que lhes pedimos para fazer foram:
- Recupere a senha;
- Acesse o sistema;
- Ver o status de uma cidade;
- Visualize todos os relatórios que foram enviados por eles mesmos;
- Editar um relatório;
- Faça um novo relatório;
- Imprimir um relatório completo;
- Altere seu contato e senha.
Os resultados foram satisfatórios, onde todos conseguiram atingir a meta sem muita dificuldade, 2 usuários tiveram alguma dificuldade em editar um relatório já enviado, pois era algo feito de forma diferente na versão anterior do sistema, mas o feedback foi positivo em relação a mudança.
Comentário de um dos usuários:
“ Tive um pouco de dificuldade em conseguir editar um relatório que eu já fiz, antes acessava direto no mapa, mas agora está em um lugar separado, está mais organizado, fica mais fácil ver tudo que eu fiz, mas seria bom se eu pudesse editá-lo no mapa também. ”
Após a realização dos testes, iniciou-se o processo de desenvolvimento do novo sistema.
Conclusão
Com base no feedback, nos testes e na versão anterior do sistema, concluímos que o novo modelo atende a todas as demandas, é mais agradável visualmente, com melhor usabilidade e escalabilidade. Além das mudanças visuais e de fluxo, também seriam necessárias mudanças na linguagem e nas tecnologias presentes para melhorar o desempenho e a segurança do sistema.
Apesar dos resultados positivos, ainda vimos a possibilidade de melhorar o sistema, principalmente em relação ao uso em dispositivos móveis, sendo necessário um ajuste para editar o relatório no próprio mapa (os relatórios só podem ser editados por quem reporta ou pelos administradores ).
Lições aprendidas
A primeira versão do sistema foi feita às pressas, sem estudo, sem uma boa estruturação do sistema e sem testes realizados, devido a isso vários problemas que passaram despercebidos durante o desenvolvimento só foram percebidos com o sistema em produção.
Com isso, pudemos comprovar que apesar de um estudo, as definições de fluxos e de tecnologias demandam um certo tempo do processo de desenvolvimento, o que torna o processo e o produto muito mais seguros, eficientes e muito mais agradáveis de usar para seus usuários, de uma forma geral até economiza tempo de desenvolvimento.