Designer de produto / UX — tarefas, uma a uma

Produzir ecrãs e componentes

As ferramentas de design geram já ecrãs a partir de uma instrução e de um sistema de design, e as ferramentas de geração de código saltam a maqueta por completo produzindo uma interface que funciona. As horas de produção de píxeis que enchiam a semana de um designer júnior são a baixa mais clara numa equipa de produto.

A produção de píxeis era a aprendizagem paga. Tirá-la não tira apenas lugares júnior; tira a forma como alguém chega a ser o designer sénior de que a mesma equipa continua a precisar.

Definir o problema certo

Isto assenta em observar pessoas reais a usar software real e no critério organizativo sobre o que o negócio pode e vai mudar. É a entrada de tudo o que vem a seguir, e gerar ecrãs polidos para o problema errado é agora mais barato e por isso mais frequente — o que aumenta o valor de acertar no problema.

Definir o problema costuma ser partilhado com a gestão de produto, e em equipas pequenas não é o designer quem ganha essa discussão. Ser valioso não é o mesmo que ser quem decide.

Investigação e testes de usabilidade

Transcrever, sintetizar notas de entrevista e analisar gravações de sessão é bem mais rápido com ajuda, e estão a vender «utilizadores» sintéticos como substituto. O substituto é fraco exatamente onde interessa: não consegue reproduzir a surpresa de uma pessoa real a fazer algo que ninguém previu, que é a descoberta para a qual a investigação existe.

A investigação é o primeiro corte de orçamento em quase todas as crises, sejam os utilizadores sintéticos bons ou não. A exposição dela é comercial antes de ser técnica.

Fazer a equipa chegar a acordo

As decisões de design em software são negociadas, não decretadas. A alavanca do designer vem da evidência e da credibilidade construída em decisões anteriores, e ambas são pessoais. As ferramentas produzem mais opções sobre que discutir; não resolvem a discussão.

O trabalho de alinhamento cresce com o tamanho da equipa e desaparece com a equipa. Protege o designer em quem já se confia, e não os efetivos do lugar.

Desenhar para produtos não determinísticos

Uma fatia grande do software novo tem um modelo no circuito, e desenhar como ele falha, como se explica e como o utilizador mantém o controlo é um ofício por resolver. Há equipas a contratar designers especificamente para isto, e a competência é rara porque quase ninguém a pratica há muito tempo.

A raridade aqui é temporária por construção — quase ninguém o faz há muito tempo porque é novo, e essa distância fecha-se quando toda a gente acumular os mesmos poucos anos de prática.