| (30 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: | ||
| Linha 50: | Linha 51: | ||
* "A experiência do usuário está se tornando mais importante que o preço." | * "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." | * "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> | <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
- 1. O que colocar no wireframe?
- 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
- 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
- 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
- Wireframe -> protótipos navegáveis -> Feedbacks -> Ajustes -> Wireframe -> ...
- Ferramentas de prototipação:
- Proto.io, invision, marvelApp
- Alguns permitem rodar no smartphone e ter uma demonstração bem fiel da IDE
- Proto.io, invision, marvelApp
- É 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
- Dicas (antes da entrevista:
- 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
- Descoberta
- 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
- Dinâmica das estimativas:
- 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
- Luis Paulo
- 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
- Todos
- 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
- Todos
- 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


