Mapa da aula
Aula 25 publicada. Mapa, exemplo, EX073.
flowchart TD
N0["25.1 Formato do ateliê"]
N1["25.2 Opção A: formulário primeiro"]
N2["25.3 Opção B: passo a passo"]
N3["25.4 Opção C: guiada pela etiqueta"]
N4["25.5 Crítica"]
N5["25.6 Protótipo"]
N6["25.7 Registro da decisão"]
N7["25.8 Verificação de usabilidade"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX073"]
Desenho lógico
flowchart LR
N0["25.1 Formato do ateliê"]
N1["25.2 Opção A: formulário primeiro"]
N2["25.3 Opção B: passo a passo"]
N3["25.4 Opção C: guiada pela etiqueta"]
N4["25.5 Crítica"]
N5["25.6 Protótipo"]
N6["25.7 Registro da decisão"]
N7["25.8 Verificação de usabilidade"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[25.1 Formato do ateliê]
|
v
[25.2 Opção A: formulário primeiro]
|
v
[25.3 Opção B: passo a passo]
|
v
[25.4 Opção C: guiada pela etiqueta]
|
v
[25.5 Crítica]
|
v
[25.6 Protótipo]
|
v
[25.7 Registro da decisão]
|
v
[25.8 Verificação de usabilidade]
|
v
[Exemplo resolvido] --> [Exercício EX073]
Objetivos de aprendizagem
Você vai (1) produzir e criticar opções de projeto para o EvidenceDesk; (2) prototipar o fluxo de entrada; (3) conduzir uma crítica de projeto; (4) registrar as decisões de projeto.
25.1 Formato do ateliê
O ateliê é iterativo: esboçar, apresentar, criticar, revisar. A equipe de Priya apresenta três projetos de entrada a Hugo e a dois colegas de turma no papel de peritos. Cada rodada é curta: dez minutos para apresentar, quinze para a crítica e uma semana para revisar. Os colegas que fazem o papel de peritos são orientados a ser francos sobre qualquer coisa que os atrasaria num balcão de entrada movimentado. Priya registra cada ponto da crítica com quem o levantou e se a versão seguinte o resolve, de modo que o ateliê deixa uma trilha de decisões, e não uma coleção de opiniões.
25.2 Opção A: formulário primeiro
Um único formulário longo registra tudo na entrada. Completo, mas lento; os peritos pulavam campos nas versões em papel. O formulário em papel que Northfield usava tinha vinte e dois campos numa página, e as auditorias encontraram os mesmos cinco geralmente em branco: número do lacre, estado da embalagem, endereço da apreensão, número do distintivo do policial e prateleira de armazenamento. Uma cópia digital desse formulário herdaria o mesmo hábito. Priya leva as contagens da auditoria ao ateliê, para que a crítica parta de evidências sobre o comportamento real, e não de preferências. A falta dos números de lacre tinha causado mais problemas no tribunal.
25.3 Opção B: passo a passo
Telas curtas guiam cada etapa — registro, conferência do lacre, referência da fotografia, local de armazenamento. Menos campos pulados; mais cliques. Cada tela pede apenas o que aquela etapa precisa, e não pode ser concluída com um campo obrigatório vazio. A tela de conferência do lacre, por exemplo, pergunta se o lacre está intacto, seu número e uma referência da fotografia. Mais cliques custam tempo, então Priya mede isso: a entrada passo a passo leva cerca de noventa segundos a mais por item do que o formulário único, e os peritos julgam isso aceitável.
25.4 Opção C: guiada pela etiqueta
Ler uma etiqueta pré-impressa para criar o item e depois preencher os campos mínimos; os detalhes são acrescentados mais tarde. Rápida, mas arrisca registros incompletos se o "mais tarde" nunca chegar. Ler uma etiqueta pré-impressa elimina erros de digitação no identificador e torna o registro quase instantâneo, o que ajuda quando chega de uma vez um porta-malas cheio de itens. O perigo é que o "mais tarde" escorregue nas semanas movimentadas. Na crítica, os peritos admitem que os registros pela metade se acumulariam, e um sistema que os permitisse logo estaria cheio de itens de que ninguém conseguiria prestar contas por completo.
25.5 Crítica
Os peritos preferem a B com a leitura de etiqueta da C. Hugo enfatiza que nada deve marcar um item como "pronto" até que todos os campos obrigatórios existam. O projeto combinado usa a leitura da etiqueta para criar o item e preencher previamente seu identificador, e então segue direto para as telas passo a passo. Um item com campos faltando fica num estado de "registro incompleto", que bloqueia o armazenamento e a aquisição, e o painel lista esses itens em vermelho. A regra de Hugo vira uma restrição do modelo de estados, e não um lembrete de treinamento. Os peritos concordam em testá-lo por um mês.
25.6 Protótipo
Priya constrói em Python um protótipo em modo texto que percorre as etapas da B e se recusa a concluir sem os campos obrigatórios. O protótipo roda num terminal e pede cada campo em ordem, validando formatos como o dígito verificador do identificador e a data. Se o usuário tenta terminar antes, ele lista os campos que faltam e recusa. Ele grava os registros no mesmo formato de linhas JSON do sistema planejado, para que os dados de teste do ateliê possam depois ser carregados diretamente na versão real.
25.7 Registro da decisão
Decisão: entrada passo a passo com leitura de etiqueta; motivo: completude e rapidez; rejeitadas: A (campos pulados), C pura (registros incompletos). Data e participantes registrados. O registro também anota as evidências por trás da decisão: as contagens da auditoria de campos em branco no papel, as medições de tempo de cada opção e a crítica dos peritos. Registrar as opções rejeitadas com os motivos significa que, quando alguém mais tarde propuser voltar a um formulário único, a equipe pode mostrar por que ele foi abandonado e o que precisaria mudar. O registro é arquivado ao lado do código do protótipo.
25.8 Verificação de usabilidade
Dois colegas de turma fazem a entrada de cinco itens sintéticos cada um, enquanto Priya cronometra e anota as confusões. Os tempos mostram que o primeiro item leva cerca de quatro minutos e o quinto cerca de dois, à medida que os usuários aprendem as telas. A confusão se concentra num ponto: os dois testadores hesitam sobre se "estado da embalagem" se refere ao saco de evidências ou ao item dentro dele. Priya renomeia o campo para "estado do saco de evidências" e acrescenta um campo opcional separado para o item, e então repete a verificação com dois outros colegas.
Acessibilidade
As telas usam rótulos claros, navegação por teclado e contraste suficiente, para que peritos com necessidades diferentes possam trabalhar com eficiência. As mensagens de erro dizem o que falta e como corrigir, em vez de mostrar códigos. Priya confere cada tela contra uma lista curta de verificação de acessibilidade antes da sessão seguinte do ateliê.
Exemplo resolvido
A verificação de usabilidade mostra que os dois usuários deixaram passar o campo do número do lacre, que aparecia depois da etapa da fotografia. Priya o move para a primeira tela, ao lado da leitura da etiqueta, e os dois o preenchem no novo teste.
Caso sintético. As sessões de usabilidade são inventadas.
Erros e limites
Colegas de turma não são peritos; repita a verificação com a equipe real usando itens sintéticos.
Exercícios
- EX073 — Fraqueza das opções. Cite uma fraqueza de cada uma das opções A e C.
Mostrar critérios de avaliação
Rubrica: 3 = A campos pulados/lenta; C registros incompletos; 2 = uma; 1 = vago; 0 = nada. - EX074 — Campo do lacre. O que a verificação de usabilidade encontrou e como foi corrigido?
Mostrar critérios de avaliação
Rubrica: 3 = campo do lacre pulado; movido para a primeira tela; 2 = parcial; 1 = vago; 0 = nada. - EX075 — Registro da decisão. Liste quatro elementos do registro da decisão.
Mostrar critérios de avaliação
Rubrica: 3 = decisão, motivo, opções rejeitadas, data/participantes; 2 = três; 1 = um; 0 = nada.
Síntese
A iteração no ateliê, com crítica real e decisões registradas, transforma ideias num fluxo de entrada utilizável.
Continue estudando — capítulo 25 de 50
← Capítulo 24 (rascunho) · Índice de capítulos do curso · Capítulo 26 (rascunho) →