(31 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 45: Linha 45:
* Exemplos:
* Exemplos:
** nubank, Uber, aibnb, tinder, amazon, Spotify
** nubank, Uber, aibnb, tinder, amazon, Spotify
[[Arquivo:Companies.jpg]]
** O exemplo do nuBank é ótimo. Além de ter toda uma linguagem visual de aplicativo, de site, muito bem definido e muito claro, com usabilidade muito boa, eles tem um atendimento diferenciado, rápido e diferente de todos os outros. Pode ser muito simples, mas nenhum outro banco, faz ou fez algo desse tipo. Observaram a oportunidade e atacaram isso. Hoje é um diferencial.
** O exemplo do nuBank é ótimo. Além de ter toda uma linguagem visual de aplicativo, de site, muito bem definido e muito claro, com usabilidade muito boa, eles tem um atendimento diferenciado, rápido e diferente de todos os outros. Pode ser muito simples, mas nenhum outro banco, faz ou fez algo desse tipo. Observaram a oportunidade e atacaram isso. Hoje é um diferencial.
* Post rodando na Internet:
* Post rodando na Internet:
** [[Arquivo:nubank-post.jpg]]
** [[Arquivo:nubank-post.jpg]]
* "A experiência do usuário está se tornando mais importante que o preço."
* "Ela determinará o sucesso ou o fracasso do seu negócio."
= De quem é a responsabilidade? =
<br>
* Quem deve se preocupar com a experiência do usuário?
** A partir do momento que seu cliente tem um contato com seu produto ou serviço ele terá uma experiência
** Que pode ser boa ou ruim
** Isso vai fazer ele tomar uma decisão futura, definir sua fidelidade
** A responsabilidade do Ux não é da equipe de design e deve estar no mindset de toda a empresa
UX - mindset
* Não importa se é um email, se é um site, se é um email marketing, se é um telefonema ou um presencial
** Todo o contato leva a uma experiência
** Se eu tenho um email mal escrito, um formulário com campos jogados, se tenho um texto desalinhado, um site muito mal desenhado, se quando o cliente vai na empresa, ninguém dá bom dia, ele fica desapontado
* Google - 3 princípios básicos:
** 1) Encante-me
** 2) Simplifique minha vida
** 3) Me faça sentir bem
* Prática:
** Como ajudar a melhorar a experiência do usuário?
** Desenvolvedores:
*** Exemplo: diminuiu o tempo de carregamento da página (usabilidade, acessibilidade)
*** O desenvolvedor pode ser mais crítico e sempre buscar feedback
*** Dar ideias e ser mais participativo
** Comercial:
*** Como está a abordagem do cliente?
*** Está sendo muito formal ou está descolado?
*** Estou levando alguma apresentação?
*** Se sim, qual a qualidade deste material?
*** Como minha apresentação está estruturada?
*** Qual a imagem que estou deixando da empresa para ele?
** Atendimento:
*** Como está sendo o atendimento?
*** Consigo atender de uma maneira melhor, diferenciada?
*** Estou resolvendo realmente o problema do cliente?
*** O cara do atendimento deve repassar informações sobre este cliente pois ele conhece bem
<br>
= Personas =
<br>
* Nesta fase precisamos conhecer bem os nossos clientes
** Quais são seus problemas?
** Quais são suas expectativas?
** Quais são suas necessidades?
* Se a gente entende o nosso público alvo, poderemos descobrir oportunidades, ou seja, produtos ou serviços que não existem ou algum que possamos melhorar
* A ferramenta Persona é usada em um monte de metodologias. Em UX usamos também como em DT
* O que são Personas?
** São personagens fictícios que representam um grupo de usuários ou clientes
** Numa persona eu tenho nome, idades, quais são os hábitos, se tem família, se tem tempo, estilo de vida, carro que anda, ...
** Não é cada pessoa é uma persona
* O que esta ferramenta está fazendo em um processo de UX?
** PAra ter uma boa experiência do usuário preciso fazer um design centrado no usuário
* Vantagens:
** Fica mais fácil dimensionar os esforços
** Conhece-se bem o público
** Toda a empresa vai conhecer as personas
** Quando se cria é melhor imprimir e pregar na parede para que todos vejam
* Como fazer essas personas?
** Sem achismos, sem chutes!
* Jeito certo:
** Pesquisas etnográficas
** Entrevistas
<br>
= Criação de Personas =
<br>
* Para quem estou criando meu produto ou serviço?
* Quais são suas metas e quais são os grupos específicos do meu público
* Pode-se compilar tudo o que se sabe numa planilha tendo pessoas que conhecem bem o píblico
* Itens básicos:
** Profissão
** Dispositivos
** Tempo
** Objetivos
** Etc
*** Depois da tabela atualizada poderemos notar alguns padrões
*** Pode-se enxergar melhor o que eles tem em comum e o que tem de diferente
* Agora é encontrar pessoas que correspondam a estes padrões
** Pode-se achar no BD de clientes ou por recrutamento, conversas com amigos, etc
* Feito isso, é conversar diretamente com eles
** Aprende-se muito com eles
** Promove-se a empatia
** Entende o que eles pensam
** Eles conhecerão quem está criando produtos ou serviços que irão ajudar eles
** O melhor dos mundos é a conversa presencial, olho no olho
* Planos:
** Plano A: Face to Face
** Plano B: Vídeoconferência
** Durante a entrevista tem alguns pontos sobre personalidade que podem ser observados e que podem ser relevantes para seu produto ou serviço
* Quando se consegue pegar estes pontos de personalidade a persona fica mais realista
* Depois dessas conversas, fica bem mais claro como estas pessoas são
* Próximo passo:
** Voltar na planilha e colocar os dados
** Incluir novas colunas:
*** Como é o escritório dessa pessoa, qual o Sw que ela usa, quais os hábitos, quais são os hobbies, os hábitos, estilo de vida
** Durante o preenchimento pode-se encontrar duas ou mais personas que possuem a mesma característica
*** Neste caso, faz-se uma combinação das personas gerando apenas uma
* O processo é iterativo, o que era certo no começo pode não ser mais
* Agora que temos a planilha mais completa e lapidada podemos ir para a representação
** Pode ser uma foto, um ícone, uma ilustração, um nome, cada uma ficando diferente da outra
* Feito isso, imprime-se bem grande, cola na parede para que todos possam olhar
* Objetivo:
** Criar um entendimento compartilhado. Todas as áreas devem conhecer muito bem estas personas
<br>
= Heurísticas de Usabilidade =
<br>
* Usabilidade é uma das área mais envolvidas com a experiência do usuário
* Jacob Nielsen: um dos pais da usabilidade e escreveu 10 itens para avaliação da usabilidade e vem com o intuito de evitar erros comuns
* A usabilidade pode ser fundamental para uma boa experiência do usuário
<br>
== #1 - Visibilidade do status do sistema ==
<br>
* Feedback
<br>
* Manter o usuário sempre informado do que está acontecendo
* Está carregando?
* Está buscando?
* O usuário precisa saber o que está acontecendo facilmente
* Barra tempo ou de loading quando estiver fazendo uploading
* Twitter: criando um novo usuário
** Colocou o endereço e quando estiver digitando algo errado, ele retorna inválido
** Antes de dar Post ele já mostra que o campo está errado
** É complicado quando se preenche alguns dados, envia e retorna um erro posteriormente
* Se começamos a dar feedback em tempo real, o usuário se sente mais confiante na aplicação
* Exemplo:
** Elevador com indicador de peso. Se estiver no vermelho, o usuário não utiliza o serviço
* O usuário precisa conhecer o status da aplicação
<br>
== #2 - Compatibilidade do sistema com o mundo real ==
<br>
* Falar a linguagem do usuário
<br>
* FAlar a língua do usuário
* Toda a parte de linguagem deve ser a que ele está familiarizado
* Não adianta usar termos técnicos que o usuário não conhece
* TEmos que adequar a parte de ícones, de cores, de mensagens ao modelo mental do usuário
* Exemplos:
** Erro em tempo de execução: Deseja depurá-lo?
** Erro de chamada. Tentar chamar novamente. Código do motivo 3
<br>
== #3 - Liberdade de ações para o usuário ==
<br>
* Não restringir o usuário a nada
* Dar possibilidade para ele entrar e sair da ação quando quiser
* Exemplo:
** Caso esteja fazendo um download tem a barra  de progresso e não quero mais, posso abortar
** Fiz um post, publiquei e me arrependi e quero deletar
* O produto em questão não pode me obrigar a nada
<br>
== #4 - Consistência ==
<br>
* Utilize sempre a mesma linguagem
* A porta que entra é a porta que sai
* As funções que possuem a mesma ação devem ser sempre tratadas da mesma forma
* Exemplo:
** Não utilize ícones diferentes para levar ao mesmo destino. Salvar: uma hora é disquete ou outra é check da cor verde
** Em uma tela colocou o botão Cancelar e Excluir. Em outra tela, no mesmo sistema, e a ordem foi trocada.
<br>
== #5 - Prevenções de erros ==
<br>
* Evitar situações de erro
* Devemos conhecer muito bem as situações que podem provocar
* Na hora de projetar a interface tem que fazer o máximo para que o usuário não erre
* Tem que estar um passo a frente do usuário sempre
Exemplo:
** Começou a digitar "user exper" e o sistema autocompletou a frase
** Mesmo se o usuário escrever errado ele traz embaixo a sugestão
** Outro exemplo:
** Uma tabela com ações, o usuário pode teclar sem querer
** Pode-se perguntar: "Usuário, tem certeza?"
** Dar a possibilidade do usuário voltar atrás
<br>
== #6 - Minimizar a sobrecarga de memória do usuário ==
<br>
* Deixar as coisas mais reconhecíveis
* Evite fazer o usuário pensar em como executar uma tarefa
* Devemos guiá-lo no uso da interface
* Exemplo:
** Mostrar BreadCrumb => historinha do João e Maria
** Com esse controle. o usuário sabe onde está
* Outro exemplo:
** Digitando uma fórmula, aparece na parte superior, a área de ferramentas do desenho
** É uma ajuda contextual e é indicado para o usuário
** Minimiza a memória
<br>
== #7 - Flexibilidade e eficiência de uso ==
<br>
* Temos que ter uma interface preparada para as pessoas leigas e avançadas
* Usuários mais avançados precisam de atalhos no teclado
* Interface deve oferecer opções para deixar a navagação mais agradável
* Teclas de atalho
* Teclas TAB para mudança de campo
<br>
== #8 - Visualmente simples  ==
<br>
* Estética e design minimalista
* Apresentar sempre a informação que o usuário precisa, nem mais, nem menos
* Não encha linguiça
<br>
== #9 - Desenvolva boas mensagens de erro ==
<br>
* Nunca jogue a culpa no usuário
* Se ele fizer algum erro, a aplicação tem que estar pronto para ajudá-lo
* Colocar mensagens com cores pode ser uma boa opção
<br>
== #10 - Ajuda e documentação ==
<br>
* O ideal é que um software nunca precise de documentação nenhuma mas se precisar deve estar disponível, bem fácil
* Exemplo: FAQs
* Outra opção, são os checks onlines mas deve-se tomar cuidado para não ser intrusivo
* Outro exemplo, é o iconezinho de help
<br>
= Análise Competitiva =
<br>
* Análise de concorrência:
** Análise extensa e bem detalhada de produtos concorrentes que já estão estabelecidos no mercado
** Análise de forma comparativa:
*** Análise e comparação de todos os players que estão no mercado
*** É ótimo porque ajuda a entender os padrões que são usados e o que é bom e o que é ruim
*** Identifica boas oportunidades
*** Permite inovar em alguns nichos.
* Principais benefícios:
** Conseguir enxergar melhor os concorrentes
** Onde eles estão atuando?
** O que eles estão fazendo?
** O que eles estão oferecendo?
** As pessoas estão reclamando?
** As pessoas estão amando o produto ou serviço?
** O que eu posso tirar de aprendizado?
* Nós mesmos podemos testar e tirar conclusões, julgamentos
* Outras pessoas podem ser chamadas para a avaliação
* Boa estratégia:
** Criar uma tabela onde podemos listar os pontos observados e os concorrentes, pontuando um por um
** Coloca-se um atributo e preenche de acordo com a observação
* Deve-se ter muito cuidado:
** Pode-se minimizar algum possível erro
** Identificar o que os outros estão fazendo bem
** Encontrar boas oportunidades
* Com essa tabela comparativa pode-se obter uma série de insights para o produto e consegue-se avaliar  melhor
* Depois que todo esse resultado está pronto, compartilha-se tudo com o resto da equipe, numa reunião, se possível imprimindo de foram bem visível, sem fazer julgamento, deixando o amor de lado fazendo uma análise bem competitiva.
<br>
= CardSorting =
<br>
* Problema
* Navegando em um site e não encontra aquilo que procuramos
* Às vezes, acontece por problemas de categorização
* CardSorting tem por objetivo definir quais serão os termos usados para categorizar os elementos
* Exemplo:
** Quais serão os itens de menu e como eles devem ser chamados
** Quais são os títulos?
* O objetivo é gerar uma taxonomia centrada no usuário
* Consegue gerar uma estrutura muito boa de navegação
* O usuário deverá gastar menos tempo para encontrar o que ele precisa
1o. Lista tudo o que seu produto vai ter
2o. Pega papéis quadriculados e escreve os itens
3o. Embaralha
4o. Prega na parede me lugares diferentes
5o. Seleciona um grupo de pessoas
6o. Conta o objetivo
7o. Pede para  cada um separar de maneira categorizada
8o. Batiza cada grupo com nomes
9o. Tira foto
10. Documente
11o. Será seu resultado final
<br>
= Wireframes =
<br>
* Wireframe é o esqueleto do seu projeto
** Aprimora o seu sistema/site/projeto
** Ecnonomia de tempo
** Você tem uma visão sobre a previsão de funcionalidades
** Agiliza o processo de criação
** Agiliza o desenvolvimento
<br>
= Como criar wireframes? =
<br>
== 1. Wireframe de baixa fidelidade ==
<br>
* Início do projeto podendo ser estágios do wireframe
* Basicamente compostos de linhas, quadrados, círculos, retangulos, triangulos com um fundo bem simples
* Pode ser desenhado à mão até em papel de pão
* Podemos faze-lo um software gráfico
== 2. Wireframe de alta fidelidade ==
<br>
* São mais incrementados possuem especificações
* Consegue dar uma visão bem geral do produto
* Dicas:
** 1. O que colocar no wireframe?
*** Pense em cada ação
*** Passo-a-passo
*** Faz parte do processo rabiscar, jogar fora e começar de novo
*** Pense em todas as funcionalidades, listando item a item
* 2. Estrutura do site:
** Comece por elementos comuns, básicos, por exemplo, cabeçalhos, rodapés, área de conteúdo, barra lateral, busca, etc
** Depois avançando, pensando no restante, botoões, elementos sobrepostos, checkbox ou botão rádio, etc
* 3. Conteúdo
** Como eu devo tratar o conteúdo do meu produto:
** Só para marcação, importante é arquitetura e formato
** Não é hora de gastar tempo pensando como será o texto
** Nos títulos, links, utilize termos genéricos
** Não perca tempo pensando em conteúdo real
** Sugestão: usar Lorem Ipsum e a SW Axure, Balsamiq, Sketch, Ps, AI
<br>
= Protótipos navegáveis =
<br>
* Permite rever os conceitos e receber feedbaks
* Ainda nos estágios iniciais
* Ganhos:
** Se você tiver isso, facilita muito na hora de demonstrar a ideia, o produto, o wireframe para sua equipe e ainda para os responsáveis pela aprovação
*** Seja por um pitch ou outro meio qualquer pois fica mais fácil o entendimento e o feedback
** Possibilitam fazer teste de usabilidade no início do processo
** Permite liberdade de experimentação pois pode fazer quantas alterações for preciso já que cada uma custa pouco
** Pode errar sem medo
** Não precisa ter conhecimentos avançados
* Pode-se usar protótipos navegáveis no seguinte fluxo:
** Wireframe -> protótipos navegáveis -> Feedbacks -> Ajustes -> Wireframe -> ...
*** Processo cíclico e quando chega no final temos uma ideia muito madura e ajuda o desenvolvedor a se orientar
** Não substitui a documentação mas ajuda no entendimento
* Ferramentas de prototipação:
** Proto.io, invision, marvelApp
*** Alguns permitem rodar no smartphone e ter uma demonstração bem fiel da IDE
* É importante chegar na fase de implementação do backend e frontend com tudo muito bem pensado e validado
* Testar e validar antes de começar uma implementação!!!
<br>
= Dicas de Teste de Usabilidade =
<br>
* Os testes devem ser feitos com personas que representem as pessoas que foram criadas
** Aquele será meu público, então tenho que testar com ele
** Design centro no usuário
** Não vale de jeito nenhum fazer com o colega da mesa ao lado
** Quem está envolvido no desenvolvimento do produto não é usuária
* Regras de ouro:
** Dicas (antes da entrevista:
*** Elabore um roteiro => liste quais as tarefas que o usuário deve fazer
*** Certifique se está tudo impresso antes de começar, vá preparado
*** Verifique e teste o equipamento de gravação
** Faça um teste piloto
*** Realize uma entrevista com um parceiro
*** Serve para validar a estrutura do teste, as perguntas e o tempo gasto
** Dicas (durante o teste):
*** Siga o roteiro. eventualmente sai do roteiro mas isto pode ser rico também
*** Explique o objetivo da entrevista
*** Deixe o entrevistado bem a vontade, falando sobre a importância da atividade de deixar claro que não está avaliando o que a pessoa sabe da tecnologia
** Feito isso, é iniciar a gravação
* Tente compilar tudo, assista o vídeo e enxergue as dificuldades do usuário para ter vários insights
* Ajuste as dificuldades e faça outro teste até chegar num ponto em que o usuário consiga usar tudo com facilidade
* Sugestão:
** Fazer o teste com no mínimo, 4 a 6 pessoas
<br>
= Contribuições =
<br>
* Todas as áreas podem contribuir para o desenvolvimento do UX
** TI
** Produto
** Usuário
** Comercial
** Marketing
* Usuário vai ter contato com este UX quando encontrar nosso serviço
* Para conseguirmos atingir uma boa experiência do usuário existem etapas:
** Descoberta
*** Pesquisa
*** Coleta de dados
*** Personas
*** Empatia
** Definição
*** Estrutura
*** Escopo
*** Fluxo do usuário
*** Wireframes
** Design
*** Layout
*** Design de interface
** Teste
*** Testes de usuabilidade
*** A!B test
*** KPI teste
** Entrega
*** Entrega do projeto
*** Compilar e entender os feedbacks
* Processo UX é incremental, não acaba nunca
* Dicas de livros:
** Não me faça pensar - Steve Krug
** Simplificando coisas que parecem complicadas - Steve Krug
** Design para a Internet - Felipe Memória
* A experiência do usuário é fator essencial para determinar o sucesso do produto
<br>
= Product Backlog e Sprint Backlog =
<br>
* Tudo o que se torna necessário no âmbito de desenvolvimento e lançamento de um produto de sucesso é representado pelo backlog do produto
* Caracteriza-se por uma lista com as devidas características, funções, tecnologias, melhoras apresentas e futuras correções para o produto futuro
* Em vários momentos de uma equipe podem surgir várias estórias numa Planning Poker ou na preparação do backlog
* Estas estórias devem ser transformadas em estórias funcionais sempre que possível pois o PO deve-se preocupar com estórias funcionais que representam funcionalidades do sistema
* Se pensarmos que uma estória de usuário é um requisito funcional da UML então estórias técnicas são os requisitos não-funcionais e estes não são responsabilidades do PO ou da pessoa de negócios
* O Product Backlog precisa de atenção e de cuidados contínuos afinal é dentro dele que estão todas as funcionalidades que o produto irá possuir
* Por isso, as reuniões de backlog (Grooming) foram criadas
** Através delas, o objetivo de garantir que o próprio backlog esteja sempre organizado pode ser cumprido
* A reunião de backlog Grooming também envolve:
** Agile Project Manager
** Alteração e novos itens
** Eliminação de itens
** Quebra de épicos
** Priorização
** Refinar os itens
** Avaliar estimativas
** Critérios de aceitação
** Organização, Ordenação, Limpeza
* Sprint Backlog:
** Consiste nas tarefas que o time executa para transformar itens do backlog de produto em um incremento pronto
** O Backlog da Sprint é todo o trabalho que o time identifica como necessário para alcançar a meta da sprint
** O time modifica o backlog da sprint no decorrer da sprint
* Figura
** Cada retangulo representa um estory ordenado pela importância
** A estória mais importante está no topo da lista
** O tamanho de cada retângulo representa o tamanho daquela estória, ou seja, o tempo estimado para o tamanho da estória
** A altura da linha azul representa a velolcidade estimada da equipe, ou seja, quantos pontos de estória a equipe acredita poder completar durante o próximo sprint
** O sprint backlog da direita é um pedaço das estórias do Product Backlog
** Ele representa a lisa de estórias que a equipe executará no sprint
** A equipe decide como as muitas estórias serão incluídas no sprint, não o PO ou qualquer outra pessoa
** Caso o PO queira que uma estória entre em um sprint onde ela ficou de fora como no caso da figura, ele terá duas opções:
*** Mudar o escopo de uma das outras estórias para que ela fique menor e então caiba
*** Ou então remover a estória C por exemplo para que a D entre
<br>
= Estimativas =
<br>
* Estimando tamanhos:
* O PO precisa de estimativas, este é um esforço cooperativo entre o PO e a equipe
* A equipe estima e o PO descreve os itens e descreve questões
** Dinâmica das estimativas:
*** Deixe a equipe fazer as estimativas
*** Não faça com que eles gastem tempo demais
*** Certifique-se de que eles tenham entendido que as estimativas de tempo são estimativas cruas, não compromissos
* Normalmente, o PO reune toda a equipe em uma sala, fornece algumas ilustrações e lhe diz que o objetivo da reunião é fazer uma estimativa de tempo para as 20 estórias mais importantes do Product Backlog
* Ele passa por cada estória uma vez e então deixa a equipe trabalhar
* O PO permanece na sala para responder perguntas e esclarecer o escopo de cada item
* Esta reunião deve ocorrer dentro de um intervalo de tempo fixo, caso contrário, as equipes tendem a gastar tempo demais estimando poucas estórias
* Planning Poker
** Para estimar o tempo das estórias contidas na sprint utiliza-se um baralho de 13 cartas
* Quando a estória for estimada, os membros, um a um, fazem a escolha de uma carta apresentando a estimativa do tempo da estória colocando-a virada para baixo sobre a mesa
* Logo após o processo ter sido concretizado as cartas são reveladas simultaneamente
* Este processo é realizado com o âmbito de que cada membro da equipe seja forçado a pensar por si só ao invés de ficar se baseando nas estimativas de outras pessoas
* O baralho é geralmente composto por cartas que possuem uma sequência de Fibonnaci, por exemplo, 0 0,5 1 2 3 5 8 13 21 34 e assim por diante e uma carta que possui um sinal de interrogação
* A escala de complexidade é baseada na sequência de Fibonnaci e cada participante do time que estiver comprometido recebe um conjunto de cartas sendo cada uma com um número de complexidade
* O grupo se reune geralmente na reunião de Sprint Planning e esclarece as estórias com o PO para depois estimar uma a uma
* SEguindo a ordem de sequência das estórias já priorizadas pelo PO
* Então o time conta até tres e cada um apresenta uma das cartas ao mesmo tempo e este é um momento importante pois um membro pode influenciar o outro na hora de mostra as cartas
* A rodada termina quando todos os jogadores entrarem em acordo
<br>
= Curso Presencial: UX - Experiência do Usuário =
<br>
* Instrutor:
** Rafael Siqueira
** rafael.hsiqueira@hotmail.com
<br>
* Persona:
** Luis Paulo
*** 28 anos, casado
*** tem uma filha de 10 anos, Maria Fernanda
*** Responsável pela implantação, instalação de serviços
*** Não tem grandes expectativas
<br>
* Problemas:
** Localização
** Assinatura
** Agendamento
** Liberação em condomínio
** Pesquisa de satisfação
<br>
* Como o time vai resolver problemas?
** Organize as ideias
** Anote todas
** Encoraje as ideias loucas (não existem ideias ruins)
** Construa sobre a ideia dos outros
<br>
* Ideias sugeridas:
** Todos
*** Portal de treinamento de instalaçao para o cliente
** Assinatura:
*** Canetinha Stylus (Galaxy Note)
** Localização:
*** Identificar o técnico mais próximo
*** Sistema agrupar OSs de produtos diferentes do mesmo cliente para o mesmo técnico
** Liberação de condomínio:
*** URA ligando para o condomínio fazendo um pré-cadastro
*** Uma credencial (crachá, transponder, biometria) para os principais condomínios da cidade
*** Antes do técnico sair a campo, o Atendimento deve ligar e já credencial o técnico no condomínio
** Agendamento:
*** Disparar um SMS para o cliente quando o técnico for sair
** Pesquisa de satisfação:
*** Preencher no momento do atendimento a pesquisa no Smartphone pelo cliente
<br>
* Ideias mais votadas:
** Todos
*** Portal de treinamento de instalaçao para o cliente
** Assinatura:
*** Canetinha Stylus (Galaxy Note)
** Localização:
*** Identificar o técnico mais próximo
** Liberação de condomínio:
*** URA ligando para o condomínio fazendo um pré-cadastro
*** Uma credencial (crachá, transponder, biometria) para os principais condomínios da cidade
*** Antes do técnico sair a campo, o Atendimento deve ligar e já credencial o técnico no condomínio
** Agendamento:
*** Disparar um SMS para o cliente quando o técnico for sair com exigência de resposta
** Pesquisa de satisfação:
*** Preencher no momento do atendimento a pesquisa no Smartphone pelo cliente
<br>
* Prototipação:
** Wireframes, não tem que ser uma obra de arte
** Todo mundo consegue fazer uma bolinha, um quadrado ou uma modelo básico qualquer
** Tente usar Mockups
** Ilustre sua ideia
** É hora de tirar o que está na sua cabeça e passar para o papel
<br>
* Aplicativo para usabilidade: POP
<br>

Edição atual tal como às 15h02min de 26 de agosto de 2016

  • Instrutor:
    • Rafael Siqueira


Objetivos


  • Apresentar metodologias, dicas e ferramentas para o usuário pegar a experiência de algum produto que já existe ou um novo produto para torná-lo excepcional


Conceitos de UX


  • O que não é UX?
    • UX não é Lay-out
    • Não teem que ser só digital
    • Não é interface
    • Não são funcionalidades
  • UX é a tradução literal do negócio
    • É a Experiência do Usuário
  • A experiência é constituída por:
    • Uma pessoa(Usuário) + Experiência positiva ou negativa
  • Exemplo:
    • Num site de ecommercce, compra-se um livro
    • A) Recebe uma pedra :(
    • B) Recebe um caixa convencional do Correios :|
    • C) Recebe uma embalagem personalizada, uma carta de agradecimentos e um cupom de 25% para as próximas compras :)


