Arquivo da tag: user story

Story mapping no IHC2010

Enfim, compartilho com vocês minha apresentação no IHC2010. Apresentei a técnica de story mapping para planejamento de produtos interativos em ambientes ágeis (baixe o artigo: User Story Mapping_v1).

Embora tenha sido desafiador falar de tecnicas ágeis em um evento acadêmico, fiquei bastante feliz em conhecer e ver a produção de outros colegas, que caminham em direções parecidas, como o @carlbberg que apresentou uma ferramenta interessante para modelagem de usuários e tarefas em ambientes ágeis, o MEX Experience Board.

User story maps: Método de priorização de fucionalidades

User story map

User story map é uma técnica desenvolvida por Jeff Patton e seu principal objetivo é auxiliar na estratégia do produto, ou seja, na priorização e planejamento de funcionalidades que serão lançadas para um determinado produto. O mais interessante da técnica é sua característica colaborativa que propicia uma discussão entre a equipe (e stakeholders) sobre as funcionalidades, sob um ponto de vista de seus usuários.

Aplicando User story map na Latitude14

Aplicando User story map na Latitude14

Consiste, resumidamente em:

  1. Definir as principais atividades que o usuário pode realizar no produto
  2. Detalhar as tarefas realizadas por usuários
  3. Agrupar atividades e tarefas
  4. Ordenar tarefas em um fluxo lógico de uso
  5. Validar com usuários o agrupamento e ordenamento de tarefas
  6. Selecionar funcionalidade para primeiro release

Veja o artigo completo para maior entendimento da técnica

Release sob medida: Por que é importante priorizar sob o ponto de vista dos usuários?

Existe o risco de lançar um produto com o mínimo possível, que, no entanto, não é considerado útil pelos usuários, ou seja, que falte alguma necessidade, ou não permita que ele faça toda uma tarefa completa, por exemplo. Por isso é importante entender bem o que é importante de ter no primeiro release que satisfaça as necessidades dos usuários para lançar o mínimo possível e útil.

Sob esse ponto de vista é possível analisar as funcionalidades, de acordo com:

Necessidade – qual o mínimo necessário para o produto existir que satisfaça seus usuários?
Flexibildiade – o que permite ao usuário realizar a tarefa de forma diferente?
Segurançar – o que tornaria o produto mais seguro de usar?
Conforto, luxúria e performance – O que faria o produto mais fácil, mais desejável ou mais rápido?

Considerando qualidade das features

Segundo Noriaki Kano, existem dois aspectos das features, os objetivos e os subjetivos. Objetivos dizem respeito a conformidade com os requerimento, enquanto subjetividade pertence a satisfação dos usuários.

Existe, segundo ele, 3 categorias de features:

  1. Must-haves – “O produto precisa ter isso para que eu considere ele aceitável”
  2. One dimensionals – “Quanto mais eu tiver disso melhor”
  3. Delighters – “Eu amo este elemento deste produto!”

Qualidades objetivas:

O produto opera sem erros?

Qualidades subjetivas:

O produto é simples de usar?
O produto é eficiente?
Eu como usuário gosto de usar o produto?

Conclusões

Patton explica que na hora de planejar o primeiro release, a discussão sobre o que deve ter ou não no primeiro release e as discussões sobre as soluções, são, na maioria das vezes, puramente especulativa. Porque não se conhece ao certo o que é importante para os usuários. Por isto penso ser importante o “ciclo zero”, no clico de vida iterativo de um produto, onde, por meio de pesquisa com usuários, procura-se resolver e clarificar especialmente estas questões:

- Quais são as principais tarefas dos usuários?
- Qual é o fluxo realizado, ou que se espera do software?
- O que é necessário que tenha?
- O que faria o produto mais flexível?
- O que faria o produto mais seguro?
- O que faria o produto mais desejavel?

Sabemos que para o primeiro release, devemos tentar reduzir o máximo, para reduzir riscos. No entando, é indicado, na hora de considerar a solução ou feature que irá fazer parte do primeiro release, considerar também, sob a ótica do mínimo necessário que se traduza em flexibilidade, segurança, prazer, ou seja, aspectos subjetivos também, para, justamente, evitar o erro de um release que não satisfaça ou seja incompleto. Embora estas questões possam também vir a serem respondidas nos testes de usabilidade, em fases avançadas de desenvolvimento, há o risco de ser tarde de mais.

A existência de um ciclo zero pode esclarecer e munir a equipe com informações mais concretas e acertadas. Talvez a solução seja, começar, a partir dessa pesquisa inicial, e implementar as funcionalidades “mais necessárias” e ir adicionando outras camadas de qualidade com o tempo. Pensando iterativamente e incrementalmente.

Obs.: Apresentaremos, com mais detalhes, esta técnica em um workshop no Dia Mundial da Usabilidade BH, aguarde mais informações.

Entenda melhor as referências do texto:

User Story maps

http://www.agileproductdesign.com/blog/the_new_backlog.html

Diagrama de necessidades de Kano

http://www.infoescola.com/administracao_/diagrama-de-kano/

Adaptando Agile para UX

http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html

A importância dos user stories no design de sistemas interativos

O desafio não é desenvolver, é saber o que desenvolver.

User Story

User Story

Atualmente, temos utilizado, aqui na Latitude14, uma técnica interessante nos nossos projetos, que veio do Agile development: os Users Stories. Ele tem nos ajudado a manter o foco na essência, nas coisas que realmente importam.

User stories são descrições simples que representam uma funcionalidade. O recomendável é que essas user stories sejam escritas do ponto de vista de uma necessidade dos usuários. No agile, as users stories são escritas em cartões (de papel) em conjunto com o cliente, a equipe de desenvolvimento orça as horas gastas para desenvolver cada user stories e então, em conjunto com o cliente, estas são priorizadas (o que ajuda a selecionar as funcionalidades mais importantes e eliminar o excesso de funcionalidades inúteis).

Elas podem ser escritas de várias formas, mas temos adotado essa: Continue lendo