Declaração do Problema: da importância, dos desafios e de como colocar em prática
Se você é designer provavelmente já ouviu frases genéricas como:
"Antes de pensar na solução, gaste um bom tempo entendendo melhor sobre o problema que você quer resolver”.
Ou até mesmo falas de autores famosos:
“Se eu tivesse 1 hora para resolver um problema, gastaria 55 minutos pensando sobre o problema e 5 minutos pensando nas soluções.” — Albert Einstein
Dentro dos variados processos de design, não é diferente. A Declaração do Problema (traduzindo do inglês Problem Statement, ou User Need Statements) é um artefato gerado a partir das informações que estão relacionadas ao universo do produto e a quem ele se destina.
Existem diversas abordagens e níveis de profundidade diferentes para capturar essas informações e gerar a Declaração. Não é uma tarefa fácil ou rápida quando levada à sério.
Segundo o artigo de Sara Gibbons, Designer Chief na Nielsen Norman Group, com apenas um parágrafo, se elaborado corretamente, é possível:
- Capturar o usuário e a necessidade
- Alinhar a equipe ao longo de uma meta concisa
- Identificar um benchmark (concorrência) e uma medida para o sucesso
Já Dan Brown, Designer na Eight Shapes, diz em seu artigo que com uma boa declaração do problema, as equipes:
- Alinham seus esforços em direção a um objetivo comum
- Definem qual é esse objetivo
- Preocupam-se em cumprir a meta
Os benefícios são diversos e fazem realmente a diferença quando experienciados na prática, mas…
Porquê para algumas pessoas ainda é tão difícil fazer esse movimento?
Quem do time deveria se encarregar de trazer o problema bem escrito?
São essas e outras questões que você vai ver a seguir.
Stakeholder ou Designer: de quem é a tarefa da Declaração do Problema?
Assim como em outros métodos de UX Design, é raro ter uma única maneira de se fazer algo, então, é importante entender em qual contexto você está.
O autor Jeff Grothelf do livro Lean UX, sugere ser tarefa de Stakeholders:
"A equipe precisa ter um ponto de partida. Achamos útil começar com uma declaração de problema. Essas declarações são criadas por stakeholders à medida que começam a abordar a visão estratégica do negócio. A declaração do problema dá à sua equipe um foco claro para o trabalho.” — Jeff Gothelf (Lean UX, 2013)
Já Alan Cooper em About Face, traz uma abordagem mais realista, partindo do pressuposto de que, na maioria das vezes, o que vamos receber serão problemas disfarçados de soluções pré prontas e que caberia a pessoa Designer extrair dali o problema raiz.
“Lembre-se que, embora as perspectivas de stakeholders sejam obviamente importantes, você não deve aceitá-las logo de cara,[…], algumas pessoas explicam problemas tentando propor soluções. É trabalho de designers ler nas entrelinhas dessas sugestões, extrair a causa raiz dos problemas, e propor soluções para ambos negócios e usuários.” — Alan Cooper (About Face, 2007)
🤔 Pergunta: Sua realidade está mais pra Allan Cooper ou Jeff Gothelf? (Responda nos comentários).
Independente disso, em ambas as situações será importante você ter capacidade de criticar qualquer texto de tarefa ou projeto, pois não dá pra ficar esperando pelo mundo ideal. Mas uma coisa é certa: um time verdadeiramente ágil possui uma cultura de compartilhamento de informação muito forte e fluida.
Receber informação de qualidade, (e eu não to falando de volume, estou falando de números, históricos, estudos já feitos, etc) sobre o problema e sobre as pessoas que usam o produto proporciona naturalmente mais qualidade e agilidade nos processos e nas entregas.
“Um problema bem começado já está meio resolvido”. — Charles Kettering (inventor e filósofo americano)
Por que tendemos receber soluções prontas e porquê Waterfall é a resposta
A metodologia Waterfall, palavra em inglês que significa cascata, é considerada a forma mais tradicional de gerenciar projetos. Assim como os fluxos de trabalho de construção e fabricação, essa metodologia é um processo sequencial. — Wikipedia
A grande tendência em receber problemas disfarçados de soluções vem desse modelo antigo, que ainda é a realidade de muitas empresas e profissionais de tecnologia. Muitos times ainda iniciam suas tarefas e projetos com mais discussões a cerca das soluções do que sobre os problemas e muito menos ainda sobre as necessidades de quem vai consumir o produto.
Por mais que exista uma ampla divulgação da importância do design centrado em pessoas e das metodologias ágeis, a cobrança do cumprimento desse papel ainda não é compartilhada por todos os componentes do time, recai naturalmente para Designers por conta da natureza da profissão, porém, enquanto não houver comunhão dessas culturas, o avanço será a passos lentos.
“Por favor, não se deixe intimidar por ‘HiPPos’ que já conhecem a solução e dizem para você apenas fazer as coisas acontecerem’. HiPPo significa a “opinião da pessoa mais bem paga” — MAA1
No discurso ou na prática: onde realmente ainda está a cultura ágil do seu time?
Partindo do pressuposto que você está inserido num time multidisciplinar formado por desenvolvedores, designers, PO ou PM, Scrum Master etc:
- O quão a vontade você se sente em questionar o que lhe é passado?
- O quão confortável e com amparo você está para debater, discordar e solicitar material (gerar demanda mesmo) em prol da qualidade do seu trabalho?
- Você sente medo de gerar algum mal entendido ao discordar ou questionar de pessoas hierarquicamente superiores durante reuniões e dinâmicas?
Dentro de um ambiente como esse, reconhecer rapidamente que a tarefa escrita durante a Planning, por exemplo, não foi suficiente para começar a trabalhar, pode acabar se tornando mais penoso do que deveria. Principalmente quando se é uma pessoa nova no time.
Se você tem menos de 3 meses, a tendência é que você atribua todas as dúvidas à sua pouca experiência e vivência na empresa. Depois desse tempo, ao reviver essa situação mais vezes, pode ser que você comece a duvidar da sua própria capacidade profissional, e aqui já pode até ser algum sinal da síndrome do impostor.
É importante que você tenha espaço pra falar! Designers tendem a uma postura questionadora, investigativa. São pessoas doutrinadas a isso, a não aceitarem soluções prontas. Além disso, tem o incentivo de valorizar o trabalho coletivo, a troca de conhecimento e a colaboração entre pares. É sobre não se ater tanto a hierarquização e ter empatia não só com as pessoas que vão usar o produto, mas também com colegas, buscando sempre facilitar o entendimento e o trabalho coletivo. Isso é cultura ágil.
Uma forte cultura de questionamento é essencial para alcançar resultados inovadores.— Jason Grant, The Art of Questioning as a UX Skill
Tenha suas cartas na manga: Técnicas pra usar quando se tem quase nenhuma, alguma ou muita informação
Aqui você encontra 11 técnicas que podem te ajudar na construção da declaração do problema.
Foram classificadas por semelhança e também por contexto de volume de informação, porém, nada impede de fazer misturas aqui. O objetivo disso é agilizar o processo de escolha dentro do seu dia a dia, visto que cada projeto chega de um jeito com mais ou menos informação.
E pra esse artigo não ficar gigante, eu resumi em linhas gerais cada técnica com o link do artigo mais aprofundado pra você se debruçar depois.
A) TENHO POUQUÍSSIMA INFORMAÇÃO
A principal característica em comum dessas 5 técnicas é a forte intenção de provocar questionamentos que instigam o time a avaliar o que se têm de informação. Inclusive, podem dar mais clareza sobre a necessidade de dar aquele passo atrás na busca de mais informações básicas e fundamentais. Vamos a elas:
- A Matriz CSD (Certezas, Suposições, Dúvidas)
Consiste basicamente em um quadro com três colunas que deverão ser preenchidas com post-its que representem as Certezas, as Suposições e Dúvidas relacionadas ao pouco que se sabe do projeto. - Os 5 porquês da Toyota
Escolha um problema, pergunte "Por que" e responda. Repita por 5 vezes essa sequencia do "por que do porque", e você chegará na raiz do problema. - Três tipos de perguntas ( Porque? E se…? Como?)
Baseado no livro A More Beautiful Question, a ideia aqui é refletir na potencialidade dessas 3 formas de se fazer pergunta e extrair disso questionamentos inteligentes e instigantes. - Histórias Investigativas (Quem, O que, Quando, Porque, Como)
Essa abordagem emprega uma visão de jornalismo investigativo junto a um canva de perguntas a ser preenchido com post-its. No fim você consegue montar uma história do seu usuário (ou não rs). - Os Seis Chapéus Pensantes
São 6 grupos de perguntas agrupadas por abordagens diferentes como Fatos, Criatividade, Benefício e etc, afim de cobrir os vários ângulos de um mesmo problema para dar uma compreensão mais holística.
B. TENHO ALGUMA INFORMAÇÃO
As 3 técnicas seguintes são bem parecidas entre si. Sugerem a mesma estrutura (construção de um parágrafo), aplicam a mesma tríade de informação (Usuário, Objetivo/Necessidade e Resultado) e são defendidas por entidades respeitadas no meio do UX Design.
Declaração de necessidade do usuário (Nielsen Group)
"De forma simplista, as declarações de necessidade do usuário nos encorajam a ver as necessidades dos usuários como verbos (ou seja, objetivos e estados finais) em vez de substantivos que descrevem soluções." — Sara Gibbons, Norman Nielsen Group.
[Alieda, mãe de 3 filhos, multitarefa e experiente em tecnologia] precisa [comparar as opções com rapidez e confiança sem sair de sua zona de conforto] para [passar mais tempo fazendo as coisas que realmente importam].
Como poderíamos (HMW — How might we) (IDEO)
"Usamos o formato How Might We porque sugere que uma solução é possível e porque oferece a você a chance de respondê-las de várias maneiras. " — Design Kit IDEO.
Como poderíamos [resolver o problema de orientação humana] através / por [grande palpite sobre a inovação] para que [resultado importante que aconteça].
Declaração do Problema (Livro Lean UX)
“A declaração do problema dá à sua equipe um foco claro para o trabalho. Ele também define quaisquer restrições importantes. Você precisa de restrições para o trabalho em grupo. Eles fornecem as proteções que mantêm a equipe aterrada e alinhada. “ — Jeff Gothelf, cáp. 8 ítem 3
Declaração do Problema (produto existente)
[Nosso produto/serviço] tem a intenção de alcançar [esses objetivos].
Nós temos observado que o produto/serviço não está encontrando [esses objetivos] o que está causando [efeito adverso] no nosso produto.
Como podemos melhorar [produto/serviço] para que nossos consumidores possam ter mais sucesso com base neste [critério mensurável]?
C. TENHO BASTANTE INFORMAÇÃO
Fechando a sequencia de técnicas, acredito que os canvas ou templates prontos para preenchimento funcionam melhor quando temos bastante informação. Fora desse contexto, tentar preencher um canva pode ser muito frustrante.
Canvas de Declaração do Problema
"O Problem Canvas tem uma abordagem psicológica para “desconstruir” um problema que vale a pena resolver; é uma ótima ferramenta que permite que você olhe para o problema de vários ângulos diferentes." — Marius Ursache
Persona, Ação, Barreira e Emoção
"Você não tem que usar a fórmula exata, mas é uma excelente estrutura para se manter em mente. Tente evitar propor soluções durante esta fase, pois é uma armadilha fácil de cair. Mantenha seu foco no problema e nos fatos." — Nikki Anderson
Planilha de declaração de problema (Problem Statment Worksheet)
"As declarações do problema se desfazem quando são muito vagas ou muito prescritivas. Em última análise, você e sua equipe precisam avaliar se a definição de um problema está funcionando para você. Isso ajuda sua equipe a reconhecer qual é o seu foco? Isso o mantém alinhado na mesma direção?" — Dan Brown
É sempre bom lembrar que independente da técnica ou canva que você escolha, o objetivo aqui é não se ater ao preenchimento das lacunas, e sim dar sentido a informação que você já tem e/ou tornar clara a necessidade do time coletar mais informações.
Pra encerrar: um resumo de tudo
No começo, nós vimos sobre a importância de levar a sério a etapa de Declaração do Problema, principalmente se sua empresa se diz ágil.
Porém, não dá pra ficar esperando pelo mundo ideal. Coletar informação e entender o problema precisará ser tarefa compartilhada entre Designers e PO's. Pelo menos até que a cultura ágil esteja a todo o vapor. Aproveite esse momento como oportunidade pra fazer a diferença.
Entenda seu contexto, observe o quão madura a cultura da empresa está e evite achar que o problema está em você, já que muito provavelmente, nem todos estão cumprindo devidamente seus papeis.
Existem diversas técnicas pra te ajudar a não empacar no início de projetos e tarefas. Leia, pratique e compartilhe suas experiências com a comunidade UX.
Fortalecer a cultura da boa comunicação e ter compromisso em solucionar necessidades reais das pessoas, é garantir bons resultados não só para quem usa o produto ou serviço, mas para quem o produz (Negócios) também.
Se você leu tudo e chegou até aqui, obrigada pela atenção. 😌
Que tal deixar nos comentários quais técnicas você costuma usar ou em que nível de maturidade ágil sua empresa está e como as informações tem chegando hoje pra você. Vamos continuar falando sobre isso, eu particularmente, adoro esse tema.
Update: Já tá disponível no Youtube a gravação da apresentação que eu fiz sobre esse tema para o coletivo +Mulheres em UX . Levou meia horinha e os 30 min finais foram perguntas. :D
