Design Thinking no processo de criação de aplicativos

Depositphotos_249347628_xl-2015
Blog Aliado / Blog do Diego

Design Thinking no processo de criação de aplicativos

Venha ver neste post um processo para criar soluções realmente úteis e como ele pode ser aplicado no desenvolvimento de aplicativos.
Aplicativos, em geral, são pequenos conjuntos de funcionalidades que tentam tornar nossa vida melhor em algum aspecto. Ás vezes são extremamente simples, outras mais complexos. Alguns são baratos (ou de graça), outros caros. Uns fáceis de usar, outros nem tanto. Mas, o atributo que mais importa para um aplicativo é com certeza o quão útil ele é.
Isto não é uma verdade apenas para aplicativos, mas para qualquer produto que tenha por fim ser uma ferramenta para uma atividade humana. Só quem já tentou desparafusar algo usando uma faca ao invés de uma chave de fenda, porque não tinha uma à mão, sabe como faz diferença ter a ferramenta apropriada para cada situação.
Eu sempre me fascinei com ferramentas! Coisas extremamente difíceis de fazer (como remover o filtro de óleo do carro), são estupidamente simples quando você tem a ferramenta certa. Um trabalho de horas é feito literalmente em segundos. Mas, o que mais me intrigava era: quem pensou em criar esta ferramenta? Ou melhor, como ele teve esta ideia?
Atribuem a Platão a famosa frase: “A necessidade é a mãe da invenção”. Sendo ele ou não o autor, não importa para este post. É um problema para os estudiosos da história da filosofia. Mas, a capacidade dos filósofos de colocar grandes revelações em frases curtas é uma coisa que sempre me impressionou.
Pois bem, até aqui estamos indo por intuição: ferramentas são boas tanto quanto são úteis, são produtos de uma necessidade (problema) e Platão era um gênio. Nossa intuição nos leva longe, mas ela tem um limite. Como avançar, ou melhor, onde queremos chegar?
Não sei vocês, mas eu quero ser como o cara que inventou a chave de fenda, ou que inventou o “saca filtro de óleo” (um nome genial para a ferramenta que faz exatamente o que seu nome diz e que eu não sabia como se chamava até escrever este post). Quero criar aplicativos que facilitem a vida do meu usuário. Que permitam que ele faça algo em segundos que antes levava horas, ou, ainda melhor, que coloquem ao seu alcance fazer algo que antes era impossível.
O primeiro questionamento é: Qual o grande problema que meu aplicativo vai ajudar a resolver? Ao abordar esta questão pela primeira vez eu percebi uma realidade chocante, mas óbvia: descobrir o problema que você quer solucionar pode ser mais difícil do que criar a ferramenta que vai ajudar a resolver este problema. Não é apenas um problema técnico, estamos aqui em outro domínio. Um tema mais ligado ao mundo da arte do que ao mundo do pragmatismo. Estamos falando de criatividade.
Criar algo novo é o desejo da maioria das empresas (inovar, ou uma variação desta palavra, está sempre no vocabulário usado em missões e visões de empresas por aí), mas, as empresas muitas vezes são avessas à criatividade (inconscientemente). Não há nada que dê mais frio na espinha em um diretor do que frases com: “Não sei quanto tempo vai levar!”, “Não sei quanto vai custar!”, e, a pior de todas, “Não tenho certeza de que poderemos ganhar dinheiro com isto no final!”.
Pare um momento e olhe ao seu redor. Cada grande produto que está cercando você, em algum momento do seu processo de criação, poderia sem dúvida alguma ter seu criador (ou time de criação) dizendo uma das frases que mencionei. Isto porque criar algo novo é por definição navegar pelo desconhecido. Se não há este elemento de desconhecimento então também não há novidade.
Como qualquer português do século XVI sabe, navegar no desconhecido é sempre mais perigoso, mas é também onde estão as maiores glórias. Se for para fazer o mesmo que outros você será mais um. Isto não o impede de ter sucesso, muito pelo contrário, é a forma mais segura de chegar lá, mas você não estará sozinho e com certeza não será o primeiro.
Então é preciso uma visão criativa para identificar o problema, e mais visão criativa para propor algo que ajude a resolver este problema. E esse processo, por ser criativo, é permeado por incertezas e não temos garantia de que conseguiremos no final.
Os leitores mais atentos (ou aqueles que simplesmente sabem ler), já notaram que o título do artigo fala de Design Thinking e que depois de mais de 500 palavras eu ainda não tinha sequer utilizado o termo “design”. Muitos estão afoitos para chegar à “parte que importa”, outros ainda vem fazendo uma “leitura dinâmica” de cada um dos parágrafos tentando achar onde acaba o blábláblá e começa o “conteúdo de verdade”.
Este é um problema que eu encontrei e quero solucionar, qual seja, abrir os seus olhos para algumas verdades doídas a respeito do processo de criação de aplicativos. Só que isto é artigo e não um aplicativo, mas Design Thinking nunca foi uma ferramenta para criar aplicativos (ou mesmo artigos). É sim um processo de pensamento e alguns dos pilares que o compõem já foram apresentados aqui, mas não de forma estruturada como “bullet points” e um power point. Isto porque este post não quer te ensinar algo, eu quero te mostrar como pensar de uma forma diferente e isto leva tempo e exige foco, pois o assunto é mais profundo do que pode parecer.
A primeira coisa sobre o qual eu quero falar é o que o Design Thinking não pode te ajudar (pelo menos não diretamente). Eu falei muito sobre “encontrar o problema” e a grande verdade é que o Design Thinking não é muito bom para te dizer onde você deve começar. Mas, por quê?
 
