O design UX é uma disciplina fascinante e, para trabalhar nela corretamente, aqueles que a praticam devem conhecer diferentes disciplinas 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, um praticante de UX deve criar e compreender tudo, desde o desenho básico até a narrativa em psicologia cognitiva.

Existe uma grande variedade de ferramentas que podem ser usadas, artefatos gerados e descobertas no processo de Design UX , e são capturados em uma variedade de documentos. E o mais conhecido, algo de uso diário para designers, é o bom e velho wireframe.

Um conjunto de wireframes para um aplicativo móvel
(De Sunzby )

Wireframes - estruturas de design tipicamente monocromáticas criadas para avaliação rápida - são ótimas. Eles nos ajudam a traduzir as contribuições de muitos lados não relacionados em um único documento que todos podem revisar. Muitas funções de trabalho diferentes avaliam wireframes; analistas de negócios, líderes de projeto, executivos de marketing e todos os tipos de designers e desenvolvedores, profissionais de marketing e provedores de serviços - até mesmo o público-alvo ao fazer testes de produtos. O wireframe ajuda a todos a ver como suas necessidades individuais serão atendidas e dá a toda a equipe a oportunidade de trabalhar os detalhes antes de se aprofundar no projeto.

Existem prós e contras, mas em certos casos, faz sentido pular o estágio de wireframe inteiro. Muito tempo poderia ser economizado se entregássemos a experiência do usuário e o design visual em um nível de alta fidelidade logo após o estágio de descoberta. Isso daria a muitos outros a oportunidade de avaliar a funcionalidade e como o produto se sente e se parece ao mesmo tempo, desde os participantes do teste do usuário até os clientes e colegas.

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

O problema com wireframes

Seja em um ambiente ágil ou em cascata, o processo de design típico inclui fases de pesquisa, definição, ideação, prototipagem, teste e comissionamento, bem como muitos outros pontos-chave para revisar com as partes interessadas ao longo do caminho.

Seu processo de design provavelmente inclui essas fases.
(Graças a Nielsen Norman Group )

Vejamos o processo de design para obter exemplos de quando os wireframes podem ser um gargalo:

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

O processo de design normalmente começa com algum tipo de investigação do problema. Pesquisa documental, entrevistas com as partes interessadas e entrevistas com usuários são algumas das atividades que podem ocorrer no processo de design para obter uma compreensão mais profunda do projeto. Depois de fazer pesquisas, a equipe de design começa a avaliar uma série de idéias e conceitos para encontrar a melhor solução.

Quando um conceito recebe mais substância, a equipe de design 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 os descrevem como algo que é quase o design em si, mas não exatamente o design a ser desenvolvido. Neste ponto, os wireframes conterão apenas imagens ou elementos de referência de todos os tipos que virão, apenas por arranjo, e coisas ainda a serem definidas, como no exemplo abaixo.

Provavelmente, há detalhes sobre a funcionalidade, requisitos de negócios e como os erros são tratados, que serão detalhados em uma grande lista de anotações. Normalmente, haverá tempo suficiente para polir essas coisas em grande detalhe, de modo que o cliente possa lê-las por conta própria.

Durante as análises de wireframes, pedimos aos nossos clientes que se concentrem no conceito que está sendo descrito e avaliem se ele parece resolver ou não um problema de usuário e de negócios. Os clientes querem saber se esta é a 'versão final', ou se podem ver exemplos das fotos que serão vistas no herói , ou outra pergunta sobre algo que será tratado durante o design visual ou estágio de desenvolvimento.

Os wireframes podem ser muito abstratos para os clientes e até mesmo para as partes interessadas internas, para que possam avaliá-los com eficácia. Os wireframes dizem às pessoas como será a aparência de um projeto quando estiver concluído, mas elas ainda precisam fazer muito trabalho mental para descobrir em suas cabeças. Nossos clientes podem ou não ser pensadores visuais, e seria muito esperar isso deles quando olham para um projeto e imaginam um site ou produto de sucesso.

Poucos clientes pediram especificamente para revisar designs visuais comentados porque é muito mais fácil para eles conectar os pontos, ter discussões mais criteriosas e dar retornos mais substanciais.

Razão 2: eles nem sempre são bons em testar usuários

Felizmente, o teste do usuário foi planejado com antecedência, porque é uma boa maneira de garantir a viabilidade de todo o conceito em um nível de detalhe para ser exibido em uma transação.

Uma maneira típica de testar essas coisas é por meio da prototipagem.

