UX - User Experience

• 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

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

#1 - Visibilidade do status do sistema

• Feedback

#2 - Compatibilidade do sistema com o mundo real

• Falar a linguagem do usuário

#7 - Flexibilidade e eficiência de uso

• Teclas de atalho
• Teclas TAB para mudança de campo

#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.

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