Valor de um sistema de design: o impacto do design e da usabilidade em sistemas complexos

Os métodos tradicionais de design de software apresentam um problema: é totalmente possível criar um sistema que não seja útil nem intuitivo, mas atenda às diretrizes de usabilidade. Normalmente, uma lista de novos recursos, atualizações funcionais e listas de desejos de componentes são coletadas das principais partes interessadas e usuários representativos, entregues a uma equipe de desenvolvimento talentosa que faz o possível para coordenar os requisitos e criar um sistema unificado que fará sentido para os usuários.

É assim que o software com uma péssima experiência do usuário é criado.

Neste whitepaper, veremos uma abordagem diferente: uma que começa a partir de um conjunto de requisitos enraizados nas necessidades do usuário (em vez de listas de desejos) e que envolve analistas de usabilidade e profissionais de design desde o início para colaborar e criar modelos rápidos e baratos do sistema final. Como esse processo de prototipagem rápida em "papel" não requer código, é tão fácil modificá-lo quanto apagar uma linha. Ele também oferece a oportunidade de colocar o protótipo na frente dos usuários e testar as ideias conceituais geradas durante a coleta de requisitos, bem como a usabilidade no nível da tela, garantindo que o produto final implementado seja utilizável e útil.

Carros, casas e software

Os carros existem desde o final de 1800. Eles começaram como carruagens mecanizadas, movidas por motores de combustão interna primitivos. Segundo todos os relatos, os primeiros carros eram desconfortáveis, não confiáveis e perigosos. Mas eles fizeram o que os meios de transporte maduros da época não conseguiram. Eles poderiam ir mais longe, mais rápido. E embora o proprietário/operador também precisasse atuar como seu próprio mecânico e fabricante de peças, era o suficiente.

As casas existem há um pouco mais de tempo do que os carros. No início, fornecer abrigo contra os elementos foi o fator decisivo na escolha de um lar digno. Se mantivesse a chuva e o vento do lado de fora, era o suficiente.

O software, particularmente o software corporativo, é o mais recente dos três. O software é interessante porque não é um objeto físico como um carro ou uma casa e, portanto, não está vinculado a uma forma ou tamanho específico. No entanto, como carros e casas, o software primitivo (e eu diria que quase todos os softwares hoje que requerem interação humana são softwares primitivos) são considerados aceitáveis se contiverem uma lista impressionante de recursos e funções. Independentemente de qualquer pessoa poder usá-lo, se o software fizer mais do que a versão anterior (ou o software de seus concorrentes), é o suficiente.

O que fica claro ao traçar a evolução desses três é que, inicialmente, sistemas complexos começam sua existência como eventos de engenharia. Basta que eles funcionem. Com o passar do tempo, os sistemas complexos evoluem da engenharia para o pessoal. Isso certamente é verdade para carros e casas. O software, no entanto, não está lá. Como mostrado na Figura 1, Don Norman referiu-se a essa ideia em seu livro de 1999 The Invisible Computer, embora ele estivesse falando sobre hardware em vez de software (ver, Norman, D., 1999: The Invisible Computer).

O software é um produto jovem, do ponto de vista da evolução do produto. Embora isso possa ser suficiente para explicar muito do motivo pelo qual continua sendo tão difícil de usar, não é motivo para aceitá-lo. Cada software é o resultado de inúmeras decisões bem-intencionadas. Ele foi projetado para ser exatamente o que é. Esse é o problema. Nem todo produto é bem projetado.

A usabilidade não é suficiente?

As empresas tentam resolver a questão do design ruim entregando as telas problemáticas a profissionais de usabilidade. Por meio de testes rigorosos e adesão a diretrizes consagradas pelo tempo, a usabilidade geral certamente pode ser melhorada. No entanto, ao lidar com sistemas complexos, melhorar a usabilidade após o projeto do sistema é semelhante a tratar os sintomas e não a doença. Com isso em mente, a seção a seguir fornece a resposta para a pergunta que inicia esta seção:

Usabilidade não é suficiente

Existem várias maneiras de abordar o design de um novo sistema. No primeiro, uma lista de novos recursos, atualizações funcionais e listas de desejos de componentes são coletadas das principais partes interessadas e usuários representativos. Esta lista é então entregue a uma equipe de desenvolvimento talentosa que faz o possível para coordenar os requisitos e criar um sistema unificado que fará sentido para os usuários. É assim que um software terrível é criado. Por que? Porque os desenvolvedores não são analistas ou designers de usabilidade e estão sendo solicitados a fazer o trabalho de ambos.

No segundo, um líder de pesquisa de usuários trabalha com as principais partes interessadas e usuários representativos para determinar as necessidades e requisitos de ambos os grupos. Isso resulta em um conjunto de requisitos mais apropriado.

