Cinco princípios para projetar apps guiados pela voz

O problema de projetar voz por cima de interfaces velhas

Anton Sten, a partir de seu trabalho com uma startup explorando interfaces voice-first, observa como é fácil construir um app em torno de toque e digitação mesmo quando a intenção é priorizar a voz. Ao começar pelos componentes e fluxos familiares, as decisões de uso já foram tomadas quando a voz entra em cena - e falar vira apenas outra forma de preencher os mesmos campos. Ele também admite ter pensado que voice-first significava dar peso igual a voz, toque e digitação, mas percebeu que isso não respondia à questão central: se a voz é sempre encaixada num fluxo desenhado para outro meio, o que realmente está sendo repensado? A resposta, para ele, não é remover o teclado nem obrigar alguém a falar quando preferir tocar, e sim questionar requisitos familiares, como escolher um projeto antes de adicionar uma tarefa.

Os cinco princípios

1. Fazer o contexto contar. Falar produz naturalmente mais contexto do que digitar: em vez de "Revisar proposta", a pessoa diz que precisa revisar antes da reunião de sexta, especialmente os preços, porque não tem certeza de que houve tempo suficiente para a pesquisa. Se o software transforma tudo isso numa tarefa genérica "Revisar proposta", o contexto se perde. Sten argumenta que, se a explicação extra não melhora o resultado, o produto está efetivamente ensinando as pessoas a serem breves. O software deveria reter a preocupação na tarefa e associar o prazo à reunião, deixando meios de corrigir a interpretação.

2. Permitir direcionar enquanto se pensa. As pessoas nem sempre chegam com uma instrução pronta: podem dizer sexta e mudar para quinta no meio da fala, ao perceber que não haveria tempo de se preparar. Ver o software responder ajuda a esclarecer o que se queria dizer. Mas exibir cada interpretação parcial pode distrair - a pergunta útil é se o feedback ajuda a continuar pensando ou vira mais uma coisa a gerenciar.

3. Deixar o entendimento claro. Uma animação de microfone mostra que o app está ouvindo, não que entendeu. Nem uma transcrição correta resolve isso: pode capturar quinta e sexta perfeitamente e ainda atribuir a data errada. Olhando a tela, ver a tarefa marcada para quinta com a preocupação anexada basta. Caminhando, sem tela, uma resposta falada curta - "adicionado para quinta, com nota para checar o orçamento da pesquisa" - permite detectar mal-entendidos. O feedback precisa distinguir três coisas separadas: capturar o que foi dito, entender e agir.

4. Facilitar a correção. Interpretar mal faz parte da experiência a ser desenhada. Corrigir por voz ("não, a reunião é sexta, quero revisar na quinta") deve ajustar o detalhe relevante sem repetir tudo nem criar uma tarefa duplicada. Há diferença entre mudar de ideia durante a formação da ação e desfazer algo já executado, e o nível de confirmação deve depender da consequência: mover uma tarefa é reversível; enviar a proposta a um cliente é outra decisão. Exigir aprovação para tudo tornaria a voz tediosa, mas ignorar incerteza para o demo parecer rápido não sobrevive ao uso diário.

5. Deixar a atenção ir e vir. O mesmo produto precisa funcionar na mesa, olhando a tela, e caminhando ou dirigindo, sem tela - a interação deve sobreviver à mudança de atenção. Isso levanta a questão de quando interromper: perguntar por voz se algo essencial estiver ambíguo, ou guardar o pensamento com um detalhe pendente, sem jamais dar a impressão de que algo foi resolvido quando não foi. Ao voltar à tela, a pessoa deve ver o que aconteceu e o que ainda depende dela, sem precisar reler uma transcrição.

Conclusão

Sten trata os princípios como checklist contra a tentação de recriar o app familiar. Ele destaca a tensão central: ver o software funcionar gera confiança, mas parte do valor da voz está em poder parar de olhar - se, ao fim de uma caminhada, a pessoa sente necessidade de conferir cada pedido, ainda há trabalho de design a fazer.