Pedidos de permissão no percurso do produto

Um pedido de permissão móvel é mais do que um ponto de controlo técnico. Pede a uma pessoa que tome uma decisão sobre o acesso, muitas vezes enquanto essa pessoa tenta concluir outra tarefa. A equipa de produto controla grande parte da experiência envolvente: quando aparece o pedido, que contexto o antecede e o que a aplicação faz depois da decisão.

Tratar as permissões como parte do percurso do produto cria um problema de conceção mais claro. Em vez de perguntar como aumentar a aceitação, importa perguntar que acesso é necessário, quando a sua finalidade se torna concreta e se a aplicação continua a ser útil sem esse acesso. Este enquadramento associa a confiança a escolhas compreensíveis, em vez de a uma redação persuasiva.

Trate cada pedido como uma decisão de produto

Cada pedido deve começar com uma funcionalidade específica e um motivo definido. Uma funcionalidade é a ação orientada para o utilizador que depende do acesso, como anexar uma fotografia próxima ou gravar áudio dentro de uma nota. Se a equipa não conseguir associar o acesso a uma ação imediata, o pedido poderá ser prematuro, desnecessário ou demasiado abrangente.

• Identifique a ação que requer acesso.
• Confirme que âmbito da permissão permite essa ação.
• Decida o que permanece disponível sem acesso.
• Documente como a aplicação gere uma alteração da decisão.

Este exercício separa a conveniência da implementação da necessidade do produto. Pedir acesso durante a primeira execução pode simplificar um ramo do desenvolvimento, mas pode eliminar o contexto necessário para avaliar o pedido. Adiar o acesso pode criar estados adicionais da interface, embora esses estados possam tornar mais fácil compreender a relação entre a ação e a permissão. O equilíbrio adequado depende da funcionalidade e das condições verificadas em cada plataforma suportada.

Use a divulgação progressiva para preservar o contexto

A divulgação progressiva consiste em apresentar informações e escolhas quando se tornam relevantes, em vez de expor todas as decisões de uma só vez. No caso das permissões, isto sugere normalmente que se aguarde até uma pessoa iniciar uma ação relacionada. Um pedido de acesso à câmara associado a uma ação explícita de captura tem um contexto mais claro do que o mesmo pedido apresentado antes de a aplicação ter estabelecido o que a câmara permitiria fazer.

Ainda assim, o percurso deve ser concebido como uma sequência e não como um aviso isolado. Importa considerar o estado anterior ao pedido, qualquer explicação fornecida pela aplicação, o passo controlado pelo sistema que poderá surgir em seguida e o destino depois de uma decisão. A equipa deve verificar que partes dessa sequência podem ser controladas em cada plataforma. A divulgação progressiva só é útil quando o passo posterior parece estar associado à ação que o desencadeou.

Conceba em conjunto a explicação e a transição

Uma explicação ao nível da aplicação pode preparar a decisão sem imitar nem prever uma interface do sistema. Esta explicação, por vezes designada ecrã de pré-permissão, é uma vista controlada pelo produto e apresentada antes de um pedido controlado pela plataforma. Deve esclarecer a finalidade imediata do acesso e descrever qualquer alternativa relevante. A adequação desse ecrã depende da complexidade do pedido e das condições de implementação da plataforma.

1. Indique a ação que a pessoa acabou de selecionar.
2. Explique por que motivo essa ação necessita do acesso pedido.
3. Descreva um percurso prático que não exija acesso, caso exista.
4. Prossiga para o fluxo verificado da plataforma sem acrescentar pressão.

A redação deve permanecer coerente entre a funcionalidade, a explicação ao nível da aplicação e qualquer texto controlado pela plataforma que a equipa possa configurar. Uma divergência cria ambiguidade, mesmo quando cada frase parece razoável por si só. Analise estas superfícies como uma única transição, reconhecendo simultaneamente que a parte da plataforma poderá ter restrições que a equipa de produto terá de confirmar durante a implementação.

Modele estados de permissão, não apenas avisos

Um modelo de estados é um mapa das condições que uma interface pode encontrar e da resposta atribuída a cada uma. Para uma funcionalidade dependente de uma permissão, o modelo deve abranger mais do que a decisão inicial. Poderá ter de distinguir entre acesso disponível, indisponível, limitado, desconhecido ou alterado fora do fluxo atual, consoante aquilo que o ambiente de destino realmente disponibiliza.

Um modelo de estados completo impede que a lógica das permissões se espalhe por ecrãs não relacionados sob a forma de exceções dispersas. Também ajuda as equipas de design, engenharia e controlo de qualidade a debater as mesmas condições. Cada estado deve conduzir a uma resposta útil da interface, em vez de conduzir a um impasse ou a um pedido repetido que já não faça sentido.

• O acesso disponível conduz diretamente à funcionalidade pedida.
• O acesso indisponível preserva as funções não relacionadas e explica a limitação.
• O acesso limitado adapta a funcionalidade quando o estado verificado da plataforma o permite.
• O acesso desconhecido aciona o ponto de decisão contextual adequado.
• O acesso alterado atualiza a interface antes de prosseguir outra ação dependente.

Analise a necessidade, o momento e a recuperação

A análise das permissões pode ser realizada funcionalidade a funcionalidade antes da implementação e repetida quando a funcionalidade mudar. O objetivo não é produzir uma regra universal. O objetivo é tornar visíveis os pressupostos, sobretudo os pressupostos sobre aquilo que a plataforma suporta, a quantidade de acesso de que a funcionalidade necessita e se uma alternativa é verdadeiramente útil.

1. Necessidade: a ação pode funcionar sem este acesso ou com um âmbito mais restrito?
2. Momento: que evento iniciado pelo utilizador dá ao pedido um motivo claro?
3. Explicação: que pormenor é necessário antes da decisão e qual pode esperar?
4. Alternativa: que percurso útil permanece disponível se o acesso estiver indisponível?
5. Recuperação: como deve a interface responder se o estado mudar posteriormente?

A análise deve incluir o percurso de regresso, além do percurso do pedido. Se o ambiente suportado disponibilizar uma forma de reconsiderar o acesso, a aplicação pode explicar a situação da funcionalidade dependente sem pressupor a decisão seguinte. Se a reconsideração estiver indisponível ou for inadequada, a interface deve evitar apresentar controlos que não possam concluir a ação pretendida.

Crie confiança com uma sequência de permissões coerente

Uma estratégia moderada de permissões decorre de algumas decisões interligadas: pedir apenas aquilo de que uma funcionalidade definida necessita, aguardar por um contexto relevante, explicar a finalidade imediata e conceber todos os estados verificados. A confiança não é uma mensagem separada que se acrescenta ao aviso. A confiança reflete-se no facto de a sequência permanecer compreensível antes, durante e depois da decisão.

O passo prático seguinte é escolher uma funcionalidade dependente de uma permissão e mapear todo o seu percurso. Assinale a ação desencadeadora, a explicação controlada pelo produto, a transição controlada pela plataforma, os estados possíveis, a alternativa e o percurso de recuperação. Esse mapa proporciona à equipa uma base concreta para eliminar acessos desnecessários, corrigir momentos inadequados e tornar as restantes escolhas mais fáceis de compreender.