Um dos grandes desafios das equipes de design é lidar com a cultura de seus clientes e organizações. Não atoa, muitos profissionais empregam o termo evangelizar para dar nome
ao conjunto de ações que visam aculturar o cliente e fazê-lo entender que a realização de processos centrados no usuário são importantes para construção de produtos melhores
e capazes de entregar mais valor para os usuários. Tudo isso, é claro, sem deixar de atender as necessidades do negócio. Esse é um cenário muito comum a organizações com pouca ou nenhuma maturidade em Design ou mesmo com culturas onde a entrega do software é o passo mais importante.
Atualmente, é comum que uma das ações de evangelização de organizações seja feita por meio de metodologias como Design Thinking, que visa trazer a visão do processo de Design com uma linguagem mais palpável para o mundo corporativo. Buscando evocar o sentimento de empatia entre os responsáveis pela concepção dos produtos, funciona quase como uma conscientização do envolvimento das pessoas usuárias nos processos. Junto ao Design Thinking, geralmente somos apresentados ao Double Diamond, que é (indiscutivelmente) um processo fácil de entender e palpável o suficiente para grande parte das pessoas. No entanto, mesmo com essa simplicidade, nem sempre conseguimos levar a frente esse tipo de processo como gostaríamos,
e as barreiras são inúmeras.
Mesmo com uma “evangelização” em andamento, nem sempre fica clara a importância da condução desses processos para o valor do produto. Há uma resistência a agendas baseadas em workshops, realização de pesquisas e todos os ritos que nós designers julgamos importantes para uma entrega de valor. Na visão dos stakeholders, esses ritos viram obstáculos para o avanço do projeto, afinal de contas, eles querem mesmo é ver o produto na rua. Isso se torna ainda mais latente quando há um entendimento por parte do cliente de que ele já sabe o que quer, especialmente quando há um conjunto de requisitos pré-definidos, com todas as estórias esperando para ganhar vida em protótipos de alta
fidelidade, que serão desenvolvidos e entregues
o mais brevemente possível.
É preciso enxergar esses obstáculos com muita naturalidade, pois não se transforma cultura de um dia para o outro. No entanto, precisamos de estratégias que levem em conta esses inúmeros obstáculos e que, ainda assim, nos permitam realizar entregas consistentes para os todas as partes interessadas. Por isso, vou recorrer a um velho conhecido: o ciclo de vida em estrela.
Brilha uma estrela
O Ciclo de Vida em Estrela é um dos processos de design presentes na literatura de Interação Humano-Computador, e aqui utilizarei como base o livro clássico da Simone Barbosa para esta disciplina. Proposto por Deborah Hix e Rix Hartson na década de 1990, esse processo é composto por 6 atividades, onde a avaliação é o elemento central e por onde todas as outras atividades devem passar a cada interação. O pulo do gato está justamente na flexibilidade na hora de iniciar o ciclo do produto, pois fica a cargo do designer (que aqui prefiro substituir pela figura do time) decidir por onde faz sentido iniciar, com base no contexto que está a nossa frente.
Digamos que uma determinada ideia tem grande dependência tecnológica para funcionar, e sem esse ingrediente, o produto não será capaz de existir. Faz sentido que o projeto inicie por meio de uma implementação inicial e experimental com
o objetivo de validar se a tecnologia atende ao requisito, para só depois ser avaliada e virar um projeto conceitual, por exemplo.
Projetos com grande apelo dentro da organização, que buscam resoluções rápidas para aproveitar aberturas de mercado podem começar por um protótipo e depois seguirem uma primeira implementação, dando vida a um MVP, sempre passando por etapas de avaliação, que nesse caso podem incluir testes de usabilidade, validação de hipóteses, inclusive se utilizando de dados gerados pelos usuários durante o contato com o produto. Aqueles projetos em que já existe um conjunto de requisitos pré-definidos podem seguir com um caminho mais convencional, mas esbarrar em uma etapa de avaliação na próxima iteração. O Ciclo de Vida em Estrela permite infinitas interações, sendo possível trabalhar em ajustes e incrementos no produto mesmo após a sua etapa de implementação, bem como retoma-la para entrega de novas versões do produto. Essas características tornam essa abordagem uma alternativa muito interessante para contextos onde é preciso entregar logo, validar depois.
Avaliando a cada iteração
Com grandes flexibilidades, vem grandes responsabilidades. Mesmo permitindo que os projetos iniciem por diversas frentes, inclusive indo direto para a construção de protótipos ou implementação, a ideia é que nenhuma iteração passe a frente sem uma etapa de avaliação, e aqui que a mágica acontece. Nessa etapa, nós sempre validamos o que foi realizado no passo anterior, com as ferramentas que julgarmos mais interessantes naquele momento. Podemos realizar um teste de usabilidade com base no protótipo construído, avaliar se a tecnologia testada por meio da implementação faz sentido para o que se quer resolver, ou até mesmo entender se os requisitos propostos atendem as necessidades dos usuários e do negócio.
Quando um ciclo é concluído e termina com o produto nas mãos dos usuários, voltamos a avaliação para acompanharmos os resultados, ouvir os feedbacks dos usuários e dar início ao ciclo de melhorias. A cada etapa de avaliação, é possível decidir que rumo o projeto deve tomar na próxima iteração. Esse tipo de abordagem é mais comum do que pensamos. Um clássico exemplo é quando utilizamos protótipos para materializar ideias e ajudar os stakeholders a entenderem o que queremos propor, e também podemos entender esse processo como uma etapa de avaliação. Se trata de estruturar como processo algo que já acontece no nosso dia a dia, e tirar proveito dessa flexibilidade para realizar a melhor entrega possível.
Simplificar para conquistar Flexibilizar o processo de construção de produtos pode nos ajudar a romper uma barreira interessante para inserção de processos de design mais abrangentes em outras etapas do projeto. Além disso, entendo que essa abordagem consegue ser mais realista,
já que leva em conta as peculiaridades de cada projeto, entendendo que cada time e cada produto são um mundo diferente.
E claro, é possível combinar esta abordagem com outras metodologias que já conhecemos, como Design Thinking e Design Sprint, por exemplo. Não há uma abordagem correta ou definitiva, é preciso entender e sentir o momento do time
e escolher a ferramenta que melhor atenderá as expectativas de todas as partes.
Referências
BARBOSA, Simone Diniz Junqueira; SILVA, Bruno Santana da. Interação Humano-Computador. Rio de Janeiro: Elsevier Brasil, 2010. 408 p. ISBN 978-8535234183