UX para sistemas corporativos. Parte 3: Quem vai usar?

Conhecer e conversar com as pessoas que irão utilizar o sistema é fundamental para projetar uma boa experiência para um sistema corporativo.

"Dã, mas isso é óbvio! Ainda mais em se tratando de um artigo de UX".

É e não é. Quando se está trabalhando em um projeto de sistema corporativo, é inviável envolver todas as pessoas que irão operar o sistema durante a fase de pesquisa e concepção da solução. Então, algumas pessoas são escolhidas para conduzir o projeto. E normalmente essas pessoas são de um nível gerencial e não operacional. É natural, pois elas têm uma compreensão melhor sobre as necessidades da empresa e quais os objetivos que o sistema tem que atingir. Mesmo se alguém operacional for envolvido, será a pessoa que mais conhece o processo. E é justamente no gap que existe entre essas pessoas e os reais operadores que reside grande parte dos problemas de concepção de um sistema corporativo.

Esse gap pode ser de compreensão do processo como um todo, dos objetivos da empresa, de formação acadêmica, experiência profissional, etc. O fato é que a compreensão e o entendimento que um gerente tem é muito mais amplo do que de quem está operando o sistema no dia-a-dia. Certamente ele é um stakeholder importante do processo. Principalmente para definir os objetivos do projeto, suas métricas, indicadores, etc. Mas não é o único. E ele normalmente não está envolvido diretamente na operação do sistema no dia-a-dia. Não conhece os problemas que ele tem e as dificuldades que a equipe tem em sua utilização.

Por isso, é importante conhecer os usuários que operam o dia-a-dia, conversar com eles, ouvir sobre as dificuldades que encontram para realizar as suas tarefas e principalmente observá-los trabalhando.

Nesse artigo, gostaria de citar alguns pontos que aprendemos nesses anos trabalhando em projetos dessa natureza e que podem ajudá-lo na hora de conceber um projeto de UX para sistemas corporativos.

Essas dicas tem uma abordagem principalmente sob o ponto de vista de quando trabalhamos para fazer uma nova versão de um sistema já existente, mas os aprendizados são semelhantes para os casos em que o projeto é de um novo sistema.

Fique atento às pistas que os usuários fornecem

Quando um usuário precisa realizar as mesmas operações todos os dias, por pior que seja o sistema, ele vai encontrar um jeito de realizar as suas tarefas. E em muitos casos, aquilo vai se tornar algo natural na sua rotina de trabalho. E se você for conversar com ele com uma abordagem do tipo "O que você acha que precisa melhorar?" ele não vai citar esses pontos em que ele encontra uma solução alternativa para realizar a sua tarefa, porque já está acostumado com a forma como trabalha. Por isso, é importante observá-los trabalhando e ficar atento a algumas pistas nesse processo:

Favoritos: se o sistema corporativo for um sistema web, ele pode usar a barra de favoritos do browser para chegar mais rapidamente à uma tarefa ou informação que ele necessita e que pela organização e navegação padrão do sistema ele precisaria dar mais cliques para chegar no mesmo lugar. Isso pode ser um insight importante para uma feature de busca, para priorizar o acesso rápido a uma parte do sistema ou para definir a organização e navegação do sistema. Outra forma de uso dos favoritos é que eventualmente ele pode precisar acessar um outro sistema (interno ou externo) para buscar uma informação complementar para o seu trabalho. Por exemplo: acessar o site da Receita Federal para validar um CPF. Se possível, avalie a possibilidade de desenvolver um serviço que integre com esse sistema ou coloque um atalho no seu sistema corporativo para ele.

Planilhas Excel paralelas: o Excel é o melhor amigo de um UX na hora de levantar requisitos. Por ser um software extremamente flexível e de um uso relativamente simples, é extremamente comum que a equipe da operação do sistema crie controles, relatórios e até features novas em planilhas Excel paralelas ao sistema. Já vi planilhas Excel que eram um sistema à parte! Toda planilha Excel paralela é uma necessidade não atendida pelo sistema atual.

Post-its e agendas: é comum os usuários se valerem de post-its, agendas, cadernos ou algo do gênero para registrar informações relacionadas com o seu trabalho. Avalie o que eles escrevem para ver se não tem uma necessidade escondida ali e que o sistema possa atender. Trabalhamos em um projeto em que o usuário precisava analisar uma série de dados e ao final do processo realizar um parecer. Ao observamos ele trabalhando vimos que ele ia registrando em uma caderno os pontos que iriam compor o seu parecer final. Na hora de concebermos o novo sistema, criamos uma feature em que ele poderia realizar as suas anotações diretamente no sistema, que salvava automaticamente e que ficava registrado caso outro operador assumisse a análise.

