Este é o complemento de "Dev ou Designer. Por que escolher se você pode ser os dois?". Aquele post é sobre a decisão de carreira. Este é sobre como é a rotina depois que você escolheu. As vantagens reais, os desafios reais que ninguém te avisa, e os padrões de operação que te impedem de queimar ou ser silenciosamente descontado.
A maioria das descrições de vaga pede que você seja uma coisa só. Designer. Desenvolvedor. Engenheiro front-end. Pesquisador de UX. A suposição organizacional é que são disciplinas separadas que colaboram através de um handoff definido: design produz specs, desenvolvimento implementa, QA valida. O modelo de linha de montagem do software.
Eu nunca me encaixei de forma limpa nesse modelo. Eu desenho a interface e depois construo ela. Penso em comportamento do usuário enquanto estou escrevendo TypeScript. Abro Figma e VS Code na mesma sessão. Por muito tempo achei que isso era uma desvantagem -- que eu estava espalhado demais para ser excelente em qualquer um dos dois. Dezesseis anos depois vejo de forma diferente. Mas também não vou fingir que foi uma jornada totalmente positiva. Existem custos reais nesse caminho.
As Vantagens Reais
Sem Atrito de Handoff
O handoff de design para desenvolvimento é uma das fontes de desperdício mais caras e mais subestimadas em times de software. Designs chegam que são tecnicamente impraticáveis. Desenvolvedores implementam algo ligeiramente diferente do que foi desenhado porque um detalhe não foi especificado. Revisões vão e voltam. Edge cases não estão cobertos no design então o desenvolvedor toma uma decisão por conta própria.
Quando sou eu fazendo ambos, esse atrito desaparece. Eu sei durante a fase de design se uma interação é viável e quanto vai custar para construir. Não desenho micro-animações que vão levar três dias para implementar em CSS com benefício marginal para o usuário. Faço esses trade-offs em tempo real, com contexto completo. O resultado: o que eu desenho, eu construo. O que eu construo, corresponde ao que eu desenhei.
Decisões Técnicas Melhores
Entender princípios de design muda como eu escrevo código. Quando estou arquitetando uma biblioteca de componentes, penso nisso pela perspectiva de um designer também: quais variações o time de design vai precisar? Quais estados -- vazio, loading, erro, sucesso, desabilitado -- todo componente vai precisar? Quais tokens de espaçamento devem ser expostos como inputs vs hardcoded?
Já vi bibliotecas de componentes construídas puramente por desenvolvedores que são tecnicamente limpas mas praticamente inutilizáveis para design. Todo prop é um parâmetro técnico, não uma decisão de design. Toda variação requer uma mudança no código. Uma perspectiva híbrida significa que eu construo pensando no caso de uso de design desde o início.
Prototipagem Mais Rápida
Quando preciso validar uma ideia de design, não faço mock no Figma e espero um desenvolvedor fazer o stub. Escrevo um protótipo em Angular. Leva mais ou menos o mesmo tempo que levaria para construir um frame de alta fidelidade no Figma, e o resultado é interativo, lida com edge cases reais, e pode ser dado a usuários reais para teste. O feedback que recebo é muito mais próximo do comportamento real.
Os Desafios Reais
Troca de Contexto é Cara
Os modos cognitivos de design e desenvolvimento são genuinamente diferentes. Pensamento de design é expansivo -- você está gerando possibilidades, considerando usuários, explorando sistemas visuais. Pensamento de desenvolvimento é convergente -- você está estreitando para uma implementação correta, resolvendo ambiguidade, gerenciando restrições.
Alternar entre eles no mesmo dia é cansativo de uma forma específica. Aprendi a agrupá-los. Faço trabalho de design pela manhã quando meu cérebro está fresco e mais generativo. Faço desenvolvimento em blocos focados quando já entrei em um modo concentrado. Misturá-los em uma única sessão produz resultados medíocres em ambos.
Ser Subvalorizado nos Dois Campos
Essa é a coisa que ninguém te conta: quando você faz os dois, alguns especialistas em cada área vão sutilmente descontar sua expertise na deles. Designers puros podem assumir que seu senso de design é comprometido pelo pragmatismo técnico. Desenvolvedores puros podem assumir que sua qualidade de código sofre porque você gasta tempo com preocupações 'soft' de design.
Já estive em reuniões onde um designer UX puro está explicando algo sobre fluxos de usuário que eu conheço muito bem, mas como meu título diz desenvolvedor sou posicionado como a pessoa técnica que precisa ser educada sobre UX. É uma experiência frustrante. A solução não é lutar na reunião. É estabelecer credibilidade através de entregas ao longo do tempo. Mas leva mais tempo do que deveria.
A Questão da Profundidade
Existem momentos de dúvida genuína sobre profundidade. Sou tão habilidoso em Angular quanto alguém que passou 100% da carreira nisso? Sou tão habilidoso em pesquisa de UX quanto alguém que focou exclusivamente nisso? Provavelmente não, em termos absolutos puros. O que tenho no lugar é um tipo diferente de profundidade: profundidade na interseção. Eu entendo coisas que especialistas de qualquer lado não veem porque não viveram na sobreposição.
Se isso é mais ou menos valioso depende inteiramente do contexto. Em uma organização grande com times dedicados de design e desenvolvimento, profundidade pura pode ser mais valorizada. Em um time de produto que precisa de alguém que se mova rápido por toda a stack da camada de interface, o híbrido frequentemente é a pessoa mais valiosa na sala.
Como era o Papel Híbrido no BMO
No BMO estive em um papel de Senior Software Developer (Angular). Meu background de UX/UI aparecia de formas específicas e práticas: eu levantava os problemas de acessibilidade em um design antes de começar a construí-lo. Trabalhava dentro do design system do banco, que pertencia a outro time. Quando um design chegava com estados faltando, eu sinalizava proativamente ao invés de implementar uma spec incompleta. Revisava componentes tanto pela lente de qualidade de código quanto de consistência visual.
Não é uma divisão 50/50. Em uma empresa grande, a função de design é mais separada. Mas o background molda como eu trabalho mesmo quando estou puramente no modo desenvolvedor, e isso me torna um colaborador melhor com o time de design do que alguém que nunca trabalhou do lado deles.
Táticas de Operação Que Realmente Importam
Depois de anos operando nessa posição, essas são as práticas específicas que me mantiveram eficaz em vez de exausto. São táticas, não filosofia.
- Agrupe seus modos. Trabalho de design pela manhã quando o cérebro é generativo. Implementação em blocos à tarde quando ele é convergente. Misturar os dois dentro de uma única hora produz output medíocre em ambos.
- Sinalize seu principal em toda reunião. Designers puros e desenvolvedores puros vão sutilmente descontar sua expertise no campo deles se você não fizer isso. Abra com aquilo para o que você foi contratado, depois deixe a segunda habilidade aparecer pelo que você pega que eles perderam.
- Mantenha um portfólio público que mostre os dois. A maioria dos candidatos mostra um ou outro. Mostrar wireframes com racional ao lado de código de produção é o sinal mais claro de que o híbrido é real, não aspiracional.
- Escolha ambientes que recompensem a sobreposição. Times de design systems, startups de produto, consultorias boutique e empresas de ferramentas para desenvolvedores vão pagar pelo híbrido. Grandes corporações com escadas profundas de especialistas não pagam, exceto em papéis específicos como Design Engineer ou UI Engineer.
- Coloque um limite de tempo para explorar novas ferramentas e frameworks em ambas as disciplinas. O híbrido amplia mais rápido do que qualquer especialista, o que significa que você pode acabar raso em todas as direções. Um orçamento firme por trimestre impede que a exploração coma a profundidade.
A interface entre design e desenvolvimento é onde os problemas mais interessantes vivem. Eu decidi viver ali.
Referências
- Nielsen Norman Group. From Confrontation to Collaboration: The Developer-Designer Relationship. https://www.nngroup.com/articles/developer-designer-relationship/
- IDEO. Design Thinking. https://designthinking.ideo.com/
- Smashing Magazine. Bridging the Gap Between Designers and Developers. https://www.smashingmagazine.com/2021/10/bridging-gap-between-designers-developers/