Apresentação feita no evento JoinCommunity 2° edição. Site do evento: http://www.joincommunity.com.br/ Arquivos mostrados durante a apresentação: https://www.dropbox.com/s/j5cqi3njpnxqvtg/NathanWolff.pdf https://www.dropbox.com/s/341r8hilqh8dz4k/SaphiraCardoso.pdf

1. Projetando um novo app usando User-Centered Design
● Usabilidade.
● Modelo mental
● User-Centered Design
● Objetivos dos usuários e funcionalidades
● Quem são os usuários?
● Personas
● Cognitive Walkthrough com Personas

2. Apresentação
Fernando Camargo:
● Graduando do curso de Eng. de Computação na UFG
● OCJP 6
● Desenvolve para Java EE, Android, Grails e front-end
web
● Desenvolvedor na Fibonacci Soluções Ágeis
● Artigos “Construindo Frameworks” na Easy Java
Magazine e “Desenvolvimento seguro com Apache
Shiro” (parte 1 e 2) na Java Magazine

3. Usabilidade
● Facilidade com que os usuários utilizarão seu app.
● Sem isso, não importa o quão incríveis são as
funcionalidades. Se o usuário não conseguir usá-las,
tudo será em vão.
● O que parece fácil para uma pessoa (você) pode ser
difícil para outra pessoa (o usuário).
● O usuário não é estúpido, a usabilidade de seu app é
ruim.
● Como alcançá-la?

4. Modelo mental
● Quando usamos algo, criamos um modelo mental sobre
como aquilo funciona.
● A partir desse modelo, tentamos prever o
comportamento dos objetos.
● Para atingir uma boa usabilidade, o app deve facilitar a
criação do modelo mental do usuário e ser consistente,
tendo um comportamento esperado pelo usuário.
● Cada usuário possui diferentes experiências na interação
com softwares. Como auxiliá-los?

5. Modelo mental
● Mantenha consistência de comportamento.
● Siga os padrões de design da plataforma alvo!
● Se seu app faz algo equivalente a um objeto real,
projete-o para se comportar de forma parecida com esse
objeto. Exemplo: livros e leitores de ebook.
● Dê retorno visual para as ações do usuário, para que ele
perceba se está indo na direção certa.
● Faça com que a interface dê dicas ao usuário. Exemplo:
mais conteúdo disponível.

6. Exemplo: livros e leitores de ebook
Google Play Books

7. Exemplo: mais conteúdo disponível
Google Play

8. User-Centered Design
● Devemos ter o processo de design focado nos usuários.
● Conjunto de técnicas disponíveis para atingir esse
objetivo.
● Aqui, apresentaremos apenas algumas delas.
● Primeiro passo: focar nos objetivos dos usuários antes
de pensar nas funcionalidades.

9. Objetivos dos usuários
● O usuário não quer usar seu app, ele quer cumprir
objetivos que serão auxiliados pelo seu app.
● Ele testará seu app com isso em mente: esse app me
ajuda a cumprir meus objetivos?
● Não confunda objetivos com funcionalidades. O objetivo
do usuário não é marcar um compromisso em um
calendário, é organizar seus compromissos para lembrar
sobre eles.

10. O problema do app que faz tudo
● Um app que tem funcionalidades demais apenas
confundirá o usuário e terá problemas de usabilidade.
● Foque em quais objetivos dos usuários seu app ajudará
a cumprir.
● Cuidado com usuário que pedem determinada
funcionalidade. Tente entender o objetivo por trás dela e
veja se seu app foi criado para atendê-lo.
● Tão importante quanto decidir o que o app deve fazer, é
decidir o que ele NÃO deve fazer.

11. Exemplo: agendador de compromissos
Objetivos dos usuários:
✔ Organizar seus compromissos por data e hora.
✔ Ser lembrado de seus compromissos.
✔ Visualizar facilmente seus compromissos para se
planejar.

12. Exemplo: agendador de compromissos
Funcionalidades:
✔ Possuir diversas visões de calendário onde estarão
marcados os compromissos do usuário.
✔ Permitir que o usuário adicione, edite e delete um
compromisso.
✔ Permitir que o usuário adicione um lembrete para o
compromisso.
✔ Avisar o usuário sobre os compromissos de acordo com
o lembrete registrado.

13. Objetivo x Funcionalidade
● Cada funcionalidade deve ser ligada a um objetivo do
usuário. Evite criar funcionalidades desnecessárias.

14. Quem são os usuários?
Quando criamos um app a ser publicado para uso
público (Google Play, AppStore, etc.), nós não
conhecemos nossos usuários.
Por isso, surgem os seguintes erros:
✗ Criá-lo para nós mesmos, como se nós fôssemos os
usuários finais.
✗ Criá-lo para “todo mundo”.

15. O erro de criarmos para nós mesmos
● Nós estamos acostumados a interagir com softwares.
Naturalmente teremos mais facilidade do que alguém
que não está acostumado.
● Nós o fizemos, naturalmente saberemos como usá-lo e
teremos a falsa impressão de que tem boa usabilidade.
● Não somos os usuários finais. Formamos um modelo
mental totalmente diferente dos usuários finais.

