Inovação - Arquitetura Aprimorada com Design Controlado por UX

Por Dino Esposito | Novembro de 2015

Dino Esposito O design e a engenharia de qualquer sistema de software começam com uma etapa conhecida: a coleta de exigências dos usuários. Isso costuma envolver diversas reuniões e entrevistas com clientes e especialistas em domínio. Depois da última reunião, praticamente todos os envolvidos no projeto devem acreditar que todos os detalhes do sistema foram definidos e o desenvolvimento pode começar com segurança. Ninguém deve ter dúvidas de que o produto final será diferente do que foi explicado e compreendido. Os clientes devem estar felizes e os arquitetos devem acreditar que sabem exatamente o que fazer.

Entretanto, na prática, a experiência mostra que concordar sobre requisitos abstratos não garante uma implementação de sucesso. Quando os clientes veem o protótipo em si, normalmente não gostam dele. Todas as reuniões e discussões não importam, pois parece que clientes e desenvolvedores formam ideias distintas do produto final. Os desenvolvedores recebem as exigências e compilam o software com base nisso. Mas, o produto final costuma perder a marca do que os clientes querem.

Acredito que normalmente os desenvolvedores tendem a mirar na plenitude funcional e não se concentrar o suficiente nos processos de negócios que os usuários finais precisam para o sistema funcionar. Por isso, enquanto os aspectos funcionais dos processos de negócios são capturados, a implementação geral raramente é refinada e suave como o esperado. Neste artigo, apresentarei uma abordagem de design que pode aprimorar as chances de os arquitetos compilarem a coisa certa na primeira tentativa. Chamo esta abordagem de design controlado por UX ou UXXD, a forma abreviada.

A maçã que caiu na minha cabeça

Você deve se lembrar da inacreditável história da maçã que caiu na cabeça de Sir Isaac Newton, o que o levou a formular a Lei Universal da Gravidade. Recentemente, uma maçã caiu na minha cabeça e a mensagem que recebi é que prestar a devida atenção às expectativas dos usuários e aos processos reais às vezes pode exigir a criação de coisas diferentes. Ou seja, é necessário mais do que apenas uma análise funcional.

Um cliente pediu para compilar um aplicativo Web fácil e rápido, de acordo com suas palavras, para dar suporte a um competitivo torneio de tênis. Houve apenas uma história de usuário. O operador indicou o nome do jogador e a posição relacionada na partida e esperou que o sistema pudesse expor um XML feed que refletisse o estado atual da partida. A mente do meu desenvolvedor criou, imediatamente, a visão de uma tabela de banco de dados para reter os dados. Em seguida, eu tinha a visão de um formulário HTML rápido com duas caixas de texto: uma para indicar o nome do jogador e outra para a posição na partida. De modo interessante, quando a discussão foi encerrada, o cliente estava certo de que ele tinha uma ferramenta para inserir jogadores e posições, além de XML para dar suporte a este recurso. Mas, quando o desenvolvedor (eu) entregou apenas isso e o cliente fez os testes na simulação de uma partida em tempo real, não deu certo. Na verdade, o cliente queria algo muito mais complexo. Uma análise da Figura 1 mostra perspectivas diferentes entre desenvolvedores e clientes. A tela de fundo é o que o cliente deseja e a representação do processo real; a tela amarela com um contorno preto na sobreposição é a solução econômica, rápida e inapropriada.

Figura 1 - A Diferença Entre o Desejado e o Compreendido

No fim do dia, o UX é muito mais do que apenas gestos e elementos gráficos, ele é a experiência pela qual os usuários passam ao interagir com seu software. Para criar um UX eficaz, como arquiteto e desenvolvedor, você deve se concentrar mais nas tarefas e nos processos de negócios do que em modelos de dados e armazenamento. Para entender as tarefas, é necessário saber mais sobre o domínio, sobre os usuários e como tais usuários operam em determinado domínio. O UXDD aborda este item, mas não é simplesmente uma recomendação genérica para usar wireframes e maquetes. Usei isso em um cenário simples e não funcionou, pois o cliente – na cabeça dele – achou que o software era muito simples e não valia o esforço de engenharia completa do processo real. Como arquiteto, não entendi a mensagem correta do cliente sobre a importância da tarefa. Nunca escolha uma solução econômica; escolha uma eficaz. Tenho que admitir que a solução original proposta – a econômica – era impossível de ser usada em uma situação realista. Minha culpa era de ter confiado total e cegamente na análise do cliente e não ter aprendido mais sobre os processos de negócios reais.

