O que eu aprendi com os Casos de Uso?

Uma das tarefas que o time de UX deveria fazer é o Caso de Uso, mas que por levar muito tempo para fazer e quebrar o fluxo ágil, muitos designers nem chegam a aprender como escrever ou para o que ele serve, resolvi ressuscitar essa prática, pois a importância dela é essencial, como documentação, ele permite literalmente desenhar o processo de execução do negócio e visualizar a responsabilidade de cada participante, quando ele entrará em cena, qual será sua interação total e quais serão os fluxos primários e alternativos do sistema.

O que é?

Um caso de uso é uma descrição por escrito de como os usuários irão executar tarefas no sistema/produto. Ele descreve, do ponto de vista do usuário, o comportamento de um sistema, uma vez que responde a uma requisição na interface. Cada caso de uso é representado como uma seqüência de passos simples, começando com a meta de um usuário e termina quando esse objetivo for cumprido.

Benefícios de Casos de Uso

Os casos de uso agregam valor ao produto/site, porque eles ajudam a explicar como o sistema deve se comportar e, no processo, eles também ajudam o brainstorm que poderia dar errado. Eles fornecem uma lista de objetivos e esta lista pode ser utilizada para determinar o custo do desenvolvimento e a complexidade total do sistema. As equipes de projeto podem então negociar as funcionalidade que se tornarão requisitos principais, secundários e terciários do sistema construído, tornando a estimativa de tempo para a conclusão de tarefas mais assertiva.
Para o Time de UX, o Caso de Uso ajuda a entender o contexto onde os usuários estarão inseridos, quais as tarefas e quais as funcionalidades deverão ter uma atenção especial em relação a experiência proposta e ajuda a prototipar o produto final com mais detalhamento.

Elementos de um Caso de Uso

Dependendo de qual a profundidade e complexidade que você quer ou precisa para começar, os casos de uso descrevem uma combinação dos seguintes elementos:

Investidor (Stakeholder) — Alguém com interesses escusos no comportamento do sistema sob discussão;
Ex.: Em uma aplicação bancária, é de maior interesse do stakeholder que pagamentos possam ser concluídos com mais praticidade.

Ator Primário — Interessados ​​que iniciam uma interação com o sistema para executar uma determinada tarefa;
Ex.: Usuário que utiliza o aplicativo bancário, para acessar sua conta-corrente pessoal.

Pré-requisitos — O que deve ser obrigatório ou deve acontecer antes e depois que o caso de uso é executado;
Ex.:Antes de confirmar o pagamento de um boleto, o sistema deve reconhecer os valores do código de barras, isso deve ser um pré-requisito do sistema para seu uso.

Gatilho — Este é o evento que faz com que o caso de uso deve ser iniciado;
Ex.: O interessado “desejar” pagar um boleto pelo aplicativo é o gatilho para as funções e tarefas de pagar boleto que serão explicadas no caso de uso.

Principais Cenários de Sucesso [Fluxo Básico] — Caso de uso em que nada dá errado;
Ex.: O Pagamento funciona perfeitamente, de acordo com o esperado pelos requisitos do negócios.

Caminhos alternativos [Fluxo Alternativo] — Esses caminhos são uma variação sobre o caminho principal. Essas exceções são o que acontece quando algo dá errado a nível de sistema;
Ex.: Quando o sistema de pagamento demora para carregar e o usuário dá incontáveis cliques por angustia com a demora, qual deve ser a resposta do sistema para essa situação?

Como pode ver, um caso de uso é um documento extenso e muitas vezes cansativo de se fazer, mas é importante termos ele com a gente.

Digamos que você está prestando uma consultoria de UX para o Banco do aplicativo, tudo funciona corretamente e o aplicativo é lançado. Bem, bancos são clientes complicados, pois devido a movimentarem quase em tempo real o dinheiro de todos os seus clientes, eles devem ter extremo o cuidado em não fazer nada fora dos padrões, principalmente para evitar dificuldades ou dar algum erro com as contas bancárias de seus clientes. Por isso, muitas vezes eles seguem um processo de homologar cada etapa e cada decisão de seus sistemas e aplicações. Bom, voltando ao exemplo, imagine que depois de 8 meses de lançado, os stakeholders do banco percebem um erro no fluxo de sua aplicação que tem lhes custado algum dinheiro. Ele o chamam para descobrir se o erro veio do seu fluxo inovador, prestando uma consultoria externa determinando como deveria ser o sistema deles ou se foi erro interno dos desenvolvedores do próprio banco, qual seria sua melhor ferramenta nesta situação? O Caso de Uso, pois eles são os stakeholders, eles aprovaram aquele fluxo quando foi prestada a consultoria, se o erro for no seu fluxo e ninguém viu o erro naquele momento, você não tinha como saber que estaria errado, afinal eles avaliaram e assinaram pelo que estava sendo escrito no caso de uso, se o erro for interno, o caso de uso prova que você determinou de maneira X e algum desenvolvedor fez Y no lugar, sem consentimento deles. Em qualquer cenário, documentações como um caso de uso, sempre ajudam a resolver esse tipo de problema.

E como escrever um Caso de Uso?

Você deve escrever os passos de um Caso de Uso em uma narrativa de fácil compreensão, porém é bom seguir um certo padrão, pois esse documento deverá ser compreensível por você e por outras pessoas no futuro. Identifique quem vai usar o produto, defina a tarefa que será executada com o produto;

Para cada tarefa definida, determine um curso normal (fluxo básico) e procure determinar os caminhos alternativos, escreva do ponto de vista do usuário/consumidor.

Presente extra do Caso de Uso!

Depois de alguns casos de uso escritos e definidos por você, você vai começar a perceber que muitos fluxos se repetem. Quando um caso escrito é muito comum, nós chamamos eles de Casos Comuns de Uso (Sim, eu sei, nada criativo!), porém esses casos comuns tem um grande impacto no nosso trabalho, pois é através deles que começamos a traçar determinados “estereótipos” dos usuários e é onde nosso trabalho começa a ficar mais agradável, pois começamos a ter algumas certezas inabaláveis sobre como devem ser essas interações.