SlideShare uma empresa Scribd logo
1 de 37
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
• Representantes da IxDA BH @ixdabh
• Coordenadores do Dia Mundial da
  Usabilidade em Belo Horizonte
 ‣   diamundialdausabilidade.com.br
Story mapping
Técnica colaborativa que
auxilia na priorização de
funcionalidades para
planejamento de releases
Quem deve participar?

                                                   Negócios
                                                   Marketing
                                                   Designers
                                                   Desenvolvedores
                                                   Cliente
                                                   Usuários




fonte: http://www.selfishprogramming.com/2008/10/
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
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
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
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
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
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
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
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
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
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
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
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
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
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.)
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
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 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
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 quem usa(rá) o sistema
“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 pergunta?
•   Onde e quando será o teste?
•   Como guiar o teste?
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
Referências
•   Jeff Patton – http://agileproductdesign

•   Livro Não me faça pensar – Steve Krug
latitude14.com.br   @latitude14

Mais conteúdo relacionado

Semelhante a Planejamento de releases de sistemas interativos com story mapping

Treinamento - Coordenador de Produto Imobiliário
Treinamento - Coordenador de Produto ImobiliárioTreinamento - Coordenador de Produto Imobiliário
Treinamento - Coordenador de Produto ImobiliárioMichel Moreira
 
Apresentação do caso Sieve - Rocket InternetA
Apresentação do caso Sieve - Rocket InternetAApresentação do caso Sieve - Rocket InternetA
Apresentação do caso Sieve - Rocket InternetAE-Commerce Brasil
 
Apresentação do caso Sieve Rocket
Apresentação do caso Sieve RocketApresentação do caso Sieve Rocket
Apresentação do caso Sieve RocketE-commerce Brasil
 
Palestra ecommerce aumento_conversao_2012
Palestra ecommerce aumento_conversao_2012Palestra ecommerce aumento_conversao_2012
Palestra ecommerce aumento_conversao_2012fschimidt
 
Apresentação JBS-Friboi - 3T09
Apresentação JBS-Friboi - 3T09Apresentação JBS-Friboi - 3T09
Apresentação JBS-Friboi - 3T09Miguel Cavalcanti
 
Apresentação Merchandising
Apresentação MerchandisingApresentação Merchandising
Apresentação MerchandisingAdriano Valadão
 
Apresentacao Jbs 3 T09[1]
Apresentacao  Jbs 3 T09[1]Apresentacao  Jbs 3 T09[1]
Apresentacao Jbs 3 T09[1]BeefPoint
 
Avantare Como Transformar Numeros Em Acao
Avantare   Como Transformar Numeros Em AcaoAvantare   Como Transformar Numeros Em Acao
Avantare Como Transformar Numeros Em AcaoMarcos Giuntini
 
Gestao de compras em Livrarias_Completo; Distribuidora de Livros
Gestao de compras em Livrarias_Completo; Distribuidora de LivrosGestao de compras em Livrarias_Completo; Distribuidora de Livros
Gestao de compras em Livrarias_Completo; Distribuidora de LivrosGerson Ramos
 
JBS - Apresentacao Resultados 2 T09
JBS - Apresentacao Resultados 2 T09JBS - Apresentacao Resultados 2 T09
JBS - Apresentacao Resultados 2 T09BeefPoint
 
Apresentação dos Resultados do 2T09
Apresentação dos Resultados do 2T09Apresentação dos Resultados do 2T09
Apresentação dos Resultados do 2T09JBS RI
 
Qualivar apresentação institucional
Qualivar   apresentação institucionalQualivar   apresentação institucional
Qualivar apresentação institucionalRicardo Bicov
 
Gestão Financeira Masdar
Gestão Financeira MasdarGestão Financeira Masdar
Gestão Financeira Masdarrazevedolima
 
Competitividade (Total) em Vendas
Competitividade (Total) em VendasCompetitividade (Total) em Vendas
Competitividade (Total) em VendasPositioning
 

Semelhante a Planejamento de releases de sistemas interativos com story mapping (20)

Treinamento - Coordenador de Produto Imobiliário
Treinamento - Coordenador de Produto ImobiliárioTreinamento - Coordenador de Produto Imobiliário
Treinamento - Coordenador de Produto Imobiliário
 
Apresentação do caso Sieve - Rocket InternetA
Apresentação do caso Sieve - Rocket InternetAApresentação do caso Sieve - Rocket InternetA
Apresentação do caso Sieve - Rocket InternetA
 
Apresentação do caso Sieve Rocket
Apresentação do caso Sieve RocketApresentação do caso Sieve Rocket
Apresentação do caso Sieve Rocket
 
Palestra ecommerce aumento_conversao_2012
Palestra ecommerce aumento_conversao_2012Palestra ecommerce aumento_conversao_2012
Palestra ecommerce aumento_conversao_2012
 
