Ciclos de prototipação em desenvolvimento de produtos

Atualmente quando falamos de protótipo, especialmente nós, designers, pensamos em arquitetura da informação e no protótipo como uma versão rudimentar de uma tela de website. Mas se recorrermos à reflexão do significado da palavra protótipo, de forma mais abrangente em Design, chegamos à conclusão que um protótipo é uma maneira de você sair do plano da ideia e realmente transformá-la em projeto, viabilizar, tornar físico, mesmo que de uma forma superficial, mas que as pessoas possam ver, tocar, interagir, e servir como um ponto de partida para entender o que você está propondo como solução projetual.

Na área de produtos, no design de móveis, temos o protótipo como um mockup, no design de moda, a peça piloto, em produtos digitais temos o protótipo, que pode ser entendido em vários estágios de maturidade e evolução, em um processo contínuo que pode ser desde o início de um produto/serviço até seu lançamento, seu acompanhamento pós lançamento ou melhoria de algo existente. Quando falamos em digital, sempre existe protótipo, se não for o que está no ar, em produção, se trata de um protótipo.

E onde entra o tal do MVP? Eu devo confessar aqui que não há consenso do que pode ser o MVP, apenas que é o protótipo necessário para lançar seu produto no mercado e validar se existe aceitação e aderência, quanto ao estado de maturidade, depende do seu plano estratégico, quando falo de MVP eu prefiro trabalhar da forma mais rudimentar possível e ir validando até o lançamento do produto, então, MVP, na minha concepção é o MINIMUM viable product, eu, por exemplo, quando comecei a Prisma, meu MVP foi um Google Forms para “ter uma noção” do mercado que iria atuar e da percepção das pessoas dele.

Agora quando falamos de software, ou de uma página web como produto, entramos em uma outra discussão, que considero essencial antes de qualquer rabisco: a análise de requisitos. Por que a necessidade de tal trabalho? Pelo nível de complexidade da solução, do contrário você desenhará apenas fluxos gráficos sem função objetiva nenhuma, apenas uma “casca” e não a ideia de uma interface.

Agora você me pergunta, Anne, o que é uma análise de requisitos, quais informações eu posso considerar requisitos para começar a rabiscar o meu protótipo? Como falamos de Design Thinking, eu sugiro e prefiro trabalhar com uma análise de requisitos como parte de co-criação, um brainstoming, junto à equipe, acredito que são peças fundamentais o front-end, a pessoa do marketing e o PO. Cada um vai falar o que acha que é o mínimo necessário para fazer “uma tela”.

Agora como se faz isso? Todo mundo anota cada requisito em um post-it, e em conjunto, a equipe agrupa os post-its por tempo, prioridade, custo e dificuldade. Aí você já tem vários ciclos de prototipação, agora só falta validar os protótipos. Essa é outra parte importante, eu diria que é o pulo do gato na verdade.

Para cada nível de maturidade do seu protótipo, é necessário um tipo de validação, imagine você testar com clientes um protótipo em um caderno ou um wireframe feito no Axure sem interação nenhuma, uma tela estática? Que tipo de feedback e interação o usuário terá com isso? Por isso, é necessário discernimento na escolha das ferramentas e práticas dentro de cada ciclo de prototipação do produto.

Aqui em baixo eu deixo um rascunho de como eu trabalho às vezes, dependendo do projeto:

Copyright © 2017–2018 por Prisma Consultoria de Design
Todos os direitos reservados. Nenhuma parte desta publicação pode ser reproduzida, distribuída ou transmitida por qualquer forma ou por qualquer meio, incluindo fotocópia, gravação ou outros métodos eletrônicos ou mecânicos, sem a prévia autorização por escrito do editor, exceto no caso de breves citações incluídas em revisões críticas e alguns outros usos não-comerciais permitidos pela lei de direitos autorais.