Por que o design importa?
Já vou começar dando um spoiler: porque o design ajuda a enquadrar problemas e oportunidades.
Designers não são necessariamente aqueles que inventam os problemas. São, muitas vezes, aqueles que insistem em descobrir qual problema realmente precisa ser resolvido. Enquanto engenheiros, desenvolvedores e cientistas de dados trabalham para fazer as coisas funcionarem, designers costumam ocupar aquele lugar meio incômodo — e necessário — de quem pergunta, em diferentes momentos do processo:
“Mas qual é o problema que estamos tentando resolver aqui, hein?”
Durante muito tempo, o design foi tratado por muitas empresas como algo secundário, quase um elemento decorativo. Era associado principalmente à aparência das coisas — e, convenhamos, o próprio nome “design” nem sempre ajuda a explicar o tamanho do seu campo de atuação.
Isso começou a mudar quando as organizações perceberam que existe um valor enorme em responder uma pergunta aparentemente simples antes de sair construindo:
Estamos tentando resolver o problema certo?
Antes de correr para encontrar uma solução, precisamos dedicar tempo suficiente para compreender o contexto, ouvir as pessoas envolvidas, investigar as causas e entender o que realmente está acontecendo.
E é justamente aí que começa boa parte do trabalho de design.
Problema certo versus problema errado
Designers frequentemente trabalham com problemas mal definidos — ou wicked problems, em alguns contextos da literatura de design.
São problemas que possuem múltiplas perspectivas, não apresentam uma definição única e clara desde o início e dificilmente têm um ponto de conclusão tão objetivo quanto uma equação matemática.
“Como aumentar a satisfação dos clientes?”
“Como reduzir o desperdício?”
“Como melhorar a experiência dos nossos colaboradores?”
“Como reduzir a pobreza?”
São perguntas legítimas, mas nenhuma delas nos entrega, sozinha, uma definição suficientemente precisa do que precisa ser feito.
O oposto seria um problema bem definido. Uma equação simples, por exemplo: 2 + 2 = 4. Existe uma resposta objetiva, critérios claros e uma maneira relativamente direta de verificar se chegamos ao resultado esperado.
Na vida real, porém, quase nunca temos essa facilidade.
Os problemas que os designers enfrentam costumam ser complexos, ambíguos e cheios de variáveis. Precisamos coletar novas informações constantemente. E existe uma característica interessante nesse processo:
quando novas informações aparecem, nossa compreensão do problema pode mudar.
E, quando o problema muda, a solução que parecia perfeita ontem pode deixar de fazer sentido hoje.
Por isso, o trabalho de design frequentemente acontece em um movimento de ida e volta entre problemas e soluções.
- Investigamos o problema.
- Imaginamos uma solução.
- Testamos.
- Aprendemos alguma coisa.
- Voltamos ao problema.
- Reenquadramos.
- Testamos novamente.
É justamente por isso que, para ser designer, antes de mais nada, é preciso ser fascinado pelos problemas.
Não pelo problema como obstáculo.
Mas pelo problema como oportunidade de descobrir algo que ainda não compreendemos.
Encontrar o problema também é começar a resolvê-lo
Quando trabalhamos com problemas mal definidos, os espaços do problema e da solução acabam se misturando.
Ao mudar a forma como enxergamos o problema, podemos mudar completamente as possibilidades de solução.
E aqui existe uma das contribuições mais importantes do design para organizações orientadas a produto:
encontrar o problema certo pode ser mais importante do que encontrar rapidamente uma solução.
Quanto mais cedo uma equipe perceber que está resolvendo o problema errado, menor será o desperdício de tempo, dinheiro e energia.
É tentador medir produtividade pela quantidade de coisas que conseguimos entregar.
Mas talvez algumas das perguntas mais importantes sejam outras:
Estamos construindo a coisa certa?
Estamos resolvendo uma necessidade real?
Estamos melhorando alguma coisa para alguém?
Para responder a essas perguntas, precisamos olhar para quem vive o problema.
Precisamos falar com as pessoas.
Precisamos observar o contexto.
Precisamos compreender comportamentos, necessidades, limitações e expectativas.
Precisamos, enfim, colocar o usuário no centro.
Foco no usuário
Designers frequentemente assumem o papel de advogados dos usuários dentro das organizações.
Não porque o usuário sempre tenha razão.
Mas porque alguém precisa garantir que suas necessidades, dificuldades e experiências não desapareçam no meio de metas, processos, tecnologias, indicadores e decisões de negócio.
É nesse contexto que aparece o User-Centered Design (UCD), ou Design Centrado no Usuário.
A abordagem parte de uma ideia simples: o design deve ser construído a partir de uma compreensão profunda das pessoas que utilizarão aquele produto ou serviço, do contexto em que ele será utilizado e das tarefas que essas pessoas precisam realizar.
Em linhas gerais, os princípios do UCD podem ser resumidos assim:
- O design parte de uma compreensão explícita dos usuários, das tarefas e dos ambientes de uso.
- Os usuários participam, de diferentes maneiras, do processo de design e desenvolvimento.
- O design é orientado e refinado por avaliações contínuas.
- O processo é iterativo: aprendemos, ajustamos e testamos novamente.
- A experiência deve ser considerada de forma holística, e não apenas a interface.
- Diferentes competências e perspectivas devem participar do processo de design.
Tudo isso parece bastante óbvio hoje.
Mas existe uma diferença enorme entre dizer que somos centrados no usuário e realmente tomar decisões a partir daquilo que aprendemos com ele.
Empresas orientadas ao design compreenderam que entender pessoas e problemas pode fazer parte da própria estratégia do negócio.
Um exemplo frequentemente citado é o Airbnb.
A empresa nasceu a partir de uma experiência dos próprios fundadores, Brian Chesky e Joe Gebbia, e desenvolveu uma cultura na qual o design passou a atuar não apenas sobre interfaces, mas também sobre problemas organizacionais e de negócio.
Alex Schleifer, então vice-presidente de Design do Airbnb, descreveu essa visão de maneira bastante direta:
“O design no Airbnb é único porque ajudamos a projetar o negócio, além de projetar produtos.”
A ideia é poderosa porque amplia o papel do design.
Se toda organização é, de alguma maneira, uma experiência construída para pessoas, então podemos aplicar princípios de design não apenas a telas, mas também a serviços, processos, estruturas, equipes e modelos de negócio.
E isso nos leva a uma questão importante:
se precisamos ouvir os usuários para entender os problemas, devemos simplesmente fazer tudo aquilo que eles pedem?
Não.
Então o cliente tem sempre razão?
Se seguirmos literalmente tudo aquilo que os usuários dizem que querem, existe o risco de limitar o processo de inovação a melhorias incrementais.
Afinal, as pessoas conseguem descrever muito bem suas necessidades, frustrações e experiências atuais. Mas isso não significa necessariamente que consigam imaginar todas as possibilidades futuras.
Essa discussão aparece no trabalho de Roberto Verganti sobre Design-Driven Innovation.
Verganti apresenta três formas de inovação:
1 — Market-pull
A empresa identifica necessidades do mercado e desenvolve respostas para elas.
2 — Technology-push
Uma nova tecnologia cria possibilidades que antes não existiam ou não eram viáveis.
3 — Design-driven
A organização repensa o significado de um produto ou serviço e, a partir disso, cria uma nova proposta de valor.
O Nintendo Wii é um exemplo frequentemente utilizado para ilustrar essa terceira perspectiva.
Em vez de competir apenas pela evolução tradicional de gráficos, processamento ou controles, a Nintendo mudou o significado da experiência de jogar videogame.
O videogame deixou de ser apenas uma atividade predominantemente sedentária e passou a incorporar movimento físico à experiência.
O ponto interessante aqui não é simplesmente “fazer aquilo que o usuário pediu”.
É perceber que o usuário pode revelar um problema sem necessariamente fornecer a solução.
E talvez essa seja uma das maiores responsabilidades do design:
escutar sem obedecer cegamente.
As pessoas não sabem o que querem… até mostrarmos possibilidades
Existe uma frase atribuída a Steve Jobs que aparece constantemente em discussões sobre inovação:
“As pessoas não sabem o que querem até você mostrar a elas.”
A frase é provocativa — e também precisa ser interpretada com cuidado.
Ela não significa que devemos ignorar os usuários.
Significa que existe uma diferença entre perguntar o que alguém quer e compreender o que essa pessoa realmente precisa.
A famosa história atribuída a Henry Ford segue uma lógica parecida: se perguntássemos às pessoas o que elas queriam para melhorar o transporte, poderiam pedir cavalos mais rápidos.
A anedota é provavelmente mais útil como metáfora do que como registro histórico.
E a metáfora é boa.
Porque o trabalho do designer não é simplesmente perguntar:
“O que você quer?”
É tentar entender:
“O que está acontecendo?”
“Por que isso acontece?”
“O que você está tentando fazer?”
“O que está impedindo você?”
“E se fizéssemos de outro jeito?”
É nesse espaço entre o que as pessoas dizem, fazem, precisam e ainda não conseguem imaginar que o design encontra uma parte importante do seu valor.
No fim das contas, talvez ser apaixonado por problemas seja exatamente isso:
não se apaixonar pela solução que tivemos ontem.
É ter curiosidade suficiente para continuar perguntando.
É desconfiar das respostas fáceis.
É aceitar que podemos estar resolvendo o problema errado.
E, principalmente, é entender que antes de construir alguma coisa, precisamos ter certeza de que vale a pena construí-la.
Porque, às vezes, a melhor contribuição que um designer pode fazer não é apresentar uma solução.
É parar a sala inteira e perguntar:
“Mas… será que esse é mesmo o problema que deveríamos estar tentando resolver?”