Novidades em diversas áreas do conhecimento, educação, design instrucional, EAD, educação corporativa, STEAM, etc.

Dona Neusa toma seis remédios por dia e erra a dose pelo menos uma vez por semana. Um grupo de estudantes recebeu a tarefa de "fazer um...

"Façam um aplicativo"

A frase veio da coordenação de um projeto de extensão em saúde: idosos do bairro erram a medicação, e a solução moderna, todo mundo sabe, é um aplicativo. O grupo de estudantes aceitou, abriu o editor de código e, antes de escrever a primeira linha, uma integrante fez a pergunta que mudou o semestre: alguém aqui já viu como a dona Neusa toma remédio? Ninguém tinha visto. Foram ver. Dona Neusa, 74 anos, feirante, guarda os comprimidos em três lugares diferentes, não usa óculos na cozinha e tem um celular cuja única função conhecida é receber ligações da filha. Um aplicativo resolveria o problema de quem encomendou o aplicativo. Não resolveria o dela.

Uma prancheta, um problema perverso e uma escola

O design thinking não foi inventado numa consultoria. Ele nasce, como ideia, de uma pergunta acadêmica dos anos 1960: existe um modo de pensar próprio de quem projeta, diferente do modo de pensar de quem investiga? Herbert Simon, que ganharia o Nobel de Economia, respondeu que sim no livro The sciences of the artificial, de 1969: as ciências naturais estudam como as coisas são; o design se ocupa de como as coisas deveriam ser, e por isso projeta quem quer que conceba cursos de ação para transformar situações existentes em situações preferidas (Simon, 2019). Nessa definição cabem o arquiteto e o engenheiro, mas também o médico que prescreve, o gestor que reorganiza uma fila e o professor que redesenha uma aula.

Herbert Simon separa as ciências naturais, que estudam como as coisas são, das ciências do artificial, que se ocupam de como as coisas deveriam ser. Projeta quem concebe cursos de ação para levar uma situação existente a uma situação preferida (Simon, 2019).

Repare no percurso: a ideia nasce como teoria do projeto, vira prática de consultoria e retorna à educação. O design thinking é, no fundo, o método de engenharia aplicado a problemas humanos e ensinado a quem não é engenheiro. Isso explica a força e a fragilidade dele. A força: qualquer pessoa consegue aprender os cinco modos em uma tarde. A fragilidade: qualquer pessoa consegue confundir os cinco modos com uma oficina de post-its.

Cinco modos, não cinco etapas

Fonte: elaborado pelo autor com base em Stanford University ([2010]), IDEO.org (2015) e Brown (2020).

Erro comum: fazer um questionário em vez de uma conversa. Questionário confirma o que a equipe já pensa; conversa revela o que ela não sabia perguntar.

Empatia: ir até a cozinha

Definição: trocar a encomenda pela pergunta

Ideação: quantidade antes de qualidade

Prototipagem: papelão antes de código

Um protótipo, no design thinking, é qualquer coisa que uma pessoa possa pegar, usar ou reagir. A d.school pede que ele seja rápido e barato, feito para responder a uma pergunta específica e descartável sem dor (Stanford University, [2010]). O guia da IDEO.org vai além: o protótipo existe para ser colocado na mão das pessoas, e o que importa não é a fidelidade, é a velocidade com que ele produz uma reação (IDEO.org, 2015). Daí o papelão. O primeiro dispensador da dona Neusa levou quarenta minutos para ser montado com copinhos, palitos de picolé, elásticos e fita, e custou menos de dez reais. Se tivesse sido impresso em 3D, teria levado uma semana e criado, na equipe, um apego que atrapalha o próximo modo.

A regra vale igualmente para software. Um aplicativo se prototipa em papel: telas desenhadas em cartões do tamanho do celular, ligadas por setas, que alguém da equipe "opera" trocando o cartão quando o usuário aponta para um botão. Prototipar em papel antes de programar não é atraso: é a forma mais barata de descobrir que a tela três não deveria existir. A equipe da dona Neusa chegou a prototipar o aplicativo encomendado, em papel, e o testou com ela e com a filha. A filha adorou. Dona Neusa não abriu a tela dois.

Teste: ficar quieto e anotar

O teste é o modo em que a equipe mais aprende e mais sofre. A instrução central da d.school é desconfortável: entregue o protótipo, não explique, observe e deixe a pessoa errar (Stanford University, [2010]). Cada explicação que a equipe dá é uma informação que o produto final não vai ter. Quando dona Neusa, na primeira sessão, tirou o copinho da tarde achando que era o da manhã, a vontade de todo mundo era dizer "não, esse aqui". Ninguém disse. Anotou-se. O problema não era ela: era que os copinhos eram iguais e a ordem da esquerda para a direita não significava nada para quem nunca usou uma linha do tempo.

Quantas pessoas é preciso testar?

Problemas encontrados por número de usuários testados (%)