Construindo o software certo – e para todos.

Já se passou quase um ano no projeto. O cliente estava inquieto. Tínhamos consumido meses significativos e dispendiosos em emocionantes sessões de design participativo. Vários sprints se passaram e tínhamos um MVP funcionando até então. Este foi um software verdadeiramente inovador. Aliás, fomos contratados justamente para isso: construir softwares inovadores.

Alertamos o cliente sobre a importância do teste antecipado com o usuário final. Temos usado software de prototipagem o tempo todo, um muito famoso. Nosso cliente de mente aberta estava convencido da importância da estratégia, mas insistia em esperar por um produto que funcionasse, um MVP. O protótipo de alta fidelidade não era alto o suficiente para eles. Eles selecionaram o grupo de usuários em potencial e queriam que os testes fossem perfeitos. Portanto, não há espaço para improvisação. Eles viam a prototipagem apenas como isso: improvisação. Eles eram perfeccionistas. Como poderíamos nós, defensores da experiência superior do usuário, culpá-los?

Startups são apostas. Os futuros clientes terão o mesmo entusiasmo dos empreendedores que financiam o projeto? Como serão percebidas as características tão valorizadas, tão polidas durante a construção do produto? Recursos de software, especialmente em startups, são hipóteses. Os patrocinadores apostam que as funcionalidades escolhidas vão encantar seus futuros clientes. Muitos textos excelentes foram escritos sobre a necessidade de testes precoces. O teste precoce reduz os riscos. Bastante. A taxa de sobrevivência entre as startups é muito, muito baixa. Eles deveriam se preocupar mais com os testes iniciais.

A questão é por que os patrocinadores de dinheiro quente relutam em adotar os testes iniciais. As respostas vêm com pouco esforço, pois giram em torno dos mesmos velhos fatores: tempo e dinheiro. O teste requer tempo e dinheiro. Isso vai adiar a estreia do produto, mesmo que o produto não seja o certo. E, como aprendemos, arrisque. Risco de expor seu bebê muito cedo. E expondo para pessoas influentes, como nosso cliente viu. Os empresários odeiam tudo o que pode causar atrasos nos cronogramas e prejudicar os orçamentos. Educá-los não é suficiente. Precisamos de ferramentas melhores.

Se nossos protótipos pudessem oferecer uma experiência mais próxima do produto final real, talvez o cliente concordasse em usá-los nos testes iniciais. Nossos protótipos eram tão de alta fidelidade quanto a ferramenta de prototipagem (uma das melhores do mercado) permitia. Insuficiente. A experiência ainda está longe do produto final. Nosso cliente estava certo; tivemos que esperar até que tivéssemos um software funcionando.

Há muito se observa a lacuna entre design e desenvolvimento. É como se fossem de planetas diferentes. Eles estudam diferentes disciplinas e frequentam cursos de graduação distintos. Eles amam o que fazem e respeitam o trabalho um do outro, mas ainda parecem ser de mundos diferentes. Os limites são claros. Para atravessá-los, existe até um termo, como se você precisa passar pela alfândega para entrar em outro país: o handover.

A prototipagem de software parece corroborar e solidificar essa lacuna. As principais empresas de software ajudam os designers a criar belos protótipos com facilidade. Os protótipos de nossos clientes eram especialmente lindos – eles se preocupam muito com esse aspecto. No entanto, o handover não passa de diretrizes (geralmente mal especificadas). Os desenvolvedores ainda têm muito trabalho pela frente para implementar essa trilha (como uma trilha aberta na floresta). Quando alguém olha atentamente para o documento de design (estrutura interna de um protótipo Figma / adobe), não consegue reconhecer widgets primitivos, como campos de texto, rótulos, etc. Existem plug-ins geradores de código de terceiros. Eles digitalizam o documento de design e geram o código HTML. A qualidade desse código é discutível. Os desenvolvedores profissionais desprezam esse código. E isso é compreensível. A geração de código sempre foi um desafio. Mas isso está fora do escopo desta discussão.

Para preencher a lacuna, decidimos investir em uma galeria de micro frontends (MFEs). Eles são componentes ativos, software funcional que pode ser reutilizado em novos aplicativos. A abordagem tem a vantagem de poder ser descoberta e inserida no protótipo durante as sessões de design participativo. O plug-in também gera código que pode ser usado em testes iniciais. Importante notar que o código é apenas parcialmente gerado, pois partes dele já estão construídas e implantadas em produção, bom código. Codificadores e designers colaboram para ajustar nosso gerador de código para produzir o melhor código possível. Eles estão falando… Essas ferramentas estão disponíveis para nossos clientes que usam tanto os micro frontends quanto o plug-in Figma.

Esses MFEs são acessíveis para pessoas com deficiência visual e auditiva. Os MFEs têm um ciclo de vida próprio para que as versões futuras acomodem outras deficiências. Se estamos no negócio de construir software de qualidade, ele deve ser acessível.

A propósito, para encerrar a história do cliente, realizamos testes de usabilidade com clientes reais assim que tínhamos o software. E eles perceberam as coisas de forma diferente do que era esperado. E conseguimos ajustar o software antes do lançamento do produto.