UX Designers e teamwork: Criando Design Principles com um time multidisciplinar
Este post foi escrito em conjunto com Caroline Guilherme.
Durante a UXConf BR 2016 participamos da oficina de “Design Principles, How to Make Insights Tangible”. A facilitadora do workshop, Camila Boga, e designer da Flutter Innovation, uma agência focada em design para a inovação.
O workshop proposto por ela consistia em quatro etapas: a criação da proto persona, elaboração de um User Jounery Map, identificação de insights e, por fim, a conclusão dos Design Principles. Mesmo não usando dados reais durante o processo, tivemos muitas ideias. Estávamos prontos/as para colocar tudo em prática assim que voltássemos para Florianópolis, mas durante a própria UXConf BR tiramos nosso cavalinho da chuva.
Por mais que tivéssemos tirado diversos insights do workshop, um dos maiores aprendizados que trouxemos do evento foi sobre o envolvimento de várias pessoas no processo de solução/design. E isso inclui desenvolvedores/as, gerentes de produto e de qualidade.
Foi por não acreditar em designers heróis, e que boas soluções só são criadas em conjunto, que chamamos toda a nossa equipe para participar da oficina.
O time de produto da Resultados Digitais funciona da seguinte forma: pequenas equipes especialistas e autônomas são responsáveis por diferentes partes do produto. Por isso os times têm composição variada, com desenvolvedores/as, designer e etc. Isso nos ajudou a começar pequeno, focando só na equipe especialista em Landing Pages (e que é a nossa, inclusive).
É claro que sabíamos que encontraríamos alguns obstáculos na realização do workshop. Como pararíamos todo o time para uma atividade de quatro horas? E a sprint? E os tickets? Nosso primeiro desafio foi assegurar que todo o time estivesse inteiramente presente durante a atividade e que priorizassem esse momento. Tendo isso em mente, fizemos do workshop um momento de descontração, team building e coffee break.
Etapa 1 — Mapa de Empatia
A oficina original da Flutter iniciava com uma etapa de Mind Mapping para a criação de uma proto persona. Como nós já temos uma proto persona definida, substituímos a etapa pela construção de um canvas de Mapa de Empatia (ou Mapa de Empatinha, como preferimos chamar).
Nós separamos o time em dois pequenos grupos de 3 pessoas cada. Isso ajudou a dar agilidade e fazer com que todos/as se sentissem responsáveis durante o processo. Ao final pedimos que as duas equipes apresentassem os mapas. Juntos tiramos as conclusões dos dois resultados.
Etapa 2 — User Journey
A User Journey Mapping é uma forma de exemplificar as ações da persona em determinado momento do dia. O cenário que escolhemos para as equipes foi a criação de um dia inteiro da proto persona, onde ela deveria executar determinada tarefa no RD Station. Eles/as deveriam marcar as ações da persona e o humor referente às ações no decorrer do dia hipotético.
Pedimos que especificassem no mapa todos os momentos do dia dessa persona, incluindo as pausas para refeição e tarefas pós-expediente. Isso promoveu uma maior aproximação por parte do grupo: todos/as envolveram a família, os hobbies, as dificuldades e sonhos daquela persona.
Etapa 3 — Insights
A partir do mapa criado na Etapa 2, os grupos tiraram diversos insights. Um deles, por exemplo, foi que a persona não tem tempo suficiente para executar a tarefa que deveria no software. Mas esses insights iniciais foram superficiais e queríamos que os times se aprofundassem ainda mais nos questionamentos. Usamos a técnica dos 5-Whys (“5 Porquês”, em português) para incentivar esse aprofundamento em cada insight. O momento de perceber os insights é, além de questionar, aprender a fazer as perguntas corretas. Não é sobre encontrar respostas, mas esmiuçar problemas.
Estaríamos prontas/os para avançar a etapa quando os times tivessem em mente um conceito chave para os resultados de cada momento de interação da persona dentro do software. Assim, aquele insight inicial do exemplo foi percebido como um problema, não de falta de tempo, mas de falta de foco. Deixando claro que dentro do software não tínhamos toda a atenção que precisávamos do usuário/a para a realização da tarefa.
Etapa 4 — Design Principles
Os novos insights possibilitaram descobrir fatos sobre a relação das personas com o software. Entender as principais brechas no dia-a-dia das personas nos permite atuar além da interação usuário/a-software. Vamos ao próximo nível: a relação do software na vida do sujeito.
Como dar foco para a pessoa? Como ajudá-la em sua rotina para torná-la mais agradável como um todo? Se os Insights nos davam perguntas, eram os Design Principles que nos dariam as respostas.
Nesta etapa os dois grupos pensaram em entendimentos comuns sobre o produto que poderiam ser respostas para os Insights. Por exemplo, se nosso produto fosse um e-commerce e a persona dele tivesse pouco tempo para analisar o que comprar (e isso fosse um impeditivo), um dos princípios seria “Praticidade”. Afinal, ser prático significa ser intuitivo e evitar esforço mental. Se nosso produto fosse um aplicativo bancário e nossa persona fosse receosa quanto a transações via smartphone, “Confiança” seria um princípio importante.
Mas claro, os exemplo acima são óbvios: um e-commerce ser prático e um app bancário transparecer confiança. A ideia dois Design Principles é encontrar um diferencial no produto. Usando o exemplo do e-commerce, se considerarmos que ele vende passagens de avião e que a persona encontra-se nas Classes C e D, temos que considerar que essa talvez seja a primeira viagem de avião desta pessoa. Como agir nessas horas? Deixou de ser óbvio, e é esse o diferencial.
No caso dos grupos da oficina, ambos chegaram a cinco Design Principles. Mesmo que ainda estejamos refinando e descrevendo eles melhor, temos certeza que o trabalho em equipe e as diferentes visões sobre o produto colaboraram com a criação desses proto-princípios.
Considerações finais
Definir os Design Principles de um produto é algo essencial, mas o principal aprendizado que tiramos foi o envolvimento de todo o time nesse processo, principalmente desenvolvedores/as.
Existe uma falsa ideia de que desenvolvedores/as não têm empatia e que só estão preocupados/as com a camada técnica do produto. Nós conseguimos provar o contrário após a conclusão do workshop. Os princípios de design extraídos da atividade foram bastante satisfatórios e tão convincentes quanto princípios que teríamos em uma atividade apenas com designers.
