De ponta - Não arrisque a experiência do usuário - Use delineados

Por Dino Esposito | janeiro de 2016

Dino Esposito Parafraseando o imortal cientista Albert Einstein, ouso dizer que não sei o que o futuro reserva para a arquitetura de software. Porém, se houver alterações em breve, uma delas certamente será a adoção de uma metodologia descendente no design de camadas. UXDD, que é a abreviação de projeto orientado por UX (UX-driven design), é uma abordagem que promove principalmente o uso de delineados e storyboards como o ponto de partida da arquitetura de software. Na abordagem UXDD, o resultado do processo de elicitação não é um conjunto imutável de requisitos,mas sim um conjunto dinâmico de esboços que indicam claramente a maneira como os usuários gostam de trabalhar. E não é de se estranhar que a maneira como os usuários gostam de trabalhar seja uma representação simples em forma de software dos processos de negócios reais. A meu ver, a tecnologia está perdendo a função central na arquitetura de software que deteve por décadas. Hoje é preciso que haja mais habilidade por parte do arquiteto para combinar tecnologias e produtos disponíveis de modo a atingir um conjunto específico de metas, tendo em conta os investimentos existentes em tecnologias específicas, plataformas herdadas, habilidades e orçamentos.

Parece precipitado? Bem, provavelmente é. Essa visão do software não é novidade, mas também nunca se popularizou.

Definindo delineados

Tenho adotado a palavra "delineado" e também a utilizo como sinônimo da palavra "esboço". Vou esclarecer e definir com rigor a diferença, da perspectiva da UXDD, entre delineados e "modelos". Aqui estão algumas definições de termos na UXDD:

Um esboço é um desenho à mão livre criado principalmente para anotar e capturar uma ideia repentina. A superfície ideal para se fazer um esboço é o papel, inclusive guardanapos de papel de cafeterias. Um esboço pode representar o esqueleto de nível superior de uma arquitetura. Porém, mais provavelmente, ele capta a ideia de uma interação entre o usuário e o sistema.
Um delineado é um tipo de esboço mais preciso e exato, pois adiciona informações sobre o layout e a lógica de navegação e detalhes sobre a organização do conteúdo. Ao mesmo tempo, um delineado não está vinculado aos detalhes da interface do usuário, como cores, elementos gráficos, sombras e fontes.
Quando um delineado é estendido para incorporar capas gráficas, torna-se um modelo.

Há uma diferença psicológica fundamental entre modelos e delineados. Quando você mostra aos usuários os modelos de um aplicativo, a atenção inevitavelmente se volta para aspectos gráficos como imagens de plano de fundo, cores e estilo. Raramente, a atenção dos usuários se volta para a organização das informações e sua respectiva navegação e disposição. Os delineados são uma espécie de modelo básico totalmente desprovido de conteúdo gráfico. Os delineados podem ser desenhados manualmente ou por meio de ferramentas de desenho genéricas, como PowerPoint, Visio ou, talvez, Balsamiq. No entanto, estão surgindo ferramentas mais especializadas para vincular delineados, formando storyboards para dar aos usuários uma ideia concreta da experiência final.

Por que os delineados são econômicos

Os desenvolvedores geralmente concordam que é muito benéfico usar delineados para formar uma ideia da camada de apresentação antes mesmo de planejar o back-end. Por muitos anos, as pessoas nesse setor cultivaram a noção de que a arquitetura de software seria semelhante à arquitetura de prédios. Surgiu então o movimento Agile para combater a ideia de que precisávamos de um amplo design fechado antes de escrever o código. Isso não quer dizer que Agile seja a ausência de projetos e análises. Muito pelo contrário, eu diria, mas o método Agile provavelmente não abordou a questão central do desenvolvimento de software. Qual é o objetivo final do software? Simplesmente escrevemos software apenas para armazenar e lidar com dados? Em vez disso, não escrevemos software principalmente para que os usuários realizem tarefas de negócios de forma mais eficiente e mais rápida? No segundo cenário, que é cada vez mais relevante atualmente, a camada de apresentação é tudo o que importa. Nesse caso, a agilidade significa a iteração e a colaboração com os usuários para definir um conjunto aceitável de delineados e storyboards, em vez de informações suficientes para criar um bom modelo persistente.