Wireframes podem e funcionam para prototipagem. A equipe de design está limitada apenas ao fluxo de teste e, como não tem uma camada de design visual, os estilos visuais que afetam o comportamento do usuário podem ser facilmente ignorados.

Este é o melhor? UX, design visual e de texto têm impactos um no outro. É difícil separá-los e isolá-los em um ambiente de teste. E, semelhante a um estudo científico, os resultados de uma função testada isoladamente não podem controlar - ou prever como - ela se comportará ao ar livre.

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

Os sites em inglês e hebraico do Haaretz têm diferentes layouts de interface do usuário.

O ponto aqui é: Um produto ou serviço multilíngue. Os idiomas podem ter gramática, alfabetos e larguras de caracteres diferentes que podem afetar o design geral.

Além do mais, como o cópia de ou o conteúdo do texto afeta a experiência do usuário, a própria tradução pode afetar a experiência do usuário também.

Por exemplo, tivemos uma tarefa em que fomos obrigados a testar algumas arquiteturas de informação devido a como os diferentes conceitos precisavam ser explicados no idioma local. Não teríamos percebido o impacto do conteúdo e da tradução sem testar o próprio conteúdo na IU.

Percebemos que mais palavras eram necessárias para descrever conceitos semelhantes no idioma local, e tivemos que alterar o tamanho e a forma dos botões globalmente para acomodar o que certos verbos exigiam naquele idioma. Se não tivéssemos encontrado nenhum problema no texto ao testar os componentes visuais na IU, não teríamos descoberto que os botões precisavam ocupar toda a largura da tela do celular, o que impactou o design UX a partir de então.

Ponto importante: faria sentido preparar IUs de alta fidelidade do zero, especialmente para um projeto multilíngue.

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

O que acontece inevitavelmente durante a fase de design visual é que tudo se move. Imagens empilhadas tornam-se mosaicos. O texto centralizado fica alinhado à esquerda. O que eram ícones com efeito de acordeão eram + e -, mas agora eles são alguns padrões.

É uma parte normal do design visual . O que também é comum é que quaisquer mudanças no design visual não serão refletidas nos wireframes porque os wireframes já foram “assinados”.

Quando todos os visuais forem aprovados, é hora de enviar tudo para os desenvolvedores. Em muitos casos, eles receberão uma variedade de detalhes, wireframes anotados e uma coleção de belos designs visuais com guias de estilo. Agora é sua vez de fazer uma referência cruzada entre esses dois documentos e trazê-los à vida.

Um wireframe anotado

Esta é uma área em que o processo de design pode realmente falhar. Fornecemos aos desenvolvedores muitos documentos para consultar e deixamos para eles determinar quais informações têm precedência. Isso aumenta o tempo necessário para chamadas de backup e QA, impactando naturalmente o tempo que leva para um produto ser lançado ou atualizado para o mercado.

Especificações de design visual

Por que não dar o desenvolvedores só um documento correto que inclui tudo? Muitos clientes também gostariam de ter uma cópia para usar como uma referência completa para o trabalho.

A solução: pular wireframes

Claramente, há momentos em que uma fase inteira de wireframe é necessária, mas há outros momentos em que não é necessário. Há momentos em que ir direto para algo hi-fi supera a fase de wireframe em geral.

Portanto, você pode considerar pular a fase de wireframe se algum destes se aplicar:

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

Dê uma olhada no trabalho existente. Referências detalhadas podem já estar disponíveis na IU. Se você estiver atualizando um site existente ou adicionando novos recursos a um aplicativo existente, examine o site ou aplicativo atual para encontrar padrões e estilos para reutilizar.

O trabalho existente pode ser rico em estilos e ter componentes e padrões reutilizáveis ​​para explorar e usar em projetos futuros.

Seria ainda melhor se você tivesse acesso aos arquivos de origem do trabalho existente. Alguns recursos e elementos podem ter sido perdidos, por assim dizer, durante a fase de desenvolvimento, e você poderia voltar ao arquivo original para ver o que o recurso deveria ter feito.

Para adicionar a um produto ou site existente (ou na sua ausência), veja se há um guia de estilo ou biblioteca de padrões no local. O cliente poderia ter pago anteriormente por algum trabalho de design em branding ou visual, e esses recursos poderiam ser reutilizados em seu projeto.

Certifique-se de que existe um guia de estilo e biblioteca de componentes.