A importância do UX


  • Quando a gente observa, pesquisa e vivencia a vida do usuário conseguimos ter mais empatia com ele
  • Quando a gente tem mais empatia pela outra pessoa a gente consegue enxergar um monte de soluções baseada nos problemas
  • Empresa Alemã:
    • Repensou a embalagem de remédios. Obsservando como os clientes utilizavam aquela caixinha, a maioria das pessoas colocavam numa caixinha os remédios, as tampinhas ficavam pra cima e os rótulos para baixo levando dificuldade para os usuários. A ideia foi criar uma embalagem que colocasse a tampinha pra baixo e o rótulo para cima resolvendo um problema para o usuário. As caixinhas ficavam mais organizadas e de fácil identificação.
  • Don Norman:
    • "Tendemos a projetar nossa racionalidade e nossas crenças na racionalidade e nas crenças dos outros."

  • Empresa Heinz:
    • Antes pensavam primeiro no desenho do produto, numa embalagem convencional para catchup. Às vezes aconteciam acidentes explodindo ou saindo muito catchup. Aí resolveram inverter a embalagem e o conteúdo ficou pra baixo, a pessoa abriria a tampa e sairia facilmente. Essa é uma solução pensada e observadas através da experiência do usuário.
  • Hiper Sland (2014):
    • "A cada 1 dólar investido em UX você tem um retorno de 2 a 100 dólares."
    • Quando temos um serviço focado na experiência do usuário, conseguimos cobrar mais por isso
  • Exemplos:
    • nubank, Uber, aibnb, tinder, amazon, Spotify

    • O exemplo do nuBank é ótimo. Além de ter toda uma linguagem visual de aplicativo, de site, muito bem definido e muito claro, com usabilidade muito boa, eles tem um atendimento diferenciado, rápido e diferente de todos os outros. Pode ser muito simples, mas nenhum outro banco, faz ou fez algo desse tipo. Observaram a oportunidade e atacaram isso. Hoje é um diferencial.
  • Post rodando na Internet:
  • "A experiência do usuário está se tornando mais importante que o preço."
  • "Ela determinará o sucesso ou o fracasso do seu negócio."