Isso é incrivelmente poderoso. Nem os usuários nem as partes interessadas normalmente são capazes de ver além de sua lista de desejos imediatos e a diferença entre a melhoria incremental, dando aos usuários o que eles querem, e a inovação - dando aos usuários o que eles precisam - está na elicitação de requisitos qualificados. Embora esse novo sistema seja baseado em um excelente conjunto de requisitos, questões como layout de tela, modelos de interação e visualização de dados (ou seja, problemas de design) ainda estão sendo determinadas por funções cujas principais competências não são design.

Na terceira, líderes de pesquisa de usuários e profissionais de design colaboram, reunindo requisitos e criando maneiras inovadoras de apoiar os usuários à medida que concluem seu trabalho de maneiras que nunca sonharam. Parece um pouco utópico demais? É verdade e quando você pode fazer parte de um "processo de design" como parte interessada, usuário ou membro da equipe, é uma coisa linda. Os sistemas emergentes de design para código, como o Indigo.Design, também ajudam a facilitar a verdadeira colaboração entre design e desenvolvimento de UX.

Não é incomum que os leads de pesquisa do usuário descubram que mesmo os próprios usuários finais nem sempre sabem o que precisam.

Aqui está um caso em questão: no pregão de muitas empresas financeiras, não é incomum ver a estação de trabalho de um trader com quatro monitores montados dois sobre dois, em um único pedestal, inclinados de tal forma que basicamente envolvem a cabeça do trader. Nos monitores, você normalmente verá uma mistura complexa de planilhas, gráficos de linhas e pontos de dados coloridos, piscando e rolando. Você pode supor que o trader não tinha muito controle sobre como os dados eram exibidos e que eles estavam simplesmente transmitindo dados de outras fontes. Mas quando um trader de uma empresa financeira foi questionado "Quem controla a forma como os dados são exibidos na tela", a resposta do trader foi surpreendente: "Sim. Temos controle total dos dados e de como eles são exibidos."

Você pode pensar que ele diria que gostaria de ver informações importantes destacadas ou até mesmo algo tão simples como "pare que essas coisas pisquem o dia todo". Mas quando perguntaram a esse trader o que ajudaria a facilitar seu trabalho, ele disse que queria um processador mais rápido porque o que ele tinha só podia rodar 4 monitores. Com um processador mais rápido, ele poderia ter seis."

Quando você pensa sobre essa resposta, percebe os limites da perspectiva do usuário. Isso teria melhorado seu desempenho? Para os traders mais experientes, provavelmente teria resultado em algum grau de melhoria incremental. Mas não é o que eles precisavam.

Pesquisa de usuários: entendendo o que os usuários precisam

O que um usuário precisa fica claro à medida que você o observa trabalhar. Fica claro quando você pede que expliquem por que tomaram uma determinada ação ou por que as ações foram tomadas em uma determinada ordem. A inovação se torna possível quando você entende o que o usuário está tentando realizar. Durante uma tarefa, o trader estava tentando decidir se comprava ou vendia um determinado produto financeiro. Para fazer isso, ele estava interessado em saber como certas moedas estavam sendo negociadas umas em relação às outras, se as taxas de variação entre as moedas estavam tendendo na direção desejada ao longo do tempo e como isso se comparava às taxas históricas de variação entre as moedas: preocupações como taxa de variação, a taxa de variação da taxa de variação, e comparações históricas da taxa de mudança. Há muitas maneiras de representar essas informações. Uma maneira inclui 6 monitores de planilhas e gráficos de linhas. Ou um designer pode criar 3 novas maneiras de visualizar os dados da taxa de mudança rapidamente (porque é nisso que eles são extraordinariamente bons). Os usuários não podem pensar nesses termos. Francamente, nem a maioria dos analistas de usabilidade.

Defendi que a criação de software mais evoluído é possível por meio da implementação de um processo de design que depende da colaboração entre profissionais de usabilidade e design. E se também pudesse diminuir o risco associado ao desenvolvimento de software? E como o risco normalmente incorre em custos, e se a experiência e o design do usuário pudessem reduzir o custo do desenvolvimento de software? Antes de olharmos para os dois modelos mais proeminentes de desenvolvimento de software, seria útil considerar outra anedota.

Um conto de dois Harrys - ou como um resultado final pode não satisfazer as expectativas

Para explicar melhor os desafios do desenvolvimento de software, vamos considerar a experiência de meninos que se apaixonaram pelos livros de Harry Potter e sua reação ao vê-los na tela grande. Quando o primeiro dos filmes de Harry Potter foi lançado, esses meninos já haviam lido os três primeiros livros e estavam ansiosos para ver o filme. Mas uma coisa interessante acontece depois de esperar na fila, pagar US$ 10 por ingresso, comprar refrigerante, balas e pipoca e assistir 90 minutos das aventuras de Harry Potter. Eles não gostaram.

Quando perguntados por que não gostaram da mudança, eles disseram que não era o mesmo que o livro. Aparentemente, nem a pessoa que escreveu o roteiro, nem o diretor nem os atores conseguiram igualar o "filme" que os meninos construíram em suas cabeças. Portanto, o filme foi uma decepção.