No entanto, não é incomum que os gerentes de software considerem o tempo gasto em delineados como um custo inútil que não traz resultados nem lucro direto. Assim, ele pode ser evitado para que a equipe se concentre em artefatos de software reais. A analogia entre o software e a engenharia civil vem de longa data, e vale a pena recordá-la agora para dizer o seguinte: Se você quiser construir uma garagem (para não mencionar tipos de prédios mais sofisticados), explicará o que deseja ou apenas esperará que os pedreiros assentem os tijolos e, depois, reclamará quando eles entregarem algo que você nunca quis ou pediu?

A criação e a validação de delineados consistem em uma tarefa extra a ser gerenciada e em um custo adicional. No entanto, uma coisa é ajustar um arquivo de delineado que gera uma tela visual; outra bem diferente é ajustar um sistema de multicamadas composto de milhares de linhas de código. Adotando os delineados e a UXDD, você definitivamente gasta mais tempo antes que qualquer linha de código seja escrita, mas economiza muito mais tempo depois que o primeiro sprint é entregue. E economiza ainda mais tempo quando o sistema está a meio caminho e seus efeitos e benefícios podem ser experimentados e avaliados de forma melhor. Com a UXDD, você se aproxima muito mais do que nunca do sonho de entregar o projeto imediatamente. O que você poupa em sprints e recriações posteriores supera em muito o gasto inicial com delineados.

Como produzir delineados

A base da UXDD e dos delineados é a ideia de que o software não deve ser criado para modelar o domínio de negócios. Em vez disso, ele deve ser escrito para espelhar o domínio de negócios. Essa mudança de perspectiva gera benefícios relevantes nos padrões que usamos para desenvolver o sistema. Em particular, proporciona à análise preliminar um enfoque fortemente orientado a tarefas e reduz a relevância da modelagem. Esse aspecto assusta a maioria dos gerentes, pois parece algo estranho que ninguém fez durante décadas. Continua-se esperando que as entrevistas com os clientes gerem informações para criar um modelo de dados abrangente, a fim de ler e atualizar o estado do sistema. À medida que os domínios e aplicativos tornam-se mais complexos, essa abordagem é cada vez menos eficaz e viável.

As entrevistas clássicas individuais e de grupo ainda são aceitáveis. No entanto, é mais desejável que tenham como objetivo compreender os eventos relevantes com os quais o sistema deve lidar e as tarefas e as circunstâncias que os causam. O debate de eventos é uma nova metodologia para capturar delineados e preparar a camada de apresentação de fora rápida e eficaz. Você pode encontrar uma breve introdução à prática de debate de eventos, escrita pelo próprio autor e mestre, em bit.ly/1N25MJl. Em poucas palavras, esse é um método para explorar domínios de negócios complexos de forma rápida e direta. Ele é fortemente orientado a tarefas e permite que você aprenda sobre o domínio e, em especial, as tarefas a serem implementadas. O que é ainda melhor: ele permite que você ouça o que os usuários realmente precisam fazer e conheça o fluxo real de ações, gatilhos e eventos que precisa espelhar e refletir por meio de software.

Como validar delineados

Este é um ponto-chave: Sem a aprovação e a aceitação explícitas do cliente na criação do delineado, qualquer esforço é perdido, pois não garante uma UX final ideal. Na UXDD, você deve ter a aprovação para os delineados antes de começar a escrever grande quantidade de código.

No entanto, fazer com que os clientes examinem os delineados é apenas a primeira etapa. A validação eficaz dos delineados normalmente requer mais esforço. Você deve mostrar aos usuários o que significa executar uma tarefa e a sequência resultante de etapas e telas para concluir qualquer tarefa. Storyboard é o termo usado para indicar a concatenação de vários delineados de modo a compor uma tarefa de negócios. Se o conteúdo dos delineados for suficientemente preciso, a reprodução de um storyboard será muito semelhante ao teste de um protótipo de software. A diferença é que um storyboard custa uma fração do que custaria um protótipo de software e pode ser corrigido quase instantaneamente. Em cenários mais avançados, pode até ser razoável que usuários de filmes usem um filme ao reproduzir storyboards. Sua linguagem corporal pode revelar muito, assim como o tempo médio que cada operação leva. Um processo de validação preciso também pode incluir elementos de análise cognitiva, como TOTE (Test-Operate-Test-Exit). Como mostrado na Figura 1, o TOTE é, essencialmente, uma sessão iterativa de tentativa e erro destinada a aumentar progressivamente a satisfação dos usuários e a realização dos objetivos comuns.