Use todos os estilos e padrões que puder encontrar para que os resultados de alta fidelidade que você obtém sejam os mais precisos possível.

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

Economize o esforço de semanas de prototipagem e testes. Se você criou seus documentos certos da primeira vez e fez uso inteligente de estilos, padrões e símbolos repetitivos, então você pode facilmente fazer grandes atualizações de alta fidelidade e publicá-las em seu fluxo de trabalho de prototipagem. Não há necessidade de wireframe.

Como um grande bônus, você pode matar dois coelhos com uma cajadada só. Você pode receber retornos visuais e de IU com retornos de UX e fazer todas essas alterações de uma vez.

Os participantes de seus testes são muito literais.

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

Um projeto recente me fez projetar mostruários financeiros para um público-alvo de baixo nível de alfabetização. A compreensão de leitura não era o único problema - conceitos abstratos eram frequentemente difíceis de entender. Esse público-alvo normalmente precisava discutir conceitos financeiros usando exemplos concretos; caso contrário, eles não seriam capazes de acompanhar a conversa.

Para entender os conceitos financeiros, os testadores neste público tiveram que sentir que estavam realmente fazendo uma transação. E para entender como o produto funcionava, ele precisava ter a aparência de um aplicativo real.

Testando usabilidade

Esqueça wireframes para um público como este! Você acabará gastando mais tempo explicando o que eles são - e seu público não será capaz de se concentrar nas tarefas específicas, ou como eles deveriam se sentir a respeito delas, porque não podem pensar em usar algo tão estranho como wireframes em seus vidas.

Seu cliente tem um tempo / orçamento limitado.

É raro ter tempo, recursos e orçamento totalmente à sua disposição. Normalmente, você pode tentar reduzir o escopo e o preço ou se esforçar para ver como pode ajustar e economizar e ainda oferecer um ótimo serviço para o seu cliente.

Se você tem um cliente que não pode pagar (ou provavelmente não vai comprar) um processo de UX inteiro, você poderia sugerir reduzir o tempo de processo do wireframe? Crie alguns internamente, se necessário, mas continue fazendo o projeto funcionar para o seu cliente. Experimente designs tangíveis e reais e deixe seu cliente reagir ao trabalho real.

Como Eliminar a Fase de Wireframes

Esta parte é principalmente subjetiva, porque depende do seu processo de trabalho pessoal e das necessidades específicas do seu cliente.

Dito isso, esse é um processo do tipo 'modelo' que você pode tentar adaptar ao seu processo de trabalho e, em seguida, modificar à medida que continua praticando dessa forma.

Etapa 1: comece com seu processo usual de investigação e descoberta.

Entrevistas, trabalho de campo, pesquisa documental, análise competitiva - tudo o que você normalmente faz (ou planeja fazer), conclua esta fase como faria normalmente.

Etapa 2: esboce um pouco.

À medida que pesquisa, você provavelmente terá ideias para layouts e padrões úteis, fluxos interessantes e assim por diante. Salve essas ideias normalmente. Prefiro fazer esboços no meu caderno com anotações escritas. Você pode preferir esboçar em um quadro branco ou fazer capturas de tela de padrões de IU existentes. O que quer que o ajude a lembrar boas ideias, faça-o.

Esboçando um conceito de interface de usuário
(De Miklos Philips )

Etapa 3: Prepare seu documento de alta fidelidade.

Abra sua ferramenta de design preferida e organize seu documento apropriadamente. Escolha alguns tamanhos de tela e comece a criar formas, grupos e símbolos repetitivos.

Reserve um tempo para salvar as cores da marca como amostras individuais, crie e organize estilos de tipo e certifique-se de criar sombras e filtros padrão que você pode aplicar em quantas formas forem necessárias.

Passe muito tempo ajustando seus símbolos. Você pode ter um botão que, dependendo de seu estado, pode ter quatro cores diferentes. Certifique-se de usar a substituição de símbolo - se puder - para que possa aplicar facilmente diferentes cores e rótulos de texto quando precisar deles.

Símbolos de design de interface do usuário em Esboço

Se forem usados ​​ícones personalizados, salve-os como símbolos individuais em uma tela retangular (ou em qualquer forma apropriada). Dessa forma, será fácil aumentá-los ou diminuí-los enquanto mantém o espaço e o alinhamento adequados.

Etapa 4: comece a projetar.