Este é exatamente o problema com os métodos tradicionais de desenvolvimento de software. A codificação começa quando todos os envolvidos no projeto concordam que os documentos de requisitos baseados em prosa, contendo a soma total dos desejos, necessidades e desejos de todos, capturam corretamente esses desejos, necessidades e desejos. Esta é a primeira das três maneiras pelas quais o software pode ser criado (descrito anteriormente). Não apenas as partes interessadas (e usuários) dependem dos desenvolvedores para criar um sistema utilizável, mas também dependem dos desenvolvedores para criar um sistema que corresponda ao sistema que eles já criaram em suas mentes! Inevitavelmente, muitos meses depois, quando a cortina é puxada para trás e a versão alfa é revelada, a equipe luta para encontrar o sistema que imaginou. Isso é seguido por variantes de "Isso não é o que eu esperava". A única diferença real entre o meu exemplo de filme e este exemplo de desenvolvimento de software é que o pai dos meninos gastou apenas US $ 40. O projeto de software gastou mais do que isso em café.

Os dois principais processos de design de software hoje são Waterfall e Agile. Cada modelo começa com descrições baseadas em prosa dos requisitos que descrevem o que o software deve fazer. Cada um começa com um "Potencial de Risco" (meu termo) de zero. Com isso, quero dizer que, no início da fase de desenvolvimento, todos estão confiantes e felizes. Nada de ruim aconteceu e todos acreditam que compartilham uma visão comum para o produto final. Então o desenvolvimento começa e o risco começa a aumentar. Por que? Porque estão sendo tomadas decisões que fazem com que a forma final do produto se afaste da visão de cada membro da equipe. É culpa da equipe de desenvolvimento? Absolutamente não. Eles foram colocados na posição desconfortável de precisar tomar decisões de design enquanto tentam fazer o que amam fazer – codificar. E assim, com o passar do tempo, o risco aumenta cada vez mais.

Conforme demonstrado nas Figuras 2 e 3, isso acontece se o projeto estiver seguindo uma metodologia Waterfall ou Agile. Waterfall é o mais problemático dos dois porque o resultado não está disponível até que a compilação seja concluída. O Agile tenta resolver esse problema dividindo a compilação em sprints curtos. No entanto, isso só permite visualizações de partes isoladas da funcionalidade, exigindo que a equipe imagine como elas funcionarão dentro do todo maior.

Nenhum dos processos permite que a equipe visualize como será o sistema final, como ele se comportará ou como interagirá com outros sistemas e outras funcionalidades até que o processo de desenvolvimento seja concluído. Em ambos, o custo inicial de desenvolvimento é alto. Alterar decisões de design que já foram implementadas no código é ainda mais caro. A probabilidade de os usuários aceitarem tal sistema é pequena.

O processo de design, como mostrado na Figura 4, por outro lado, coordena as habilidades dos analistas de usabilidade e profissionais de design e aborda esse problema.

Além de criar um melhor conjunto de requisitos (que, reconhecidamente, poderia ser a entrada para os métodos Waterfall ou Agile), os profissionais de usabilidade e design também criam modelos rápidos e baratos do sistema final. Por meio de uma série rápida de esboços, wireframes e maquetes de tela, a equipe pode fornecer uma visão de todo o sistema que permite que todos se reúnam, questionem e cheguem a um acordo. Como esse processo de prototipagem rápida não requer código, é tão fácil modificá-lo quanto apagar uma linha. Ele também oferece a oportunidade de colocar o protótipo na frente dos usuários e testar as ideias conceituais geradas durante a coleta de requisitos, bem como a usabilidade no nível da tela. Depois que os bugs forem resolvidos e todos compartilharem um entendimento comum do produto final, a equipe de desenvolvimento pode começar a trabalhar. E além dos requisitos, eles também têm projetos que demonstram concretamente a forma visual final desses requisitos. O risco de desenvolvimento é, portanto, minimizado antes do início da codificação e mantido relativamente constante durante todo o processo de desenvolvimento.

Um bom design é um processo iterativo baseado em pesquisa que descobre e define requisitos. Ele fornece uma compreensão do que os usuários precisam realizar, além do que desejam. Ele permite consenso antecipado, modificações e testes de usuários. É rápido. É barato. É utilizável e intuitivo, bonito e inspirador. Reduz o risco. Ele fornece inovação em vez de melhoria incremental. Ele se encaixa nos métodos de desenvolvimento de software existentes. É escalável e suportável.

O software é um produto infinitamente maleável. Pode ser moldado em absolutamente qualquer coisa. Não precisa se preocupar com a disponibilidade de matérias-primas, logística de transporte ou suporte de fábrica. Será o que foi projetado para ser. Tudo o que é necessário é o desejo e um processo para torná-lo grande.

Recursos

Norman, D. (1999). O computador invisível: por que bons produtos podem falhar, o computador pessoal é tão complexo e os aparelhos de informação são a solução. A imprensa do MIT.