Figura 1 Fluxograma TOTE de análise cognitiva adaptado para análise de UX

Não há mágica por trás do TOTE: trata-se de bom senso. Porém, embora pareça precipitado, ele funciona de forma eficaz. Quanto mais você aplicar a análise cognitiva e quanto mais gastar inicialmente, mais economizará depois. Para quem faz isso, o saldo é amplamente positivo. No geral, não pode ser pior do que quando você começa a programar com base em modelos presumidos e, depois, descobre que os artefatos errados foram entregues.

Uma história exemplar

A história que se segue é real. Após uma série interminável de reuniões, a equipe e o cliente tinham certeza de que todos os aspectos do site a ser criado tinham sido devidamente discutidos e analisados. Todos os aspectos do sistema foram supostamente esclarecidos e determinados; não eram esperadas surpresas ruins. A lua de mel durou apenas alguns dias, até que o desenvolvedor que trabalhava na página de logon gerou a primeira exceção. O logon só poderia ocorrer mediante associação? Não haveria uma autenticação por redes sociais? A resposta foi um sonoro "Não. O cliente não mencionou isso". O logon foi entregue sem a autenticação do Facebook e do Twitter. E adivinhe? Para o cliente, os logons sociais eram uma exigência estrita. Era tão estrita e óbvia que não foi sequer mencionada. Os logons sociais geravam trabalho extra. Caso se soubesse de antemão, isso provavelmente teria orientado a implementação do sistema de associação de forma diferente. Ao mesmo tempo, ficou claro para todos na equipe que se alguém mostrasse aos usuários um esboço da página de logon, a ausência do botão social teria sido observada e relatada, como mostrado na Figura 2.

Figura 2 Delineados para logon social que ninguém criou

De delineados a protótipos

Quanto mais você se interessar pela ideia de usar a análise cognitiva no processo de elicitação, mais buscará ferramentas específicas que ajudem a criar delineados e storyboards. Os delineados são relativamente fáceis e rápidos de criar, mas isso não se aplica aos storyboards. Deve-se observar que a simples concatenação de alguns delineados pode não ser suficiente para certos usuários e determinados cenários de negócios. Às vezes, é necessário escrever código para provas de conceito. É útil esclarecer a terminologia aplicável. Tipicamente, uma prova de conceito é um breve exercício para verificar uma suposição ou experimentar uma nova tecnologia em determinado contexto. Gosto de chamar a prova de conceito de "hello world" específico de um domínio. Por outro lado, um protótipo é um sistema fictício que tenta simular o sistema completo e é criado para testar a viabilidade ou até mesmo a utilidade de um sistema. Isso é o que você precisa ter quando os storyboards não são suficientes. Finalmente, outro termo que muitas vezes é usado como sinônimo, embora tenha sua própria definição estrita, é "piloto". Um piloto é um sistema de produção completo testado apenas em relação a um subconjunto do público geral a que se destina ou a um conjunto de dados.

Conclusão

Para serem eficazes, os delineados devem ser a moeda de troca entre as partes interessadas, apenas em um nível de abstração diferente da linguagem ubíqua do design independente de domínios. O objetivo da linguagem ubíqua e dos delineados é simplificar a conversa e reduzir o risco de mal-entendidos, deturpações de dados e suposições incorretas devido à falta de informações e diretrizes.

A linguagem ubíqua e os delineados não são métodos que podem transformar magicamente ideias em código de execução. De forma muito menos ambiciosa, a finalidade de ambos é encontrar uma sequência de etapas concretas que possam reduzir o custo de escrever software para se aproximar do orçamento e dos prazos esperados.

No próximo mês, vou explorar isso de forma ainda mais detalhada e discutir as (profundas) implicações arquitetônicas do uso de delineados.

Dino Espositoé coautor de “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) e “Programming ASP.NET MVC 5” (Microsoft Press, 2014). Um evangelista técnico para as plataformas Microsoft .NET Framework e Android na JetBrains e palestrante frequente em eventos do setor no mundo inteiro, Esposito compartilha sua visão do software em software2cents.wordpress.com e no Twitter em @despos.

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Jon Arne Saeteras