Criando regras para microinterações

Adicionar botão intuitivo para verificar notificações.

Porém, quando o desenvolvedor ia começar a elaborar a nova feature algumas dúvidas surgiram:

• Esse botão abre uma nova página, um modal ou será um menu flyout?

• Haverá um aviso de novas notificações de tempos em tempos? Se sim, qual será esse intervalo?

• Como o usuário saberá que há novas notificações?

• O que acontece depois de acionar a microinteração?

Ao tentar desenvolver a ideia, mesmo com as dúvidas, chegou a este resultado:

Quando, na verdade, o que tinham pedido se aproximava mais de algo como:

Logo na apresentação inicial do botão, notamos uma diferença notável do que queriam dizer e a interpretação final.

Perceba que, com a orientação inicial, deixamos aberto para que diversas dúvidas surgissem no momento de realmente desenvolver a microinteração.

O que determinam as regras de microinterações?

Existem alguns pontos necessários para compreendermos a que se refere cada microinteração, o motivo de ter sido desenvolvida e a forma como irá operar, porém cada caso pode demandar de especificações diferentes.

Basicamente, as regras de microinterações podem definir coisas como:

• O que acontece quando a microinteração é ativada pelo gatilho (trigger)?

• Qual a sequência de ações e o momento (timing) para acontecer?

• Existem informações nas quais se baseia? Localização, hora, clima, etc… E de onde esta informação será retirada?

• Quais as configurações e parâmetros do algoritmo da ação?

• Qual feedback será apresentado e quando?

• A microinteração se repete? Com que frequência?

Seguindo mais ou menos essa ideia conseguimos preparar regras mais bem elaboradas que facilitarão o trabalho do desenvolvedor ou mesmo a manutenção de cada um das microinterações já existentes.

Para desenvolver suas próprias regras, é preciso seguir algumas considerações importantes. Vamos ver um pouco mais sobre elas!

Crie regras claras

Como já notamos, criar regras claras e de fácil compreensão é fundamental para auxiliar em todo o processo de desenvolvimento de uma microinteração. Então, como seria se alterássemos aquele exemplo inicial para algo como:

Adicionar botão no menu principal para facilitar a visualização de notificações não lidas. Ao receber novas notificações, apresentar uma indicação sobre o botão com a quantidade de novas notificações não lidas. Após clicado, o botão abre um menu flyout com as novas informações e retira a indicação de notificações não lidas do botão. A cada nova atualização de notificações não lidas, o processo se repete. Após clicar em uma das notificações, o menu fecha e volta ao estado default, sem indicações de notificação.

Agora temos uma descrição muito mais detalhada do que precisamos, certo? Percebe que, logo no início da descrição, temos determinado o objetivo da microinteração?

"Adicionar botão no menu principal para facilitar a visualização de notificações não lidas."

Antes de determinar as regras da interação, precisamos deixar claro o que pretendemos realizar com aquilo para depois desenvolver as demais especificações. Isto é, o objetivo será a base para desenvolver cada etapa da microinteração, por isso a importância de tê-lo claro.

Mas, será que a apresentação das regras dessa forma, em um texto corrido, é a melhor forma de apresentar nossas regras?

Apresentando suas regras de microinterações

Que tal apresentar as orientações anteriores dessa forma:

Note que temos uma visão completamente diferente da que tivemos com a apresentação em um texto corrido. Agora conseguimos visualizar com mais clareza o que pretendiam realizar e diminuímos ainda mais as chances de ambiguidade e erros.

O formato de texto corrido pode servir em algumas situações, mas a representação visual como base para as orientações ajuda muito na compreensão da ideia.

E, como representação visual, podemos usar tanto um fluxo de telas, diagramas, imagens ou qualquer outro apoio que seja relevante para tornar entendimento mais claro.

Para orientar o que adicionar nessas representações, podemos considerar os seguintes pontos:

• O estado default: Como será o estado inicial do objeto, como o usuário encontrará em sua primeira interação?

• Estado ativo: O que acontece com o objeto enquanto a microinteração ocorre?

• Estado atualizado: O que acontece quando o usuário termina a interação?

Representando em algo visual a microinteração criada no projeto, teríamos um resultado mais ou menos assim:

Veja que agora deixamos nossa representação mais linear e fácil de entender!

Tenha em mente que a ideia é definir as regras de forma a ajudar tanto o desenvolvedor a compreender bem a ideia antes de começar a executá-la, quanto a própria equipe durante o planejamento das regras.

Analisar e reajustar

Existem alguns tópicos muito relevantes a refletir enquanto desenvolvemos as regras, para evitar que hajam lacunas que prejudiquem a experiência do usuário.

Um bom exemplo seria, ao terminar de desenvolver as regras, fazermos uma primeira observação do geral elaborado e, a partir daí, começar a pensar os possíveis erros e falhas no qual o usuário pode cair.

Essa é uma boa prática para prevenção de erros. Nesse momento sentimos o quanto uma boa apresentação das regras da microinteração faz diferença! Quer dizer, tendo uma definição clara é muito mais fácil de fazer análises críticas.

É importante sempre repassar as regras e realizar testes para analisar se o que definimos faz sentido para o usuário.

Definindo regras para microinterações

Assim como afirmou Dan Saffer em seu livro Microinterações: Desenhando com detalhes:

"As regras deveriam gentilmente guiar os usuários através da ‘interação’ com a microinteração".

Ou seja, devemos ter um cuidado extra ao desenvolver as orientações para nossas microinterações para que a experiência do usuário seja o mais natural e intuitiva possível.

O mais importante, antes de mais nada, é definir o objetivo da microinteração e, a partir disso, analisar todo o conteúdo e informações que poderão ser relevantes para o seu desenvolvimento.