O design UX é uma disciplina fascinante. Para fazer isso bem, os profissionais 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, a arte e a compreensão de um profissional de UX envolvem tudo, desde o desenho básico, passando pelo design narrativo / de jornada até a psicologia cognitiva.

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

Wireframes - normalmente esqueletos monocromáticos de designs criados para avaliação rápida - são ótimos. Eles nos permitem traduzir as contribuições 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 durante o teste do produto. 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 ocorra.

Existem prós e contras, mas, em certos casos, faz sentido pular a fase de wireframe por completo. Muito tempo poderia ser economizado lidando com a experiência do usuário 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 outros 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 wireframes às vezes podem ser problemáticos, quando ignorá-los faz sentido e como adaptar um processo sem wireframe para um fluxo de trabalho.

O problema com wireframes

Seja em um ambiente em cascata ou ágil, o processo de design típico envolve fases de pesquisa, definição, ideating, 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 olhando

O processo de design normalmente começa com algum tipo de pesquisa sobre o problema. Pesquisa documental, entrevistas com partes interessadas e entrevistas com usuários são apenas algumas das atividades que podem ser realizadas para obter um entendimento mais profundo. 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 elaborado, 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 é gostar a coisa, mas não a atual coisa que será construída. Nesse estágio, os wireframes conteriam imagens de espaço reservado e todos os tipos de TKs (por 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 lista enorme de anotações. Normalmente, nunca há tempo suficiente para examiná-los detalhadamente, então o cliente terá que lê-los por conta própria.

Durante as análises de wireframe, pedimos aos nossos clientes que se concentrem no conceito que está sendo descrito e avaliem se ele parece estar ou não resolvendo os problemas de negócios e usuários. 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 eles podem ver exemplos das fotos a serem exibidas na imagem do herói - ou outra pergunta sobre algo que será tratado no design visual, prototipagem de interface do usuário ou desenvolvimento.

Os wireframes podem ser muito abstratos para os clientes e até mesmo as partes interessadas internas avaliarem com eficácia. Wireframes dizem às pessoas como será um design quando estiver pronto, mas elas ainda têm que fazer muito trabalho mental para fazê-lo funcionar em suas cabeças. Nossos clientes podem ser ou não pensadores visuais, e pode ser demais esperar que olhem para um projeto e imaginem um produto ou site de sucesso.

Alguns clientes solicitaram especificamente a revisão de designs visuais anotados porque é muito mais fácil para eles conectar os pontos, ter uma discussão cuidadosa e dar um feedback bem pensado.

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

Esperançosamente, alguns testes de usuário foram programados 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 é por meio da prototipagem.

Wireframes podem - e fazem - trabalhar para prototipagem. A equipe de design está limitada a testar apenas o fluxo e a funcionalidade e, por não ter 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 uns aos outros. É 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 juntas de forma holística.

Caso em questão: 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 disso, como o conteúdo da cópia afeta a experiência do usuário, a tradução em si pode afetar a experiência do usuário.

Por exemplo, tivemos uma tarefa em que precisávamos testar algumas arquiteturas de informação diferentes por causa de 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 IU.

Descobrimos que mais palavras eram necessárias para descrever conceitos semelhantes no idioma local, e que teríamos que alterar os tamanhos e formas dos botões globalmente para acomodar as palavras detalhadas necessárias para aquele idioma. Sem nos concentrar nos problemas de texto ao testar os componentes visuais reais na IU, 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 no futuro.

Conclusão principal: faz sentido preparar IUs de alta fidelidade desde o início, especialmente para um projeto multilíngue.

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

O que inevitavelmente acontece durante a fase de design visual é que tudo se move. As imagens empilhadas se tornam ladrilhos. O texto centralizado fica alinhado à esquerda. Os ícones de acionamento do acordeão eram + e -, mas agora são duas divisas.

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

Quando todos os recursos 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, juntamente com um guia de estilo. Agora cabe a eles cruzar as referências entre esses dois documentos e dar vida a tudo isso.

Esta é uma área em que o processo de design pode realmente falhar. Fornecemos aos desenvolvedores muitos documentos para referência e deixamos que eles determinem quais informações têm precedência. Isso aumenta a quantidade de tempo necessária para chamadas de suporte e QA, naturalmente impactando o tempo que leva para trazer um produto ou atualização para o mercado.

Por que não apenas dar desenvolvedores 1 documento preciso que inclui tudo? A maioria dos clientes também gostaria de ter 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 totalmente 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 da interface do usuário disponíveis. Se você estiver fazendo atualizações em um site existente ou adicionando um novo recurso a um aplicativo existente, observe o site e o aplicativo atuais para encontrar padrões e estilos para reutilizar.

Seria ainda melhor se você tivesse acesso aos arquivos de origem do 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 (ou na ausência de) um produto ou site existente, verifique se há um guia de estilo ou 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 para seu projeto.

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

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

Poupe algum esforço durante as 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 , você pode facilmente fazer atualizações incrementais em alta fidelidade e publicá-las diretamente no seu fluxo de trabalho de prototipagem. Sem necessidade de wireframing.

Como uma grande vantagem, você pode matar dois coelhos com uma cajadada só. Você pode obter feedback visual e de IU junto com seu feedback de experiência do usuário e fazer todas essas alterações de uma 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 de leitura não era o único problema - conceitos abstratos costumavam ser muito difíceis de abordar. Esse público-alvo normalmente precisava discutir conceitos financeiros usando exemplos concretos; caso contrário, eles não seriam capazes de realmente acompanhar a conversa.

Para entender os conceitos financeiros, os participantes do teste neste público precisavam sentir como se estivessem realmente fazendo uma transação. E para entender como o produto funcionava, ele precisava ter a aparência de um aplicativo real.

Esqueça wireframes para um público como este! Você vai acabar gastando muito tempo explicando o que eles são - e seu público não estará se concentrando nas tarefas, nem em como eles se sentem sobre elas, porque eles não podem se identificar com o uso de algo tão estranho 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 se ver tentando reduzir o escopo e o preço, ou lutando para ver onde pode economizar e economizar e ainda oferecer um ótimo serviço ao cliente.

Se você tem um cliente que não pode pagar (ou que provavelmente não vai comprar) uma avaliação completa de UX, posso sugerir cortar o tempo de wireframe? Crie alguns internamente, se necessário, mas mantenha o projeto em andamento para o seu cliente. Teste designs reais e tangíveis e faça seu cliente reagir 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 isso, este é um “modelo” de processo que você pode tentar inicialmente adaptar ao seu fluxo de trabalho e, em seguida, ajustar à medida que pratica trabalhando dessa forma.

Etapa 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), conclua esta fase como faria normalmente.