De quem é a responsabilidade?


  • Quem deve se preocupar com a experiência do usuário?
    • A partir do momento que seu cliente tem um contato com seu produto ou serviço ele terá uma experiência
    • Que pode ser boa ou ruim
    • Isso vai fazer ele tomar uma decisão futura, definir sua fidelidade
    • A responsabilidade do Ux não é da equipe de design e deve estar no mindset de toda a empresa
UX - mindset
  • Não importa se é um email, se é um site, se é um email marketing, se é um telefonema ou um presencial
    • Todo o contato leva a uma experiência
    • Se eu tenho um email mal escrito, um formulário com campos jogados, se tenho um texto desalinhado, um site muito mal desenhado, se quando o cliente vai na empresa, ninguém dá bom dia, ele fica desapontado
  • Google - 3 princípios básicos:
    • 1) Encante-me
    • 2) Simplifique minha vida
    • 3) Me faça sentir bem
  • Prática:
    • Como ajudar a melhorar a experiência do usuário?
    • Desenvolvedores:
      • Exemplo: diminuiu o tempo de carregamento da página (usabilidade, acessibilidade)
      • O desenvolvedor pode ser mais crítico e sempre buscar feedback
      • Dar ideias e ser mais participativo
    • Comercial:
      • Como está a abordagem do cliente?
      • Está sendo muito formal ou está descolado?
      • Estou levando alguma apresentação?
      • Se sim, qual a qualidade deste material?
      • Como minha apresentação está estruturada?
      • Qual a imagem que estou deixando da empresa para ele?
    • Atendimento:
      • Como está sendo o atendimento?
      • Consigo atender de uma maneira melhor, diferenciada?
      • Estou resolvendo realmente o problema do cliente?
      • O cara do atendimento deve repassar informações sobre este cliente pois ele conhece bem


