Morte ao Wireframe. Direto para alta fidelidade!

UX design é uma disciplina fascinante. Para fazê-lo bem, os praticantes devem ser bem versados ​​em uma ampla variedade de tópicos e habilidades. Para praticar a metodologia de design centrada no usuário e criar soluções inovadoras e fáceis de usar para os desafios diários de design de produtos, o ofício e a compreensão de um profissional de UX envolvem tudo, desde o desenho básico até o design narrativo/de jornada até a psicologia cognitiva.

Há uma grande variedade de ferramentas usadas, artefatos gerados e descobertas descobertas no processo de design de UX/UI, e elas são capturadas em uma variedade de documentos ou até mesmo em um protótipo. Nosso artefato mais reconhecível é o bom e velho wireframe.

Os wireframes – geralmente esqueletos monocromáticos de designs criados para avaliação rápida – são ótimos. Eles nos permitem traduzir a entrada de muitas partes não relacionadas em um documento que todos podem revisar. Muitas funções de trabalho diferentes avaliam wireframes; analistas de negócios, gerentes de projeto, executivos de marketing, todos os tipos de designers e desenvolvedores, vários outros fornecedores e prestadores de serviços - até mesmo o público-alvo ao testar produtos. O wireframe permite que todos vejam como suas necessidades individuais serão atendidas e dá a toda a equipe a chance de resolver todos os problemas antes que qualquer trabalho pesado precise ocorrer.

Existem prós e contras, mas em certos casos, faz sentido pular completamente a fase de wireframing. Muito tempo pode ser economizado ao lidar com o UX e o design visual no nível de alta fidelidade logo após a descoberta ou durante a preparação para a prototipagem. Isso daria a outras pessoas a oportunidade de avaliar a funcionalidade e a aparência do produto ao mesmo tempo, desde participantes de testes de usuários até clientes e colegas.

Vamos descobrir por que os wireframes às vezes podem ser problemáticos, quando ignorá-los faz sentido e como adaptar um processo sem wireframe a um fluxo de trabalho.

O problema dos wireframes

Seja em um ambiente em cascata ou ágil, o processo de design típico envolve fases de pesquisa, definição, idealização, prototipagem, teste e implantação, bem como muitos pontos de contato para revisão com as partes interessadas ao longo do caminho.

Vejamos o processo de design para exemplos de quando o design de wireframe pode ser um gargalo:

Razão 1: os clientes não entendem o que estão vendo

O processo de design normalmente começa com algum tipo de pesquisa sobre o problema. Pesquisa documental, entrevistas com stakeholders e entrevistas com usuários são apenas algumas das atividades que podem ser realizadas para obter uma compreensão mais profunda. Após a pesquisa, a equipe de design começa a avaliar uma série de ideias e conceitos para encontrar a melhor solução.

Quando um conceito é mais desenvolvido, a equipe de design geralmente compartilha uma série de wireframes com o cliente durante uma sessão de revisão.

O problema é que os wireframes são muito abstratos.

Eles descrevem algo que é como a coisa, mas não a coisa real que será construída. Nesse estágio, os wireframes conteriam imagens de espaço reservado e todos os tipos de TKs (a vir), FPOs (apenas para posicionamento) e TBDs (a serem decididos), como o exemplo abaixo.

Provavelmente há detalhes sobre funcionalidade, requisitos de negócios e tratamento de erros que serão indicados em uma enorme lista de anotações. Normalmente, nunca há tempo suficiente para vasculhar esses detalhes, então o cliente terá que lê-los por conta própria.

Durante as revisões do wireframe, pedimos aos nossos clientes que se concentrem no conceito que está sendo descrito e avaliem se ele parece estar resolvendo ou não os problemas do negócio e do usuário. No entanto, ainda recebemos perguntas sobre coisas que, para nós, não parecem estar relacionadas. Os clientes querem saber se o wireframe é a “cópia final” ou se podem ver exemplos das fotos a serem exibidas na imagem do herói – ou outra pergunta sobre algo que será tratado em design visual, prototipagem de interface do usuário ou desenvolvimento.

Os wireframes podem ser muito abstratos para que os clientes e até mesmo as partes interessadas internas avaliem efetivamente. Os wireframes dizem às pessoas como um design será quando estiver pronto, mas elas ainda precisam fazer muito trabalho mentalmente para fazê-lo se encaixar em suas cabeças. Nossos clientes podem ou não ser pensadores visuais, e pode ser demais esperar que eles olhem para um projeto e imaginem um produto ou site de sucesso.

Houve alguns clientes que solicitaram especificamente a revisão de designs visuais anotados porque é muito mais fácil para eles conectar os pontos, ter uma discussão ponderada e fornecer feedback bem considerado.

