Padrões de design são soluções comuns para problemas comuns. Quando você adiciona um controle deslizante a uma página inicial, está empregando um padrão de design. Quando alguém pergunta: "Por que reinventar a roda?", Eles estão defendendo a adoção de um padrão de design.
Na Web, o termo “padrões de projeto” geralmente se refere a técnicas de programação, no entanto padrões de design também existem no design visual. E enquanto resolver um problema de codificação recorrente com a mesma solução é uma abordagem eficiente, a reutilização de um design visual não é tão desejável.
Os padrões de projeto são muito menos comuns no design de impressão do que na Web, apesar do design de impressão ter tido muito mais tempo para criá-los. A razão para isso é que o web design é fortemente influenciado por disciplinas como arquitetura de informação, codificação e usabilidade; todos os quais abrangem o uso de padrões de design.
Os programadores não valorizam a originalidade, valorizam soluções eficazes e elegantes. Se você já escreveu em PHP, você saberá que existem várias maneiras de recuperar dados de um banco de dados, mas a maioria dos codificadores PHP tem um snippet que eles usam várias vezes. Se você tiver escrito JavaScript, saberá que há várias formas de loop, mas uma delas é mais eficiente e geralmente preferível. Na verdade, a maioria dos editores de código tem uma função de snippets precisamente porque os programadores reutilizam as soluções.
Os designers, por outro lado, valorizam a originalidade e, embora seja provavelmente verdade que alguns designers usam padrões de design porque não têm imaginação (ou coragem) para fazer o contrário, a maioria dos projetistas está simplesmente adotando uma fórmula que tenha resultados comprovados.
No entanto, usar um padrão de design não é natural para o processo de design, e é por isso que você encontrará os padrões de design mais óbvios nos quais a codificação tem uma influência maior. Compare os sites criados para aplicativos para dispositivos móveis e, na maioria das vezes, você verá que eles usam os mesmos padrões de design repetidamente: O aplicativo é exibido em um telefone, alinhado à esquerda ou à direita; ao lado do telefone há um slogan e uma chamada à ação; o fundo é uma fotografia borrada, geralmente de uma cafeteria.
Padrões de design certamente parecem funcionar. São convenções que evoluem com o tempo, e é incrivelmente raro que um padrão de design seja creditado a um único indivíduo. Como o darwinismo cultural, aqueles padrões que sobrevivem ao ponto de serem identificáveis como padrões devem ser bem-sucedidos.
Padrões de design também são provavelmente o caminho mais simples para o sucesso de um web designer. Eles fornecem soluções comprovadas que centenas, senão milhares, de clientes já assinaram. Além disso, os padrões de design não precisam ser testados na versão beta, eles não precisam de testes A / B, você provavelmente nem precisa fazer com que sua mãe os experimente, porque os padrões de projeto são testados em toda a Web. diariamente e apenas os que trabalham sobrevivem.
Empregar um padrão de design é o equivalente criativo da pintura por números.
Mas enquanto os padrões de design (aparecem) funcionam para os clientes, eles não funcionam para designers. Empregar um padrão de design é o equivalente criativo da pintura por números. E se formos honestos conosco mesmos, estamos nisso por mais que um salário. Sim, você tem uma responsabilidade para com seu cliente em fornecer os melhores resultados possíveis, mas também tem uma responsabilidade para com você mesmo. Se você não for criativo, há maneiras mais fáceis de pagar o aluguel.
Os defensores dos padrões de projeto argumentam que aumentam o engajamento ao fornecer ao usuário final uma interface comum com a qual estão familiarizados, garantindo que um design tenha uma curva de aprendizado superficial. Isso, no entanto, é um modo desatualizado de pensar. Claro, se você estiver criando um aplicativo complexo, algumas convenções ajudarão os usuários a encontrar o caminho certo, mas é muito improvável que você crie um website para um público que não tenha experiência com a Web.
Quando a Web era nova, fazia sentido tornar todos os links azuis. Ajudou as pessoas a encontrar o caminho de volta. Mas uma linguagem comum para links não é mais necessária porque entendemos onde provavelmente encontraremos links. Como testemunhado pelo fato de que o padrão de design do link azul não é mais onipresente.
O problema com os padrões de projeto é que, embora pareçam funcionar no curto prazo, eles também têm uma data de validade; e ninguém sabe o que é.
Os padrões de design evoluem como a flora e a fauna, as melhores, ou talvez apenas as ideias mais adaptáveis, prosperam e se propagam. Mas, como os dinossauros que nunca viram o meteorito chegando, padrões de projeto encontram eventos de nível de extinção.
Um evento de nível de extinção é uma mudança tão rápida que a evolução não é rápida o suficiente para se adaptar à mudança. O T-Rex pode ter governado as florestas do Cretáceo, mas não conseguiu lidar com alguns graus de mudança de temperatura, bem como com aquele pequeno mamífero parecido com um musaranho que passou despercebido.
Para muitos padrões de design, o design responsivo era um evento de nível de extinção.
Até a explosão do design móvel, um dos padrões de design mais usados era o layout do Santo Graal (assim chamado porque era considerado ideal, mas difícil de conseguir com o CSS que estava disponível na época). Quando a Web para dispositivos móveis introduziu a necessidade de um design responsivo, os layouts do santo graal caíram em desuso porque, embora ainda funcionassem para desktops, eles não se adaptam prontamente às telas dos dispositivos móveis.
Problemas que os designers têm que resolver não existem no vácuo. A Web é um ecossistema em constante mudança, com influências externas, pressões internas e mudanças aparentemente aleatórias. Quando usamos um padrão de projeto, estamos resolvendo o problema de ontem, com a solução de ontem; e deixamos o problema de hoje sem resposta.
Os primeiros princípios são um método de pensamento lógico que reduz todo problema a idéias centrais que não podem ser deduzidas umas das outras.
Parafrasear Exemplo superior da Wikipedia: Todos os navegadores estão com bugs; Safari é um navegador; O Safari é um buggy. A terceira afirmação é desnecessária, pois pode ser deduzida a partir das duas primeiras afirmações.
Elon Musk é um devoto do pensamento dos primeiros princípios. Semana passada, VentureBeat relatado que a empresa de Musk, a SpaceX, construiu um foguete espacial por cerca de 2% do custo normal, simplesmente aplicando os primeiros princípios a pensar.
Quando você confia em um padrão de projeto, está assumindo um problema que talvez não seja necessário resolver.
A antítese do pensamento dos primeiros princípios é o pensamento análogo; padrões de design são pensamento análogo. Quando você confia em um padrão de projeto, está assumindo um problema que talvez não seja necessário resolver. Se você estilizar todos os seus links de azul, estará resolvendo um problema de usabilidade a partir de 2000, mas é um problema que mal existe em 2015.
Ao adotar uma abordagem de primeiros princípios, nos concentramos no núcleo do problema que nosso cliente realmente possui, sem herdar problemas não relacionados resolvidos pelas escolhas de design de outras pessoas.
Padrões de design oferecem soluções efetivas de curto prazo para problemas comuns. No entanto, quanto mais prevalente o padrão de projeto, mais estabelecido é e maior a probabilidade de que ele esteja se aproximando de um evento de nível de extinção.
Em vez de comparar soluções e obter respostas das respostas de outras pessoas, devemos nos concentrar nos problemas atuais de nossos clientes.
A Web está constantemente mudando ao nosso redor, e o design continua a evoluir, ao adotar uma abordagem de primeiros princípios, podemos produzir um trabalho que seja robusto o suficiente para sobreviver on-line. Quem sabe? Você pode até ser criativo.