Sua primeira rodada pode ser um pouco difícil à medida que você se acostuma a trabalhar dessa maneira e ver até onde vai o guia de estilo (e onde não vai). Além de criar soluções para padrões que ainda não têm um estilo definido, você pode esperar fazer muitas modificações para obter os estilos perfeitos.

Por meio desse processo, escolha um bom 'endereço de conteúdo' ou conteúdo real, se o tiver. Não acredite em títulos que dizem: 'O título da página vai aqui.' Dê ao espectador uma ideia do que haveria lá se fosse real.

Da mesma forma, não crie uma lista de nomes em que todos sejam John Smith com um número de telefone 555-1212. Use um gerador aleatório ou plug-in para ter nomes e números diferentes, ou crie a lista de dados que você precisa exibir. Isso pode parecer muito trabalhoso, mas permitirá que você resolva problemas com a largura dos caracteres e ajudará o usuário a entender que esses cinco campos a preencher são diferentes.

Tente não fazer com que todos os campos para preencher uma lista de contatos digam John Smith. Use um gerador aleatório ou plug-in para ter nomes e números diferentes, ou crie a lista de dados que você precisa exibir.
(Cortesia de Plugin Craft Y Tethr modelo para InVision Sketch)

Etapa 5: Saiba quando parar de projetar.

Existem alguns detalhes nos quais você não deve se concentrar neste momento porque eles realmente demoram muito. Talvez seja a escolha da imagem exata para um herói ou crie um ícone personalizado para indicar o status do download. Estes são alguns casos em que você pode escolher usar uma imagem ou ícone de referência e testar imagens reais ou iconografia posteriormente.

Você terá que decidir o que é apropriado aqui, porque vai depender dos objetivos do projeto e também do quão longe ele está.

Observe que dependerá do que os participantes do teste precisarão para avaliar adequadamente o trabalho. Para o público de baixo nível de alfabetização que mencionei anteriormente, nada era muito detalhado. Para cada participante, fiz uma variante do protótipo com seu nome real e número de telefone que foi usado por meio do aplicativo para dar a eles uma noção da realidade. Quanto menos eles tivessem de assumir, mais fácil seria para eles seguirem o fluxo, e os resultados também eram melhores.

Etapa 6: Desfrute de resultados e retornos de teste de alta qualidade.

Publique seus projetos na ferramenta de prototipagem de sua escolha e leve-os ao campo para teste. Agora você pode ter retornos em mais do que apenas funcionalidade, você pode descobrir problemas potenciais em um nível visual, como problemas com contraste de cor ou legibilidade, e você pode descobrir problemas com a direção ou tradução do conteúdo. Você também pode provocar sentimentos positivos ou negativos que os usuários possam ter sobre a aparência do produto ou da marca.

Prototipagem de alta fidelidade para um aplicativo de viagens
(De Igor Ivancovic )

Essas são coisas que você provavelmente receberá um reembolso de qualquer maneira quando chegar à fase de design visual, então por que não obter um reembolso agora? Alguns desses comentários visuais podem afetar diretamente a UX e vice-versa, então é bom trabalharmos juntos, se possível.

Conclusões

Sem dúvida, existem muitos casos em que toda uma fase de wireframes será necessária para o sucesso do projeto. Um design complexo, como um aplicativo da web responsivo, precisa de wireframes separados dedicados especificamente a isso. Você vai economizar dinheiro e tempo para trabalhar todos os requisitos do negócio, casos limites e tratamento de erros no estágio de wireframe, do que fazê-lo em um estágio visual que já foi conceituado e aplicado.

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

• Melhore o retorno do acionista . Clientes, desenvolvedores, outros designers e testadores de público-alvo podem ver exatamente o que receberão, permitindo que forneçam feedback de alta qualidade.

• Simplifique sua prototipagem no processo de trabalho . Não apenas seus designs estarão prontos para serem testados, mas você poderá obter retornos em um grande número de coisas ao mesmo tempo: UX, conteúdo e recursos visuais.

• Entregue um documento para clientes e desenvolvedores . Elimine a necessidade de referência cruzada e visualização de uma variedade de documentos para entender como um botão deve funcionar. Essa também é uma ótima maneira de seu cliente discutir o trabalho ou projeto com as partes interessadas internas e dar-lhe ainda mais feedback.

• * Economize tempo e dinheiro . É sempre bom!

Tente experimentar este método da próxima vez que tiver um projeto em que tenha materiais de design existentes para consultar ou onde faria uma grande diferença para o seu público-alvo se o projeto fosse de baixa ou alta qualidade.