Razão 2: eles nem sempre são adequados para testes de usuário

Felizmente, alguns testes de usuário foram agendados no processo de design, pois é uma boa maneira de testar tudo, desde a viabilidade de um conceito inteiro até o nível de detalhe a ser exibido em uma transação.

Uma maneira típica de testar esse tipo de coisa é através da prototipagem.

Os wireframes podem – e funcionam – funcionar para prototipagem. A equipe de design está limitada apenas a testar o fluxo e a funcionalidade e, como não possui uma camada de design visual, os estilos visuais que afetam o comportamento do usuário podem ser facilmente ignorados.

Isso é sábio? UX, visual e design de cópia impactam um ao outro. É difícil separá-los e isolá-los em um ambiente de teste. Semelhante a um estudo científico, os resultados de uma função testada isoladamente não podem controlar – ou prever como – ela se comportará na natureza.

Às vezes, é mais eficaz testar todas essas coisas de forma holística.

Caso em questão: um produto ou serviço multilíngue. Os idiomas podem ter diferentes gramáticas, alfabetos e larguras de caracteres que podem afetar o design geral.

Além disso, como o conteúdo da cópia afeta o UX, a própria tradução pode afetar o UX.

Por exemplo, tivemos uma tarefa em que fomos obrigados a testar algumas arquiteturas de informação diferentes devido à forma como vários conceitos precisavam ser explicados no idioma local. Não teríamos descoberto o impacto na redação e tradução sem testar a cópia real na interface do usuário.

Descobrimos que mais palavras eram necessárias para descrever conceitos semelhantes no idioma local e que teríamos que alterar os tamanhos e as formas dos botões globalmente para acomodar as palavras detalhadas necessárias para esse idioma. Sem focar nos problemas de texto ao testar componentes visuais reais na interface do usuário, não teríamos descoberto que os botões precisavam ocupar toda a largura da tela do celular, o que impactou nosso design de UX daqui para frente.

Importante: faz sentido preparar interfaces de usuário de alta fidelidade desde o início, especialmente para um projeto multilíngue.

Razão 3: Eles tornam a vida dos desenvolvedores e do controle de qualidade um inferno

O que inevitavelmente acontece durante a fase de design visual é que tudo se move. As imagens empilhadas tornam-se telhas. O texto centralizado fica alinhado à esquerda. Os ícones de gatilho de acordeão eram + e - , mas agora eles são alguns chevrons.

Esta é uma parte normal do processo de design visual. O que também é normal é que quaisquer alterações feitas no design visual não serão refletidas nos wireframes porque os wireframes foram “autorizados”.

Quando todos os visuais forem aprovados, é hora de entregar tudo aos desenvolvedores. Na maioria dos casos, eles receberão um conjunto de wireframes detalhados e anotados e um conjunto de belos designs visuais junto com um guia de estilo. Agora cabe a eles fazer a referência cruzada entre esses dois documentos e dar vida a tudo isso.

Esta é uma área onde o processo de design pode realmente falhar. Damos aos desenvolvedores muitos documentos para consultar e deixamos que eles determinem quais informações têm precedência. Isso aumenta o tempo necessário para chamadas de suporte e controle de qualidade, afetando naturalmente o tempo necessário para lançar um produto ou atualização no mercado.

Por que não fornecer aos desenvolvedores apenas um documento preciso que inclua tudo? A maioria dos clientes também gostaria de receber uma cópia para usar como referência completa para o trabalho.

A solução: pular wireframes

Claramente, há momentos em que uma fase de wireframe completa é necessária e há momentos em que não é. Há até momentos em que ir direto para a alta fidelidade supera completamente a fase de wireframe.

Você pode considerar pular a fase de wireframe se alguma delas for verdadeira:

Existe material de referência sólido no local.

Dê uma olhada no trabalho existente no local. Pode já haver referências detalhadas de interface do usuário disponíveis. Se você estiver atualizando um site existente ou adicionando um novo recurso a um aplicativo existente, consulte o site e o aplicativo atuais para encontrar padrões e estilos a serem reutilizados.

Seria ainda melhor se você tivesse acesso aos arquivos de origem para o trabalho existente. Alguns recursos e elementos podem ter se perdido na tradução, por assim dizer, durante o processo de desenvolvimento, e você pode consultar o arquivo de origem para ver como esse recurso deveria ter sido feito.

Além de (ou na ausência de) um produto ou site existente, verifique se há um guia de estilo ou uma biblioteca de padrões em vigor. O cliente pode já ter pago por algum trabalho de branding e design visual, e esses recursos podem ser reutilizados novamente para o seu projeto.