Personas


  • Nesta fase precisamos conhecer bem os nossos clientes
    • Quais são seus problemas?
    • Quais são suas expectativas?
    • Quais são suas necessidades?
  • Se a gente entende o nosso público alvo, poderemos descobrir oportunidades, ou seja, produtos ou serviços que não existem ou algum que possamos melhorar
  • A ferramenta Persona é usada em um monte de metodologias. Em UX usamos também como em DT
  • O que são Personas?
    • São personagens fictícios que representam um grupo de usuários ou clientes
    • Numa persona eu tenho nome, idades, quais são os hábitos, se tem família, se tem tempo, estilo de vida, carro que anda, ...
    • Não é cada pessoa é uma persona
  • O que esta ferramenta está fazendo em um processo de UX?
    • PAra ter uma boa experiência do usuário preciso fazer um design centrado no usuário
  • Vantagens:
    • Fica mais fácil dimensionar os esforços
    • Conhece-se bem o público
    • Toda a empresa vai conhecer as personas
    • Quando se cria é melhor imprimir e pregar na parede para que todos vejam
  • Como fazer essas personas?
    • Sem achismos, sem chutes!
  • Jeito certo:
    • Pesquisas etnográficas
    • Entrevistas


Criação de Personas


  • Para quem estou criando meu produto ou serviço?
  • Quais são suas metas e quais são os grupos específicos do meu público
  • Pode-se compilar tudo o que se sabe numa planilha tendo pessoas que conhecem bem o píblico
  • Itens básicos:
    • Profissão
    • Dispositivos
    • Tempo
    • Objetivos
    • Etc
      • Depois da tabela atualizada poderemos notar alguns padrões
      • Pode-se enxergar melhor o que eles tem em comum e o que tem de diferente
  • Agora é encontrar pessoas que correspondam a estes padrões
    • Pode-se achar no BD de clientes ou por recrutamento, conversas com amigos, etc
  • Feito isso, é conversar diretamente com eles
    • Aprende-se muito com eles
    • Promove-se a empatia
    • Entende o que eles pensam
    • Eles conhecerão quem está criando produtos ou serviços que irão ajudar eles
    • O melhor dos mundos é a conversa presencial, olho no olho
  • Planos:
    • Plano A: Face to Face
    • Plano B: Vídeoconferência
    • Durante a entrevista tem alguns pontos sobre personalidade que podem ser observados e que podem ser relevantes para seu produto ou serviço
  • Quando se consegue pegar estes pontos de personalidade a persona fica mais realista
  • Depois dessas conversas, fica bem mais claro como estas pessoas são
  • Próximo passo:
    • Voltar na planilha e colocar os dados
    • Incluir novas colunas:
      • Como é o escritório dessa pessoa, qual o Sw que ela usa, quais os hábitos, quais são os hobbies, os hábitos, estilo de vida
    • Durante o preenchimento pode-se encontrar duas ou mais personas que possuem a mesma característica
      • Neste caso, faz-se uma combinação das personas gerando apenas uma
  • O processo é iterativo, o que era certo no começo pode não ser mais
  • Agora que temos a planilha mais completa e lapidada podemos ir para a representação
    • Pode ser uma foto, um ícone, uma ilustração, um nome, cada uma ficando diferente da outra
  • Feito isso, imprime-se bem grande, cola na parede para que todos possam olhar
  • Objetivo:
    • Criar um entendimento compartilhado. Todas as áreas devem conhecer muito bem estas personas


