Contar o que existe
Toda peça repetida entra numa lista com a tela onde aparece.

Somos um estúdio de UI/UX em Fortaleza. Levantamos as peças que o seu produto já usa, montamos a biblioteca — botão, campo, aviso, tabela, modal —, escrevemos a regra de uso de cada uma e deixamos o arquivo de design e o repositório chamando as coisas pelo mesmo nome.
Sistema de design não começa por arquivo bonito: começa por contagem. No último inventário que fizemos apareceram onze alturas de botão e sete cinzas diferentes num produto de quatro telas.
Toda peça repetida entra numa lista com a tela onde aparece.
Nome curto, em português, escolhido junto com quem programa.
Uma régua de oito passos encerra a discussão de margem.
Cada tom ganha um papel: aviso, erro, apoio, fundo.
Cinco tamanhos de texto, nenhum improvisado no meio da tela.
Foco, erro, desativado e carregando desenhados uma vez só.
Quando usar e quando não usar, em duas linhas por peça.
O componente do repositório e o do arquivo se chamam igual.
Ninguém espera o sistema inteiro para começar a usar. Cada lote sai pronto, documentado e com as telas de exemplo que provam que ele serve.
A contagem das peças que o produto já tem e o vocabulário fechado com o time.
Cor, texto, espaço, cantos e sombras definidos como valores, não como gosto de cada tela.
Campo, seleção, marcação e o comportamento de erro que vale para todas elas.
Menu, abas, trilha e rodapé, com a versão de celular resolvida junto.
Mensagem de sucesso, alerta, confirmação e a regra de quando interromper a pessoa.
Tabela, lista, cartão e o que cada um mostra quando vem vazio.
Regras de uso, telas de exemplo e uma sessão gravada com o time de desenvolvimento.
Do inventário avulso ao sistema montado lote a lote com o time dentro.
Não programamos a biblioteca. Entregamos o desenho, os valores e a documentação; quem escreve o componente é o seu time, e ficamos na revisão enquanto isso acontece.
Quadro dos últimos trabalhos, publicado com autorização de cada empresa.
| Quem | Onde | O que mudou |
|---|---|---|
| Ivanilde R. | gerente de produto varejo de material de construção | Descobrimos onze botões diferentes. Dois eram o mesmo botão com um pixel de diferença. |
| Firmino T. | líder técnico software de frota | Quando o nome do componente ficou igual nos dois lados, o "qual card é esse" sumiu do nosso canal. |
| Lucimara P. | designer única empresa de energia solar | Eu era a única designer de quatro produtos. A régua de espaço me devolveu as tardes. |
| Osmar do A. | diretor de tecnologia rede de farmácias | O lote de formulário entrou em produção antes do sistema estar pronto. Era exatamente o que eu precisava. |
| Berenice Q. | desenvolvedora sênior plataforma de cursos | A regra escrita de quando não usar o modal evitou três discussões por sprint. |
| Waldemar C. | sócio software de contabilidade | Os estados de erro estavam em cinco lugares e nenhum igual. Agora são um. |

As sete perguntas mais comuns de quem já tem produto rodando.
Não. Os lotes existem justamente para que o time continue entregando: cada um sai fechado e entra em produção enquanto montamos o seguinte.
Não escrevemos. Entregamos desenho, valores e documentação, e revisamos o que o seu time implementa até os dois lados baterem.
Serve, e economiza lote. Nesse caso o trabalho vira configurar os valores da sua marca e documentar as peças que vocês criaram por fora dela.
O time decide junto conosco, em uma sessão de uma hora. Nome imposto de fora morre no primeiro mês.
Os valores mudam num lugar só e descem para todas as peças. É o motivo de a cor entrar como função e não como código solto na tela.
Dá, e é o começo mais comum. Duas semanas depois você tem a contagem e a lista de conflitos em ordem, e decide se continua.
Cada peça nasce com o comportamento nas duas larguras. Componente que só funciona no monitor volta para a prancheta.

Quase ninguém sabe responder de cabeça. O inventário responde em duas semanas, com a lista de conflitos em ordem de incômodo.