Envolva pessoas com diferentes níveis de experiência no projeto

É importante conversar com as pessoas que têm mais experiência no sistema, pois elas têm uma compreensão maior de como ele funciona, mas ao mesmo tempo elas podem estar "cegas" quanto aos problemas que o mesmo possui, pois já encontraram os atalhos para conseguir realizar as suas tarefas. Inclusive algumas ações elas já fazem "no automático", sem saber qual o sentido do que estão fazendo.

Pergunta: "Por que você fez essa ação no sistema?". Resposta: "Não sei. Só sei que foi assim que me ensinaram".

Por isso é importante que durante a etapa de pesquisa você converse com pessoas com diferentes janelas de tempo de uso do sistema. Pessoas que acabaram de entrar na empresa podem dar insights extremamente valiosos para o projeto, pois elas evidenciarão mais claramente os problemas de usabilidade do sistema.

É importante também envolver essas pessoas de diferentes níveis nos testes. Tanto nos testes para validar um conceito ou uma ideia, quanto nos testes de usabilidade de um protótipo de alta fidelidade. Em muitos casos, as pessoas com mais tempo de casa terão mais dificuldades em se adaptar a um novo modelo conceitual que as pessoas mais novas. É importante identificar essas dificuldades para projetar o processo de mudança de um sistema para o outro da forma menos traumática possível.

Conheça o perfil das pessoas que irão operar o sistema

É importante conhecer bem o perfil das pessoas que irão operar o sistema. Um sistema de telemarketing, por exemplo, tem um perfil de operadores muito diferente de um sistema bancário, por exemplo. A formação acadêmica, profissional, conhecimento do processo é muito diferente. E é importante levar em consideração esse aspecto na hora de projetar a experiência de uso de um sistema.

Isso influencia desde a taxonomia até a definição de fluxos críticos do sistema. Quanto menos familiarizado com o processo o usuário estiver, mais difícil será a sua compreensão sobre o uso do sistema.

Uma dica é olhar a forma como a empresa anuncia as vagas de emprego para posições que irão operar o sistema. Ali a empresa explicita qual o perfil que está buscando no mercado. Uma conversa com o pessoal responsável pelo recrutamento e gestão de pessoas também pode ajudar nesse sentido.

Outro ponto importante a se avaliar nesse aspecto é o índice de turnover na área que irá operar o sistema. Se o índice de turnover é alto, o sistema tem que ser muito mais didático e fácil de usar, pois frequentemente novas pessoas irão começar a operar o mesmo. Features como wizards e tooltips podem ser necessárias para tornar o uso mais fácil.

Observe as pessoas no seu ambiente de trabalho

É importante entender o contexto em que o sistema será utilizado. Como é o ambiente de trabalho, se o usuário consegue trabalhar focado ou se tem muitas distrações. Quanto maiores as distrações, menor vai ser o nível de concentração que ele vai ter para operar o sistema e isso tem que ser levado em consideração. Principalmente ao finalizar fluxos e processos importantes. Se algo é crítico, evidencie para o usuário. Peça confirmação.

Também é importante entender quais outros sistemas se relacionam com a operação do usuário no dia-a-dia. E-mail, por exemplo, normalmente é uma ferramenta complementar. Algumas comunicações ocorrem por e-mail, inclusive com clientes. E onde fica o registro histórico dessas mensagens? Dá para levar algumas dessas comunicações para dentro do sistema?

É importante definir como o sistema será inserido nesse contexto, como ele vai influenciá-lo ou modificá-lo.


Pense que essas pessoas irão utilizar o sistema todos os dias. Seu trabalho muitas vezes se dará exclusivamente na operação desse sistema. Elas serão avaliadas por seu desempenho e sua produtividade e é sua responsabilidade garantir que elas possam desempenhar suas funções da melhor maneira possível.

Nesse sentido, claro que a responsabilidade não é apenas da equipe de UX, mas de todo o time. Mas isso vou deixar para o próximo artigo.

Não leu os artigos anteriores dessa série? Então leia agora:

UX para Sistemas Corporativos. Parte 1: o "Tempo" do Projeto

UX para Sistemas Corporativos. Parte 2: Aprendizado e Produtividade

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.