Nossos princípios

Como premissa, procuramos simplificar e facilitar as tarefas de nossos usuários, exibindo as informações necessárias somente quando pertinente para executar sua ação, buscando otimizar o tempo gasto nas tarefas.

“Milhões viram a maçã cair, mas foi Newton quem perguntou por quê.” — Bernard Mannes Baruch

Quem usa o Mobiis está trabalhando: opera doca, despacha carga, acompanha frota. Tem pressa, é interrompido e raramente lê. Por isso os princípios abaixo não são teoria de design. São o critério para responder, em qualquer tela, a pergunta “isso ajuda a pessoa a concluir a tarefa mais rápido e com menos erro?”

Os quatro princípios em um olhar

Princípio	Em uma frase	Pergunta de teste	Diretrizes que o aplicam
Questionamos	Entender o problema antes de desenhar a solução.	“Que problema real da pessoa isto resolve?”	Filosofia de design
Clareza	A pessoa sabe onde está, o que pode fazer e o que vai acontecer.	“Alguém que nunca viu esta tela entende o que fazer em 5 segundos?”	Navegação e hierarquia, Estados da interface, Feedback ao usuário
Objetividade	Cada tela tem um objetivo principal e mostra só o que serve a ele.	“Qual é a ação principal desta tela, em uma frase?”	Formulários e validação, Estilo de escrita
Consistência	Coisas parecidas se comportam e se chamam do mesmo jeito.	“Quem conhece a tela de Cargas adivinha como funciona a de Rotas?”	Nomenclaturas, Estilo de escrita, componentes do MDS
Questionamos é sobre como decidimos. Os outros três são sobre como a interface deve ser. Um vem antes de desenhar, os outros servem para revisar o que foi desenhado.
Cada princípio abaixo tem a mesma estrutura: o que é, o que dizem os autores, como aplicar, como testar e sinais de que estamos quebrando o princípio.

Questionamos

O trabalho deve ter um propósito. Procuramos abordar problemas reais e urgentes que as pessoas estão enfrentando. Questionamos até entender claramente o núcleo do problema antes de gastar tempo no desenvolvimento de soluções. Questionamos a fim de não perder tempo resolvendo os problemas errados.

“The important thing is not to stop questioning. Curiosity has its own reason for existing. One cannot help but be in awe when he contemplates the mysteries of eternity, of life, of the marvelous structure of reality. It is enough if one tries merely to comprehend a little of this mystery every day.” — Albert Einstein

“Você não pode apenas perguntar aos clientes o que eles querem e depois tentar dar isso a eles. Quando você terminar de construir, eles querem algo novo.” — Steve Jobs

Repare que as duas citações se completam: questionar não é perguntar ao usuário qual botão ele quer. É investigar o que ele está tentando fazer e o que o atrapalha. O pedido costuma chegar como solução (“põe uma coluna nova na tabela”), e o nosso trabalho é voltar até o problema (“o que essa pessoa precisa saber e não consegue?”).

Como aplicar

Escreva o problema em uma frase antes de abrir o Figma ou o editor: quem está tentando fazer o quê e o que impede. Se a frase não sai, ainda não entendemos o problema.
Pergunte “por quê?” até chegar na causa. Cinco vezes costuma bastar (a técnica dos “5 porquês”, do Sistema Toyota de Produção).
Veja o problema acontecendo. Acompanhe o operador na doca ou no pátio, em vez de só ouvir o relato dele na reunião.
Pergunte o que acontece se não fizermos. Se a resposta for “nada demais”, talvez não seja prioridade.
Desenvolvedores também questionam. Um requisito que não faz sentido não vira certo só porque está no card.

Exemplo do dia a dia

Pedido: “Adicionar a coluna Previsão de chegada na tabela de cargas.”

Por quê? “Para ver quais cargas vão atrasar.”

Por quê? “Para avisar o cliente antes.”

Problema real: o operador precisa saber quais cargas estão em risco de atraso sem abrir uma por uma.

Solução melhor: um filtro ou destaque Em risco de atraso, em vez de mais uma coluna para o operador comparar de cabeça.