O que é?
Comecemos pelo o que significa “Design Thinking”? Em tradução livre poderíamos abordar como “pensamento do desenho” e isto não nos ajudaria em nada. Poderíamos buscar quem inventou o termo, mas isto é controverso, ou talvez, quem mais falou sobre o tema? Daí chegaríamos a Rolf Faste, um professor de design industrial em Stanford, e isto nos dá uma pista muito boa.
Eu entendo “Design Thinking” por “meio (ou forma) de pensar do designer”. Isto pode parecer aquelas definições redundantes de dicionário, tipo: “Medicina: o ofício do médico” e quando você vai ler o outro verbete, encontra “Médico: aquele que pratica a medicina”. O que eu entendo, e professo Rolf Faste também defendia, é que o designer tem uma forma própria de pensar, que inerente a ele, e a esta forma de pensar damos o nome de “Design Thinking”.
O Design Thinking é então, uma perspectiva específica de enxergar o mundo através dos princípios do design. Isto permite ao observador focar em determinados aspectos e identificar as oportunidades em que desenhos diferentes (novos) podem transformar alguns processos do mundo real. “Perceba como isto está ligado às soluções e não à identificação dos problemas em si. Esta abordagem de pensamento também não é a ideal para escolher entre os diversos desafios do mundo qual aquele que você irá tentar melhorar.”
Em suma, um designer pode fazer uma bicicleta melhor ou mesmo criar algo totalmente novo que substitua a bicicleta (como um patinete elétrico), ou, mudando totalmente de assunto, fazer um elevador inteligente (como temos em prédios de grande circulação), onde você diz para qual andar quer ir e ele te diz qual elevador pegar. Tudo isto pode ter sido criado com auxílio do Design Thinking, mas o ele em si não te ajuda a escolher se você vai abrir uma empresa de patinetes elétricos ou de automação de elevadores.
Como todas as boas ideias, tudo parece óbvio depois que alguém aponta o problema. Não é horrível perder 15 minutos de todo mundo de manhã no lobby do prédio enquanto eles esperam o elevador, ou, preciso ir até o cliente/shopping/faculdade mas é longe demais (ou vai demorar muito) para andar, mas perto demais para ir de carro? Que tal ir de bicicleta?! No calor de dezembro em São Paulo?!
Existem outras ferramentas para esta fase inicial. Algumas olham para dentro, como uma análise SWOT, feedbacks de clientes, etc. Outras para fora, como pesquisas de mercado, avaliações de desempenho dos colaboradores, etc. Em todo o caso, elas não cabem neste post.
O processo de pensamento que guia o Design Thinking é muito próximo à forma como idealmente um software é desenvolvido e, por isto, a sinergia é grande. Ambos são baseados em iterações. Não confundir com interações. Iterar é repetir, é fazer novamente, e o processo design implica em tentar várias vezes para atingir o desenho ótimo. Desenhar, testar, avaliar, melhorar o desenho e começar de novo.
Como nosso foco aqui é a construção de aplicativos, não vou me alongar mais do que o necessário na teoria do Design Thinking. Existem centenas de artigos, livros e vídeos no YouTube que abordam mais profundamente (e provavelmente melhor do que eu conseguiria) a teoria e a história do Design Thinking. Vou focar aqui naquilo que acredito ser mais relevante para nós.
Imersão
Existe uma primeira fase que é a Imersão (ou descoberta). O Design Thinking pressupõe empatia. Você só consegue ver o quão ruim é ter de esperar 15 minutos toda manhã para subir para o seu andar quando você vive isto. Quando digo viver não significa que você precisa efetivamente esperar estes 15 minutos todo dia (embora este seja um grande motivador para acelerar o processo), mas se colocar na pele de alguém que passa por isto. As ferramentas utilizadas para enxergar este problema (frustação, dor) são: entrevistas, cadernos de sensibilização ou observação direta (como sombra ou como ator). Os dois primeiros são indiretos, ou seja, o usuário descreve sua rotina, com informações racionais e sentimentais. No último, temos uma coleta direta da informação, o que me parece o ideal, mas nem sempre é possível.
Esta primeira etapa cria dados preciosos, mas brutos. Muitas vezes somos surpreendidos com feedbacks dos usuários. Por vezes, eu achava que o problema era X mas existia um outro problema Y que frustrava muito mais o usuário e que eu não conhecia. É importante se libertar de pré-conceitos nesta fase. E praticar o desapego.
Análise e Síntese
Aqui é onde minha formação em Análise de Sistemas faz diferença, só que não! Outra coisa importante para você entender é que Design Thinking é uma ferramenta do time e não do indivíduo. Nada impede você de aplicar os conceitos para seu trabalho individual, mas o verdadeiro potencial da ferramenta só é totalmente explorado quando temos diversas mentes colaborando.
O termo cocriar virou palavra da moda, e muitas vezes é utilizado de forma completamente incorreta, com significados totalmente alheios ao seu conceito original, alguns até metafísicos, mas não vou entrar em polêmicas. Eu leio cocriar, como “colaborar para criar”, e só isso. Aliás, a colaboração é um dos pilares do Design Thinking.
A ideia da fase de análise e síntese é, através de um processo de colaboração organizar e sintetizar os dados obtidos na imersão para que possamos focar nossa visão no núcleo do problema. Aqui temos ferramentas como Personas. Persona é uma ferramenta na qual criamos um cliente fictício que reúne alguns predicados que obtivemos na fase de imersão. Isto nos permite criar empatia e extrapolar para além dos nossos usuários reais (que às vezes ainda nem existem).
Mapas mentais e de empatia também podem ser usados. Para olhos externos, de quem não está participando do time, é a hora em que os “loucos” começam a colar post-its nas paredes com se não houvesse amanhã! Aliás, vamos desfazer este pré-conceito: você pode desenvolver todo um produto usando Design Thinking sem usar 1 post-it. Ao mesmo tempo, usar 19 cores diferentes de post-it não significa que você está usando Design Thinking.
Ao terminar você tem um grande panorama de quem são seus clientes, quais os problemas/desafios deles e seus desejos/necessidades/sonhos.
Ideação
Chegou a fase mais prazerosa e desafiadora. Se você é fã dos post-its, como eu sou, chegou a hora de torrar um pouco do budget na papelaria!
É aqui também onde o processo para aplicativos fica mais especializado. As etapas anteriores são as mesmas e podem ser feitas da mesma forma se você está criando um novo tênis ou um novo aplicativo de celular. Na Ideação não! Aqui você precisa ter domínio técnico sobre o produto.
Como o próprio nome sugere é a hora de ideias. É neste momento que você busca insights de como resolver o problema (ou melhorar algo que já resolve o problema hoje em dia).
Outra palavra que já foi da moda e hoje está meio batida, é a principal ferramenta desta fase: o Brainstorming. Novamente adotarei minha filosofia de não gastar parágrafos e parágrafos explicando algo que você pode encontrar no primeiro link dos resultados da pesquisa do Google.
O Brainstorming é útil, mas também gera dados brutos. Para que funcione apropriadamente não pode haver julgamentos e tolhimentos ao raciocínio, mas estas atividades precisam ser feitas em algum momento e podem ser um ponto de polêmica. Aqui entra outra necessidade, talvez a mais importante, que é a seleção de ideias.
Uma proposta comum é atribuir valores numéricos para quesitos como: tempo para fazer (implementar), investimento necessário e retorno esperado (números de 1 a 5 para cada, por exemplo), sendo que a soma destes valores indica a prioridade da ideia. No caso de aplicativos acredito que temos de fazer um ajuste. O prazo para implementar costuma estar diretamente ligado ao investimento (exceto quando estamos falando de adquirir algo como parte da solução). Sendo assim, entregar um aplicativo com muitas funcionalidades o torna mais atraente. Portanto, para aplicativos devemos dar um peso maior às funcionalidades que são rapidamente implementadas. Ao mesmo tempo, devemos ter sempre em mente o produto minimamente viável. Se 20 funcionalidades simples te impedem de fazer uma funcionalidade core, você vai precisar reavaliar.
Ainda na ideação entre a fase de prototipação, aquelas ideias que teríamos precisam ser tangibilizadas. Você não deve escrever uma única linha de código antes de ter feito um protótipo e checado se sua ideia era mesmo tão boa quanto você pensava. Fazer um protótipo não é perda de tempo, na verdade, é sempre uma forma de ganhar tempo.
Em um processo criativo você vai errar muito mais do que acertar, não importa o quanto você ache que conhece o assunto, ou quantos anos você já faz isto. Criar é fazer algo novo, e achar que você vai acertar de primeira é arrogância. O protótipo te permite testar a ideia rapidamente e por uma fração do custo.
Se você quiser pular todo este artigo e só levar uma frase dele, que seja: “ANTES DE FAZER O PRODUTO, FAÇA UM PROTÓTIPO DELE”.
Um protótipo não precisa ser rebuscado. Pode ser um simples desenho no papel, o que importa não é a forma, mas o conteúdo que ele carrega.
Pensando em desenvolvimento de aplicativos, existem 1001 ferramentas para prototipação. Você pode avançar e já fazer um mock-up (um protótipo de alta fidelidade), mas isto costuma ser mais demorado, e assim mais custoso, portanto, evite fazer mock-ups nas primeiras iterações.
Validação
Aqui o foco é na interação, como seu produto e o usuário reagem um ao outro.
Você e seu time acham que tiveram uma, ou várias ideias brilhantes. Você constrói um protótipo, dá na mão de um usuário e ele simplesmente não entende como usar aquilo. É frustrante.
É preciso aceitar as falhas. Abraçá-las, entender que faz parte do processo falhar, e que cada falha te aproxima do sucesso. Sei que parece papo de livro de autoajuda mas não é. Imagine que você é um atleta de salto com vara. O recorde mundial atual é saltar incríveis 6,18m e pertence a um sueco. Bem, ninguém imagina que ele começou na prática do esporte semana passada e que em seu primeiro salto ele atingiu esta marca, nem no segundo. Na verdade, ele é bem novo, tem 21 anos apenas. Seu pai também era um atleta do salto com vara. A primeira vez que ele tentou saltar ele tinha 3 anos de idade. Com 10 anos já saltava quase 4 metros. A pergunta é: quantos saltos abaixo do recorde ele deu antes de conseguir bater o mesmo? Se você for um pessimista, cada um deste saltos é um pequeno fracasso. Se você se imaginou como um atleta do salto com vara e for pessimista assim, provavelmente nunca conseguirá chegar nem perto de um feito destes. Cada salto permitia a ele ir mais alto e mais perto do recorde. Provavelmente ele ficou frustrado algumas vezes no caminho, é normal, mas ele devia entender que este era um caminho sem atalhos e que precisava passar centímetro por centímetro até o seu objetivo.
Criar um aplicativo é muito mais fácil do que saltar 6,18m e provavelmente você não vai precisar de anos de iterações para lançar um bom produto, mas não pule a validação, não acelere etapas.
No meio do texto eu dei um puxão de orelha em quem estava tentando “trapacear” na leitura, tentando “fazer o download do conhecimento” em segundos como no filme Matrix. Eu mesmo faço isto às vezes (mais do que eu gostaria de assumir), mas para algumas coisas não há atalhos.
Para fazer um aplicativo realmente bom você vai precisar suar. Vai precisar gastar tempo planejando, imaginando e testando.
Perceba que em nenhum lugar em falei de código. Isto porque eu guardei para o final meu melhor conselho, e o que mais pode assustar você. Sempre duas iterações no mínimo: uma para prototipar e validar e depois outra para desenvolver e validar, ou seja, você só escreve o programa depois da primeira validação. E haverá uma segunda validação com o programa já pronto (no lugar do protótipo). Não, não é exagero! No longo prazo você vai perceber, como eu percebi, que na verdade isto te faz ganhar tempo.
Eu não tinha mencionado antes, mas tudo o que eu disse até agora é um ciclo, se falhar na validação você deve voltar para, no mínimo, a ideação e tentar novamente. Às vezes você vai ter que ir mais para trás ainda, mas, novamente, faz parte do processo e é a única forma (pelo menos que eu conheça) de atingir a excelência.
Em um próximo artigo vou abordar outra ferramenta que anda lado a lado com a abordagem do Design Thinking e que é mais pragmática do que ele: UX – User Experience.
Até lá!
 
 
SOBRE O AUTOR

Diego Yegros é formado em Tecnologia da Informação com especialização em Direito Tributário. Em seus 19 anos de experiência profissional atuou como Arquiteto em empresas multinacionais do segmento de TI, definindo a arquitetura, gerenciando e implementando inúmeros projetos de alta complexidade para SAP , SAP S/4 HANA e BIG DATA. Participa desde 2006 de todas as iniciativas tecnológicas envolvendo SAP e SAP S/4 HANA, com ênfase no desenho de soluções de aplicativos orientados para área fiscal e contábil. Desde 2013, integra e coopera com as equipes de tecnologia da SAP na solução fiscal TDF.
 
Acompanhe nossas publicações e webinars e esteja atento.
 

PRÓXIMOS WEBINARS