Design, além do pixel
Como podemos transformar a percepção ‘popular’ de que o design é apenas estética?…Vamos falar sobre isto com o case do SGU-Clínica (produto para consultórios da FESC).
Para iniciar é interessante a contextualização sobre a carreira. Design, mais especificamente a carreira em UX (experiência do usuário), é uma das profissões que mais está alta no mundo da tecnologia. Em uma pesquisa feita pelo LinkedIn o profissional de UX está na lista como uma fonte de suma importância para as empresas.
Traduzindo, existe uma percepção cada vez maior de que o Designer é a ponte entre a camada estratégica e a ‘operacional’ da empresa.
Aproveitando, quando falamos em operacional, nos deixamos levar para vários caminhos. Aqui a operação é justamente o ponto de contato com maior importância, seja por parte de quem desenvolve ou por aqueles que utilizam (usuários). Dentro deste processo, temos um universo de informações, que em geral se perdem conforme são levadas para camadas superiores (estratégicas). Criar esta conexão é justamente o papel do Designer. Tendo o dever de transformar conhecimento tácito em conhecimento explícito e, por sua vez, comunicar a informação com o menor ruído possível.
Mas, o que acontece quando temos decisões sendo tomadas sem ouvir nossos usuários? Ou ouvindo uma parte muito seleta deles?
Bem, é este universo com transformação de informação que vamos abordar aqui. Quando falamos no SGU-Clínica, estamos falando de um produto que tem um ano e foi idealizado totalmente para o consultório médico. Para entender um pouco sobre o SGU-Clínica, no futuro estaremos publicando um artigo específicio sobre o produto.
Contextualização
O desenvolvimento do SGU-Clínica aconteceu por meio de pré-requisitos, ou seja, existiu a obrigatoriedade de que funcionalidades e jornadas fossem desenvolvidas pois acreditava-se que eram de suma importância para o produto e, portanto, elas entraram no roadmap. Sendo assim, o time focou nestas prioridades para idealizar e desenvolver o produto.
Após um ano do produto em produção o time se deparou com o dilema do MVP eterno, ou seja, funcionalidades foram desenvolvidas sempre com o escopo de ‘precisamos entregar’ e, como consequência, pouco valor real foi gerado. Isto, por sua vez, pode acontecer por diversos fatores e um deles — talvez o mais predominante — é idealizar que ‘Design é caro’ e que ‘ O resultado final é apenas uma tela bonita’. Feita esta introdução, vamos exemplificar todo o processo e refletir sobre o valor do não Design.
O primeiro desafio
A primeira ação a ser feita tinha ligação direta com o modelo de trabalho aplicado pelo time até então. Como o time estava sendo reativo às demandas, não existia clareza das necessidades dos usuários, nem o real impacto das entregas (não existiam métricas claras). O processo até então era:
Ao invés de simplesmente opinar ou reestruturar tudo, o objetivo aqui foi transformar de dentro para fora. Para isso utilizamos nossa maior fonte de informação e conhecimento, que até então não foi explorada: o usuário!
Além deste fator, também ficou evidente que estávamos fazendo entregas sem medir e acompanhar se o que havia sido prototipado e desenvolvido realmente entregava valor para os usuários. Assim, tomamos como premissa dois fatores chave para compreender e transformar a forma de trabalho do time:
1. Ouvir os usuários; e
2. Gerar entregas com valor.
Ouvir os usuário
Aqui seguimos em uma linha exploratória, então deixamos de lado tudo que acreditávamos sobre o produto e sobre as jornadas. Nosso objetivo foi o de realmente compreender o dia-a-dia de dois perfis: médicos e secretárias. Foi então que surgiu um questionamento: ‘E a aplicação já existente?’
Pois bem, ela não seria esquecida. Apesar de precisarmos dar um passo para trás, também era importante compreender o que estava funcionando (entregando valor, ou não) e o que não estava. Assim, dividimos nosso roteiro de entrevista em dois momentos:
Compreensão da Jornada
Perguntas relacionadas ao dia-a-dia, geralmente abertas, para entender a forma de trabalho e identificar fatores externos ao sistema, como o uso de agendas físicas e etc.
Utilização do sistema — Dizem x Fazem
Iniciamos a segunda metade das conversas com perguntas semiestruturadas e seguimos com um teste da aplicação. Aqui o cuidado foi o de não criar um roteiro/perguntas que direcionassem o usuário para um caminho de respostas e percepções.
Pesquisa NPS
Em paralelo às etapas acima, seguimos o case do SuperHuman e idealizamos uma pesquisa de NPS para nos contar a história dos usuários, ou seja, para nos demonstrar o valor real da aplicação. O NPS, então, foi dividido em 3 etapas:
- Avaliação de 1 à 5;
- Qual o maior benefício que você obtém com o SGU-Clínica?; e
- Como nós podemos melhorar o SGU-Clínica para você?.
Nosso intuito aqui nunca foi afagar o ego conseguindo um NPS alto, ou perder os cabelos com notas baixas. Mas sim, como comentado, identificar valor. Em outras palavras, procuramos entender o que realmente fazia sentido, o que os usuários entendiam como algo negativo/positivo e, ao mesmo tempo, com base em todo o contexto, onde poderíamos investir mais esforço
Esta etapa nos mostrou que possuíamos muitas oportunidades para seguir em frente, e foi isto que fizemos. Cada resposta é importante, mas neste cenário focamos em entender melhor os resultados de 3 pra cima, para saber como iríamos transformar usuários indiferentes em embaixadores do produto.
Gerar entregas com valor
Aqui vamos falar de dois cenários que colidem quando se está trabalhando com um produto em produção: atuação atual x nova visão. Basicamente, ao mesmo tempo que precisamos nos preocupar com as novas descobertas, também é necessário não esquecer o que já foi planejado. Como nosso Head de Inovação costuma comentar: ‘é como trocar a roda de um carro em movimento’. Bem, esta é a realidade.
O trabalho não para
Seria incrível falar: “Então nós paramos 100% nosso desenvolvimento e ficamos totalmente focados nesta etapa!”. Acontece que o mundo é um pouco mais complexo do que a maioria dos livros nos mostra.
Durante todo este processo nós ainda possuíamos um produto que precisava de manutenção, usuários que demandavam atenção e funcionalidades que estavam para serem liberadas. Aí a pergunta é:
Como utilizar os novos dados e alavancar o que já temos?
Esta resposta veio no meio das pesquisas. Começamos a identificar padrões tanto nas falas quanto nos testes. Padrões estes de situações e fluxos que poderiam (e até já deveriam) funcionar de forma diferente do atual. Muitos por consequência de testes que foram ‘pulados’ e a decisão ter ficado no ‘achismo’. Sendo assim, conseguimos neste momento fomentar um pequeno backlog de correções e melhorias que poderiam — agora que estávamos em contato com os usuários — serem facilmente prototipadas, testadas e corrigidas.
Esta é, em si, uma etapa muito importante e para isto utilizamos duas matrizes:
A primeira, focou em dados, dividir e entender se o que estávamos identificando encaixava-se em ‘problemas, melhorias ou novas funcionalidades’. Repare que aqui ainda falamos em ‘funcionalidade’ e não em valor.
A segunda matriz foi focada no ‘Agora’ e dividida em entregas de alto/baixo impacto e pouco/muito tempo. E como fica evidente na imagem a seguir, a maioria nos demandariam pouco esforço e teriam um alto impacto para o usuário (e aqui sim começariam a gerar valor).
Temos os dados, e agora?
Com o backlog do time fomentado e os dados da pesquisa em mão, nós entramos em um ciclo de dual-track, o que possibilitou finalmente conseguirmos gerar demanda e permitir que as etapas do discovery ocorressem. Mas para que isto acontecesse de forma eficaz, seria necessário que todas as informações levantadas fizessem sentido com as jornadas dos usuários (médicos e secretárias).
Para isto nós literalmente desenhamos a jornada de cada usuário. Focamos aqui em: Fase, Objetivos, Ações/pontos de contato e emoções. Este último aspecto acabou funcionando, também, como um verificador. Isto pois conseguimos identificar situações onde falhamos ao observar o usuário e onde precisaríamos voltar e dar mais atenção
Como mencionado, o desenho da jornada aconteceu tanto para os médicos quanto para as secretárias. Ao mesmo tempo que começamos a desenhar todos os passos, conseguimos identificar, novamente, padrões e relações com os dados levantados previamente durante as pesquisas. Além disto, outros pontos foram surgindo e tudo isto nos permitiu ter uma ideia real do nosso processo até o momento, assim como o que precisaríamos revisitar e focar novamente.
Nesta etapa já conseguiríamos iniciar inúmero processos de discovery, pois já era possível identificar diversas situações que precisavam de atenção. Precisávamos agora ir mais além, para isso usamos a árvore de oportunidades para nos auxiliar em ter uma visão focada em valor.
Árvore de oportunidades
Seguindo a metodologia defendida pela Teresa Torres, procuramos ir além de apenas identificar problemas. Nosso objetivo era o de entregar e medir o valor. Para isto, trabalhamos em cima de uma árvore de oportunidades, onde pensamos em:
- Objetivo macro;
- Oportunidades — valor para o usuário;
- Soluções para cada oportunidade; e
- Experimentos para atacar cada solução.
Como demonstrado acima, a árvore pode tomar uma dimensão inimaginável e foi por este motivo que trabalhamos com todo o time. Não apenas viemos atualizando o time sobre as pesquisas, compartilhando material e as entrevistas em si, mas também usamos da opinião de todos na hora de desenvolver a árvore.
Aqui uma dinâmica com todos nos rendeu muitos pontos de vista. Não apenas conseguimos sair da nossa ‘caixa’ de pesquisadores, designers e PO’s, mas também foi possível tocar pontos já levantados pelos usuários, com visões distintas de todo o time.
Interessante ressaltar aqui que esta dinâmica nos ajudou a fomentar, agora sim, soluções para as oportunidades. Mas isto foi apenas a primeira etapa, após definir qual oportunidade será seguida, uma nova análise da mesma e das possíveis soluções se inicia. Neste ponto é muito importante ter este aglomerado de soluções já existentes, pois acabam servindo como um norte desafiador, ou seja, nos demonstram pontos que podemos validar (com experimentos) e também abrem um maior leque para outras soluções aparecerem.
Definindo as entregas
Pensando no futuro, utilizamos inicialmente o RICE para compreender como cada oportunidade identificada iria refletir no valor do produto. Com estes dados conseguimos unir pesquisas qualitativas e quantitativas, transformando assim nosso cenário de suposições para um que se baseie em dados reais e métricas.
Obviamente este não é o final da jornada, na verdade é apenas o início. As próprias oportunidades possuem métricas que serão acompanhadas, seja antes, durante ou após as entregas. Além do fato de estarmos encontrando o caminho ‘ideal’ para a FESC.
Claro que existem diversas ‘receitas de bolo’ e de um modo ou de outro seria muito cômodo seguir uma delas e não questionar mais. Acontece que o Design é um campo totalmente iterativo e como tal necessita de atitudes que promovam e advoguem por esta iteração. Deste modo, compreendemos que nosso processo não é perfeito — está longe disto. Mas para criar o bolo perfeito estamos dispostos a testar diferentes receitas, unir as que fazem sentido e crescer. Afinal de contas, este é o jeito FESCKER de ser. Experimentar e errar é o caminho para o aprendizado, e toda essa experiência nos coloca mais perto do sucesso.
Conclusão
Quando falamos que o Design vai além do pixel, estamos desafiando a visão de que o resultado final é uma tela bonita. Apesar de termos muito o que seguir, aqui demonstramos que o resultado final, na verdade, é uma ótima experiência. Hoje temos aplicações cada vez mais incríveis no mercado e pensar que o usuário será facilmente enganado por um ‘pixel’ perfeito -entenda-se uma tela bonita - é algo que já não funciona mais.
Além disto, existe o desafio de como transformar uma empresa que não possuía a cultura de design, ou simplesmente de pensar no usuário. No caso da FESC, no momento que escrevo este artigo, não temos nem dois anos de designers andando pelos corredores. Este, por sua vez, se torna um desafio ainda maior na hora de utilizar dinâmicas, seja de pesquisa, prototipagem ou teste.
No momento este artigo é apenas uma demonstração de como, aqui na FESC, estamos nos transformando e começando a disseminar que o Design vai muito além do pixel ou uma tela bonita. Também serve como provocação para que as empresas passem a dar mais valor para o discovery e não apenas para o visual elegante de uma aplicação.
Tem alguma sugestão ou dúvida? Nos envie! Seria ótimo conversar mais sobre e trocar experiências!