Heurísticas de Usabilidade


  • Usabilidade é uma das área mais envolvidas com a experiência do usuário
  • Jacob Nielsen: um dos pais da usabilidade e escreveu 10 itens para avaliação da usabilidade e vem com o intuito de evitar erros comuns


  • A usabilidade pode ser fundamental para uma boa experiência do usuário


#1 - Visibilidade do status do sistema


  • Feedback


  • Manter o usuário sempre informado do que está acontecendo
  • Está carregando?
  • Está buscando?
  • O usuário precisa saber o que está acontecendo facilmente
  • Barra tempo ou de loading quando estiver fazendo uploading
  • Twitter: criando um novo usuário
    • Colocou o endereço e quando estiver digitando algo errado, ele retorna inválido
    • Antes de dar Post ele já mostra que o campo está errado
    • É complicado quando se preenche alguns dados, envia e retorna um erro posteriormente
  • Se começamos a dar feedback em tempo real, o usuário se sente mais confiante na aplicação
  • Exemplo:
    • Elevador com indicador de peso. Se estiver no vermelho, o usuário não utiliza o serviço
  • O usuário precisa conhecer o status da aplicação


#2 - Compatibilidade do sistema com o mundo real


  • Falar a linguagem do usuário



  • FAlar a língua do usuário
  • Toda a parte de linguagem deve ser a que ele está familiarizado
  • Não adianta usar termos técnicos que o usuário não conhece
  • TEmos que adequar a parte de ícones, de cores, de mensagens ao modelo mental do usuário
  • Exemplos:
    • Erro em tempo de execução: Deseja depurá-lo?
    • Erro de chamada. Tentar chamar novamente. Código do motivo 3


