Planejamento de releases
e usabilidade de sistemas
        interativos
    Fabrício Marchezini e Leandro Alves
Quem somos
• Sócios da Latitude14
 ‣   latitude14.com.br e @latitude14
• Mentores da Aceleradora @aceleradora
• Representa...
Story mapping
Técnica colaborativa que
auxilia na priorização de
funcionalidades para
planejamento de releases
Quem deve participar?

                                                   Negócios
                                       ...
Etapas
1. Listar funcionalidades
2. Escrever em cartões
3. Ordenar em fluxo de tarefas
4. Ajustar posição quanto à
   criti...
Passo 1

             Brainstorming: faça uma lista de
            possíveis features do seu sistema



• Mantenha o ponto...
Passo 1
• Ex.: software de controle de vendas
  ‣   Fazer pedido ao fornecedor
  ‣   Receber pedido do fornecedor
  ‣   Ge...
Passo 1
• Escreva cada item em um cartão diferente
• “Eu, como usuário x, preciso .... no sistema”
• Deixe espaço para out...
Passo 2
• Adicione detalhes importantes:
 ‣   Usuários (profissão, cargo, papel desempenhado)
 ‣   Frequência de uso (muito...
Passo 3

• Ordene as cartas em uma sequência lógica
  de tarefas
 ‣   O objetivo é contar uma história de como o sistema f...
Fazer pedido ao      Receber pedido do         Gerar etiqueta para os
   fornecedor                                       ...
Passo 4

• Ajustar conforme criticidade (verticalmente)
  ‣   Coloque acima as cartas mais críticas e mais frequentemente ...
muito usado
Necessidade




                            Receber pedido do
                                                ...
Passo 5

• Marque as quebras no fluxo
 ‣   Discuta onde há quebras no modelo
 ‣   Pode ser uma mudança de usuário, regras d...
muito usado

              compra                    recebimento                                   Venda                  ...
Passo 6

• Marcar primeiro release
 ‣   Deve ser o menor número de funcionalidades úteis para os
     usuários e o context...
muito usado

              compra                    recebimento                                   Venda                  ...
Passo 7


• Estime o tempo de desenvolvimento
 ‣   Peça a equipe de desenvolvimento que estime o tempo para
     cada cart...
Passo 8


• Reparta o bolo: programe outros releases
 ‣   No final você poderá ver quantos releases serão necessários e
   ...
Release 1




Release 2




Release 3



Release 4
Vantagens do story map
•   A primeira versão tem somente o que é mais útil e tem
    maior valor de negócio
•   Facilita v...
E onde entra a
usabilidade nessa
    história?
Porque testar?

•   Se você quer um produto realmente bom, teste!
•   Insights para tomada de decisão
•   Conhecer melhor ...
“Anyone can cook”
     Chef Gusteau
Mesmo que seja
um miojo...
Ingredientes

•   Computador
•   Usuário
•   Tarefas
•   Condutor e observador
•   Bloco de notas
Modo de preparo

•   Planejamento
•   Recrutamento
•   Realização
•   Análise de resultados
Planejamento

•   Quem vou recrutar?
•   O que quero descobrir/confirmar?
    ‣   Quais tarefas testar, para responder esta...
Realização
•   Não diga o que o usuário deve fazer
•   Observe reações verbais e gestuais
•   Deixe o participante confort...
Referências
•   Jeff Patton – http://agileproductdesign

•   Livro Não me faça pensar – Steve Krug
latitude14.com.br   @latitude14
Planejamento de releases e usabilidade de sistemas interativos
Planejamento de releases e usabilidade de sistemas interativos
Planejamento de releases e usabilidade de sistemas interativos
Planejamento de releases e usabilidade de sistemas interativos
Planejamento de releases e usabilidade de sistemas interativos
Planejamento de releases e usabilidade de sistemas interativos
Próximos SlideShares
Carregando em…5
×

Planejamento de releases e usabilidade de sistemas interativos

2.446 visualizações

Publicada em

Apresentação da técnica chamada story mapping, utilizada para priorização de funcionalidades e planejamento de releases de produtos interativos (no contexto de desenvolvimento ágil), e aplicação testes de usabilidade simplificados dentro desses releases.

Publicada em: Design, Tecnologia, Negócios
2 comentários
16 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
2.446
No SlideShare
0
A partir de incorporações
0
Número de incorporações
222
Ações
Compartilhamentos
0
Downloads
0
Comentários
2
Gostaram
16
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Boa tarde!

    Eu sou Fabrício Marchezini, ele é Leandro Alves.

    Vamos mostrar pra vocês hoje é uma técnica chamada story mapping, que é utilizada para priorização de funcionalidades e planejamento de releases de sistemas, usada principalmente no contexto de desenvolvimento ágil.

    Depois disso, vamos falar um pouco sobre testes de usabilidade e como vocês podem aplicá-los de forma simplificada durante o desenvolvimento dos produtos de vocês.

    São duas coisas que não tem relação direta uma com a outra, mas as duas impactam muito na qualidade do produto final do ponto de vista da experiência do usuário.
  • Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
  • Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
  • Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
  • Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
  • Todo mundo conhece essa figura aqui?
    Quem aqui trabalha ou trabalhou com métodos ágeis?
    Quem só leu ou ouviu falar?
    Quem não tem a menor idéia?

    Ela representa o fluxo de desenvolvimento do SCRUM, que é um método de desenvolvimento de progetos ágil. No Scrum, o desenvolvimento é feito em forma de Sprints, que são ciclos de desenvolvimento com tempo fixo (normalmente, duram de 2 a 4 semanas). Esta figura mostra um sprint completo do Scrum.

    No Scrum (e em outros métodos ágeis), temos um backlog do produto, que é uma lista de todas as funcionalidades planejadas para entrar no sistema. Cada funcionalidade é representada por um “user story”. Um user storie é uma caracteristica ou funcionalidade do sistema, descrita do ponto de vista do usuário (para quem não conhece um user story, vamos mostrar depois como ele é).

    Esse backlog é ordenado de acordo com o valor que cada funcionalidade agrega ao produto, de forma que as user stories mais importantes serão desenvolvidas primeiro.

    Desse backlog, são retiradas as funcionalidades a ser desenvolvidas no próximo sprint. No final desse sprint, temos uma parte do produto funcional, potencialmente pronta. Então, começa-se outro sprint.

    Costuma-se dizer que o processo de desenvolvimento ágil é iterativo. Realmente, é um ciclo que se repete várias vezes, mas o valor agregado ao produto se dá de forma incremental.
  • Todo mundo conhece essa figura aqui?
    Quem aqui trabalha ou trabalhou com métodos ágeis?
    Quem só leu ou ouviu falar?
    Quem não tem a menor idéia?

    Ela representa o fluxo de desenvolvimento do SCRUM, que é um método de desenvolvimento de progetos ágil. No Scrum, o desenvolvimento é feito em forma de Sprints, que são ciclos de desenvolvimento com tempo fixo (normalmente, duram de 2 a 4 semanas). Esta figura mostra um sprint completo do Scrum.

    No Scrum (e em outros métodos ágeis), temos um backlog do produto, que é uma lista de todas as funcionalidades planejadas para entrar no sistema. Cada funcionalidade é representada por um “user story”. Um user storie é uma caracteristica ou funcionalidade do sistema, descrita do ponto de vista do usuário (para quem não conhece um user story, vamos mostrar depois como ele é).

    Esse backlog é ordenado de acordo com o valor que cada funcionalidade agrega ao produto, de forma que as user stories mais importantes serão desenvolvidas primeiro.

    Desse backlog, são retiradas as funcionalidades a ser desenvolvidas no próximo sprint. No final desse sprint, temos uma parte do produto funcional, potencialmente pronta. Então, começa-se outro sprint.

    Costuma-se dizer que o processo de desenvolvimento ágil é iterativo. Realmente, é um ciclo que se repete várias vezes, mas o valor agregado ao produto se dá de forma incremental.
  • Fazendo um paralelo com a criação de uma obra de arte, a abordagem mostrada é mais semelhante com essa figura.

    Nela, o artista tem uma visão completa do resultado final e pinta bloquinho por bloquinho da tela.

    O problema de desenvolvermos produtos assim é que, o risco de se criar um “frankenstein” é muito grande. É o que chamamos de “efeito puxadinho”, em que a cada nova funcionalidade agregada, é necessária uma adaptação na interface. O resultado final não é legal.
  • O que a gente sugere é fazer uma pequena adaptação na forma de lidar com o backlog do produto (a lista de funcionalidades que ele terá), de forma a tornar o processo mais próximo à forma que um artista produz uma obra na realidade.

    No início do processo se tem uma idéia vaga do que se pretende construir, então criamos um esboço, que vai evoluindo em nível de detalhes durante o tempo.

    Essa abordagem permite que se tenha uma visão geral do produto final e que se faça “correções no percurso” de forma mais fácil.
  • O story mapping é uma técnica colaborativa que ajuda a identificar as funcionalidades de maior valor e ordená-las de forma a criar uma estrutura lógica que vai permitir entregar um sistema que seja o mais útil possível, desde o primeiro release, mas mantendo a abordagem iterativa e incremental do desenvolvimento ágil.

    Essa técnica, criada por um cara chamado Jeff Patton, que vem estudando as formas de aproximar as metodologias ágeis do processo de design centrado no usuário.
  • A equipe inteira deve participar. A idéia é que cada membro contribua com o conhecimento e a visão que tem do produto e se chegue num consenso. Cada um entende um aspecto diferente do produto. Designer=interface, usuários. Marketing=necessidades dos usuários. Negócio=retorno de investimento. Desenvolvedor=possibilidades, restrições técnicas, etc...
  • Somente citar, iremos explicar detalhadamente quando começar o workshop
  • E vocês o que acharam?
  • E vocês o que acharam?
  • E vocês o que acharam?
  • E vocês o que acharam?
  • E vocês o que acharam?
  • E vocês o que acharam?
  • Explicar que o story mapping ajuda a demarcar pontos para testes mais completos com usuários
  • Pra quem não conhece o teste de usabilidade É... e acontece assim assim assado
  • Tem, também, o teste menos formal
  • E vocês o que acharam?
  • E vocês o que acharam?
  • E vocês o que acharam?
  • O legal é que, da mesma forma que qualquer um pode cozinhar, qualquer um pode realizar testes de usabilidade com um pouco de prática.

    Mas, mesmo sabendo cozinhar, eventualmente você vai a um restaurante. E isso acontece por uma série de motivos. Da mesma forma, em alguns casos, ainda é recomendado que um especialista externo realize avaliação e pesquisa no seu produto.
  • Ninguém morre de fome se tem um miojo por perto

    Qualquer teste é melhor que nenhum teste
    Teste o máximo possível e teste após modificar o produto
    Que começa a cozinhar, inicia fazendo “comida ruim”
  • Alguém do público-alvo é
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto
    Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  • No nosso site vocês vão encontrar nossos dados de contato. Nosso twitter é @latitude14. Se quiserem conversar mais conosco sobre esses assuntos ou qualquer outro relacionado a experiência do usuário e design de aplicações e produtos interativos, estamos aqui na Campus Party até hoje à noite.
  • Planejamento de releases e usabilidade de sistemas interativos

    1. 1. Planejamento de releases e usabilidade de sistemas interativos Fabrício Marchezini e Leandro Alves
    2. 2. Quem somos • Sócios da Latitude14 ‣ latitude14.com.br e @latitude14 • Mentores da Aceleradora @aceleradora • Representantes da IxDA BH @ixdabh • Coordenadores do Dia Mundial da Usabilidade em Belo Horizonte ‣ diamundialdausabilidade.com.br
    3. 3. Story mapping Técnica colaborativa que auxilia na priorização de funcionalidades para planejamento de releases
    4. 4. Quem deve participar? Negócios Marketing Designers Desenvolvedores Cliente Usuários fonte: http://www.selfishprogramming.com/2008/10/
    5. 5. Etapas 1. Listar funcionalidades 2. Escrever em cartões 3. Ordenar em fluxo de tarefas 4. Ajustar posição quanto à criticidade 5. Agrupar por atividades macros 6. Marcar o primeiro release
    6. 6. Passo 1 Brainstorming: faça uma lista de possíveis features do seu sistema • Mantenha o ponto de vista de quem vai usar o sistema • Cada item deve começar com um verbo • Esqueça detalhes de implementação
    7. 7. Passo 1 • Ex.: software de controle de vendas ‣ Fazer pedido ao fornecedor ‣ Receber pedido do fornecedor ‣ Gerar etiquetas para itens recebidos ‣ Vender produtos ‣ Devolver e reembolsar produtos ‣ Analisar vendas
    8. 8. Passo 1 • Escreva cada item em um cartão diferente • “Eu, como usuário x, preciso .... no sistema” • Deixe espaço para outros detalhes Fazer pedido ao fornecedor
    9. 9. Passo 2 • Adicione detalhes importantes: ‣ Usuários (profissão, cargo, papel desempenhado) ‣ Frequência de uso (muito, pouco, raro ou diariamente, semanalmente etc.) ‣ Valor (valor para o negócio. ROI) Fazer pedido ao fornecedor (comprador) Frequência: semanalmente Valor: médio
    10. 10. Passo 3 • Ordene as cartas em uma sequência lógica de tarefas ‣ O objetivo é contar uma história de como o sistema funciona ‣ Sobreponha os cartões que aconteçam no mesmo tempo
    11. 11. Fazer pedido ao Receber pedido do Gerar etiqueta para os fornecedor Vender produto Analisar vendas vendedor produtos recebidos (comprador) (consultor de vendas) (analista de vendas) (controlador de estoque) (controlador de estoque) Frequência: Frequência: diário Frequência: mensal Frequência: diário Frequência: diário semanalmente Valor: alto Valor: alto Valor: alto Valor: médio Valor: médio Devolver e reembolsar (consultor de vendas) Frequência: diário Valor: médio sequência de uso
    12. 12. Passo 4 • Ajustar conforme criticidade (verticalmente) ‣ Coloque acima as cartas mais críticas e mais frequentemente usadas pelos usuários. ‣ Discuta com a equipe o quão crítica cada funcionalidade é para o negócio
    13. 13. muito usado Necessidade Receber pedido do Vender produto vendedor (consultor de vendas) (controlador de estoque) Frequência: diário Frequência: diário Valor: alto Valor: alto Fazer pedido ao Gerar etiqueta para os fornecedor Devolver e reembolsar Analisar vendas produtos recebidos (comprador) (consultor de vendas) (analista de vendas) (controlador de estoque) Frequência: Frequência: diário Frequência: mensal Frequência: diário semanalmente Valor: médio Valor: alto Valor: médio Valor: médio raramente usado sequência de uso
    14. 14. Passo 5 • Marque as quebras no fluxo ‣ Discuta onde há quebras no modelo ‣ Pode ser uma mudança de usuário, regras de negócio ou processo ‣ Divida verticalmente as quebras e dê um nome ‣ Cada grupo representa as atividades que as pessoas realizam no sistema
    15. 15. muito usado compra recebimento Venda Análise Necessidade Receber pedido do Vender produto vendedor (consultor de vendas) (controlador de estoque) Frequência: diário Frequência: diário Valor: alto Valor: alto Fazer pedido ao Gerar etiqueta para os fornecedor Devolver e reembolsar Analisar vendas produtos recebidos (comprador) (consultor de vendas) (analista de vendas) (controlador de estoque) Frequência: Frequência: diário Frequência: mensal Frequência: diário semanalmente Valor: médio Valor: alto Valor: médio Valor: médio raramente usado sequência de uso
    16. 16. Passo 6 • Marcar primeiro release ‣ Deve ser o menor número de funcionalidades úteis para os usuários e o contexto do negócio ‣ É o primeiro release mas não necessariamente o primeiro a ser público
    17. 17. muito usado compra recebimento Venda Análise Necessidade Receber pedido do Vender produto vendedor (consultor de vendas) (controlador de estoque) Frequência: diário Frequência: diário Valor: alto Valor: alto Fazer pedido ao Gerar etiqueta para os fornecedor produtos recebidos Devolver e reembolsar Analisar vendas (comprador) (controlador de estoque) (consultor de vendas) (analista de vendas) Frequência: Frequência: diário Frequência: diário Frequência: mensal semanalmente Valor: médio Valor: médio Valor: alto Valor: médio raramente usado sequência de uso
    18. 18. Passo 7 • Estime o tempo de desenvolvimento ‣ Peça a equipe de desenvolvimento que estime o tempo para cada cartão (em dias, horas, semanas etc.)
    19. 19. Passo 8 • Reparta o bolo: programe outros releases ‣ No final você poderá ver quantos releases serão necessários e quais funcionalidades conterá em cada um
    20. 20. Release 1 Release 2 Release 3 Release 4
    21. 21. Vantagens do story map • A primeira versão tem somente o que é mais útil e tem maior valor de negócio • Facilita ver as relações de dependência entre as funcionalidades • Ajuda a formar a “visão do todo” • Facilita a comunicação interna • Gera rápido retorno • Reduz risco
    22. 22. E onde entra a usabilidade nessa história?
    23. 23. Porque testar? • Se você quer um produto realmente bom, teste! • Insights para tomada de decisão • Conhecer melhor quem usa(rá) o sistema
    24. 24. “Anyone can cook” Chef Gusteau
    25. 25. Mesmo que seja um miojo...
    26. 26. Ingredientes • Computador • Usuário • Tarefas • Condutor e observador • Bloco de notas
    27. 27. Modo de preparo • Planejamento • Recrutamento • Realização • Análise de resultados
    28. 28. Planejamento • Quem vou recrutar? • O que quero descobrir/confirmar? ‣ Quais tarefas testar, para responder esta pergunta? • Onde e quando será o teste? • Como guiar o teste?
    29. 29. Realização • Não diga o que o usuário deve fazer • Observe reações verbais e gestuais • Deixe o participante confortável • Peça para ele “pensar alto” • Grave a interação e o áudio para análise futura • Um teste deve durar no máximo uma hora • 3 x 5 > 1 x 15
    30. 30. Referências • Jeff Patton – http://agileproductdesign • Livro Não me faça pensar – Steve Krug
    31. 31. latitude14.com.br @latitude14

    ×