Apresentação JBS-Friboi - 3T09
Apresentação JBS-Friboi - 3T09Apresentação JBS-Friboi - 3T09
Apresentação JBS-Friboi - 3T09
 
Apresentação Merchandising
Apresentação MerchandisingApresentação Merchandising
Apresentação Merchandising
 
Introducao canvas
Introducao canvasIntroducao canvas
Introducao canvas
 
Introdução ao business model canvas
Introdução ao business model canvasIntrodução ao business model canvas
Introdução ao business model canvas
 
Apresentacao Jbs 3 T09[1]
Apresentacao  Jbs 3 T09[1]Apresentacao  Jbs 3 T09[1]
Apresentacao Jbs 3 T09[1]
 
Avantare Como Transformar Numeros Em Acao
Avantare   Como Transformar Numeros Em AcaoAvantare   Como Transformar Numeros Em Acao
Avantare Como Transformar Numeros Em Acao
 
Gestao de compras em Livrarias_Completo; Distribuidora de Livros
Gestao de compras em Livrarias_Completo; Distribuidora de LivrosGestao de compras em Livrarias_Completo; Distribuidora de Livros
Gestao de compras em Livrarias_Completo; Distribuidora de Livros
 
JBS - Apresentacao Resultados 2 T09
JBS - Apresentacao Resultados 2 T09JBS - Apresentacao Resultados 2 T09
JBS - Apresentacao Resultados 2 T09
 
Apresentação dos Resultados do 2T09
Apresentação dos Resultados do 2T09Apresentação dos Resultados do 2T09
Apresentação dos Resultados do 2T09
 
P de ponto 2012_01
P de ponto 2012_01P de ponto 2012_01
P de ponto 2012_01
 
Vendas formação gerenciamento_equipe_gestão
Vendas formação gerenciamento_equipe_gestãoVendas formação gerenciamento_equipe_gestão
Vendas formação gerenciamento_equipe_gestão
 
Criação de negócios inovadores
Criação de negócios inovadoresCriação de negócios inovadores
Criação de negócios inovadores
 
Qualivar apresentação institucional
Qualivar   apresentação institucionalQualivar   apresentação institucional
Qualivar apresentação institucional
 
Nisher
NisherNisher
Nisher
 
Gestão Financeira Masdar
Gestão Financeira MasdarGestão Financeira Masdar
Gestão Financeira Masdar
 
Competitividade (Total) em Vendas
Competitividade (Total) em VendasCompetitividade (Total) em Vendas
Competitividade (Total) em Vendas
 

Planejamento de releases de sistemas interativos com story mapping

  • 1. Planejamento de releases e usabilidade de sistemas interativos Fabrício Marchezini e Leandro Alves
  • 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.
  • 4.
  • 5.
  • 6. Story mapping Técnica colaborativa que auxilia na priorização de funcionalidades para planejamento de releases
  • 7. Quem deve participar? Negócios Marketing Designers Desenvolvedores Cliente Usuários fonte: http://www.selfishprogramming.com/2008/10/
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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.)
  • 22. 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
  • 23.
  • 25. 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
  • 26. E onde entra a usabilidade nessa história?
  • 27.
  • 28.
  • 29. Porque testar? • Se você quer um produto realmente bom, teste! • Insights para tomada de decisão • Conhecer melhor quem usa(rá) o sistema
  • 30. “Anyone can cook” Chef Gusteau
  • 31. Mesmo que seja um miojo...
  • 32. Ingredientes • Computador • Usuário • Tarefas • Condutor e observador • Bloco de notas
  • 33. Modo de preparo • Planejamento • Recrutamento • Realização • Análise de resultados
  • 34. 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?
  • 35. 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
  • 36. Referências • Jeff Patton – http://agileproductdesign • Livro Não me faça pensar – Steve Krug
  • 37. latitude14.com.br @latitude14

Notas do Editor

  1. 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.
  2. Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
  3. Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
  4. Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
  5. Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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...
  12. Somente citar, iremos explicar detalhadamente quando começar o workshop
  13. E vocês o que acharam?
  14. E vocês o que acharam?
  15. E vocês o que acharam?
  16. E vocês o que acharam?
  17. E vocês o que acharam?
  18. E vocês o que acharam?
  19. Explicar que o story mapping ajuda a demarcar pontos para testes mais completos com usuários
  20. Pra quem não conhece o teste de usabilidade É... e acontece assim assim assado
  21. Tem, também, o teste menos formal
  22. E vocês o que acharam?
  23. E vocês o que acharam?
  24. E vocês o que acharam?
  25. 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.
  26. 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”
  27. Alguém do público-alvo é Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  28. Alguém do público-alvo é Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  29. Alguém do público-alvo é Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  30. Alguém do público-alvo é Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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
  37. 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
  38. 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
  39. 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
  40. 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
  41. 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
  42. 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
  43. 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.