#3 - Liberdade de ações para o usuário


  • Não restringir o usuário a nada
  • Dar possibilidade para ele entrar e sair da ação quando quiser
  • Exemplo:
    • Caso esteja fazendo um download tem a barra de progresso e não quero mais, posso abortar
    • Fiz um post, publiquei e me arrependi e quero deletar
  • O produto em questão não pode me obrigar a nada


#4 - Consistência



  • Utilize sempre a mesma linguagem
  • A porta que entra é a porta que sai
  • As funções que possuem a mesma ação devem ser sempre tratadas da mesma forma
  • Exemplo:
    • Não utilize ícones diferentes para levar ao mesmo destino. Salvar: uma hora é disquete ou outra é check da cor verde
    • Em uma tela colocou o botão Cancelar e Excluir. Em outra tela, no mesmo sistema, e a ordem foi trocada.


#5 - Prevenções de erros


  • Evitar situações de erro
  • Devemos conhecer muito bem as situações que podem provocar
  • Na hora de projetar a interface tem que fazer o máximo para que o usuário não erre
  • Tem que estar um passo a frente do usuário sempre

Exemplo:

    • Começou a digitar "user exper" e o sistema autocompletou a frase
    • Mesmo se o usuário escrever errado ele traz embaixo a sugestão
    • Outro exemplo:
    • Uma tabela com ações, o usuário pode teclar sem querer
    • Pode-se perguntar: "Usuário, tem certeza?"
    • Dar a possibilidade do usuário voltar atrás



#6 - Minimizar a sobrecarga de memória do usuário


  • Deixar as coisas mais reconhecíveis
  • Evite fazer o usuário pensar em como executar uma tarefa
  • Devemos guiá-lo no uso da interface
  • Exemplo:
    • Mostrar BreadCrumb => historinha do João e Maria
    • Com esse controle. o usuário sabe onde está
  • Outro exemplo:
    • Digitando uma fórmula, aparece na parte superior, a área de ferramentas do desenho
    • É uma ajuda contextual e é indicado para o usuário
    • Minimiza a memória


#7 - Flexibilidade e eficiência de uso


  • Temos que ter uma interface preparada para as pessoas leigas e avançadas
  • Usuários mais avançados precisam de atalhos no teclado
  • Interface deve oferecer opções para deixar a navagação mais agradável
  • Teclas de atalho
  • Teclas TAB para mudança de campo


#8 - Visualmente simples


  • Estética e design minimalista
  • Apresentar sempre a informação que o usuário precisa, nem mais, nem menos
  • Não encha linguiça


#9 - Desenvolva boas mensagens de erro


  • Nunca jogue a culpa no usuário
  • Se ele fizer algum erro, a aplicação tem que estar pronto para ajudá-lo
  • Colocar mensagens com cores pode ser uma boa opção


#10 - Ajuda e documentação


  • O ideal é que um software nunca precise de documentação nenhuma mas se precisar deve estar disponível, bem fácil
  • Exemplo: FAQs
  • Outra opção, são os checks onlines mas deve-se tomar cuidado para não ser intrusivo
  • Outro exemplo, é o iconezinho de help


Análise Competitiva


  • Análise de concorrência:
    • Análise extensa e bem detalhada de produtos concorrentes que já estão estabelecidos no mercado
    • Análise de forma comparativa:
      • Análise e comparação de todos os players que estão no mercado
      • É ótimo porque ajuda a entender os padrões que são usados e o que é bom e o que é ruim
      • Identifica boas oportunidades
      • Permite inovar em alguns nichos.
  • Principais benefícios:
    • Conseguir enxergar melhor os concorrentes
    • Onde eles estão atuando?
    • O que eles estão fazendo?
    • O que eles estão oferecendo?
    • As pessoas estão reclamando?
    • As pessoas estão amando o produto ou serviço?
    • O que eu posso tirar de aprendizado?
  • Nós mesmos podemos testar e tirar conclusões, julgamentos
  • Outras pessoas podem ser chamadas para a avaliação
  • Boa estratégia:
    • Criar uma tabela onde podemos listar os pontos observados e os concorrentes, pontuando um por um
    • Coloca-se um atributo e preenche de acordo com a observação
  • Deve-se ter muito cuidado:
    • Pode-se minimizar algum possível erro
    • Identificar o que os outros estão fazendo bem
    • Encontrar boas oportunidades
  • Com essa tabela comparativa pode-se obter uma série de insights para o produto e consegue-se avaliar melhor
  • Depois que todo esse resultado está pronto, compartilha-se tudo com o resto da equipe, numa reunião, se possível imprimindo de foram bem visível, sem fazer julgamento, deixando o amor de lado fazendo uma análise bem competitiva.


