Três coisas que as equipes de produto precisam dos designers

** Este artigo foi escrito por Chris Hill-Scott. Este artigo foi publicado pela primeira vez em março deste ano no Design in Government GOV.UK Blog ****. Você pode ler o artigo original ** ** aqui ** * *. **

Este artigo contém informações do setor público licenciadas sob a Open Government License v3.0.


Mapeamento das opções que GOV.UK Notify dá às equipes para a marca de seus e-mails (Crédito: Design in Government)

Acho que as equipes de produto precisam de 3 coisas dos designers. E, como designer, sua vida será mais fácil se você puder identificar quais das 3 coisas uma equipe precisa em qualquer momento.

As 3 coisas são:

• tornando as coisas visíveis
• fazendo coisas reais
• fazer as coisas fazerem sentido

Quando falo sobre "equipes", quero dizer equipes de produtos multidisciplinares que estão construindo, operando e iterando seus serviços. Eu trabalhei em algumas dessas equipes enquanto estava no Government Digital Service (GDS), e tenho uma ideia de muito mais por ser um avaliador de serviço.

• Quer escrever para nós? Dê uma olhada no ** [ guia para colaboradores **] do Apolitical (https://apolitical.co/opinion-writing-becoming-an-apolitical-contributor/)

Quando digo "designers", quero dizer conteúdo, gráfico, interação e designers de serviço. Mas, felizmente, este conselho é útil para qualquer pessoa envolvida em fazer coisas como parte de uma equipe.

** Tornando as coisas visíveis **

É quando alguém, talvez você, tem uma ideia de como o futuro deveria ser diferente. Você torna essa ideia visível e compreensível para que a equipe possa decidir se vai construí-la de verdade.

Você pode fazer esboços, protótipos, maquetes, diagramas, mapas ou apresentações - o que quer que ajude a equipe a entender qual é o conceito ou ideia será como para a pessoa que tem que usá-lo. Você pode testar o que fez com os usuários para ver se suas suposições estão corretas.

Este trabalho também pode tratar de tornar o presente visível. Você pode analisar alguns dados ou ajudar a comunicar os resultados da pesquisa para que a equipe tenha uma melhor compreensão do contexto em que trabalhando.

Este trabalho é valioso em 2 níveis:

• Garantir que todos na equipe compartilhem a compreensão da ideia
• Desenvolver a compreensão da equipe sobre o problema: se sua ideia não resolver o problema, ela diz algo sobre como você entende o problema

Mas esse trabalho também é arriscado. Pode trazer mais perguntas do que respostas. Para equipes que operam um serviço, pode ser frustrante ter alguém lhes dizendo para recuar e perguntar qual problema eles estão "de fato" tentando resolver quando sentem que já têm muitos problemas.

Você deve ter cuidado para não perder muito tempo trabalhando dessa maneira. Quanto mais detalhes você adicionar neste estágio, mais o design pode divergir da entrega.

Tento adicionar detalhes suficientes para perceber o quanto estou errado, então começo de novo. Se eu repetir esse processo várias vezes, acabo ficando apegado a uma ideia. É quando eu sei que é hora de parar de trabalhar nisso e compartilhar com outras pessoas.

Pode levar alguns minutos para fazer um bom esboço, mas leva meses de esforço da equipe para desenvolver um produto real. Tornar as coisas visíveis é parte desse processo, não uma entrega em si.

** Fazendo coisas reais **

O design deve estar envolvido na produção porque um produto de alta qualidade vem da obsessão por centenas de pequenos detalhes.

É por isso que é útil aprender um pouco de codificação e como gerar uma solicitação pull.

É difícil justificar priorizar uma história em algum backlog para tornar as apóstrofes curvas, não retas, ou criar elementos da linha de interface up. Mas se você for e consertar essas coisas sozinho, isso sinalizará que você se preocupa com a qualidade do produto. As equipes percebem isso, então, eventualmente, preocupar-se com os detalhes torna-se parte dos valores da equipe.

Se você tem uma equipe que se preocupa com a qualidade do produto, eles provavelmente virão e perguntarão quando não souberem de algo. Eles começarão a usar seus conhecimentos para fazer perguntas ponderadas sobre seu trabalho que irão melhorar sua qualidade e sua prática.

** Portanto, a contribuição mais difícil, mas mais importante, que um designer pode dar é manter o produto coerente. **

Isso só acontece se você reservar tempo para isso e se estiver disponível para responder às perguntas que surgem enquanto os desenvolvedores estão construindo as coisas. Sempre haverá decisões de design que você não pode prever. Você não quer que essas decisões sejam tomadas apenas com base no que é tecnologicamente simples.

Quando você fica bom nisso, pode fazer pequenas melhorias que são enviadas para a produção no mesmo dia. É difícil exagerar o valor de melhorias pequenas, frequentes e reais. Com o tempo, isso leva a um produto radicalmente melhor.

Crucialmente, fazer melhorias pequenas e frequentes ganha a confiança da equipe. Você precisa ter a confiança da equipe antes de fazer os outros tipos de trabalho de design de que o produto precisa.

O risco de ficar obcecado com os detalhes é que o design se torne um bloqueador. É quando a única maneira de fazer um bom design acontecer é impedindo o envio de um design ruim. Isso parece ótimo - você tem controle - mas fará com que as pessoas façam o mínimo para passar por você, em vez de fazer o melhor que puderem pelo produto e pelo usuário.

** Fazendo as coisas fazerem sentido **

Algo que você aprende quando estuda design é como seu pensamento é moldado pela escolha da ferramenta. Na arte, isso é direto: um esboço a lápis expressa uma qualidade diferente de uma escultura. No trabalho, há uma diferença entre pensar em parágrafos, pensar em PowerPoint e pensar em post-its. Eles são ferramentas, e escolher a certa é importante.

O processo que você usa também molda o seu pensamento: uma reunião tem um resultado diferente de um workshop, que tem um resultado diferente para uma conversa individual.

Quando se trata de fazer software, não temos - em um nível fundamental - escolha as ferramentas ou o processo. Temos código e alguma forma de agile.

Agile é uma coisa boa. Mas é importante estar ciente do tipo de produto que você obtém de uma maneira iterativa e incremental de trabalhar.

Se tudo o que você fizer for adicionar recursos, o produto, eventualmente, não fará mais sentido como um todo. Mesmo que os recursos sejam úteis e sensíveis, o produto será confuso de usar.

Portanto, a contribuição mais difícil, mas mais importante, que um designer pode dar é manter o produto coerente. Ian Bogost fala sobre o papel do designer ser “[tornar as coisas ainda mais o que já são](https://web.archive.org/web/20190217013728/https://design.blog/2016/09/29/ian -bogost-play-any /) ”.

Este trabalho pode garantir que um elemento apareça no mesmo lugar de uma página para outra. Pode ser verificar se as coisas são nomeadas de maneira consistente de um lugar para outro. Pode ser a remoção de uma caixa de seleção, uma vez que o motivo de sua existência mudou.

É especialmente difícil manter a coerência quando um novo recurso surge, mas é também quando a coerência pode sofrer mais. Para evitar esses pontos de aperto, a equipe precisa se sentir capacitada para fazer esse trabalho continuamente, em antecipação aos novos recursos e em resposta a eles.

** Você não pode fazer todas as coisas de uma vez **

Há muitas coisas na postagem acima. Seria opressor fazer tudo de uma vez. A única maneira de fazer isso é decidir que trabalho fazer e quando.

Pode parecer interminável também, além de opressor. Formei-me como designer gráfico. Na universidade sempre havia um prazo para entrega da obra. Posteriormente, trabalhando para agências, a obra era entregue ou entregue ao cliente no final de um projeto. Trabalhar em equipes de produto e trabalhar no governo é um pouco diferente. O desenvolvimento de abordagens diferentes leva tempo.

Mas espero que as coisas se tornem mais diretas quando você souber qual abordagem é a certa para uma situação. ** - Chris Hill-Scott **

** Queremos saber sua opinião sobre este artigo. ** ** Lance um artigo ** ** para nós ou envie seus comentários para ** hello@apolitical.co

(Crédito da foto: Unsplash)