O UXDD é um conjunto de prescrições arquitetônicas que pode minimizar o risco de perder pontos de negócios importantes relacionados às tarefas e à IU. É interessante que o UXDD pode mudar algumas das práticas consolidadas do desenvolvimento e da engenharia de software atuais.

Design de Cima para Baixo

De uma perspectiva funcional, você pode compilar com sucesso um sistema de trabalho independentemente se começar o esforço de design da parte de baixo (digamos que seja do modelo de persistência) ou de cima (da camada de apresentação e do modelo de exibição). De uma perspectiva de UX, você só será bem-sucedido se iniciar o design dos modelos de apresentação e exibição e compilar todos os outros itens, incluindo a pilha de back-end, ali.

Muitos de nós aprendemos profissionalmente que, ao ter um modelo de persistência de entidades e relações, compilado de requisitos de usuários, tudo estaria praticamente pronto. Este modelo seria o modelo de todo o sistema usado por meio da pilha completa e, somente às vezes, com parceria de alguns objetos de transferência de dados específicos à IU. Neste contexto, a criação e a compilação do sistema são realizadas de um modo de baixo para cima e a camada de apresentação reflete, inevitavelmente, na visão centrada em persistência do modelo de dados. Costumamos chamar isso de CRUD (criar, ler, atualizar, excluir) e normalmente reduzimos qualquer sistema a CRUD com uma lógica de negócios um pouco mais sofisticada. Ao fazer isso, prestamos pouca atenção à camada de apresentação. Às vezes, uma IU próxima demais ao modelo de dados é boa para os usuários, mas, às vezes, não. O último cenário dá um realce à negociação adicional quando o primeiro protótipo em funcionamento for entregue. Primeiro, você elabora um sistema de baixo para cima para descobrir, em algum momento, que a camada mais externa precisa ser alterada para refletir diferentes processos do usuário. Isso é a mesma coisa que tentar encaixar uma peça quadrada em um buraco redondo. Por causa disso, vejo esse item como o maior desafio de muitos projetos de software.

O que podemos fazer para melhorar o processo? Acredito que a resposta seja voltar para uma abordagem de design de cima para baixo que começa na camada de apresentação e toma outras decisões e detalhes de implementação por meio das necessidades da apresentação. Para torná-lo eficaz, um tipo de início, ou etapa anterior à cascata é necessária para garantir que um profundo entendimento do UX seja capturado antes de seguir para a compilação do back-end do sistema.

Metodologia Controlada por UX

Aprendi com especialistas em UX que os requisitos são gerados de modo aprimorado e ativo por meio de discussões com base em evidências e não passivamente por meio de entrevistas. Alguns arquitetos e analisas tendem a se manter muito passivos durante a descoberta, fazendo com que os usuários reduzam a prioridade de recursos para que o software fique pronto o quanto antes. Então, eles reclamam que o sistema mal pode ser usado quando o recebem. Enquanto isso, manter-se muito passivo na descoberta com a desculpa de que “isso é o cliente quer” não ajuda a entender o que você vai criar. Atualmente, produzimos software para refletir o mundo real e não para criar modelos do que o cliente disse que quer. A falta de aspectos estruturais dos negócios é um problema caro e mortal.

É uma prática comum usar wireframes para chegar a um acordo com a IU esperada. Executar wireframes de modo iterativo pelos usuários para solicitar comentários funciona somente até certo ponto. Wireframes são ótimos, mas são de valor limitado sem storyboards.

Poucas tarefas são realizadas por completo através de uma única tela que você pode resumir de modo eficaz a um wireframe. Apenas olhar para um wireframe de uma tela pode não ser suficiente para ver possíveis gargalos na implementação do processo. Concatenar telas em um storyboard é uma ideia muito melhor. Quanto a isso, o maior desafio que vejo é encontrar ferramentas para compilar storyboards. Estas ferramentas são um marketplace em rápido crescimento. A Figura 2 lista algumas ferramentas que podem ajudá-lo a criar um protótipo rapidamente da camada de apresentação dos aplicativos, de modo a fornecer aos usuários uma ideia concreta do processo que está sendo criado.

