Como realizei um discovery completo com acesso a apenas 5 usuários
Contexto
Projeto para a Gerdau, cliente do ramo industrial, B2B para a área de finanças da empresa, elaborado durante meu período de trabalho para a ENACOM Group.
Entrega final
Um software para a criação de orçamentos de grande porte. As telas do projeto foram redesenhadas para não haver conflito com o acordo de confidencialidade.
Equipe
Atuei como Product Designer junto de 1 Product Owner, 1 Desenvolver Front-End e 1 Desenvolvedor Back-End
A Gerdau chegou até à empresa com um pedido: eles desejavam facilitar e agilizar a criação de orçamentos para obras feitas em suas instalações.
Planejar e orçamentar pequenas obras já requer um trabalho extenso e atencioso, então imagine a dificuldade de considerar cada fator financeiro em construções e reformas de grande fábricas e usinas. Melhorar essa experiência era o meu desafio como única Product Designer do projeto.
Apenas mais um dia de trabalho, certo? Errado, pois nunca antes eu havia realizado um discovery em que o usuário precisaria selecionar, categorizar e modificar uma quantidade tão grande de dados a cada projeto.
Assim, meu principal desafio era descobrir:
Como simplificar a manipulação de extensas quantidades de dados?
O projeto
O sistema desenvolvido seria utilizado pela área de finanças da Gerdau - ou seja, era um projeto B2B, em que os clientes que teriam reuniões conosco seriam também usuários do produto final. Além disso, foi solicitado que não houvesse o envolvimento de outros funcionários da empresa contratante além dos que participariam das reuniões, então nossa equipe só teria acesso a um total de 5 usuários para entendimento do fluxo, aplicação de pesquisas e realização de testes de usabilidade.
Dessa forma, o dia a dia do projeto foi pensado para envolver os clientes como os usuários teste do projeto, onde o discovery seria feito através de entrevistas e a validação de telas seria conduzida em um formato de teste de usabilidade. Misturar o cliente pagante com o usuário do produto não era o ideal, mas esse era o modelo em que seria possível atender as necessidades do projeto e agradar os diferentes stakeholders ao mesmo tempo.
Assim, o projeto foi executado em cerca de 6 meses, os quais foram divididos em sprints semanais. Cada sprint possuía a mesma estrutura:
Então, como podem imaginar, o ritmo era bastante acelerado. Do discovery a entender parte do fluxo até a entrega dos protótipos no Figma, tudo isso a cada semana.
Os curtos prazos ficavam mais apertados ainda quando você considerava que tudo isso era realizado por uma equipe pequena: apenas 4 profissionais, sendo eu a única Product Designer. Seria necessária uma imersão profunda em termos técnicos com os quais não estava habituada para assim conseguir pensar na melhor experiência para o usuário do software. Assim, dentre outros tópicos, tive que entender sobre:
Grandes obras industriais: orçamentos milionários, onde há uma padronização e categorização específica do mercado para os materiais utilizados.
Impostos relacionados: para um orçamento preciso, é necessário considerar os impostos de cada item da obra, do tijolo à mão-de-obra contratada. Como simplificar e automatizar esse cálculo?
Cotações de diferentes fornecedores: todo orçamento que se preze leva em conta uma pesquisa de preço. Haveria um meio de facilitar a escolha de onde comprar cada item?
Pesquisas disfarçadas
de reuniões
O PO deveria levantar os requisitos, mas era algo impossível de se fazer sozinho: eram tantas informações e dados a serem considerados em cada parte do fluxo que era comum algo importante ser esquecido ou ficar de fora das anotações. Além disso, nas primeiras semanas era comum eu e ele termos divergências em nossos entendimentos a respeito do complexo fluxo do usuário.
Assim, para conseguir trabalhar nessa velocidade e evitar erros de entendimento, precisei assumir uma postura bastante ativa durante as conversas com o cliente e ajudar eu mesma no levantamento de requisitos:
Entendendo o projeto de ponta a ponta
Até mesmo quando o assunto dizia respeito ao Back-End, por exemplo, eu participava da conversa nem que fosse para auxiliar o cliente na compreensão de termos técnicos - nessas situações, aproveitava para aprender mais sobre a área
Alinhamento dos requisitos
Utilizei o momento de leitura da história do usuário e documentos de levantamento de requisitos do PO como um espaço de checagem pra ver se as informações batiam com o que eu mesma anotei
Perguntas nada desnecessárias
O cliente adora descrever o trabalho dele pra você: eles não esperam que vocês pegue tudo de primeira, afinal estudam aquele assunto há anos. Pergunte quantas vezes precisar e peça explicações detalhadas - só não pode levar dúvidas para casa.
Flexibilidade com o fluxo
A cada início de sprint, na primeira reunião da semana, nós buscávamos entender uma etapa a mais do fluxo de trabalho deles antes do nosso sitema: como eles montavam um orçamento até aquele momento? A ideia era mapear quantas planilhas usavam, como a precificação de cada material era feita, como as diferentes áreas da empresa se comunicavam para construir esse documento, etc.
Uma dica que dou para a hora de pensar o fluxo de softwares com essa complexidade é começar pelas funcionalidades básicas que envolvem a jornada do usuário e ir acrescentando conforme a descoberta de mais etapas. Sim, você deve estar pensando que assim você precisará reformular ou adaptar o fluxo diversas vezes, então por que fazer isso, certo?
Em fluxos muito complexos, o próprio usuário/cliente não saberá ou lembrará de te falar tudo que envolve seu trabalho. Aconteceram muitas situações em que, por exemplo, o usuário reportava sentir falta de selecionar o elemento X em um teste de usabilidade - elemento o qual não tinha sido mencionado em nenhum momento nas conversas anteriores. A falta de flexibilidade com o fluxo só irá te frustrar em projetos desse estilo, então o ideal é ter em mente que o fluxo é mutável até a entrega final.
Por isso, faça e valide por partes, de modo a garantir que as peças estão corretas para montar o quebra-cabeça final.
Como potencializar o uso de rascunhos
Uma parte importante das reuniões era a realização de rascunhos durante o levantamento de requisitos. Enquanto os clientes respondiam as perguntas e explicavam pontos do fluxo, eu criava rascunhos de baixa ou média fidelidade, utilizando o Excalidraw ou o próprio Figma. Nesse processo, aprendi algumas lições valiosas:
Algumas pessoas só entendem com exemplos visuais
Com o rascunhos em mãos, era mais simples validar propostas e tirar dúvidas, evitando divergências nos entendimentos.
Esteja bem alinhado com a equipe de desenvolvimento
Não crie falsas expectativas sobre o resultado para o cliente. Em caso de dúvida quanto à possibilidade de implementação, evite mostrar rascunhos sem um alinhamento interno prévio.
Rascunhos agilizam a validação com o time técnico e de produto
Por ser um sistema com uma manipulação grande de dados e, portanto, com um back-end complexo, existiam limitações técnicas ou de tempo para aplicar algumas soluções. Com rascunhos, eu conseguia entender para onde seguir sem perder tempo com o que não encaixava no roadmap.
A criação de uma boa experiência começa nos rascunhos
Há sempre mais de uma forma de realizar alguma ação. Quando em dúvida sobre qual ideia seguir, protótipos de baixa fidelidade das duas ou três melhores possibilitavam a aplicação de testes de usabilidade e a identificação de qual era a solução que valia a pena investir tempo.
Validação das telas (quase) finais
Ao final de cada semana, telas em alta fidelidade eram validadas com o cliente em reunião. Para garantir uma entrega de boa qualidade dentro das rápidas sprints de 1 semana, segui alguns valores durante a construção das telas:
Reaproveite o que der de outras telas do sistema
Não estou dizendo para reutilizar soluções e não pensar no que seria melhor para o usuário. Com ele e os objetivos do negócio em mente, pense no fluxo que deseja alcançar e veja o que pode ser aproveitado de outras telas que você já criou para o projeto. Em sprints pequenas, você tem um curto período de tempo para fazer muita coisa. Há valor na repetição, seja ele estético ou para simplificar seu trabalho!
Tente dar um aspecto visual único para diferentes áreas do sistema
Em sistemas como o desse projeto, os usuários terão que manipular uma quantidade imensa de dados dentro do software. Se você dispor informações distintas de maneiras similar, o usuário pode se perder. Facilite para ele e adapte a disposição visual dos elementos, nem que seja em pequenos detalhes.
Utilize elementos visuais de fácil identificação
Em sistemas como o desse projeto, os usuários terão que manipular uma quantidade imensa de dados dentro do software. Se você dispor informações distintas de maneiras similar, o usuário pode se perder. Facilite para ele e adapte a disposição visual dos elementos, nem que seja em pequenos detalhes.
Aproveite que o cliente também é seu usuário
Quando não havia tempo para aplicar testes de usabilidade, eu solicitava para o próprio cliente testar o protótipo em nossos reuniões. Além de possibilitar a identificação de pontos fortes e fracos da interface e do fluxo, o cliente se sentia parte da construção do sistema e ficava mais engajado.
Usuários não participativos não são um problema
Nem sempre o cliente quer manusear o protótipo, mas uma simples mudança no discurso resolve parte do problema. Em vez de apenas apresentar as telas, faça perguntas como “Agora que já executei essa etapa, o que você faria depois?” ou “Estou nessa tela. Como posso começar um projeto?”. O cliente não estará com a mão no mouse, então não é o teste de usabilidade perfeito, mas você ainda entenderá se o fluxo e os elementos visuais estão funcionando.
Resultados
Nem tudo deu certo...
- Nem todos os usuários extinguiram o uso de planilhas em seu dia a dia. Os motivos eram variados: desde uma curva de aprendizado para mexer no sistema mais lenta do que gostariam até porque achavam mais rápido executar algumas ações no Excel. O ideal seria centralizar a criação de orçamentos unicamente no sistema, evitando erros de comunicação e arquivos perdidos.
- A importação de planilhas para o sistema originava alguns erros. Essa era uma funcionalidade importante para eles (exatamente porque nem todos os usuários deixaram de utilizar Excel) e, por isso, deveria existir. Erros na digitação de dados nos arquivos resultaram em itens duplicados ou com falta de informações.
Mas teve muito resultado bom
- Padronização de fluxos e termos, diminuindo problemas de comunicação entre diferentes usuários
- Menor desperdício de dinheiro na compra de materiais em quantidades desnecessárias ou insuficientes
- Diminuição do uso de planilhas, evitando a perda das mesmas e, consequentemente, de tempo de trabalho
- Maior facilidade na visualização e na análise do orçamento final e da dimensão de cada projeto
- Potencialização de ganhos com a possibilidade de uma comparação mais assertiva entre possíveis fornecedores
Tudo isso resultou na agilização do trabalho da equipe financeira, diminuindo em 1 semana o tempo para execução de cada orçamento.
Como realizei um discovery completo com acesso a apenas 5 usuários
Contexto
Projeto para a Gerdau, cliente do ramo industrial, B2B para a área de finanças da empresa, elaborado durante meu período de trabalho para a ENACOM Group.
Entrega final
Um software para a criação de orçamentos de grande porte. As telas do projeto foram redesenhadas para não haver conflito com o acordo de confidencialidade.
Equipe
Atuei como Product Designer junto de 1 Product Owner, 1 Desenvolver Front-End e 1 Desenvolvedor Back-End
A Gerdau chegou até à empresa com um pedido: eles desejavam facilitar e agilizar a criação de orçamentos para obras feitas em suas instalações.
Planejar e orçamentar pequenas obras já requer um trabalho extenso e atencioso, então imagine a dificuldade de considerar cada fator financeiro em construções e reformas de grande fábricas e usinas. Melhorar essa experiência era o meu desafio como única Product Designer do projeto.
Apenas mais um dia de trabalho, certo? Errado, pois nunca antes eu havia realizado um discovery em que o usuário precisaria selecionar, categorizar e modificar uma quantidade tão grande de dados a cada projeto.
Assim, meu principal desafio era descobrir:
Como simplificar a manipulação de extensas quantidades de dados?
O projeto
O sistema desenvolvido seria utilizado pela área de finanças da Gerdau - ou seja, era um projeto B2B, em que os clientes que teriam reuniões conosco seriam também usuários do produto final. Além disso, foi solicitado que não houvesse o envolvimento de outros funcionários da empresa contratante além dos que participariam das reuniões, então nossa equipe só teria acesso a um total de 5 usuários para entendimento do fluxo, aplicação de pesquisas e realização de testes de usabilidade.
Dessa forma, o dia a dia do projeto foi pensado para envolver os clientes como os usuários teste do projeto, onde o discovery seria feito através de entrevistas e a validação de telas seria conduzida em um formato de teste de usabilidade. Misturar o cliente pagante com o usuário do produto não era o ideal, mas esse era o modelo em que seria possível atender as necessidades do projeto e agradar os diferentes stakeholders ao mesmo tempo.
Assim, o projeto foi executado em cerca de 6 meses, os quais foram divididos em sprints semanais. Cada sprint possuía a mesma estrutura:
Então, como podem imaginar, o ritmo era bastante acelerado. Do discovery a entender parte do fluxo até a entrega dos protótipos no Figma, tudo isso a cada semana.
Os curtos prazos ficavam mais apertados ainda quando você considerava que tudo isso era realizado por uma equipe pequena: apenas 4 profissionais, sendo eu a única Product Designer. Seria necessária uma imersão profunda em termos técnicos com os quais não estava habituada para assim conseguir pensar na melhor experiência para o usuário do software. Assim, dentre outros tópicos, tive que entender sobre:
Grandes obras industriais: orçamentos milionários, onde há uma padronização e categorização específica do mercado para os materiais utilizados.
Impostos relacionados: para um orçamento preciso, é necessário considerar os impostos de cada item da obra, do tijolo à mão-de-obra contratada. Como simplificar e automatizar esse cálculo?
Cotações de diferentes fornecedores: todo orçamento que se preze leva em conta uma pesquisa de preço. Haveria um meio de facilitar a escolha de onde comprar cada item?
Pesquisas disfarçadas
de reuniões
O PO deveria levantar os requisitos, mas era algo impossível de se fazer sozinho: eram tantas informações e dados a serem considerados em cada parte do fluxo que era comum algo importante ser esquecido ou ficar de fora das anotações. Além disso, nas primeiras semanas era comum eu e ele termos divergências em nossos entendimentos a respeito do complexo fluxo do usuário.
Assim, para conseguir trabalhar nessa velocidade e evitar erros de entendimento, precisei assumir uma postura bastante ativa durante as conversas com o cliente e ajudar eu mesma no levantamento de requisitos:
Entendendo o projeto de ponta a ponta
Até mesmo quando o assunto dizia respeito ao Back-End, por exemplo, eu participava da conversa nem que fosse para auxiliar o cliente na compreensão de termos técnicos - nessas situações, aproveitava para aprender mais sobre a área
Alinhamento dos requisitos
Utilizei o momento de leitura da história do usuário e documentos de levantamento de requisitos do PO como um espaço de checagem pra ver se as informações batiam com o que eu mesma anotei
Perguntas nada desnecessárias
O cliente adora descrever o trabalho dele pra você: eles não esperam que vocês pegue tudo de primeira, afinal estudam aquele assunto há anos. Pergunte quantas vezes precisar e peça explicações detalhadas - só não pode levar dúvidas para casa.
Flexibilidade com o fluxo
A cada início de sprint, na primeira reunião da semana, nós buscávamos entender uma etapa a mais do fluxo de trabalho deles antes do nosso sitema: como eles montavam um orçamento até aquele momento? A ideia era mapear quantas planilhas usavam, como a precificação de cada material era feita, como as diferentes áreas da empresa se comunicavam para construir esse documento, etc.
Uma dica que dou para a hora de pensar o fluxo de softwares com essa complexidade é começar pelas funcionalidades básicas que envolvem a jornada do usuário e ir acrescentando conforme a descoberta de mais etapas. Sim, você deve estar pensando que assim você precisará reformular ou adaptar o fluxo diversas vezes, então por que fazer isso, certo?
Em fluxos muito complexos, o próprio usuário/cliente não saberá ou lembrará de te falar tudo que envolve seu trabalho. Aconteceram muitas situações em que, por exemplo, o usuário reportava sentir falta de selecionar o elemento X em um teste de usabilidade - elemento o qual não tinha sido mencionado em nenhum momento nas conversas anteriores. A falta de flexibilidade com o fluxo só irá te frustrar em projetos desse estilo, então o ideal é ter em mente que o fluxo é mutável até a entrega final.
Por isso, faça e valide por partes, de modo a garantir que as peças estão corretas para montar o quebra-cabeça final.
Como potencializar o uso de rascunhos
Uma parte importante das reuniões era a realização de rascunhos durante o levantamento de requisitos. Enquanto os clientes respondiam as perguntas e explicavam pontos do fluxo, eu criava rascunhos de baixa ou média fidelidade, utilizando o Excalidraw ou o próprio Figma. Nesse processo, aprendi algumas lições valiosas:
Algumas pessoas só entendem com exemplos visuais
Com o rascunhos em mãos, era mais simples validar propostas e tirar dúvidas, evitando divergências nos entendimentos.
Esteja bem alinhado com a equipe de desenvolvimento
Não crie falsas expectativas sobre o resultado para o cliente. Em caso de dúvida quanto à possibilidade de implementação, evite mostrar rascunhos sem um alinhamento interno prévio.
Rascunhos agilizam a validação com o time técnico e de produto
Por ser um sistema com uma manipulação grande de dados e, portanto, com um back-end complexo, existiam limitações técnicas ou de tempo para aplicar algumas soluções. Com rascunhos, eu conseguia entender para onde seguir sem perder tempo com o que não encaixava no roadmap.
A criação de uma boa experiência começa nos rascunhos
Há sempre mais de uma forma de realizar alguma ação. Quando em dúvida sobre qual ideia seguir, protótipos de baixa fidelidade das duas ou três melhores possibilitavam a aplicação de testes de usabilidade e a identificação de qual era a solução que valia a pena investir tempo.
Validação das telas (quase) finais
Ao final de cada semana, telas em alta fidelidade eram validadas com o cliente em reunião. Para garantir uma entrega de boa qualidade dentro das rápidas sprints de 1 semana, segui alguns valores durante a construção das telas:
Reaproveite o que der de outras telas do sistema
Não estou dizendo para reutilizar soluções e não pensar no que seria melhor para o usuário. Com ele e os objetivos do negócio em mente, pense no fluxo que deseja alcançar e veja o que pode ser aproveitado de outras telas que você já criou para o projeto. Em sprints pequenas, você tem um curto período de tempo para fazer muita coisa. Há valor na repetição, seja ele estético ou para simplificar seu trabalho!
Tente dar um aspecto visual único para diferentes áreas do sistema
Em sistemas como o desse projeto, os usuários terão que manipular uma quantidade imensa de dados dentro do software. Se você dispor informações distintas de maneiras similar, o usuário pode se perder. Facilite para ele e adapte a disposição visual dos elementos, nem que seja em pequenos detalhes.
Utilize elementos visuais de fácil identificação
Tags e ícones são bons para auxiliar o usuário na rápida identificação de etapas do processo. Devido à grande quantidade de dados, é importante que as pessoas consigam identificar diferenças cruciais ao bater o olho. Se possível, inclua filtros para separar as informações e permita que o usuário tenha uma lista dos itens que deseja consultar.
Aproveite que o cliente também é seu usuário
Quando não havia tempo para aplicar testes de usabilidade, eu solicitava para o próprio cliente testar o protótipo em nossos reuniões. Além de possibilitar a identificação de pontos fortes e fracos da interface e do fluxo, o cliente se sentia parte da construção do sistema e ficava mais engajado.
Usuários não participativos não são um problema
Nem sempre o cliente quer manusear o protótipo, mas uma simples mudança no discurso resolve parte do problema. Em vez de apenas apresentar as telas, faça perguntas como “Agora que já executei essa etapa, o que você faria depois?” ou “Estou nessa tela. Como posso começar um projeto?”. O cliente não estará com a mão no mouse, então não é o teste de usabilidade perfeito, mas você ainda entenderá se o fluxo e os elementos visuais estão funcionando.
Resultados
Nem tudo deu certo...
- Nem todos os usuários extinguiram o uso de planilhas em seu dia a dia. Os motivos eram variados: desde uma curva de aprendizado para mexer no sistema mais lenta do que gostariam até porque achavam mais rápido executar algumas ações no Excel. O ideal seria centralizar a criação de orçamentos unicamente no sistema, evitando erros de comunicação e arquivos perdidos.
- A importação de planilhas para o sistema originava alguns erros. Essa era uma funcionalidade importante para eles (exatamente porque nem todos os usuários deixaram de utilizar Excel) e, por isso, deveria existir. Erros na digitação de dados nos arquivos resultaram em itens duplicados ou com falta de informações.
Mas teve muito resultado bom
- Padronização de fluxos e termos, diminuindo problemas de comunicação entre diferentes usuários
- Menor desperdício de dinheiro na compra de materiais em quantidades desnecessárias ou insuficientes
- Diminuição do uso de planilhas, evitando a perda das mesmas e, consequentemente, de tempo de trabalho
- Maior facilidade na visualização e na análise do orçamento final e da dimensão de cada projeto
- Potencialização de ganhos com a possibilidade de uma comparação mais assertiva entre possíveis fornecedores
Tudo isso resultou na agilização do trabalho da equipe financeira, diminuindo em 1 semana o tempo para execução de cada orçamento.
Como realizei um discovery completocom acesso a apenas 5 usuários
Contexto
Projeto para a Gerdau, cliente do ramo industrial, B2B para a área de finanças da empresa, elaborado durante meu período de trabalho para a ENACOM Group.
Entrega final
Um software para a criação de orçamentos de grande porte. As telas do projeto foram redesenhadas para não haver conflito com o acordo de confidencialidade.
Equipe
Atuei como Product Designer junto de 1 Product Owner, 1 Desenvolver Front-End e 1 Desenvolvedor Back-End
A Gerdau chegou até à empresa com um pedido: eles desejavam facilitar e agilizar a criação de orçamentos para obras feitas em suas instalações.
Planejar e orçamentar pequenas obras já requer um trabalho extenso e atencioso, então imagine a dificuldade de considerar cada fator financeiro em construções e reformas de grande fábricas e usinas. Melhorar essa experiência era o meu desafio como única Product Designer do projeto.
Apenas mais um dia de trabalho, certo? Errado, pois nunca antes eu havia realizado um discovery em que o usuário precisaria selecionar, categorizar e modificar uma quantidade tão grande de dados a cada projeto.
Assim, meu principal desafio era descobrir:
Como simplificar a manipulação de extensas quantidades de dados?
O projeto
O sistema desenvolvido seria utilizado pela área de finanças da Gerdau - ou seja, era um projeto B2B, em que os clientes que teriam reuniões conosco seriam também usuários do produto final. Além disso, foi solicitado que não houvesse o envolvimento de outros funcionários da empresa contratante além dos que participariam das reuniões, então nossa equipe só teria acesso a um total de 5 usuários para entendimento do fluxo, aplicação de pesquisas e realização de testes de usabilidade.
Dessa forma, o dia a dia do projeto foi pensado para envolver os clientes como os usuários teste do projeto, onde o discovery seria feito através de entrevistas e a validação de telas seria conduzida em um formato de teste de usabilidade. Misturar o cliente pagante com o usuário do produto não era o ideal, mas esse era o modelo em que seria possível atender as necessidades do projeto e agradar os diferentes stakeholders ao mesmo tempo.
Assim, o projeto foi executado em cerca de 6 meses, os quais foram divididos em sprints semanais. Cada sprint possuía a mesma estrutura:
Então, como podem imaginar, o ritmo era bastante acelerado. Do discovery a entender parte do fluxo até a entrega dos protótipos no Figma, tudo isso a cada semana.
Os curtos prazos ficavam mais apertados ainda quando você considerava que tudo isso era realizado por uma equipe pequena: apenas 4 profissionais, sendo eu a única Product Designer. Seria necessária uma imersão profunda em termos técnicos com os quais não estava habituada para assim conseguir pensar na melhor experiência para o usuário do software. Assim, dentre outros tópicos, tive que entender sobre:
Grandes obras industriais: orçamentos milionários, onde há uma padronização e categorização específica do mercado para os materiais utilizados.
Impostos relacionados: para um orçamento preciso, é necessário considerar os impostos de cada item da obra, do tijolo à mão-de-obra contratada. Como simplificar e automatizar esse cálculo?
Cotações de diferentes fornecedores: todo orçamento que se preze leva em conta uma pesquisa de preço. Haveria um meio de facilitar a escolha de onde comprar cada item?
Pesquisas disfarçadas
de reuniões
O PO deveria levantar os requisitos, mas era algo impossível de se fazer sozinho: eram tantas informações e dados a serem considerados em cada parte do fluxo que era comum algo importante ser esquecido ou ficar de fora das anotações. Além disso, nas primeiras semanas era comum eu e ele termos divergências em nossos entendimentos a respeito do complexo fluxo do usuário.
Assim, para conseguir trabalhar nessa velocidade e evitar erros de entendimento, precisei assumir uma postura bastante ativa durante as conversas com o cliente e ajudar eu mesma no levantamento de requisitos:
Entendendo o projeto de ponta a ponta
Até mesmo quando o assunto dizia respeito ao Back-End, por exemplo, eu participava da conversa nem que fosse para auxiliar o cliente na compreensão de termos técnicos - nessas situações, aproveitava para aprender mais sobre a área
Alinhamento dos requisitos
Utilizei o momento de leitura da história do usuário e documentos de levantamento de requisitos do PO como um espaço de checagem pra ver se as informações batiam com o que eu mesma anotei
Perguntas nada desnecessárias
O cliente adora descrever o trabalho dele pra você: eles não esperam que vocês pegue tudo de primeira, afinal estudam aquele assunto há anos. Pergunte quantas vezes precisar e peça explicações detalhadas - só não pode levar dúvidas para casa.
Flexibilidade com o fluxo
A cada início de sprint, na primeira reunião da semana, nós buscávamos entender uma etapa a mais do fluxo de trabalho deles antes do nosso sitema: como eles montavam um orçamento até aquele momento? A ideia era mapear quantas planilhas usavam, como a precificação de cada material era feita, como as diferentes áreas da empresa se comunicavam para construir esse documento, etc.
Uma dica que dou para a hora de pensar o fluxo de softwares com essa complexidade é começar pelas funcionalidades básicas que envolvem a jornada do usuário e ir acrescentando conforme a descoberta de mais etapas. Sim, você deve estar pensando que assim você precisará reformular ou adaptar o fluxo diversas vezes, então por que fazer isso, certo?
Em fluxos muito complexos, o próprio usuário/cliente não saberá ou lembrará de te falar tudo que envolve seu trabalho. Aconteceram muitas situações em que, por exemplo, o usuário reportava sentir falta de selecionar o elemento X em um teste de usabilidade - elemento o qual não tinha sido mencionado em nenhum momento nas conversas anteriores. A falta de flexibilidade com o fluxo só irá te frustrar em projetos desse estilo, então o ideal é ter em mente que o fluxo é mutável até a entrega final.
Por isso, faça e valide por partes, de modo a garantir que as peças estão corretas para montar o quebra-cabeça final.
Como potencializar o uso de rascunhos
Uma parte importante das reuniões era a realização de rascunhos durante o levantamento de requisitos. Enquanto os clientes respondiam as perguntas e explicavam pontos do fluxo, eu criava rascunhos de baixa ou média fidelidade, utilizando o Excalidraw ou o próprio Figma. Nesse processo, aprendi algumas lições valiosas:
Algumas pessoas só entendem com exemplos visuais
Com o rascunhos em mãos, era mais simples validar propostas e tirar dúvidas, evitando divergências nos entendimentos.
Esteja bem alinhado com a equipe de desenvolvimento
Não crie falsas expectativas sobre o resultado para o cliente. Em caso de dúvida quanto à possibilidade de implementação, evite mostrar rascunhos sem um alinhamento interno prévio.
Rascunhos agilizam a validação com o time técnico e de produto
Por ser um sistema com uma manipulação grande de dados e, portanto, com um back-end complexo, existiam limitações técnicas ou de tempo para aplicar algumas soluções. Com rascunhos, eu conseguia entender para onde seguir sem perder tempo com o que não encaixava no roadmap.
A criação de uma boa experiência começa nos rascunhos
Há sempre mais de uma forma de realizar alguma ação. Quando em dúvida sobre qual ideia seguir, protótipos de baixa fidelidade das duas ou três melhores possibilitavam a aplicação de testes de usabilidade e a identificação de qual era a solução que valia a pena investir tempo.
Validação das telas (quase) finais
Ao final de cada semana, telas em alta fidelidade eram validadas com o cliente em reunião. Para garantir uma entrega de boa qualidade dentro das rápidas sprints de 1 semana, segui alguns valores durante a construção das telas:
Reaproveite o que der de outras telas do sistema
Não estou dizendo para reutilizar soluções e não pensar no que seria melhor para o usuário. Com ele e os objetivos do negócio em mente, pense no fluxo que deseja alcançar e veja o que pode ser aproveitado de outras telas que você já criou para o projeto. Em sprints pequenas, você tem um curto período de tempo para fazer muita coisa. Há valor na repetição, seja ele estético ou para simplificar seu trabalho!
Tente dar um aspecto visual único para diferentes áreas do sistema
Em sistemas como o desse projeto, os usuários terão que manipular uma quantidade imensa de dados dentro do software. Se você dispor informações distintas de maneiras similar, o usuário pode se perder. Facilite para ele e adapte a disposição visual dos elementos, nem que seja em pequenos detalhes.
Utilize elementos visuais de fácil identificação
Tags e ícones são bons para auxiliar o usuário na rápida identificação de etapas do processo. Devido à grande quantidade de dados, é importante que as pessoas consigam identificar diferenças cruciais ao bater o olho. Se possível, inclua filtros para separar as informações e permita que o usuário tenha uma lista dos itens que deseja consultar.
Aproveite que o cliente também é seu usuário
Quando não havia tempo para aplicar testes de usabilidade, eu solicitava para o próprio cliente testar o protótipo em nossos reuniões. Além de possibilitar a identificação de pontos fortes e fracos da interface e do fluxo, o cliente se sentia parte da construção do sistema e ficava mais engajado.
Usuários não participativos não são um problema
Nem sempre o cliente quer manusear o protótipo, mas uma simples mudança no discurso resolve parte do problema. Em vez de apenas apresentar as telas, faça perguntas como “Agora que já executei essa etapa, o que você faria depois?” ou “Estou nessa tela. Como posso começar um projeto?”. O cliente não estará com a mão no mouse, então não é o teste de usabilidade perfeito, mas você ainda entenderá se o fluxo e os elementos visuais estão funcionando.
Resultados
Nem tudo deu certo...
- Nem todos os usuários extinguiram o uso de planilhas em seu dia a dia. Os motivos eram variados: desde uma curva de aprendizado para mexer no sistema mais lenta do que gostariam até porque achavam mais rápido executar algumas ações no Excel. O ideal seria centralizar a criação de orçamentos unicamente no sistema, evitando erros de comunicação e arquivos perdidos.
- A importação de planilhas para o sistema originava alguns erros. Essa era uma funcionalidade importante para eles (exatamente porque nem todos os usuários deixaram de utilizar Excel) e, por isso, deveria existir. Erros na digitação de dados nos arquivos resultaram em itens duplicados ou com falta de informações.
Mas teve muito resultado bom
- Padronização de fluxos e termos, diminuindo problemas de comunicação entre diferentes usuários
- Menor desperdício de dinheiro na compra de materiais em quantidades desnecessárias ou insuficientes
- Diminuição do uso de planilhas, evitando a perda das mesmas e, consequentemente, de tempo de trabalho
- Maior facilidade na visualização e na análise do orçamento final e da dimensão de cada projeto
- Potencialização de ganhos com a possibilidade de uma comparação mais assertiva entre possíveis fornecedores
Tudo isso resultou na agilização do trabalho da equipe financeira, diminuindo
Tudo isso resultou na agilização do trabalho da equipe financeira, diminuindo em 1 semana o tempo para execução de cada orçamento.