Etapa 2: esboce um pouco ao longo do caminho.

Enquanto você está conduzindo uma pesquisa, provavelmente está tendo algumas ideias para layouts e padrões úteis, fluxos envolventes e assim por diante. Registre-os da maneira que você costuma fazer. Eu gosto de fazer esboços em 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 IU interessantes. O que quer que o ajude a lembrar boas ideias, faça-o.

Etapa 3: Prepare seu documento de alta fidelidade

Abra a ferramenta de design de sua escolha e configure seu documento adequadamente. Escolha alguns tamanhos de prancheta 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, crie e organize estilos de tipo e faça sombras projetadas 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. Use substituições de símbolo - se puder - para que possa aplicar facilmente diferentes cores e rótulos de texto, conforme necessário.

Se houver ícones personalizados usados, salve-os como símbolos individuais em uma prancheta quadrada (ou em qualquer forma apropriada). Dessa forma, será fácil escalá-los para cima e para baixo, mantendo o espaçamento e 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 onde seu guia de estilo se comporta (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, use uma boa “direção de cópia” ou uma cópia real, se tiver. Não crie títulos que digam “O título da página vai aqui”. Dê ao espectador uma ideia do que seria vá 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 fazer nomes e números diferentes, ou crie qualquer conjunto de dados que você precisa exibir. Isso pode parecer um exagero, mas permite que você resolva problemas com o layout e a largura dos caracteres e ajuda o visualizador a entender que essas cinco entradas são diferentes.

Etapa 5: Saiba quando parar de projetar.

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

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

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 baixo nível de 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 todo o processo, de modo que o aplicativo realmente parecesse ser “deles”. Quanto menos eles tivessem que assumir, mais fácil seria para eles seguirem e melhores os resultados.

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

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

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

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:

• Melhorar o feedback das partes interessadas . Clientes, desenvolvedores, outros designers e participantes de teste do público-alvo podem ver exatamente o que receberão, permitindo-lhes dar feedback de alta qualidade.
• Acelere seu fluxo de trabalho de prototipagem . Não apenas seus designs estarão prontos para serem testados imediatamente, como também você poderá obter feedback sobre uma série de coisas ao mesmo tempo: a UX, a cópia e os recursos visuais.
• Entregue um único documento para clientes e desenvolvedores . Elimine a necessidade de referência cruzada e verificaçã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 com seus stakeholders internos para obter ainda mais feedback.
• Economize tempo e dinheiro . E isso é sempre uma coisa boa!

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

• • •

Leituras adicionais no Blog de design do ApeeScape:

• eCommerce UX - Uma Visão Geral das Melhores Práticas (com Infográfico)
• A importância do design centrado no ser humano no design de produtos
• 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 Mágicas do Usuário