Teste rápido

Consigo explicar, sem citar tela ou componente, qual problema da pessoa isto resolve?

Sinais de que estamos quebrando o princípio

O pedido descreve a tela (“um botão aqui”), mas não a necessidade.
Ninguém sabe dizer quem pediu nem para quê.
A funcionalidade foi feita, entregue e ninguém usa.

Clareza

Nós projetamos para maior clareza e foco. Procuramos ajudar os usuários a executar tarefas por meio da priorização de funcionalidades, hierarquia visual e conscientização contextual. O usuário deve conseguir distinguir o real objetivo das telas e o que pode fazer nelas.

Para uma interface ser eficaz e eficiente, o usuário deve ser capaz de reconhecer a sua utilidade e entender como ela pode ajudá-lo, prever o que vai acontecer durante o uso, e conseguir interagir com sucesso. Não há motivos para mistérios nas interfaces. Clareza inspira confiança e cativa o uso.

“Desordem e confusão são falhas de design, não atributos da informação.” — Edward Tufte, Envisioning Information (1990)

“Não me faça pensar.” — Steve Krug, primeira lei da usabilidade, Don’t Make Me Think (2000)

Tufte lembra que uma tela cheia de dados não é culpa dos dados: é de como foram organizados. Krug lembra que cada segundo que a pessoa gasta decifrando a interface é um segundo tirado da tarefa dela.

Como aplicar

Toda tela deve responder a três perguntas, sem exigir que a pessoa procure:

Pergunta	O que responde	Onde
Onde estou?	Título da página, breadcrumb, item ativo no menu	PageHeader, Breadcrumb, menu lateral
O que posso fazer aqui?	Uma ação principal em destaque, as demais em segundo plano	Button (máx. 1 Primary por tela)
O que vai acontecer?	Rótulos que dizem o resultado, estado do sistema sempre visível	Rótulos de botão, Loading, Toast, Alert

Hierarquia visual conta a história. O que é mais importante tem mais tamanho, contraste e espaço. Se tudo grita, nada é ouvido.
Mostre o estado do sistema. Carregando, salvando, falhou, deu certo: a pessoa nunca deve ficar em dúvida se o clique funcionou (uma das dez heurísticas de Jakob Nielsen: visibilidade do estado do sistema).
Diga o que a ação faz. Excluir rota é claro. OK e Confirmar não dizem nada.
Cor não é o único sinal. Status precisa de texto ou ícone além da cor, para quem tem daltonismo ou está com a tela sob o sol.
Sem mistério. Ação irreversível diz o que será perdido antes de acontecer.

Teste rápido

Teste dos 5 segundos: mostre a tela por 5 segundos. A pessoa consegue dizer para que ela serve e qual é o próximo passo?
Teste de apertar os olhos: desfoque a tela. Ainda dá para ver o que é mais importante?

Sinais de que estamos quebrando o princípio

Dois ou mais botões Primary brigando por atenção.
Ícones sem rótulo ou sem tooltip, cujo significado só quem já conhece entende.
Mensagens como Algo deu errado ou Erro 500, sem dizer o que fazer.
Uma ação que muda o dado e não confirma nada visualmente. Aplica-se em: Navegação e hierarquia, Estados da interface, Feedback ao usuário.

Objetividade

Cada tela ou ação deve possuir um objetivo principal e resolver um problema central.

O tempo que leva para fazer uma decisão aumenta com o número de opções apresentadas. — Lei de Hick

“A perfeição é alcançada não quando não há mais nada a acrescentar, mas quando não há mais nada a retirar.” — Antoine de Saint-Exupéry, Terra dos homens (1939)

“Livre-se de metade das palavras de cada página. Depois, livre-se de metade do que sobrou.” — Steve Krug, Don’t Make Me Think

“Bom design é o menor design possível.” — Dieter Rams, princípio nº 10 do bom design (“menos, porém melhor”)

