Orientações gerais para correções dos protótipos, apresentados em 28/07/21.

Pessoal, este foi apenas o primeiro protótipo apresentado. Agora é melhorá-lo!

Vamos estabelecer notas para todos os trabalhados apresentados nos vídeos.
E pedimos que mantenhamos o diálogo considerando o nosso acordo de que
a disciplina está em ensino emergencial remoto, no meio da Pandemia, portanto
é passível de mudanças, em comum acordo e sempre com um discurso de paz.

As orientações, a seguir, estão baseadas no vídeo das apresentações dos projetos.

Temos tópicos que são pontos positivos para todos os projetos, mas apresentaremos
exemplos com base em alguns dos projetos. Assim como, temos correções que devem
ser conferidas por todos vocês, em todos os projetos. Não são criíticas, mas são pontos
que precisam de revisão, inclusive de verificações relacionadas à formatação e ABNT.

Deste modo, as notas já foram estabelecidas com base nos arquivos apresentados.
A avaliação dos protótipos foi baseada nos cinco princípios de Jakob Nielsen (1993),
conforme foram explicados em sala de aula: Compatibilidade visual com o usuário,
consistência entre as telas, feedbacks das telas, controle do sistema pelos usuários e
gestão de erros para orientar o usuário (como respostas de ajuda e botão de ajuda.).

Pontos POSITIVOS para todas as equipes:

1- Definição do objetivo principal para o seu sistema e definição do público principal.

Todas as equipes conseguiram explicar nas apresentações, mas sempre expliquem
qual é o objetivo principal para a tarefa principal do sistema de um público principal.

2- As equipes fizeram análises de similares, mas precisam deixar claro que os sistemas
similares tem o mesmo objetivo do sistema que a equipe vai gerar design, ou redesign.
Exemplo: O trabalho de Laura especificou como o sistema dela é melhor que outros.
Em outros projetos, é importante que vocês precisam entender a diferença entre
fluxograma e wirframe. Um wireframe é um GRID das telas, com a estrutura geral.

3- O fluxograma destacar o fluxo/caminho principal para a tarefa principal do sistema.

Mas no fluxograma se apontam os demais fluxos/caminhos possíveis de “ida e volta”.
Exemplo: O trabalho do Worth Fruit especificou a tarefa principal e as “ramificações”.
Um fluxograma desenha os níveis de navegação e destaca um caminho principal nele.

4- A defesa sobre a escolha da metodologia de construção deve ser especificada nas

apresentações, para que outras equipes saibam que vocês seguiram um método para
desenvolvimento (Garret) e depois escolheram testes com personas, como o Embarca.
E se escolheram Double Diamond, a partir dele, optaram por métodos como Personas,
no aplicativo Macth FIT. De modo geral, todas as equipes apontaram a metodologia.
Pontos que precisam ser REVISADOS, nas apresentações e relatórios.

1- Determinar uma tarefa principal, para poder desenhar um fluxograma.

Explicação: Os fluxogramas só devem ser desenhados/representados, após você

descrever qual vai ser a tarefa principal, para que o fluxograma fique mais completo.
Por exemplo: a partir da tela de abertura (splash), qual a tarefa principal do sistema?
Para que você possa redesenhar o fluxograma, você precisar ter uma tarefa principal.

2- Descrever/Especificar como foi a pesquisa com os usuários da pesquisa.

Explicação: Descrever o público alvo do seu sistema, com quantos usuários fez o teste,
qual é o perfil deles quanto à idade, gênero, nível de instrução, contexto de utilização.
Qual a tarefa principal (objetivo) que você pediu para o usuário realizar no protótipo?
Para fazer pesquisa com o usuário, defina esta relação usuário à artefato àcontexto.

3- Para fazer o protótipo final, devemos implementar os resultados da pesquisa.

Explicação: vocês construíram protótipos de baixa e média fidelidade, depois fizeram a
pesquisa com o usuário, testando o protótipo; agora devem melhorar a navegação e a
interface, com base no que foi respondido pelos usuários em relação à tarefa principal.

4- As equipes que ainda NÃO tem protótipos navegáveis, precisam construi-los.

Explicação: Quando o protótipo é de alta fidelidade, ele deve ter uma tarefa principal
que siga até o final dela, mesmo que a estética não esteja totalmente perfeita, Mas...
se você chama o sistema de MVP (produto mínimo viável), então deve construir os
níveis e subníveis de menus. No final, tem-se a tarefa principal e mais funcionalidades.

Observação para esta quarta feira, dia 05 de agosto:

Entre às 19h e 20h, teremos estas explicações das correções dos projetos.
A partir das 20h, teremos uma apresentação do trabalho de Mateus Costa.
Às 21h teremos perguntas sobre a apresentação de Mateus e dúvidas finais.
Podemos marcar horários para orientações direcionadas às equipes em outro
dia da semana, apenas para saber em que melhorar o seu projeto, em especial.

Proposta para a finalização da disciplina, com protótipo final e relatório final:

Mantenhamos as equipes já formadas, porque a disciplina termina em Agosto.
Como todos os protótipos serão melhorados, a nota da 2ª avaliação será melhor.
Teremos uma conversa para propor que as equipes possam se autoavaliar e ver
se concordam com as notas aplicadas pelos professores, ou se querem reavaliação.