Revolução vs. Evolução: aplicando um sistema de design com recursos limitados

Nov 26 2022
Projetar para um ideal não leva a resultados ideais
TL;DR Resumo As empresas têm recursos limitados para facilitar a mudança de design Organizações como Airbnb e Apple nos mostraram que uma abordagem de design em primeiro lugar para o produto pode levar a belas experiências - e, ei, às vezes até sucesso comercial! E empresas como MailChimp e Google (com o lançamento do Material Design) fizeram um trabalho admirável de correção de curso para uma mudança de design positiva e abrangente. Muitas vezes, quando as equipes de design falam sobre sistemas de design, essas são as empresas que eles têm em mente: “O que precisamos é de um Material Design para [nosso produto]!” Coisas muito empolgantes, mas é uma tarefa difícil para uma equipe com recursos de engenharia limitados e de alta demanda que já possuem uma lista de pendências carregada: eles adorariam ter um produto bem projetado, mas primeiro devem trabalhar em [X, Y,

TL;DR Resumo

  • Muitas (a maioria?) Equipes de produtos digitais não têm liderança centrada no design e/ou os recursos necessários para passar por um grande redesenho do produto (ou para aplicar um novo sistema de design de forma abrangente).
  • No entanto, uma armadilha comum do designer nessas organizações é projetar padrões “ideais” de aspiração que representem uma grande mudança no sistema: ou seja, “vamos projetar o melhor sistema que pudermos imaginar”, em vez de um sistema que melhor aprimore o produto existente.
  • Minha abordagem preferida é menos “revolução”, mais “evolução”: desenvolvendo um sistema a partir das raízes do produto existente (em vez de forçar uma mudança revolucionária), você obterá uma experiência de usuário mais coerente, previsível e amigável muito mais rapidamente .

As empresas têm recursos limitados para facilitar a mudança de design

Organizações como Airbnb e Apple nos mostraram que uma abordagem de produto que prioriza o design pode levar a belas experiências - e, ei, às vezes até ao sucesso comercial! E empresas como MailChimp e Google (com o lançamento do Material Design ) fizeram um trabalho admirável de correção de curso para uma mudança de design positiva e abrangente.

Muitas vezes, quando as equipes de design falam sobre sistemas de design, essas são as empresas que eles têm em mente: “O que precisamos é de um Material Design para [nosso produto]!” Coisas muito empolgantes, mas é uma tarefa difícil para uma equipe com recursos de engenharia limitados e de alta demanda que já possuem uma lista de pendências carregada: eles adorariam ter um produto bem projetado, mas primeiro devem trabalhar em [X, Y, e projetos Z]… todos os quais provavelmente têm histórias de “ROI” mais claras do que mudanças de design.

Soa familiar? Isso acontece comigo, especialmente nas organizações de estágio inicial a intermediário em que prefiro trabalhar.

Então, você é um designer que trabalha com um “orçamento” de engenharia limitado. Você tem ótimas ideias para o seu produto, além de novos padrões, comportamentos e estética que está morrendo de vontade de implementar. Mas quando você dá um passo para trás e olha para todo o seu produto hoje, veja como você se sente sobre isso:

Seu produto e como você se sente sobre ele. Dica: é uma abstração (a menos que seu produto seja uma máquina de bolhas, caso em que isso é bem próximo da experiência final :P)

Aí está: você tem suas grandes e principais experiências de usuário, que ao longo do tempo foram associadas a páginas irmãs, fluxos e outras ramificações de produtos. Estes foram construídos ao longo de meses ou anos, por pessoas de produtos variados com direções de design variadas. Alguns desses recursos provavelmente foram criados como soluções MVP — “nossos clientes precisam disso agora! Acrescentaremos 'design' mais tarde” — e não fomos tocados desde então. Tudo isso foi construído com as melhores intenções para o usuário e o negócio, mas como um sistema de design, você pode estar lidando com um ninho de ratos de experiências.

Então, como você, designer de produto, coloca isso em forma?

Revolução: alcançando o nirvana do design de uma só vez

Viva a revolução! Quando você está sentado no Sketch em frente ao seu monitor Apple Thunderbolt, esta é uma armadilha emocional fácil de cair: “se eu pudesse começar do zero, poderia fazer este produto cantar! ”. Mas como você planeja realmente implementar isso? Provavelmente algo assim:

Uau! Deu muito trabalho (misterioso), mas conseguimos o produto que queríamos.

Ótimo trabalho: você obteve seu sistema de design perfeito! Vamos detalhar essa abordagem para aplicar um sistema de design.

Prós

  • Seu produto agora tem o design dos nossos sonhos! É MÁGICO!
  • Você projetou tudo de uma vez, com os mesmos designers na sala, então é tudo super coeso e bem pensado. É TÃO BOM!
  • Isso ... praticamente nunca funciona dessa maneira.
  • Toneladas de recursos precisavam ser dedicadas por um longo período de tempo.
  • Isso foi projetado no vácuo (seja bem pesquisado ou não), portanto, não considera alguns desafios do mundo real que você inevitavelmente descobrirá quando usuários reais começarem a usá-lo.
  • Por fim (mas talvez principalmente ), seus usuários/clientes tiveram que usar a versão antiga e ruim do seu produto por meses ou anos , apenas para enfrentar uma mudança repentina e massiva no design do produto sempre que você lançasse essa novidade.

O modelo “North Star”: alcançando o nirvana do design de produto, um ponto maravilhoso de cada vez

Então, sua equipe está projetando a experiência de produto ideal, mas você não tem os recursos necessários para uma revolução de design unilateral. Imagina isso! Mas agora que projetamos esses ótimos padrões, comportamentos e regras, vamos começar a aplicá-los de maneira oportunista enquanto trabalhamos nas páginas e recursos do produto. Aqui vai nada:

O modelo “North Star” para redesenho: atirar para a lua, mas implementar pouco a pouco.

Tudo bem, temos algum movimento aqui e, ao final desse processo, temos algumas experiências muito legais em nosso produto (mesmo que ainda estejamos carregando alguma bagagem conosco também).

Prós

  • Veja seus sonhos de design se tornarem realidade em seu produto, mesmo que sejam apenas peças.
  • Muito mais realista do que a Revolução do Design completa.
  • Em um futuro distante (e se você conseguiu manter as mesmas preferências de design ao longo desses anos), poderá ver o restante do produto se formando. Pode ser.
  • Mudanças mais dramáticas requerem mais recursos por mudança (conforme você abre casos extremos, restrições técnicas, etc.), então a taxa de mudança é mais lenta do que se você usasse padrões antigos ou alterados de forma mais conservadora.
  • Você obteve um ótimo design no final, mas observe as fases de transição deste projeto: são meses ou anos que seus usuários e clientes estão usando este produto realmente irregular , onde a experiência e o estilo podem mudar drasticamente de tela para tela. Você está realmente projetando para que seu trabalho finalmente dê frutos daqui a alguns anos ? Acho que não.
  • No momento em que a maioria do seu produto migrou para este novo sistema, você (e o restante da comunidade de design) provavelmente mudou em termos do que é considerado um design de interface do usuário bom, comum ou até moderno. Todo esse trabalho e você ainda está preso a um design (isso mesmo, seu “novo design”) que já tem alguns anos.
Campos da velha escola vs. Campos de Material Design. Eles são muito diferentes.

Em termos de estilo e comportamento, eles são muito diferentes , portanto, se você estiver migrando partes de sua UX pouco a pouco, terá formulários e entradas dramaticamente diferentes apresentados em seu produto. É um pequeno exemplo que representa um problema maior em fazer mudanças drásticas de design de forma fragmentada.

Mas, há esperança! Você pode evitar alterações de projeto difíceis e desleixadas projetando um sistema que se baseie no que você tem. Pode-se até dizer que você deve “evoluir” seu produto de onde ele está hoje…

É a evolução, baby : chegar a um produto melhor, mais rápido, valorizando o que você tem

Para uma equipe de design com orçamento de engenharia limitado, recomendo que você crie (ou aprimore) seu sistema de design aproveitando o melhor do que seu produto já faz e desenvolvendo a partir dele. Mesmo se você for o primeiro designer em uma pequena equipe de inicialização, alguém (seja um designer, líder de produto ou desenvolvedor) escolheu tomar essas decisões de interface do usuário por motivos reais. Suas etapas variam dependendo do estado atual do seu produto, mas o processo começa mais ou menos assim:

  1. Aprenda sobre seu sistema de design atual (se houver) : de onde vêm os componentes? Existe uma folha ou biblioteca de estilos principais em algum lugar da sua organização? Como estes são organizados? Quem construiu? Quem usa mais e quais partes eles usam? Quando eles têm que sair da estrada sem ele?
  2. Faça um inventário dos padrões e comportamentos que você vê em seu produto : como você apresenta diferentes tipos de informações aos usuários? Como os usuários escolhem o que querem ver? Como eles inserem informações? Para elementos de interface: você vê guias, cartões, listas ou formulários? Em que situações cada elemento surge?
  3. Anote as regras que seu produto parece seguir; então aperte você mesmo as regras: em algum lugar por trás de toda a dívida de design, há uma lógica de como seu produto foi montado. Entenda as regras de design que seu produto parece seguir e, em seguida, duplique-as. “ Parece que usamos tabelas para muitas coisas, inclusive quando os usuários precisam escolher com o que interagir ” talvez se torne uma regra: “ usamos linhas de tabela para permitir que os usuários escolham entre itens relacionados, mas independentes ”.
  4. Obtenha consenso de sua(s) equipe(s): comunique sua avaliação e seu plano. A construção de consenso é mais fácil falar do que fazer, mas o fato de você ter construído esse sistema a partir do produto existente tornará essa conversa e transição mais fácil do que se você criar novos padrões e regras. Certamente muitas dessas partes interessadas também contribuíram para a aparência do produto hoje, portanto, esse caminho é mais respeitoso com suas funções e todo o conhecimento organizacional inserido nos designs existentes.
  5. Comece a construir com este sistema: agora que você sabe quais regras seguir e padrões usar, especifique esses padrões e comece a seguir as regras! Da próxima vez que seus engenheiros estiverem inserindo uma tabela, um cartão, um formulário, etc., certifique-se de que é esse elemento especificado e que eles o estão usando da maneira correta. Com o tempo, mais da sua interface estará usando esse novo sistema de design, mas ele deve combinar relativamente bem com as partes mais antigas da interface.
O modelo de “Evolução” para aplicar um sistema de design. Ei, as coisas ficam verdes rapidamente!

Prós

  • MUITO VERDE . Ao basear o novo sistema livremente nos padrões existentes, você chega ao “bom” mais rapidamente.
  • As “boas experiências” se misturam relativamente bem com as “experiências antigas”, tornando a experiência mais perfeita – sim, mesmo durante os difíceis meses e/ou anos de transição.
  • Uma mudança menos dramática significa que você pode aplicar seus novos componentes e padrões mais rapidamente. Então, quando todos estiverem conectados ao sistema, você pode alterá-los e atualizá-los no nível do sistema: isso aumenta as chances de você conseguir acompanhar o vizinho de Jones (ou seja, seus concorrentes) mais tarde, quando eles inevitavelmente chegarem uma nova IU própria.
  • Mudanças menos dramáticas também podem ser boas do ponto de vista do usuário: os usuários notoriamente não gostam de mudanças (veja todas as reformulações do Facebook, sempre, ou uma reformulação em grande escala de sua ferramenta B2B favorita), portanto, evitar grandes saltos pode atenuar os solavancos em seu relacionamento com seus usuários/clientes.
  • Isso consome menos recursos e é mais natural para sua organização orgânica. Ao contrário de “revolução” e iniciativas executivas gigantes, isso pode manter melhor a boa vontade da equipe. Faz com que fazer um bom design pareça certo , em vez de apenas parecer um trabalho realmente difícil.
  • Nenhum!
  • Estou brincando. Como você pode ver, não chegamos à fase “ideal” do nirvana do design neste modelo. O modelo mais conservador de “Evolução” nos trouxe um bom design de forma mais rápida e fácil, mas talvez não tenhamos abraçado algumas oportunidades de 'grandes ideias' que, de outra forma, poderíamos ter.
  • Às vezes, trabalhar pequeno e não planejar uma “grande visão” pode fazer com que você perca algumas dependências e/ou oportunidades posteriormente na evolução do seu sistema de design. Existem maneiras de mitigar isso - por exemplo, tendo algum tipo de visão diferente de "dar passos de bebê" - que abordarei em um post mais detalhado posteriormente.
  • Às vezes, o design de produto “antigo” em seu produto é muito, muito ruim, então pode nem ser um bom ponto de partida. (Este é um caminho mental tentador a seguir, mas eu o desencorajo a fazê-lo: na maioria dos casos, se você estiver trabalhando em um produto de sucesso moderado, então algo no design antigo está funcionando bem, quer você prefira ou não ).

Seu trabalho é melhorar as experiências que seus clientes e usuários têm com seu produto. Se você mirar na lua em cada pequeno projeto e depois queimar um monte de recursos de engenharia tornando essas mudanças uma realidade, você pode estar “gastando” mal esses recursos e, assim, limitando a quantidade de trabalho que você pode fazer para melhorar outras coisas para seus usuários . Fazer um fluxo de usuário perfeito é melhor do que fazer três fluxos de usuário bons ? Talvez para você, mas provavelmente não para seus usuários.

Ao ser mais realista com seu sistema de design – construindo-o a partir de bases existentes e mantendo-o amigável para a transição – você pode adotar um novo sistema mais rapidamente e você (e seus usuários) pode começar a colher os benefícios.

Então, vá em frente e evolua!

Atualização (mais ou menos um ano depois)

Escrevi outro artigo sobre este sistema de design no qual estava trabalhando para a Hired - o mesmo projeto que inspirou este artigo “Evolution” um ano antes.

Triunfos, perdas e lições da construção de um sistema de design

Eu suavizei um pouco minha posição em uma abordagem “semelhante à Estrela do Norte” com algumas lições desse projeto, mas os inquilinos principais desta postagem ainda permanecem: Na maioria dos casos, o Evolution ainda é a abordagem responsável por seus usuários, seu produto , e sua organização.