Nos últimos anos, escrevi centenas de histórias de usuários, mas recentemente aprendi sobre dois tipos de formatos de histórias de usuários: histórias de usuários declarativas e histórias de usuários imperativas. Na minha opinião, ambos os formatos são úteis em diferentes estágios do desenvolvimento do produto e a escolha de um sobre o outro depende de quem está usando as histórias do usuário.

Então, o que são histórias de usuários declarativas e imperativas?

Histórias de usuários imperativas

Em uma história de usuário imperativa, o valor-chave é dado a “como” . Eles são muito detalhados, incluem detalhes mais sutis da jornada do usuário e descrevem como o produto deve se comportar com base em diferentes ações do usuário e pontos de gatilho. Os critérios de aceitação mostrarão a parte “como” como o herói de cada ponto.

Honestamente, esta é a única maneira que eu conhecia. Meu lema tem sido: quanto mais detalhes, melhor. Eu costumo cobrir a descrição da chave no formato de história do usuário “ Como ____, eu quero ____, então eu ____” e cubro muitos detalhes, cenários, casos extremos nos critérios de aceitação normalmente na forma “ Dado, quando, então".

Vamos ver um exemplo de como escrevo histórias de usuários (aparentemente é imperativo 😊😜) —

Exemplo de história de usuário imperativo:

Como autor, quero enviar meu artigo, para que meu artigo possa ser visto pelos espectadores na plataforma.

Dado que estou escrevendo um artigo, quando , escrevi 100 palavras, ou seja, o número mínimo de palavras, então, devo ver o botão Publicar na cor azul. Deve ser clicável.

Dado que estou escrevendo um artigo, quando não escrevi 100 palavras, ou seja, o número mínimo de palavras, então, devo ver o botão Publicar na cor cinza. Deve ser clicável.

Dado que vejo o botão de publicação na cor cinza, quando , passo o mouse sobre o botão de publicação , devo ver um texto de foco ou uma dica de ferramenta com a mensagem “Contagem mínima de palavras não atendida”.

Quando não usar histórias de usuário imperativas?

1. Dado que as histórias imperativas são muito detalhadas, esse tipo de escrita deve ser evitado quando a descoberta do produto não aconteceu completamente, ou quando apenas conceitos iniciais e wireframes de baixa fi são criados e o feedback do usuário não foi incorporado no processo de design.
2. Se sua equipe de design também estiver usando histórias de usuários para entender quais recursos estão no escopo e precisam ser projetados. O estilo imperativo de escrita toma muitas decisões de design e não deixa muito espaço para as equipes de UX/design pensarem. No exemplo acima, a história abrange decisões conceituais e toma decisões de design para um UI Designer, como usar texto de foco para informar ao usuário que há uma contagem mínima de palavras para publicar e decidir a cor do botão.

O estilo de escrita declarativa se concentra mais no “o quê” . A ênfase é definir qual valor está sendo criado para o usuário.

Vamos ver como a história de usuário declarativa coloca um foco mais forte no valor em comparação com o exemplo imperativo da história de usuário anterior.

Exemplo de história de usuário declarativa:

Como autor, quero enviar meu artigo, para que meu artigo possa ser visto pelos espectadores na plataforma.

Dado que estou escrevendo um artigo, quando , escrevi o número mínimo de palavras, então devo poder publicar meu artigo.

Dado que estou escrevendo um artigo, quando , não escrevi o número mínimo de palavras, não devo poder publicar meu artigo.

Dado que não escrevi um número mínimo de palavras, quando não consigo publicar meu artigo, devo ser informado de que preciso escrever um número mínimo de palavras para publicar.

Ao evitar detalhes sobre a jornada do usuário e a interface, a história do usuário não dita as decisões de design. Ao manter o número mínimo de palavras abstrato, ele mantém a história do usuário aberta ao feedback do usuário final. Concentre-se em 'o que' o mantém relevante para diferentes partes interessadas e também promove um ambiente de trabalho colaborativo. Ajuda diferentes pessoas a interpretar e idealizar de forma diferente e ter sua própria visão sobre “como” o valor pode ser alcançado.

Evoluir e iterar é a chave

Embora o estilo declarativo tenha algumas vantagens, pode não funcionar o tempo todo. Acho útil começar com um estilo aberto e declarativo com foco no QUE, e gradualmente passar para o estilo imperativo quando

• Testes de usabilidade são realizados e inferências são feitas.
• UX/UI está evoluindo e sendo finalizado.
• A história está sendo refinada com a equipe de design e engenharia, diferentes “comos” estão sendo explorados e finalizados, condições de borda estão sendo exploradas, casos de teste estão sendo escritos.