CardSorting


  • Problema
  • Navegando em um site e não encontra aquilo que procuramos
  • Às vezes, acontece por problemas de categorização
  • CardSorting tem por objetivo definir quais serão os termos usados para categorizar os elementos
  • Exemplo:
    • Quais serão os itens de menu e como eles devem ser chamados
    • Quais são os títulos?
  • O objetivo é gerar uma taxonomia centrada no usuário
  • Consegue gerar uma estrutura muito boa de navegação
  • O usuário deverá gastar menos tempo para encontrar o que ele precisa

1o. Lista tudo o que seu produto vai ter 2o. Pega papéis quadriculados e escreve os itens 3o. Embaralha 4o. Prega na parede me lugares diferentes 5o. Seleciona um grupo de pessoas 6o. Conta o objetivo 7o. Pede para cada um separar de maneira categorizada 8o. Batiza cada grupo com nomes 9o. Tira foto 10. Documente 11o. Será seu resultado final

Wireframes


  • Wireframe é o esqueleto do seu projeto
    • Aprimora o seu sistema/site/projeto
    • Ecnonomia de tempo
    • Você tem uma visão sobre a previsão de funcionalidades
    • Agiliza o processo de criação
    • Agiliza o desenvolvimento


Como criar wireframes?


1. Wireframe de baixa fidelidade


  • Início do projeto podendo ser estágios do wireframe
  • Basicamente compostos de linhas, quadrados, círculos, retangulos, triangulos com um fundo bem simples
  • Pode ser desenhado à mão até em papel de pão
  • Podemos faze-lo um software gráfico

2. Wireframe de alta fidelidade


  • São mais incrementados possuem especificações
  • Consegue dar uma visão bem geral do produto
  • Dicas:
    • 1. O que colocar no wireframe?
      • Pense em cada ação
      • Passo-a-passo
      • Faz parte do processo rabiscar, jogar fora e começar de novo
      • Pense em todas as funcionalidades, listando item a item
  • 2. Estrutura do site:
    • Comece por elementos comuns, básicos, por exemplo, cabeçalhos, rodapés, área de conteúdo, barra lateral, busca, etc
    • Depois avançando, pensando no restante, botoões, elementos sobrepostos, checkbox ou botão rádio, etc
  • 3. Conteúdo
    • Como eu devo tratar o conteúdo do meu produto:
    • Só para marcação, importante é arquitetura e formato
    • Não é hora de gastar tempo pensando como será o texto
    • Nos títulos, links, utilize termos genéricos
    • Não perca tempo pensando em conteúdo real
    • Sugestão: usar Lorem Ipsum e a SW Axure, Balsamiq, Sketch, Ps, AI



Protótipos navegáveis


  • Permite rever os conceitos e receber feedbaks
  • Ainda nos estágios iniciais
  • Ganhos:
    • Se você tiver isso, facilita muito na hora de demonstrar a ideia, o produto, o wireframe para sua equipe e ainda para os responsáveis pela aprovação
      • Seja por um pitch ou outro meio qualquer pois fica mais fácil o entendimento e o feedback
    • Possibilitam fazer teste de usabilidade no início do processo
    • Permite liberdade de experimentação pois pode fazer quantas alterações for preciso já que cada uma custa pouco
    • Pode errar sem medo
    • Não precisa ter conhecimentos avançados
  • Pode-se usar protótipos navegáveis no seguinte fluxo:
    • Wireframe -> protótipos navegáveis -> Feedbacks -> Ajustes -> Wireframe -> ...
      • Processo cíclico e quando chega no final temos uma ideia muito madura e ajuda o desenvolvedor a se orientar
    • Não substitui a documentação mas ajuda no entendimento
  • Ferramentas de prototipação:
    • Proto.io, invision, marvelApp
      • Alguns permitem rodar no smartphone e ter uma demonstração bem fiel da IDE
  • É importante chegar na fase de implementação do backend e frontend com tudo muito bem pensado e validado
  • Testar e validar antes de começar uma implementação!!!