Use o máximo de estilos e padrões que puder encontrar para que suas saídas de alta fidelidade sejam as mais precisas possível.

Você programou muitos testes e protótipos iterativos ao longo do caminho.

Economize algum esforço ao longo das semanas de prototipagem e testes. Se você configurar seu documento com cuidado na primeira vez e fizer uso inteligente de estilos, padrões e símbolos repetidos, poderá facilmente fazer atualizações incrementais em alta fidelidade e publicá-las diretamente em seu fluxo de trabalho de prototipagem. Não precisa de wireframes.

Como uma grande vantagem, você pode matar dois coelhos com uma cajadada só. Você pode obter feedback visual e de interface do usuário junto com seu feedback de UX e fazer todas essas alterações de uma só vez.

Seus participantes de teste são muito literais.

Assim como seus clientes e colegas de trabalho às vezes podem exigir exemplos concretos, o mesmo pode acontecer com o público-alvo do seu projeto.

Um show recente me fez projetar telas financeiras para um público-alvo de baixa alfabetização. A compreensão da leitura não era o único problema - conceitos abstratos eram muitas vezes muito difíceis de abordar. Esse público-alvo normalmente precisava discutir conceitos financeiros usando exemplos concretos; caso contrário, eles não foram capazes de realmente acompanhar a conversa.

Para entender os conceitos financeiros, os participantes do teste nesse público precisavam sentir que estavam realmente realizando transações. E para entender como o produto funcionava, ele precisava parecer uma aplicação real.

Esqueça os wireframes para um público como esse! Você vai acabar gastando muito tempo explicando o que eles são – e seu público não vai se concentrar nas tarefas, nem como eles se sentem sobre elas porque eles não conseguem se relacionar com algo tão desconhecido em suas vidas.

Seu cliente tem tempo e/ou orçamento limitados.

É raro ter tempo, recursos e orçamento a seu favor. Muitas vezes, você pode tentar reduzir o escopo e o preço, ou se esforçar para ver onde pode economizar e ainda oferecer um ótimo serviço ao seu cliente.

Se você tem um cliente que não pode pagar (ou que provavelmente não comprará) um trabalho completo de UX, posso sugerir cortar o tempo de wireframe? Crie alguns internamente se precisar, mas mantenha o projeto em movimento para o seu cliente. Teste designs reais e tangíveis e faça com que seu cliente reaja ao trabalho real.

Como matar a fase de wireframe

Esta parte é bastante subjetiva, pois dependerá do seu fluxo de trabalho pessoal e das necessidades específicas do seu cliente.

Dito isto, este é um “modelo” de processo que você pode inicialmente tentar adaptar ao seu fluxo de trabalho e, em seguida, ajustar à medida que obtém mais prática trabalhando dessa maneira.

Passo 1: Comece com seu processo usual de pesquisa e descoberta.

Entrevistas, observações de campo, pesquisa documental, análises competitivas – o que quer que você faça normalmente (ou tenha programado para fazer), complete esta fase como faria normalmente.

Passo 2: Esboce um pouco ao longo do caminho.

Enquanto você está realizando uma pesquisa, provavelmente está obtendo algumas ideias para layouts e padrões úteis, fluxos envolventes e coisas do gênero. Registre-os como costuma fazer. Eu gosto de fazer esboços em miniatura no meu caderno, com notas escritas ao lado deles. Você pode preferir esboçar em um quadro branco ou fazer capturas de tela de padrões de interface do usuário interessantes. O que quer que o ajude a lembrar de boas ideias, faça-o.

Etapa 3: preparar seu documento de alta fidelidade

Abra sua ferramenta de design de escolha e configure seu documento corretamente. Escolha alguns tamanhos de pranchetas e comece a criar formas, grupos e símbolos repetíveis.

Reserve um tempo para salvar a paleta de cores da marca como amostras individuais, criar e organizar estilos de texto e criar sombras e filtros padrão que você pode aplicar em todas as formas conforme necessário.

Gaste muito tempo acertando seus símbolos. Você pode ter um botão que, dependendo de seu estado, pode ter quatro cores diferentes. Faça uso de substituições de símbolos - se puder - para que você possa aplicar facilmente cores e rótulos de texto diferentes conforme necessário.

Se houver algum ícone personalizado usado, salve-o como símbolos individuais em uma prancheta quadrada (ou qualquer forma apropriada). Dessa forma, será fácil dimensioná-los para cima e para baixo, mantendo o espaçamento e o alinhamento adequados.

Passo 4: Comece a projetar.