16. O erro de criarmos para todo mundo
● É impossível criar um design que possua boa
usabilidade para “todo mundo”.
● Pessoas formam modelos mentais diferentes de acordo
com sua experiência de vida.
● É melhor funcionar muito bem para um seleto grupo de
usuários do que funcionar mal para todo mundo.
● Devemos selecionar o grupo de usuários importante para
nosso app.

17. Selecionando um público-alvo
Imaginemos um app que visa aumentar a produtividade.
Quais tipos de pessoas devem ser nosso público-alvo?
● Estudantes (pré-vestibular, universitários, de
concursos...)
● Free lancers
● Empresários

18. O que fazer agora?
Saber o publico-alvo não é o suficiente. Ainda não temos
contato com nossos usuários. Então como trazê-los para
o foco do design?
Podemos usar uma das técnicas de User-Centered
Design:
Personas

19. Personas
● Técnica que consiste em criar personagens que
representem bem o público-alvo do software.
● Esses personagens são usados para descrever
objetivos, habilidades, experiência técnica e o contexto
de uso dos usuários.
● Se possível, devem ser criadas a partir de pesquisas
com usuários, de forma a criar personas de acordo com
um padrão encontrado. Caso não seja possível, pode-se
criar personas provisórias baseadas apenas no que se
sabe sobre os prováveis usuários.

20. Personas: por que usá-las?
● Ter o design focado em usuário não é fácil.
● Usuários são complicados e variados. E nem sempre
conseguimos manter contato contínuo com eles.
● Com personas, podemos fazer suposições sobre os
usuários mais explícitas.
● Coloca o foco em usuários específicos, ao invés de “todo
mundo”.
● Limita nossas escolhas aos grupos de usuários
representados, nos ajudando a tomar melhores decisões.

21. Personas: onde usá-las?
● Decisões sobre funcionalidades do produto.
● Design de navegação, interação e visual.
● Testar o produto do ponto de vista das personas,
tentando pensar como elas pensariam.
● Ter uma forma de se comunicar com a equipe sobre um
tipo específico de usuário usando a persona em seu
lugar.

22. Personas: composição
● Nome
● Foto
● Slogan. Uma frase que descreva bem a persona.
● Informações comuns (idade, ocupação, onde vive, nível de
habilidade com tecnologia...)
● Objetivos a serem alcançados
● Pontos de frustração
● Pontos importantes sobre a persona (uma espécie de resumo)
● Descrição detalhada sobre ela.
● Cenários de uso do app

23. Personas: composição
Devemos notas algumas coisas:
● Precisamos personificar a persona, trazer ela à vida,
como se fosse uma pessoa real.
● Precisamos dos objetivos finais dela. Por exemplo: o
objetivo de um aluno pré-vestibular é passar no
vestibular. Ele usaria um app para aumentar sua
produtividade, mas esse não é o objetivo final dele.
● Os cenários definem a forma e o local de uso do app.
Por exemplo: ele pode ser usado no ônibus, onde poderá
interromper o uso a qualquer momento.

24. Personas: processo de criação
Existem duas opções:
● Através de uma pesquisa com os usuários (nem sempre
é possível), onde se encontra padrões entre eles e
usa-os para formar as personas.
● Através de conhecimento prévio sobre o tipo de pessoa.
Por exemplo, conseguimos imaginar como é a vida de
um estudante universitário.

25. Personas: categorias
Um projeto médio comumente deve ter entre 3 e 7
personas. Elas são divididas entre as seguintes
categorias:
● Primária
● Secundária
● Suplementar
● Negativas
Entre outras de menor uso.

26. Personas: categoria primária
● São as personas que representam o grupo de usuários
mais importante.
● Devem possuir uma UI específica para elas. Portanto,
deve representar bem as outras personas.
● Quanto menor número de personas primárias, melhor.
Um projeto pequeno deve ter uma, um médio deve ter
duas e um grande, três.

27. Personas: categoria secundária
● São personas cujas necessidades podem, na maioria
das vezes, ser alcançadas focando nas primárias.
● Porém, podem ter algumas necessidades específicas
que não são prioridade para as primárias.
● Podem ser necessárias pequenas adições na interface,
mas essas não podem interferir negativamente nas
primárias.

28. Personas: exemplo de primária
Fora dos slides.

29. Personas: exemplo de secundária
Fora dos slides.

30. Cognitive Walkthrough com Personas
● É uma exploração passo-a-passo de um serviço/software
para ver quão bem um tipo particular de pessoa
consegue completar um ou mais objetivos.
● Usamos personas para fazer esse passo-a-passo de
forma que “entramos no personagem” e tentamos pensar
como elas.
● Pode ajudar a encontrar problemas de usabilidade,
acessibilidade, entre outros.

31. Bibliografia e fontes de estudo
● http://wiki.fluidproject.org/display/fluid/Design+Handbook
● Smashing Android UI, Juhani Lehtimaki. Smashing
Magazine Book Series. 2012.

32. Dúvidas?