Ether Reports

Ether Reports
Ether Reports é uma aplicação que permite gerar relatórios de Chamadas e Gravações feitas com os produtos Neopath.

Nesta nova versão, é possível gerar relatórios amplos (com escopo variando de acordo com permissão do usuário) ou fazer o uso de filtros para extrair informações mais específicas. Essas configurações também podem ser salvas como modelos de relatórios e reutilizadas sempre que preciso.

Atuação e aprendizados:
Este foi o meu primeiro projeto na Neopath, nele atuei tanto em UI quanto em UX, trabalhando no alinhamento com stakeholders, colaborando na avaliação de requisitos e necessidades do usuário, prototipando, elaborando e aplicando testes de usabilidade e, posteriormente, documentando e acompanhando o desenvolvimento.

Ele me possibilitou definir uma nova identidade visual para os produtos da empresa, trabalhar com Arquitetura de Informação e iterar o protótipo diversas vezes de acordo com os objetivos e resultados dos testes.

Foi a primeira vez que trabalhei considerando, além das necessidades dos usuários e do negócio, requisitos de editais. Tentar equilibrar todas essas frentes foi desafiador e me ajudou a desenvolver novas habilidades em produto.

O problema
Por ter sido desenvolvida para atender requisitos com urgência, a aplicação anterior, apesar de mais simples, apresentava sérios problemas de Arquitetura de Informação.

Além da variedade de subcategorias de relatórios, cada uma possuía diversas opções de “filtros” que deveriam ser configurados pelo usuário nos seus respectivos formulários.

Esses formulários possuíam muitos campos. Entre eles apenas alguns obrigatórios, porém sempre visíveis.

Essa combinação de subcategorias e campos e os seus outputs não eram intuitivos para os usuários, gerando dúvidas e frustração logo nas primeiras escolhas: Qual subcategoria disponibilizaria os dados que precisava? Como seria o relatório final?

Início

Recolhendo Informações
Iniciei o projeto recolhendo artefatos e informações que a empresa já possuía sobre os usuários. Por ser um produto que já estava em uso, pude ter acesso a requisições recentes.

Utilizei matriz CSD para organizar tudo que encontrei e alinhar minhas percepções com os stakeholders.

Análise mais detalhada
Após o alinhamento com stakeholders, pude fazer uma análise mais detalhada da aplicação anterior considerando as necessidades dos usuários e objetivos da empresa. Utilizei esta análise para me guiar no novo Design.

Conversando com o Desenvolvimento
Conversar com o desenvolvimento me permitiu entender como a aplicação anterior havia sido desenvolvida, como os requisitos chegavam e descobrir o que estava sendo usado no front que poderia ser aproveitado na nova plataforma.

A aplicação anterior já utilizava uma biblioteca bastante completa de Material Design, uma vantagem tanto para o Design quanto para o Desenvolvimento. Assim, tentei aproveitar ou adaptar componentes desta biblioteca e do plugin previamente utilizado para plotar relatórios.

Neste ponto acredito que ter background como Front-end me ajudou bastante. Pude explorar a documentação e testar o que era possível adaptar com facilidade.

Concept da nova identidade
Para ilustrar melhor algumas mudanças em UI, criei um concept para a nova identidade dos produtos. Assim, foi mais fácil argumentar que, por exemplo, a barra de navegação não poderia ser verde mas ainda assim era possível manter a identidade visual da empresa.

Muito foi revisto após este concept, mas ele teve papel importante na definição da nova identidade visual dos produtos, que antes não era consistente e variava bruscamente a cada aplicação.

As ondas verdes, que, a partir daí, passaram a ser adotadas amplamente nos materiais da empresa, vieram de uma peça antiga do Marketing.

Após essa fase inicial, pude focar nos fluxos e rabiscoframes, sempre realinhando com a equipe, requisitos e necessidades dos usuários. Esses rabiscoframes virariam os protótipos estudados nos testes.

Testes de usabilidade e mudanças no produto

Ciclos:
Cada ciclo documentado aqui representa uma remodelagem maior no protótipo do produto e, dentro de cada um deles, executei uma ou duas rodadas de testes com cenários distintos.

Cenários:
Pude utilizar muitas requisições de clientes como base para criar os cenários de testes da nova aplicação.

…

Primeiro ciclo:
O primeiro ciclo de testes deixou ainda mais evidente o problema de Arquitetura de Informação na plataforma e me permitiu argumentar e ter maior liberdade para propor mudanças maiores na estrutura do aplicação.

Já o picker de operadores e grupos teve ótimos resultados nos testes, permitindo assim que seguisse estes princípios no desenvolvimento dos novos componentes.

Segundo ciclo:
No segundo ciclo, além da remodelagem no mapa da aplicação, ela havia recebido novos requisitos. Agora, as diferentes saídas de relatórios de chamadas ou de gravações seriam dadas em função dos filtros avançados.

Nos testes desta fase, percebemos que a forma como mostrávamos o escopo de sistema como default no formulário não era intuitiva: os usuários não identificavam o campo já preenchido com “sistema” como editável, não entendiam que “sistema” significava que o relatório gerado contaria com dados de todos os usuários.

Assim, eu e o Arquiteto de Sistemas precisamos rever como tornar este requisito intuitivo para o usuário, considerando tanto na visualização quanto o funcionamento dessa feature.

Terceiro ciclo:
No terceiro ciclo, além de testar uma nova visualização para o tratamento do escopo de sistema como default, avaliamos a necessidade e adicionamos uma nova feature: permitir que os modelos de relatórios fiquem salvos.

Desta vez, os usuários não encontraram muitas dificuldades, mas nos primeiros testes ainda pude identificar alguns deslizes menores prontamente corrigidos, como a ausência de labels de horas, minutos e segundos no picker de duração.

As diversas iterações e mudanças aos poucos foram refinando o produto e os testes deste ciclo trouxeram bons resultados.

Resultado final:

Além de cumprir com novos requisitos, os filtros avançados possibilitaram a simplificação do mapa da aplicação.

Agora, as seções são: home, meus relatórios (onde ficam os modelos salvos), chamadas e gravações. Qualquer variação em um relatório de chamadas ou de gravações pode ser feita através da combinação dos campos do formulário com os filtros avançados.

A estrutura do relatório indica o formato dos seus outputs:

Formulários mais enxutos:
A combinação de janela de tempo (“Visualizar por:”) e o período aparece em todos os relatórios, sempre preenchendo automaticamente o período de acordo com o mais recente para a janela escolhida.

Outros campos obrigatórios, como “Operadores/Grupos:” só aparecem quando uma estrutura específica de relatório é selecionada:

Simplicidade como padrão:
A aplicação utiliza como padrão relatórios mais abrangentes e simplificados, reduzindo a complexidade dos formulários para quem busca opções mais abrangentes.

Os campos opcionais agora aparecem em filtros avançados, que possuem o mesmo formato tanto em Chamadas quanto em Gravações:

Esses filtros podem ser combinados para gerar relatórios mais específicos e, assim, a complexidade da plataforma varia conforme as necessidades de cada perfil.


Configure apenas uma vez:
Os modelos de relatórios gerados ainda podem ser salvos e reutilizados posteriormente.

Componentes reutilizáveis:
Os pickers podem aparecer no formulário principal ou dentro de filtros avançados, como é o caso do Picker de Operadores/Grupos.

Eles foram projetados considerando não apenas esta aplicação mas outros produtos da empresa com necessidades semelhantes.

Créditos

Ícones menores (formulários etc.): Material Icons
Demais ícones: flaticon.com
Mockups: Mockup psd created by freepik – www.freepik.com