Pular para o conteúdo

O que o design não é

“The design is not just what it looks like and feels like. The design is how it works.” — Steve Jobs

Quando se pensa em “design”, vem a imagem de cores, fontes e telas bonitas. Esta página existe para desfazer essa imagem, porque quem trata design como acabamento entrega interfaces bonitas e difíceis de usar.

Design não é algo que você adiciona depois de concluir um produto

Seção intitulada “Design não é algo que você adiciona depois de concluir um produto”

Quer você perceba ou não, você está constantemente projetando qualquer coisa que constrói. É uma parte intrínseca da criação de algo. O design não é apenas a aparência: não são só as cores e as fontes. O design é como funciona. Quando você decide adicionar um botão que faz alguma coisa, isso é design. Você decidiu adicionar um botão com um ícone ou rótulo, onde ele foi colocado, o tamanho e a cor. As decisões são projeto. O que isso muda no dia a dia

  • Design entra no começo, quando o problema está sendo entendido, e não no fim, para “dar um tapa no visual”.
  • Ao começar uma funcionalidade, quem vai desenhar e quem vai implementar conversam juntos desde o primeiro rascunho.
  • “Ainda não tem design” não significa “ainda não foi decidido”. Sempre foi. A questão é quem decidiu e com que critério.

O design é testável. Um projeto atenderá a uma meta específica melhor do que outro. Considere diferentes tipos de bicicleta. Uma bicicleta dobrável tem um conjunto de objetivos de design diferente de uma bicicleta de montanha. Coisas como peso, tamanho e banda de rodagem são fatores importantes para ajudar o usuário a atingir seus objetivos. Como entendemos que o projeto trata da solução de problemas específicos, também devemos entender que podemos comparar objetivamente a eficácia de dois projetos na solução desses problemas. O que isso muda no dia a dia

  • Toda decisão de design responde a uma meta: “isto serve para que a pessoa consiga ___ mais rápido / com menos erro”.
  • Discuta com base em evidência, não em gosto: quanto tempo leva, quantas pessoas erram, onde travam.
  • Teste com poucas pessoas, cedo e sempre. Cinco pessoas já revelam a maior parte dos problemas de usabilidade (Nielsen e Landauer, 2000). Vale mais testar três vezes com cinco operadores do que uma vez com cinquenta.
  • Quando duas opções competem, teste as duas (mesmo que seja com um protótipo).

Um desenvolvedor que decide o valor padrão de um campo, o texto de uma mensagem de erro ou o que acontece quando a lista vem vazia está desenhando, com ou sem Figma. O mesmo vale para quem, em Produto, define uma regra de negócio que vira uma etapa a mais na tela. O que isso muda no dia a dia

  • Os princípios e as diretrizes são para todo o time, e não só para quem usa o Figma.
  • Decisões pequenas (nome de rótulo, valor padrão, ordem das colunas) merecem o mesmo cuidado que as grandes. É nelas que a experiência se decide.

“The details are not the details. They make the design.” — atribuída a Charles Eames

Enfeite que não ajuda a tarefa (ilustração no lugar de dado, animação sem função, gradiente que compete com a informação) tem custo: chama atenção do que importa. No Mobiis, a interface é ferramenta de trabalho. Beleza é consequência de clareza, e não o objetivo. Isso não quer dizer que ela deva ser feia. Cor, espaço e tipografia são ferramentas de hierarquia: servem para mostrar o que é importante.

Você ouve… O que está por trás Uma pergunta melhor
“Depois a gente dá um tapa no visual.” Design como camada final. “Quem decide como isso funciona enquanto não temos o design?”
“Eu achei feio / eu não gostei.” Design como opinião. “O que a pessoa consegue ou não consegue fazer por causa disso?”
“É só um botão.” Ignora que cada elemento é uma decisão. “O que acontece quando a pessoa clica? E se ela errar?”
“O usuário vai se acostumar.” Empurra a complexidade para a pessoa. “Quanto tempo a pessoa gasta até se acostumar, e quantas vão desistir antes?”
“Isso é coisa do designer.” Design como função, e não como responsabilidade de todos. “Que decisões nossas alteram a experiência dela?”
  • Design entrou no começo da funcionalidade, e não só no fim?
  • As decisões têm uma meta que possamos verificar (tempo, erro, sucesso na tarefa)?
  • Já testamos com quem usa de verdade, mesmo com um protótipo?
  • Quem implementa conhece e aplica os princípios, mesmo sem ter desenhado a tela?