Objetividade não é ter menos coisas na tela. É ter só o que serve à ação do momento. Uma tabela de cargas com 15 colunas pode ser objetiva, se é isso que o operador precisa comparar. Um formulário com 3 campos que ninguém sabe preencher, não.

Como aplicar

Uma tela, um objetivo. Se a descrição da tela precisa de “e” (consultar cargas e cadastrar motorista), provavelmente são duas telas.
Revele aos poucos (divulgação progressiva). O essencial aparece; o avançado fica atrás de um clique: Collapse para opções raras, Drawer ou Modal para tarefas secundárias.
Adivinhe a intenção. Preencha o que o sistema já sabe: a unidade do usuário, a data de hoje, o último valor usado.
O sistema faz o trabalho pesado. Calcular, validar, formatar (CPF, placa, peso) é com ele, não com a pessoa.
Corte etapas. Cada passo a mais é uma chance de desistir ou errar.
Texto curto e direto. Veja Estilo de escrita.

Teste rápido

Diga a ação principal desta tela em uma frase. Se não couber, ou se a pessoa levar mais de alguns segundos para achar o botão certo, a tela tem objetivo demais ou hierarquia de menos.

Sinais de que estamos quebrando o princípio

Toolbar com dez botões do mesmo peso.
Formulário que pede dados que o sistema já tem.
Texto de ajuda de três parágrafos no topo da tela.
Uma configuração que quase ninguém muda, ocupando o mesmo espaço da que todo mundo usa. Aplica-se em: Formulários e validação, Estilo de escrita.

Consistência

Padronização de componentes, comportamentos e funcionalidades. Comportamento igual para itens semelhantes.

Se parece um botão, deve se comportar como um botão.

A moeda física, independente se é dólar, euro ou real, segue o mesmo padrão estrutural.

“Os usuários passam a maior parte do tempo em outros sites. Isso significa que preferem que o seu funcione do mesmo jeito que os outros que já conhecem.” — Jakob Nielsen, base da Lei de Jakob (2000)

A consistência poupa esforço: a pessoa aprende uma vez e reaproveita em todo o sistema. Também poupa o time, porque decisões repetidas viram um componente pronto.

Como aplicar

A consistência acontece em três níveis:

Nível	Regra	Como garantir
Visual	Mesma coisa, mesma aparência.	Use os componentes e os tokens do MDS (`--mds-*`), nunca cor, espaçamento ou tamanho avulsos.
Comportamento	Mesmo gesto, mesmo resultado.	Se Excluir pede confirmação numa tela, pede em todas.
Linguagem	Um conceito, um nome.	Sempre Carga, nunca “Pedido” numa tela e “Remessa” em outra. Veja Nomenclaturas e Estilo de escrita.

Antes de criar, procure. Existe um componente que resolve? Existe um que resolve com uma variação? Só depois disso vale propor um novo, e ele entra no MDS, não só na tela.
Consistência não é uniformidade. Telas diferentes têm necessidades diferentes. O que precisa ser igual é o que significa a mesma coisa.
Exceção justificada é permitida. Estas diretrizes são um direcionamento, não um livro de regras. Mas a exceção tem motivo, é decidida com o time e, se funcionar, vira padrão.

Teste rápido

Quem domina uma tela do produto consegue adivinhar como funciona outra, sem treinamento?

Sinais de que estamos quebrando o princípio

Dois botões diferentes para a mesma ação em telas diferentes.
Um mesmo status com duas cores (ou duas palavras) em módulos diferentes.
Cor, fonte ou espaçamento escritos à mão em vez do token.
Um componente “quase igual” ao do MDS, criado só para uma tela. Aplica-se em: Nomenclaturas, Estilo de escrita, Feedback ao usuário, Estados da interface.

Quando os princípios conflitam

Acontece. Uma tela mais objetiva pode ficar menos clara, e o padrão consistente pode ser confuso num caso específico. [Proposta] Use esta ordem para desempatar:

Questionamos: antes de qualquer coisa, confirme que estamos resolvendo o problema certo.
Clareza: se a pessoa não entende, o resto não importa.
Consistência: só abra mão dela quando houver evidência de que o padrão atrapalha. E, nesse caso, corrija o padrão no MDS, não só a tela.
Objetividade: reduza tudo o que puder depois de garantir os três acima.

Conflito	Exemplo	Quem vence
Objetividade × Clareza	Tirar o texto de ajuda deixa a tela limpa, mas ninguém entende o campo.	Clareza. Deixe a ajuda, mas em Tooltip ou no rótulo.
Consistência × Clareza	O padrão do sistema esconde uma ação crítica atrás de um menu.	Clareza, mas leve o caso ao time para atualizar o padrão.
Consistência × Objetividade	Um atalho novo economizaria um clique, mas seria um componente à parte.	Consistência. Se o atalho é bom, proponha para o MDS inteiro.

Para reflexão

Evite o excesso de recursos

Muitas vezes é tentador continuar adicionando mais e mais recursos à funcionalidade ou ao módulo. Mas cada novo recurso tem um preço. Toda vez que você adiciona um, considere:

A página pode ficar mais lenta e consumir mais recursos da máquina.
A interface pode ficar mais confusa e, portanto, mais difícil de usar.
Maior complexidade significa maior possibilidade de bugs.

Reduza o esforço do usuário

Procure reduzir a quantidade de trabalho e esforço que os usuários têm de despender. Isso geralmente significa antecipar as necessidades do usuário, o que requer conhecer os tipos de situação e de usuário para quem a funcionalidade se destina.

Se algo pode ser feito automaticamente, faça-o automaticamente.
Tente minimizar o número de etapas necessárias para executar uma tarefa.
Reduza a quantidade de informações que as pessoas precisam lembrar ao usar a funcionalidade. Guias, listas usadas recentemente e sugestões automáticas ajudam nisso (Nielsen: reconhecer é mais fácil que lembrar).
Mantenha o texto curto e direto ao ponto.

Mantenha a pessoa no controle

Automatizar não é decidir pela pessoa. Sugira e preencha, mas deixe editar, desfazer e sair. Quem pode voltar atrás perde o medo de agir (Nielsen: controle e liberdade do usuário).

Para designers

Comece pelo problema, não pela tela. Escreva o problema antes de desenhar.
Cada tela: um objetivo, uma ação Primary. Diga-os em voz alta na revisão de design.
Procure no MDS antes de desenhar um componente novo. Se ele não existe, proponha, e não só desenhe.
Mostre os cinco estados (carregando, vazio, erro, sucesso, com dados), e não só o caminho feliz. Veja Estados da interface.

Para desenvolvedores

Questione o requisito quando ele descrever a solução e não o problema. É parte do trabalho, não é atrito.
Use os componentes e tokens do MDS. Se precisar de algo que não existe, abra uma discussão em vez de criar um estilo local.
Nome de conceito, rótulo e mensagem de erro são design. Siga Nomenclaturas e Estilo de escrita, e não escreva o texto no improviso.
Um clique que não muda nada visível é bug de clareza. Sempre dê um retorno (Loading, Toast, Alert).

Checklist de revisão

Sei dizer qual problema real esta tela resolve. (Questionamos)
A pessoa entende onde está, o que pode fazer e o que vai acontecer. (Clareza)
Há uma ação principal clara, e no máximo um botão Primary. (Clareza, Objetividade)
Tudo o que está na tela serve à ação do momento. O resto está atrás de um clique. (Objetividade)
Usei componentes, tokens e nomes do MDS. (Consistência)
Coisas iguais se parecem e se comportam do mesmo jeito que em outras telas. (Consistência)
Se abri uma exceção, sei justificar e já avisei o time.

Para ir além

Jakob Nielsen, 10 heurísticas de usabilidade (Nielsen Norman Group)
Laws of UX, coletânea de leis como Hick e Jakob, com exemplos
Steve Krug, Don’t Make Me Think (2000)
Don Norman, The Design of Everyday Things (1988, revisado em 2013)
Dieter Rams, Dez princípios do bom design
Edward Tufte, Envisioning Information (1990)