Dicas de Teste de Usabilidade


  • Os testes devem ser feitos com personas que representem as pessoas que foram criadas
    • Aquele será meu público, então tenho que testar com ele
    • Design centro no usuário
    • Não vale de jeito nenhum fazer com o colega da mesa ao lado
    • Quem está envolvido no desenvolvimento do produto não é usuária
  • Regras de ouro:
    • Dicas (antes da entrevista:
      • Elabore um roteiro => liste quais as tarefas que o usuário deve fazer
      • Certifique se está tudo impresso antes de começar, vá preparado
      • Verifique e teste o equipamento de gravação
    • Faça um teste piloto
      • Realize uma entrevista com um parceiro
      • Serve para validar a estrutura do teste, as perguntas e o tempo gasto
    • Dicas (durante o teste):
      • Siga o roteiro. eventualmente sai do roteiro mas isto pode ser rico também
      • Explique o objetivo da entrevista
      • Deixe o entrevistado bem a vontade, falando sobre a importância da atividade de deixar claro que não está avaliando o que a pessoa sabe da tecnologia
    • Feito isso, é iniciar a gravação
  • Tente compilar tudo, assista o vídeo e enxergue as dificuldades do usuário para ter vários insights
  • Ajuste as dificuldades e faça outro teste até chegar num ponto em que o usuário consiga usar tudo com facilidade
  • Sugestão:
    • Fazer o teste com no mínimo, 4 a 6 pessoas


Contribuições


  • Todas as áreas podem contribuir para o desenvolvimento do UX
    • TI
    • Produto
    • Usuário
    • Comercial
    • Marketing
  • Usuário vai ter contato com este UX quando encontrar nosso serviço
  • Para conseguirmos atingir uma boa experiência do usuário existem etapas:
    • Descoberta
      • Pesquisa
      • Coleta de dados
      • Personas
      • Empatia
    • Definição
      • Estrutura
      • Escopo
      • Fluxo do usuário
      • Wireframes
    • Design
      • Layout
      • Design de interface
    • Teste
      • Testes de usuabilidade
      • A!B test
      • KPI teste
    • Entrega
      • Entrega do projeto
      • Compilar e entender os feedbacks
  • Processo UX é incremental, não acaba nunca
  • Dicas de livros:
    • Não me faça pensar - Steve Krug
    • Simplificando coisas que parecem complicadas - Steve Krug
    • Design para a Internet - Felipe Memória
  • A experiência do usuário é fator essencial para determinar o sucesso do produto


Product Backlog e Sprint Backlog


  • Tudo o que se torna necessário no âmbito de desenvolvimento e lançamento de um produto de sucesso é representado pelo backlog do produto
  • Caracteriza-se por uma lista com as devidas características, funções, tecnologias, melhoras apresentas e futuras correções para o produto futuro
  • Em vários momentos de uma equipe podem surgir várias estórias numa Planning Poker ou na preparação do backlog
  • Estas estórias devem ser transformadas em estórias funcionais sempre que possível pois o PO deve-se preocupar com estórias funcionais que representam funcionalidades do sistema
  • Se pensarmos que uma estória de usuário é um requisito funcional da UML então estórias técnicas são os requisitos não-funcionais e estes não são responsabilidades do PO ou da pessoa de negócios
  • O Product Backlog precisa de atenção e de cuidados contínuos afinal é dentro dele que estão todas as funcionalidades que o produto irá possuir
  • Por isso, as reuniões de backlog (Grooming) foram criadas
    • Através delas, o objetivo de garantir que o próprio backlog esteja sempre organizado pode ser cumprido
  • A reunião de backlog Grooming também envolve:
    • Agile Project Manager
    • Alteração e novos itens
    • Eliminação de itens
    • Quebra de épicos
    • Priorização
    • Refinar os itens
    • Avaliar estimativas
    • Critérios de aceitação
    • Organização, Ordenação, Limpeza
  • Sprint Backlog:
    • Consiste nas tarefas que o time executa para transformar itens do backlog de produto em um incremento pronto
    • O Backlog da Sprint é todo o trabalho que o time identifica como necessário para alcançar a meta da sprint
    • O time modifica o backlog da sprint no decorrer da sprint
  • Figura
    • Cada retangulo representa um estory ordenado pela importância
    • A estória mais importante está no topo da lista
    • O tamanho de cada retângulo representa o tamanho daquela estória, ou seja, o tempo estimado para o tamanho da estória
    • A altura da linha azul representa a velolcidade estimada da equipe, ou seja, quantos pontos de estória a equipe acredita poder completar durante o próximo sprint
    • O sprint backlog da direita é um pedaço das estórias do Product Backlog
    • Ele representa a lisa de estórias que a equipe executará no sprint
    • A equipe decide como as muitas estórias serão incluídas no sprint, não o PO ou qualquer outra pessoa
    • Caso o PO queira que uma estória entre em um sprint onde ela ficou de fora como no caso da figura, ele terá duas opções:
      • Mudar o escopo de uma das outras estórias para que ela fique menor e então caiba
      • Ou então remover a estória C por exemplo para que a D entre


Estimativas


  • Estimando tamanhos:
  • O PO precisa de estimativas, este é um esforço cooperativo entre o PO e a equipe
  • A equipe estima e o PO descreve os itens e descreve questões
    • Dinâmica das estimativas:
      • Deixe a equipe fazer as estimativas
      • Não faça com que eles gastem tempo demais
      • Certifique-se de que eles tenham entendido que as estimativas de tempo são estimativas cruas, não compromissos
  • Normalmente, o PO reune toda a equipe em uma sala, fornece algumas ilustrações e lhe diz que o objetivo da reunião é fazer uma estimativa de tempo para as 20 estórias mais importantes do Product Backlog
  • Ele passa por cada estória uma vez e então deixa a equipe trabalhar
  • O PO permanece na sala para responder perguntas e esclarecer o escopo de cada item
  • Esta reunião deve ocorrer dentro de um intervalo de tempo fixo, caso contrário, as equipes tendem a gastar tempo demais estimando poucas estórias
  • Planning Poker
    • Para estimar o tempo das estórias contidas na sprint utiliza-se um baralho de 13 cartas
  • Quando a estória for estimada, os membros, um a um, fazem a escolha de uma carta apresentando a estimativa do tempo da estória colocando-a virada para baixo sobre a mesa
  • Logo após o processo ter sido concretizado as cartas são reveladas simultaneamente
  • Este processo é realizado com o âmbito de que cada membro da equipe seja forçado a pensar por si só ao invés de ficar se baseando nas estimativas de outras pessoas
  • O baralho é geralmente composto por cartas que possuem uma sequência de Fibonnaci, por exemplo, 0 0,5 1 2 3 5 8 13 21 34 e assim por diante e uma carta que possui um sinal de interrogação
  • A escala de complexidade é baseada na sequência de Fibonnaci e cada participante do time que estiver comprometido recebe um conjunto de cartas sendo cada uma com um número de complexidade
  • O grupo se reune geralmente na reunião de Sprint Planning e esclarece as estórias com o PO para depois estimar uma a uma
  • SEguindo a ordem de sequência das estórias já priorizadas pelo PO
  • Então o time conta até tres e cada um apresenta uma das cartas ao mesmo tempo e este é um momento importante pois um membro pode influenciar o outro na hora de mostra as cartas
  • A rodada termina quando todos os jogadores entrarem em acordo


Curso Presencial: UX - Experiência do Usuário


  • Instrutor:
    • Rafael Siqueira
    • rafael.hsiqueira@hotmail.com


  • Persona:
    • Luis Paulo
      • 28 anos, casado
      • tem uma filha de 10 anos, Maria Fernanda
      • Responsável pela implantação, instalação de serviços
      • Não tem grandes expectativas


  • Problemas:
    • Localização
    • Assinatura
    • Agendamento
    • Liberação em condomínio
    • Pesquisa de satisfação


  • Como o time vai resolver problemas?
    • Organize as ideias
    • Anote todas
    • Encoraje as ideias loucas (não existem ideias ruins)
    • Construa sobre a ideia dos outros


  • Ideias sugeridas:
    • Todos
      • Portal de treinamento de instalaçao para o cliente
    • Assinatura:
      • Canetinha Stylus (Galaxy Note)
    • Localização:
      • Identificar o técnico mais próximo
      • Sistema agrupar OSs de produtos diferentes do mesmo cliente para o mesmo técnico
    • Liberação de condomínio:
      • URA ligando para o condomínio fazendo um pré-cadastro
      • Uma credencial (crachá, transponder, biometria) para os principais condomínios da cidade
      • Antes do técnico sair a campo, o Atendimento deve ligar e já credencial o técnico no condomínio
    • Agendamento:
      • Disparar um SMS para o cliente quando o técnico for sair
    • Pesquisa de satisfação:
      • Preencher no momento do atendimento a pesquisa no Smartphone pelo cliente


  • Ideias mais votadas:
    • Todos
      • Portal de treinamento de instalaçao para o cliente
    • Assinatura:
      • Canetinha Stylus (Galaxy Note)
    • Localização:
      • Identificar o técnico mais próximo
    • Liberação de condomínio:
      • URA ligando para o condomínio fazendo um pré-cadastro
      • Uma credencial (crachá, transponder, biometria) para os principais condomínios da cidade
      • Antes do técnico sair a campo, o Atendimento deve ligar e já credencial o técnico no condomínio
    • Agendamento:
      • Disparar um SMS para o cliente quando o técnico for sair com exigência de resposta
    • Pesquisa de satisfação:
      • Preencher no momento do atendimento a pesquisa no Smartphone pelo cliente


  • Prototipação:
    • Wireframes, não tem que ser uma obra de arte
    • Todo mundo consegue fazer uma bolinha, um quadrado ou uma modelo básico qualquer
    • Tente usar Mockups
    • Ilustre sua ideia
    • É hora de tirar o que está na sua cabeça e passar para o papel


  • Aplicativo para usabilidade: POP