Como criar um bom protótipo
Por Alex Oliveira e Julia Mendonça
Atualizado em: 15/02/2024
🤔 Por que fazer?
A prototipação evita retrabalho, ou seja, perda de tempo durante o desenvolvimento. Facilita a visualização de todo o trabalho que precisa ser feito, sendo utilizada como um guia para acompanhar o progresso do desenvolvimento tanto para o cliente quanto para a equipe.
No protótipo também é onde conseguimos visualizar o sistema no seu mais alto nível, porém com detalhes suficientes para mensurarmos a sua complexidade e, assim, decidir sobre a sua viabilidade.
✏️ Introdução
A prototipação envolve muitos passos antes do design no Figma propriamente dito, a seguir apresentaremos alguns conselhos gerais e orientações úteis.
Durante o processo, reuniões periódicas com o cliente para alinhamento e verificação são essenciais para se conseguir cobrir os requisitos do cliente e evitar retrabalho. É importante estabelecer ao menos uma reunião fixa por semana enquanto durar o período de prototipação. Lembre-se sempre de estar atento ao se pensar no fluxo e funcionalidades para não criar conflitos que causem prejuízos futuros.
Para todas as etapas de planejamento/prototipação, não fuja do usual para que o sistema não fique pouco intuitivo e difícil de usar. Busque referências não apenas para a parte visual, mas também para pensar no fluxo entre as telas e na forma em que as funcionalidades deverão ser utilizadas.
Mostre o que foi feito para outros membros da equipe, uma visão externa ajuda a ver problemas ou possíveis melhorias que não vemos por estarmos familiarizados com o que nós mesmos planejamos.
💡 O que precisamos para uma boa prototipação?
- Google docs
- Lucid Chart
- Figma (manual de figma em breve)
⚙️ Passo a passo
Minimundo
O minimundo é um artefato que descreve o que precisa ser feito em palavras simples e de entendimento comum entre desenvolvedores e clientes. Ele fornece uma visão sucinta, mas completa das funcionalidades que o cliente deseja para o seu sistema. Por exemplo, para uma loja de pet shop que atende apenas cachorros, um trecho de minimundo seria:
A empresa digitalPet precisa de um sistema para o gerenciamento de seus serviços e acompanhamento dos pets de seus clientes. Os principais serviços da empresa são serviços para os pets de seus clientes como banho, tosa e passeio. Deve ser possível que os atendentes de caixa registrem os clientes juntamente com as informações dos seus pets. Para que um cliente seja cadastrado é necessário informar nome, sobrenome, cpf, e quantos pets o cliente possui. Para inserir a informação dos pets deve ser informado nome, idade, raça e peso.
O texto de mini mundo pode ser escrito a partir das informações fornecidas pelo cliente nas reuniões de diagnóstico e de proposta. Caso não se tenha informações suficientes, deve-se marcar outra reunião para entender melhor os requisitos.
Depois, o minimundo deve ser apresentado ao cliente e ajustado para melhor cobrir os requisitos essenciais do sistema. Lembre-se de ater-se ao essencial para o funcionamento do sistema. Funcionalidades assistenciais podem ser combinadas posteriormente.
Reuniões de alinhamento
Durante o processo de prototipação o cliente não tem o sistema propriamente dito sendo construído, o que pode gerar certo desconforto. Por esse motivo, é importante trabalhar em entregáveis para que o cliente consiga visualizar o progresso no que ele investiu. Os principais artefatos entregáveis são: mapa do site, wireframe e protótipo. Trataremos desses itens posteriormente.
Recomenda-se que as reuniões sejam combinadas com o cliente num intervalo de 1 hora, e que metade (ou até um pouco mais da metade) desse tempo seja de exposição do que foi feito. O tempo restante fica para o cliente dar seu parecer e sugerir alterações.
É muito importante ouvir bem o que diz o cliente para conseguir “traduzir” suas demandas em requisitos bem definidos.
Mapa do site/Fluxograma
Planeje quais serão as telas/páginas do sistema, e quais telas serão acessadas a partir delas. E ainda, quais tipos de usuários tem acesso a essas telas. A depender do sistema, teremos um usuário administrador com telas diferentes das do usuário comum. É necessário, portanto, identificar esse tipo de ocorrência já nesta etapa. Discutir essa questão nas Reuniões de alinhamento com o cliente, além de fundamental, pode facilitar futuramente no seu desenvolvimento e a interação do usuário.
Requisitos
Os requisitos são basicamente as exigências que o sistema precisa para cumprir as suas funções essenciais. Existem dois tipos de requisitos, mas focaremos aqui nos requisitos funcionais.
No minimundo, quando temos o trecho:
Deve ser possível que os atendentes de caixa registrem os clientes
Temos aqui uma funcionalidade. Perceba que Deve ser possível é uma imposição do minimundo, ou seja, não pode faltar.
Uma outra dica, é que os requisitos são testáveis do ponto de vista da equipe que desenvolve. Podemos saber claramente se o sistema está ou não está cadastrando usuários. Algo que não é um requisito são deveres relacionados ao negócio do cliente, por exemplo: "O sistema deve ser fácil de usar". É algo que não dá para a própria equipe testar, não sabemos quem usará o sistema, o perfil das pessoas etc.
Para um requisito estar completo, devemos também definir algumas tarefas que ele deve seguir para concluirmos que o sistema de fato está cumprindo o requisito de maneira correta. De novo, no cadastro de usuários, o minimundo nos fornece uma dica importante. Ele nos diz quais são os dados de interesse que um cliente deve ter para ele ser cadastrado.
[...] é necessário informar nome, sobrenome, cpf, e quantos pets o cliente possui.
Se ao cadastrar não colocarmos a quantidade de pets que o cliente possui, não estamos cumprindo o requisito de maneira adequada. Por isso, precisamos também elencar o que chamamos de critérios de aceitação do requisito.
Em quê os requisitos nos ajudam?
Os requisitos são importantes para que façamos uma boa divisão das tarefas, e o foco de implementar fica sempre em um pequeno pedaço do sistema, testável e simples de entender.
Definindo prioridades
Uma vez que se tenha listados os requisitos, deve-se ordená-los de forma a priorizar os requisitos mais importantes para serem feitos primeiro. Aplicando a regra de Pareto ao contexto de sistemas, temos que 80% do valor do produto vem de 20% das funcionalidades implementadas. Portanto, identifique os requisitos que trarão mais valor ao cliente mais rapidamente e comece o trabalho por eles.
Exemplo de lista de requisitos ordenada por prioridade para o Pet Shop:
- Agendar serviço
- Gerenciar serviços agendados
- Guardar cadastro de animal
- Receber pagamento pela plataforma
- Possibilidade de cashback
Mas, nem tudo que é prioridade podemos começar a desenvolver, o cliente nos dará a visão macro da funcionalidade principal do sistema. Entretanto, começamos pelas funções mais básicas do sistema. Agendar o serviço é uma prioridade, porém, para agendar temos que ter um cliente e um serviço. Para isso devemos primeiro implementar as funções de criação, seguindo o que foi explicitado no minimundo.
Wireframe
É a etapa onde se monta o esqueleto das telas. Aqui não se deve gastar tempo com cores ou outras minúcias estéticas. O foco deve ser a disposição dos itens, o tamanhos de um em relação ao outro e verificar mais uma vez se cada tela possui tudo o que precisa, se agrega valor e se não faltou nada.
Exemplo:
Dica: adicione comentários sobre os itens para não se esquecer a que cada um se refere. Será também importante para quando for apresentar ao cliente na Reunião de Alinhamento. Sim, faça uma Reunião de Alinhamento para mostrar o wireframe! Isso poupará bastante esforço na etapa de protótipo.
Entidades do sistema
Com o seu minimundo definido, começaremos extraindo as entidades mais importantes para que possamos examiná-las e conhecer mais sobre a sua natureza. Para isso, precisamos simplesmente extrair os substantivos, no exemplo do pet shop temos: cliente, pet e serviço. Todos eles possuem características que são registradas, e precisam ser salvas no sistema. Cuidado! Pois nem todo substantivo é um objeto, coisas do tipo calendário e lista de clientes não são! Uma coleção de outros objetos não é um objeto, é apenas uma forma de se fazer a exibição do mesmo. Uma outra dica é que objetos também executam alguma ação no sistema, ou exercem algum tipo de ação, sozinhos, ou com outros. Por exemplo, do cliente que pode solicitar serviços para serem aplicados aos pets.
Para registrar esses objetos de maneira simples, usaremos um software chamado lucid chart. Usaremos postits de cores variadas para algumas representações. Acabamos de encontrar os principais objetos, então, registraremos eles com postits azuis dessa forma:
Ainda precisamos definir as características essenciais desses objetos, por exemplo, o cliente possui nome, cpf, quantidade de pets e outros atributos. Vamos representálos com postits amarelo e colocar abaixo dos azuis. Cada uma das características do cliente estará em um postit diferente, veja na imagem a seguir.
Algumas características precisam ser pensadas, como data de criação, tags e nomes que podem ser buscados. Nessa etapa, avaliamos se faz sentido ou não colocar algum atributo de filtro. Por exemplo, faz sentido o nome do pet ser usado como filtro de busca no sistema? Aqui não faz, então não é. Mas para fins de controle, pode ser que o dono queira filtrar pela data os serviços que foram feitos. Então, abaixo do objeto de serviços aplicados colocamos em um postit vermelho com sendo indicador de que é um atributo de filtragem. Outro atributo que pode ser usado também, é o custo total do atendimento ao cliente. Colocaremos em vermelho. Até o momento não temos atributos que precisem ser destacados, apenas o nome do usuário e o nome do serviço.
Você deve estar se perguntando: Mas, se o cliente possui pets, como sabemos quais são os pets que ele possui? É nesse momento que definimos este tipo de comportamento, pois um cliente possui pets. Para isso iremos fazer uma mesclagem entre os objetos, é aqui que um objeto vira característica do outro. Veja na imagem abaixo como representamos esse tipo de iteração:
Além disso, precisamos representar que um serviço ocorreu, isso está bastante implícito no texto, então cabe retornar ao minimundo e acrescentar o que é necessário registrar esse evento, e quais são as informações necessárias para que seja possível realizar um registro do serviço. Segue abaixo uma representação do objeto venda:
Mininundo atualizado apoś a percepção da falha e após uma conversa com o cliente:
A empresa digitalPet precisa de um sistema para o gerenciamento de seus serviços e acompanhamento dos pets de seus clientes. Os principais serviços da empresa são serviços para os pets de seus clientes como banho, tosa e passeio. Deve ser possível que os atendentes de caixa registrem os clientes, juntamente, com as informações dos seus pets. Para que um cliente seja cadastrado é necessário informar: nome, sobrenome, cpf, e quantos pets o cliente possui. Para inserir a informação dos pets deve ser informado o nome, idade, raça e peso.
Os vendedores em caixa precisam registrar as vendas que foram feitas, e para isso devem informar os dados do cliente, qual ou quais serviços serão alocados e qual pet do cliente estará recebendo o serviço. Além disso, o sistema deve calcular o valor total da venda, de acordo com os serviços que foram selecionados.
Dessa forma, vamos coletando informações e atualizando os documentos com o máximo de informações possíveis.
Protótipo
Em breve no manual de figma.
🤝 Dicas úteis:
O cliente não irá dizer de forma completa tudo que o sistema precisa, e é nessa fase de protótipo que devemos exaurir todas as informações possíveis. Descobrir novos requisitos em tempo de desenvolvimento não é um pecado capital, mas pode ser bem custoso. Por isso, examine todos os dados, vista a camisa do time do cliente e tente identificar o que falta a partir do seu entendimento do negócio dele. Tente identificar o que está incoerente, por exemplo, um fluxo de login que não permite trocar a senha ou recuperar, uma falha na lógica que permita que o usuário tenha infinitos descontos ou um preço absurdamente alto.
Sempre use termos de conhecimento geral e não os termos técnicos que você aprende na universidade. Se possível, coloque um dicionário com os termos que você combinou com o cliente. Este dicionário também servirá para a sua equipe facilitar a comunicação.