Culpa Designer.
Eu sinto isso o tempo todo, tenho certeza que você também. Eu sinto essa culpa quando não consigo fazer algo que a comunidade de design tem insistido que todos os designers devem fazer .
Quando eu pulo direto para protótipos de alta fidelidade, me sinto culpado. Quando confio demais em minhas próprias suposições do que em insights de usuários, sinto-me culpado. E, quando não consigo iniciar uma biblioteca de padrões no início de um novo projeto, sinto-me culpado.
Para os dois primeiros pontos, com certeza você deve se sentir culpado. Estas são as melhores práticas por razões que não vou entrar aqui. (Não acredite em mim? Dê uma olhada Aqui e Aqui .)
Mas você deve se sentir culpado por não iniciar uma biblioteca de padrões?
Eu percebi que a resposta é Não. Você não deveria.
Não estou sugerindo que você não precise de uma biblioteca de padrões em algum momento. Você faz. Apenas talvez não agora. Na verdade, criar uma biblioteca obrigatória de padrões muito cedo no seu projeto pode estar atrasando seu processo.
Como? Bem, no começo de um projeto é benéfico ser um pouco confuso. Manter as coisas soltas é a chave para um Lean UX processo conforme você testa suposições para determinar o que seus usuários precisam. Agora não é a melhor hora para se concentrar na sua documentação padrão.
Depois de algum tempo, porém, a tensão de não ter uma biblioteca de padrões se instalará. Você saberá que é hora de começar a investir na sua biblioteca de padrões quando esses quatro sinais surgirem:
Os desenvolvedores freqüentemente dizem que eles seguem o princípio de SECO - Não se repita. Isso mantém seu código limpo e livre de redundâncias.
As bibliotecas de padrões podem ajudar as equipes de produto a seguir esse princípio também.
No momento em que estávamos alguns meses construindo nosso aplicativo, minha equipe estava sentindo uma sensação de déjà vu ao discutir nossos projetos. Que padrão usamos para abrir um modal novamente? Como deve ser o campo de texto nesta página?
Um padrão compartilhado pode ajudar a evitar essas discussões cíclicas. Agora, quando surge a questão de qual padrão usar, temos um ponto de referência confiável.
"Vamos usar o modal que se desvanece enquanto dispara e tem um campo de pesquisa típico."
Sim, eu disse isso em uma reunião. Nenhuma piada Esse foi um daqueles momentos em que a dura percepção de nossa necessidade de uma biblioteca de padrões se instalou.
As bibliotecas padrão podem ajudar a criar uma linguagem comum em toda a sua equipe e departamentos. Quando você diz "frigideira", pode supor que tenho a imagem apropriada na minha cabeça. Da mesma forma, você poderia dizer “Selecionador de lista modal” e sua equipe saberá exatamente do que você está falando.
É uma realidade infeliz, mas seu aplicativo terá algumas pequenas fissuras no começo. Uma fonte proscrita aqui, algumas margens renegadas lá. Isso está ok. Você ainda está descobrindo as coisas.
Com o tempo, no entanto, essas pequenas fissuras começam a se transformar em rachaduras mais sérias na experiência do usuário. Seu aplicativo pode começar a parecer não polido, assimétrico.
Malcolm Gladwell escreveu uma vez como as pessoas podem detectar arte fraudulenta em segundos. Você não quer arriscar que seus usuários cancelem seu aplicativo da mesma maneira inconsciente.
O processo de criação da biblioteca de padrões pode ajudar sua equipe a identificar e corrigir essas inconsistências antes que elas saiam do controle.
Durante os estágios iniciais de um novo produto, é comum que uma pequena equipe assuma a propriedade completa. Isso mantém todos focados, para que possam reagir às necessidades e insights do cliente o mais rápido possível.
À medida que o produto cresce, a quantidade de equipes e colaboradores também cresce. Sem a documentação padrão, novas equipes podem reavivar os debates sobre padrões que você achava que estavam acabados.
Uma biblioteca de padrões pode ajudar a comunicar o que, como e por que por trás de seus padrões para novas equipes e partes interessadas.
É melhor lembrar que as bibliotecas de padrões são ferramentas, não dogmas. No entanto, se você estiver criando um produto, sentirá a culpa. Você vai se preocupar que você ignorou conselhos práticos e deixou seu time para baixo.
Isso está ok. É mais importante dar alguns grandes saltos de fé, ver suas ideias falharem e continuar aprendendo e repetindo.
Você construirá uma biblioteca de padrões um dia, não se preocupe. A hora virá quando você não puder ignorar a tensão. O melhor de tudo, não será uma obrigação.
Vai parecer uma epifania.
[- Este artigo foi originalmente publicado em Médio . Republicado com a permissão do autor. -]