Você é um designer.
Seu último projeto, assim como todo projeto anterior, acabou em uma espiral de caos.
Tudo começou com o seu arquivo vectorial detalhando as telas principais, mas acabou sendo semanas de idas e vindas com engenheiros e partes interessadas. Todo mundo queria ter uma palavra a dizer. Todos acharam algo faltando. Tantos pedaços de interface do usuário têm muitos estados – não é de admirar que você tenha esquecido de desenhar uma prancheta inteira para cada um deles! Além disso – o PM estava ameaçando você com todos os prazos. Ah, e sua ferramenta de vetor começou a ficar mais de 100 pranchetas detalhando os estados que as pessoas pediram para ver. As coisas rapidamente ficaram agitadas! Apenas quando você pensou que você tem algum controle sobre essa bagunça, os desenvolvedores terminaram o primeiro conjunto de recursos. Você sentiu o sangue correndo para o seu rosto – nada parece do jeito que deveria. A tipografia estava toda desarrumada. As cores estão apagadas.
Você se perguntou: “Por que os engenheiros não conseguem fazer as coisas direito?” Afinal, você enviou a eles seu projeto de vetor acompanhado por uma especificação de CSS gerada por essa nova ferramenta da moda. Os engenheiros disseram que usaram a especificação e que você deveria parar de usar as ferramentas de ilustração vetorial para o design da interface do usuário, mas você discorda. Todos em seu design A comunidade do Slack usa essa ferramenta.
Você começa a levantar a voz ao perceber que o seletor de datas parece completamente diferente. Eles dizem que eles já têm um selecionador de data e codificar um novo atrasaria o projeto, provavelmente levaria a mais bugs e provavelmente seria terrível para os usuários também. Você não tem ideia do que eles estão falando. Sua biblioteca de vetores de símbolos não tem esse seletor de datas que eles mencionaram. E para adicionar insulto à injúria, eles nem sequer criaram essa incrível animação para a qual você enviou um GIF. Aparentemente, levará pelo menos duas semanas para recriar.
Você se sente derrotado. Você usa as ferramentas que parecem ser populares e, no entanto, nunca consegue entregar as experiências que planejou. O processo parece quebrado.
Você é engenheiro.
Seu último projeto, assim como todo projeto anterior, acabou em uma espiral de caos. Os designers, mais uma vez, não especificaram todos os estados dos componentes, mas emitiram um alarme quando você preencheu os espaços em branco com os estados ativo e ativo com base nas classes que você já tinha em seus arquivos CSS. Sua impaciência atingiu o teto em uma reunião de três horas sobre inconsistências entre imagens vetoriais e o código real. Você tentou o seu melhor para explicar que as ilustrações estáticas criadas nesses arquivos vetoriais não podem ser recriadas com precisão no código. Navegadores e ferramentas vetoriais vivem em mundos completamente diferentes e as coisas sempre parecerão diferentes. Designers não quiseram ouvir e estavam constantemente atacando seu time com o conceito de “design perfeito de pixel”. Você queria dizer que seria perfeito pixel se eles usassem ferramentas que realmente usam CSS para estilo. No entanto, você parou você mesmo. Você teve essa discussão (argumento) antes. Você ainda espera que os designers um dia entendam que os usuários não se importam com os arquivos vetoriais perfeitos, que os usuários só experimentam o que foi criado no código. A menos que os designers comecem a trabalhar mais perto do código, as coisas sempre serão quebradas.
Você revirou os olhos quando eles trouxeram a questão de um selecionador de data. Sua equipe se esforçou para criar uma biblioteca modular de componentes que estão sendo reutilizados em todas as interfaces. Ele economiza toda a sua equipe por muito tempo, definitivamente melhora a experiência do usuário (todos os componentes são testados corretamente) e há menos bugs no sistema. Não é sua culpa que designers tenham dificuldade em sincronizar com essa realidade. Se eles perguntarem, você diria que tentar desenhar manualmente todos os componentes que já existem no código é uma idéia terrível e sempre será uma font de erros. Eles não escutam.
E a última gota – mais uma vez eles criaram algumas animações em uma ferramenta que gera um GIF. Eles realmente esperam que você codifique algo enquanto olha para um GIF longo de 5 segundos? Isso não é apenas um processo terrível, mas e o prazo final do projeto? E quanto ao desempenho desta animação extravagante?
Você se sente derrotado. Você está olhando para mais uma longa noite tentando acompanhar todas as mudanças a serem feitas. Você sabe que o resultado final será uma decepção e gostaria que as coisas fossem mais unificadas. Este processo está completamente quebrado.
Ferramentas erradas. Processos errados.
Soa familiar? Este é o estado do desenvolvimento de produtos digitais em 2019.Designers e engenheiros expressam seus pensamentos e idéias com ferramentas sem compatibilidade e sincronicidade. Os desenvolvedores trabalham com as tecnologias de produção finais específicas da plataforma, os designers costumam usar ferramentas de ilustração vetorial (Sketch, Figma, XD …) para projetar representações estáticas de interfaces.
Esses dois não poderiam ser mais diferentes e menos compatíveis:
- Diferentes mecanismos de renderização usados, por exemplo, em um navegador e uma ferramenta de ilustração vetorial, causam diferenças insolúveis na renderização de font, cores e gradientes.
- A animação de pranchetas estáticas com ferramentas de saída de GIFs (por exemplo, Princípio) leva a um processo muitas vezes doloroso e lento de converter um GIF em código confiável e de alto desempenho.
- A falta de conexão entre componentes codificados e ferramentas de ilustração vetorial impede a adoção de sistemas de projeto e leva a uma experiência de produto inconsistente, cheia de bugs e cara.
A saída incorreta de uma ferramenta de design leva à entrada incorreta fornecida ao processo de desenvolvimento. Aqueles combinados resultam na saída incorreta experimentada pelos usuários. Contanto que a entrada permaneça incorreta, o resultado final não será satisfatório.
Deixe-me dar uma analogia. Imagine que você está assando um bolo. Você está olhando a foto de um grande bolo de limão em um livro de receitas. A primeira coisa a fazer é pegar uma xícara de farinha. Você está se sentindo criativo, então, em vez disso, você retira a receita do livro e a transforma em um grão fino. Hmm… Parece farinha e é feito da mesma coisa que a ilustração no livro – deve levar a uma deliciosa sobremesa, certo? Não. A entrada está completamente incorreta e, a menos que você a substitua pelo material real, esse bolo vai deixar sua querida família doente. Sem mencionar o gosto horrível.
Designers devem voltar à realidade e “assar o bolo” com ingredientes reais, não imagens de ingredientes. E as ferramentas de design precisam ser capazes de produzir os ingredientes reais … não meras imagens.Aqui está uma ideia: não culpe os designers. Não culpe os engenheiros. Ferramentas de design de culpa que estão presas no paradigma errado e impedem que a indústria progrida em direção a um processo unificado de engenharia de projeto.