Figura 2 - Ferramentas para Criação de Protótipos de IU Rápida e Eficaz

Ferramenta	URL
Axure	axure.com
Balsamiq	balsamiq.com
Indigo Studio	infragistics.com/products/indigo-studio
JustInMind	justinmind.com
UXPin	uxpin.com

Além disso, versões recentes do Microsoft Visio e PowerPoint (principalmente em combinação com o Visual Studio Ultimate) também contam com algumas funcionalidades de criação de protótipos. Todas as ferramentas listadas na Figura 2 oferecem uma plataforma avançada para criar wireframes e, em alguns casos, oferecem a capacidade de criar maquetes clicáveis e torná-las protótipos funcionais.

A ferramenta mais avançada disponível fornece comentários iniciais e, o mais importante, permite a você envolver os clientes no início do processo de design e antes de gravar uma linha de código única. Se descobrir que perdeu pontos importantes da apresentação quando metade do back-end tiver sido concluído, você descarta ou ajusta o que for necessário.

Enquanto isso, a terceirização da camada de apresentação a uma equipe de especialistas em UX não é o suficiente. Atualmente, a camada de apresentação é a parte mais importante do sistema e deve ser resultado do esforço combinado dos arquitetos de solução, arquitetos de UX e clientes. Essa deve ser a primeira etapa e, de preferência, você deve seguir somente quando o cliente terminar a apresentação. Em termos de metodologia, é aceitável ter certa inclinação e concluir todo o design de apresentação antes da codificação, além de ser mais ágil e adicionar a análise da apresentação como uma etapa inicial, como mostrado na Figura 3.

Figura 3 - As Três Etapas do Design Controlado por UX Arquitetônico

Criando o Restante da Solução

Ao concluir a camada de apresentação de toda a solução ou apenas para o início atual, você tem uma coleção de telas, por exemplo, de formas, com um fluxo de dados bem definido (deve ficar claro o que entra e o que sai de cada formulário). Em termos arquitetônicos, isso quer dizer que você conhece o modelo de entrada de cada ação e o modelo de exibição necessário para preencher o formulário ou gerar a resposta esperada. A camada de apresentação conecta-se ao back-end por meio de uma camada de serviço intermediária que corresponde, de modo conceitual, ao padrão de Camada de Serviço, como definido por Martin Fowler (bit.ly/1JnFk8i), além da camada de aplicativo na arquitetura em camadas do Design Controlado por Domínio. Este é o segmento lógico do sistema em que você implementa os casos de uso e qualquer orquestração das tarefas exigidas. A camada de aplicativo é a parte principal do back-end e dialoga diretamente com a camada de apresentação. A camada de aplicativo é composta por pontos de extremidade diretos para cada uma das ações que podem ser disparadas pela apresentação. Estes pontos de extremidade recebem e retornam apenas os modelos de entrada e exibição, resultantes dos wireframes.

Esta abordagem é, de fato, eficaz? Pode apostar. Se sua análise de wireframe estiver completa e correta, você está implementando somente o que os clientes de processos querem e está correto na primeira vez. Você reduz, significativamente, as chances de renegociar alterações após implantar a primeira versão ou demonstração. Isso economiza tempo e, posteriormente, dinheiro. Como mostrado na Figura 4, os desenvolvedores indicam isso como um item emblemático de como os usuários enxergam o software. Desse modo, o UXDD leva à criação de software.

Figura 4 - Essência do Software pela Perspectiva do Usuário

Conclusão

Comparado a como criamos software atualmente, por meio do modelo de dados, o UXDD atribui mais importância às tarefas e à apresentação do que aos modelos de dados. Nem toda a modelagem e persistência de dados deixa de ser importante, mas suas funções são funcionais às tarefas mais do que no sentido inverso. Goste ou não, isso é o mais próximo do que o mundo real demanda atualmente. O UXDD está relacionado a metodologia em vez de tecnologia ou padrões. O UXDD não recusa nem tem qualquer mandato como tecnologias ou padrões, apesar de se sair muito bem com CQRS e Event Sourcing. Se você não está satisfeito com o processo real da compilação de aplicativos, use a abordagem UXDD como uma forma de pensamento lateral.

Dino Espositoé co-autor 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