Sua primeira rodada pode ser um pouco difícil à medida que você se acostuma a trabalhar dessa maneira e vê onde seu guia de estilo se sustenta (e onde não). Além de criar soluções para padrões que ainda não têm um estilo definido, espere fazer alguns ajustes para obter todos os estilos corretos.

Ao longo deste processo, vá com uma boa “direção de cópia” ou com uma cópia real, se você a tiver. Não faça títulos que digam: "O título da página vai aqui". Dê ao espectador uma noção do que aconteceria aqui se fosse real.

Da mesma forma, não crie uma lista de nomes que digam John Smith com o número de telefone 555-1212. Use um gerador de lista aleatória ou plug-in para criar nomes e números diferentes ou crie qualquer conjunto de dados que você precise exibir. Isso pode parecer um exagero, mas permite que você resolva problemas com layout e larguras de caracteres e ajuda o espectador a entender que essas cinco entradas são todas diferentes.

Passo 5: Saiba quando parar de projetar.

Existem alguns detalhes que você não deve cuidar neste momento porque eles realmente levarão muito tempo. Talvez seja escolher a imagem exata para entrar em um herói ou projetar um ícone personalizado para indicar um estado de download. Esses são alguns casos em que você pode optar por usar uma imagem ou ícone de espaço reservado e testar imagens ou iconografia reais posteriormente.

Você terá que fazer a chamada sobre o que é apropriado aqui, pois dependerá dos objetivos do projeto, bem como de quão longe você está com ele.

Observe que isso pode depender do que os participantes do teste de usuário precisam para avaliar adequadamente o trabalho. Para o público-alvo de baixa alfabetização que mencionei acima, nada era muito detalhado. Para cada participante, fiz uma variante do protótipo com seu nome real e número de telefone usado em toda parte, para que o aplicativo realmente parecesse ser “deles”. Quanto menos eles tivessem que assumir, mais fácil era para eles seguirem e melhores meus resultados.

Etapa 6: aproveite o feedback de alta qualidade e os resultados dos testes.

Publique seus projetos diretamente na ferramenta de prototipagem de sua escolha e leve-os ao campo para testes. Agora você pode obter feedback sobre mais do que apenas a funcionalidade. Você pode descobrir possíveis problemas visuais, como problemas com contraste de cores ou legibilidade, e descobrir problemas com direção de cópia ou tradução. Você também pode provocar sentimentos positivos ou negativos que os usuários possam ter sobre a aparência ou a marca.

Essas são todas as coisas sobre as quais você provavelmente obteria feedback de qualquer maneira quando chegasse à fase de design visual. Por que não obter todo esse feedback agora? Alguns dos comentários sobre os visuais podem afetar diretamente o UX e vice-versa, por isso é bom trabalhar tudo isso ao mesmo tempo, se puder.

Empacotando

Sem dúvida, existem muitos casos em que uma fase de wireframe completa é necessária para o sucesso do projeto. Um design complexo, como um aplicativo da Web responsivo, precisa de um foco separado e dedicado em wireframes. Economizaria tempo e dinheiro para resolver todos os requisitos de negócios, casos extremos e tratamento de erros no estágio de wireframe, do que seria se uma camada visual completa já tivesse sido concebida e aplicada.

No entanto, nos casos certos, ir direto para a alta fidelidade pode melhorar seu processo:

• Melhore o feedback das partes interessadas . Clientes, desenvolvedores, outros designers e participantes de teste do público-alvo podem ver exatamente o que obterão, permitindo que forneçam feedback de alta qualidade.
• Acelere seu fluxo de trabalho de prototipagem . Além de seus designs estarem prontos para serem testados imediatamente, você pode obter feedback sobre várias coisas ao mesmo tempo: o UX, a cópia e o visual.
• Entregue um único documento para clientes e desenvolvedores . Elimine a necessidade de referências cruzadas e verifique uma variedade de documentos para entender como um botão deve funcionar. Essa também é uma ótima maneira de seu cliente discutir o trabalho com as partes interessadas internas para obter ainda mais feedback.
• Economize tempo e dinheiro . E isso é quase sempre uma coisa boa!

Dê uma chance a essa abordagem na próxima vez que tiver um projeto em que tenha alguns materiais de design existentes para consultar ou onde fará uma grande diferença para seu público se o trabalho for de baixa ou alta fidelidade.

• • •

Leia mais no Blog Toptal Design:

• eCommerce UX – Uma visão geral das melhores práticas (com infográfico)
• A Importância do Design Centrado no Homem no Design de Produto
• Os melhores portfólios de UX Designer – Estudos de caso e exemplos inspiradores
• Princípios heurísticos para interfaces móveis
• Design Antecipatório: Como criar experiências de usuário mágicas