Currently viewing the tag: "necessidades não articuladas"

Se temos um problema temos uma necessidade!

A necessidade de o resolver para obtermos algo de melhor em determinada situação. A maior parte das vezes resolvemos o problema através de um manual ou livro de instruções porque esse problema foi identificado e foi criada uma solução para o resolver. 

Num artigo que eu anteriormente escrevi eu disse: “Eu gosto de pensar que, nas pessoas, existem necessidades não satisfeitas (conhecidas mas sem solução), necessidades não articuladas (sem solução por não haver definição do problema) e necessidades ocultas (problemas não identificados e não definidos). Se de facto existe diferença significativa entre elas, e eu acho que sim, a co-criação pode ser de facto o diálogo construtivo que é necessário.”

A propósito deste artigo Wim Rampen (@ wimrampen no twitter) comentou: “@Jabaldaia like your last post… you got me thinking on the three types of unmet needs.. will get back to that. Thx” o que me fez sentir a necessidade de voltar de novo ao tema.

O que é uma necessidade?

Que abordagem posso fazer a uma necessidade?

Quando falo de necessidades não satisfeitas (conhecidas mas sem solução), quero dizer que a solução pode existir para um determinado contexto mas não é satisfeita noutros contextos. Uma rede de distribuição de água pode ser um exemplo.

Para simplificar a dança de conceitos eu parto do princípio que a identificação e definição de uma necessidade correspondem à identificação e definição de um problema.

Quando estamos perante necessidades não articuladas (sem solução por não haver definição do problema), estamos perante o sentimento da necessidade mas incapazes de a traduzir para iniciar o caminho da satisfação dessa necessidade.

Num grande artigo escrito por Ralph Ohr podemos encontrar importantes pontos de vista nesta matéria:

“Uma compreensão analítica de inovação, tal como a abordagem “jobs-to-be-done” seguida por Bettencourt, visa encontrar soluções para as necessidades definidas e encontrar necessidades para as soluções definidas, respectivamente. Isso pressupõe que as necessidades do cliente são basicamente acessíveis e podem ser previstas. Em caso de incerteza, ou seja, se as necessidades não estão (ainda) bem definidas, uma abordagem interpretativa parece ser mais indicada para a inovação. As necessidades evoluem e mudam frequentemente imprevisíveis com o tempo devido a razões culturais, tecnológicas, económicas ou ambientais. É uma questão de “previdência” para ser capaz de prever essas evoluções, por exemplo, através da participação em redes de interpretação. Ao combinar a visão e empatia, as necessidades previstas podem ser abordadas por soluções inovadoras.”

Essa evolução referida por Ralph Ohr leva-nos muitas vezes à identificação de necessidades ocultas e eventualmente à antecipação da sua satisfação se o conhecimento dessas necessidades for bem trabalhado.

Oeveren Robbert van-Jan escreveu em Designthinking: Como converter necessidade em demanda o seguinte:

“Se você der uma olhada nos diferentes níveis de conhecimento, você vê que as pesquisas tradicionais de mercado se concentra nas coisas que os clientes dizem ou pensam, o conhecimento explícito. Mas, para ter uma compreensão mais profunda, você deve observar o comportamento dos clientes. Então você achar que há tantas coisas mais que não são capazes de expressar, simplesmente porque eles não estão cientes de que estão fazendo coisas que não eram destinados desta forma. Quando foi a última vez que a sua bicicleta acorrentada a uma cerca ou o seu casaco pendurado em uma maçaneta? Você acha que a maçaneta foi projectada para isso?”

Ir de facto ao encontro das necessidades das pessoas para procurar criar algo que as satisfaça é um caminho que reclama alerta constante pois como diz Ralph-Ohr é evolutivo e ao mesmo tempo um caminho onde é difícil de avaliar os efeitos de mudança como diz Tim brown:

Então, o que acontece quando deixamos o mundo da tangibilidade e digite o abstracto. Examinar design de software pode ser uma boa primeira paragem. Aqui vemos muitas das mesmas características no mundo tangível (prototipagem rápida, iteração, a transparência razoável) que ajudam a mitigar a falha catastrófica, mas também vemos algumas das características do abstracto e complexo que qualquer sinal de perigo em potencial. Os efeitos de rede do software moderno significa que o impacto final do nosso projecto pode ser difícil de entender e imaginar antecipadamente. A relativa facilidade de interacção e inovação torna constante mudança e o impacto dessa mudança difícil de avaliar. À medida que avançamos ainda mais a partir do conforto de tangibilidade para sistemas financeiros, redes sociais, sistemas de cuidados de saúde e como a avaliação da previsibilidade e transparência de projectos novos se tornam ainda mais um problema e os riscos de aumento dramático fracasso.

Tanto quanto eu posso ver há poucas coisas inerentes ao processo de design que protege pensadores de design com essas falhas mesmo se optar por enfrentar abstracto, questões intangíveis, como serviços, sistemas e redes. Em vez disso, pode imaginar como aplicar o mesmo rigor e disciplina no processo de design que surgiu a partir de centenas de anos de prática no mundo tangível. Podemos nos concentrar em como fazer o processo de concepção do intangível como transparente e aberto à observação, como o projecto do tangível. Podemos desenvolver protótipos de ambientes que nos permitem aprender com a falha, sem implicações catastróficas. Podemos aceitar que precisamos de melhores mecanismos para críticas e comentários para que possamos começar a estabelecer um corpo de conhecimento sobre o que funciona e o que não, na concepção destas coisas que não vão “baque” quando nós as deixarmos.”

Eu acho que esta diferenciação ou ponto de vista acerca das necessidades, pode ajudar-nos a resolver problemas e a criar algo mais sustentável.

O que pensa?