Da decisão
ao que acontece.

Conhecer o público, o conteúdo e a função ajuda a escolher o formato. Um site pode organizar leitura e caminhos; uma aplicação pode receber uma informação, processá-la e produzir um resultado; um jogo organiza escolhas sob regras; um agente conversacional responde ao longo de uma conversa.

Esses formatos podem se combinar. Um jogo pode funcionar em um site, e uma aplicação pode incluir um agente. A pergunta útil é qual ação deve ocupar o centro da primeira versão. Acrescentar uma conversa de IA a uma tarefa de regras fixas muda o trabalho de construção e de teste, por isso essa escolha precisa ter uma razão.

Chamamos de interface a parte pela qual a pessoa interage com o projeto: o texto que lê, o campo em que escreve, o botão que aciona ou o comando que usa. A interface deve corresponder à tarefa. Se o objetivo é comparar informações, a pessoa precisa encontrá-las; se é experimentar uma regra, precisa reconhecer as ações possíveis e suas consequências.

Antes de pedir construção, prepare um briefing: uma descrição do que será feito, para quem, com qual conteúdo e dentro de quais limites. No jogo fictício, esse documento reúne as palavras conferidas, o que aparece no início da rodada, as respostas aceitas, o retorno após cada tentativa e a condição de encerramento.

O briefing também diz o que não entra nesta versão. Contas de usuário, armazenamento de dados, novas fases ou serviços externos não devem aparecer apenas porque a IA os sugeriu. Cada recurso acrescenta decisões sobre funcionamento, acesso, uso de informações e manutenção. O grupo precisa saber por que ele é necessário antes de incluí-lo.

Descrever o que acontece em cada situação

Uma aplicação recebe uma entrada, como a resposta digitada pelo jogador, e produz uma saída, como a indicação de acerto. Entre as duas, aplica uma regra. A validação verifica se a entrada pode ser usada: por exemplo, se o campo foi preenchido antes de tentar comparar a palavra.

O projeto também muda de estado, isto é, de situação de funcionamento. Uma rodada pode estar esperando uma resposta, mostrando um erro ou encerrada. Descrever esses estados ajuda a perceber o que falta. Se você só disser o que acontece quando o jogador acerta, o programa ainda terá de lidar com respostas erradas, campo vazio e fim das tentativas.

No exemplo, o grupo pode definir:

• No início, a explicação aparece e há três tentativas disponíveis.
• Com o campo vazio, o jogo pede uma resposta e mantém o número de tentativas.
• Com uma resposta incorreta, informa o erro e desconta uma tentativa.
• No acerto, encerra a rodada e apresenta a explicação da palavra.
• Após três respostas incorretas, encerra a rodada, mostra a palavra e sua explicação.
• Ao recomeçar, restaura as condições iniciais.

Essas são regras inventadas para o exemplo. Antes de pedir código, o grupo teria de decidir como tratar diferenças de maiúsculas, minúsculas e acentos. Se a regra estiver ausente, não saberemos depois se uma resposta foi rejeitada por erro do programa ou por uma decisão que ninguém chegou a tomar.

Para um site de conteúdo, os casos podem ser outros: uma seção sem material, uma fonte indisponível ou uma pessoa que não entende o primeiro passo. Para um agente, são as diferentes condições da conversa. A forma do teste muda, mas a relação permanece: uma tarefa definida precisa de um comportamento esperado.

Se o projeto usa imagens, animação ou som

Um recurso de mídia deve participar do que a pessoa faz ou compreende. Ele pode apresentar uma personagem, distinguir um acontecimento ou criar uma atmosfera. Antes de produzi-lo, diga qual função terá; isso ajuda a escolher o que criar e o que conferir.

A oficina de 28/09 organizava os pedidos em assunto, descrição e estilo. O assunto identifica o recurso e seu uso. A descrição informa elementos, ação, enquadramento, duração e restrições pertinentes. O estilo indica a linguagem visual ou sonora. No modelo M13, esses elementos aparecem em pedidos de imagem e som.

Uma personagem precisa continuar reconhecível entre as poses. A sprite sheet, ou folha de quadros, reúne imagens de uma ação para que o código as alterne e produza movimento. A folha sozinha não é uma animação executável. É preciso conferir o arquivo, a ordem dos quadros, o alinhamento e sua integração ao jogo.

Como exemplo de especificação, a oficina propôs oito quadros de 64 × 64 pixels em uma linha, formando uma folha de 512 × 64 pixels. Os pixels são as unidades de cor que compõem essa imagem digital; as medidas indicam quantas há na largura e na altura. Esses números descrevem um arranjo possível; não garantem que o gerador entregue o arquivo com as medidas pedidas. A inspeção deve comparar o tamanho real, o fundo e a posição da personagem. Depois, observe a velocidade da animação e a colisão, a regra que determina quando a personagem encontra um obstáculo.

Com música, a mesma diferença entre pedido e resultado permanece. BPM, batidas por minuto, indica o andamento pretendido. Pedir uma faixa a 100 BPM não basta para programar as ações do jogo nesse tempo: primeiro, é preciso ouvir e conferir o arquivo. A oficina propunha começar com dez batidas de teste antes de integrar a música inteira.

Os sinais de acerto e erro precisam ser distinguíveis e não devem ficar encobertos pela trilha. A pessoa deve poder controlar o som, e as informações importantes precisam continuar disponíveis quando ele estiver desligado. Registre arquivo, duração, ponto de entrada, autoria e condições de uso. Desenhar, fotografar objetos ou criar formas e sons por programação também eram alternativas da oficina.