Lista de verificação de design de recursos

Lista de verificação de design de recursos

Como designer de UX de uma equipe que está trabalhando em um aplicativo relativamente novo, eu principalmente desenho novos recursos, em vez de melhorar ou renovar recursos existentes. (O dono do meu produto continua me prometendo que isso vai mudar quando estivermos “com a funcionalidade completa”. Considerando a realidade do nosso mundo ágil, isso pode ser o equivalente ao décimo segundo do desenvolvimento de produtos, amirite?)

Quando nós (o desenhista comunitário) estamos produzindo recursos, é fácil perder aspectos cruciais, porque as coisas que desenhamos são complexas – é isso que torna nosso trabalho maravilhosamente excitante!

Para aliviar isso, colecionei uma lista de perguntas – mais como uma arenga de perguntas – que continuam recorrendo às discussões da equipe. Isso é na esperança de capturar a maior parte das possíveis armadilhas de um recurso antes que qualquer código seja escrito. Também pode ser visto como uma tentativa de formalizar algumas das considerações que entram no planejamento de recursos de software. Pense nisso como uma avaliação heurística preliminar das sortes.

Em termos de processo, o momento mais apropriado para analisar essas questões é quando você tem uma ideia de ambos:

1. o que o usuário precisa é que você está tentando endereçar (idealmente verificado para ser uma necessidade real do usuário)
e
2. como você está planejando resolvê-lo.

Como nunca se deve ir pela primeira ideia, você idealmente teria explorado algumas soluções diferentes. Talvez estes estejam na forma de esboços brutos ou protótipos lo-fi, ou você pode perguntar a eles no estágio de refinamento, antes que qualquer implementação de código comece. Espero que, no momento em que o desenvolvimento estiver na metade, você saiba as respostas para a maioria deles. Eles também podem ajudá-lo a descobrir qual das soluções propostas é a mais adequada.

Com isso estabelecido, vamos para as perguntas!

1. Meta
Qual é o objetivo de usar o recurso? Por que o usuário está escolhendo fazer isso? Defina isso no começo para evitar perder de vista a intenção. Isto virá a calhar mais tarde, quando o nariz fundo em uma pilha de detalhes e escorregamento de escopo em configuração.

2. Padrões Existentes
Esta é uma função comum em outros aplicativos? Isso poderia ser, por exemplo, gerenciar uma lista de itens, incluindo adicionar um item, reclassificar a lista ou executar uma exclusão em massa em vários itens. Para uma funcionalidade típica, como a lista de itens, as questões de acompanhamento seriam: Existe uma maneira estabelecida de fazer isso (com o qual o grupo de usuários de destino está familiarizado)? Existe um padrão ou diretriz conhecida para a plataforma em que o aplicativo está sendo executado? (Isso vale especialmente para dispositivos iOS ou Android.)

3. Paralelos conceituais
Se este é um conceito inteiramente novo, você pode abstraí-lo para termos mais gerais? Existe uma funcionalidade semelhante em algum lugar que compartilha a mesma abordagem da sua solução? Existem metáforas no mundo real ou no dia a dia dos usuários que você pode aplicar?

4. Conhecimento prévio
Também pode ser relevante pensar se certas coortes de usuários trazem de experiências anteriores para a mesa: Existe uma ferramenta onipresente na qual eles são especialistas? Isso influencia suas expectativas de como, digamos, importar obras? Ou até que ponto eles são usados ​​para salvar automaticamente clicando em “salvar”?
Para me colocar no lugar desses, lembro-me há quatro anos, quando fiz a transição do Illustrator para o Sketch: Controlar pontos de ancoragem no Sketch era ao mesmo tempo limitador e descontrolado. Honestamente, eu poderia ter desistido se o Sketch não tivesse muitas outras vantagens motivando-me a continuar.

5. Complexidade
Quão avançado é esse recurso? Essa é uma ação que os usuários encontrarão em sua primeira visita à interface do usuário ou é exclusiva para especialistas? Qual deve ser a importância desse recurso: uma estrada de tijolos amarelos deve estar levando diretamente a ela ou deve ser escondida para que os usuários iniciantes não tropeçam nela acidentalmente e quebrem alguma coisa?

6. Contexto físico
Qual é o contexto de usar o recurso? O ambiente dos usuários poderia influenciar o modo como eles processam informações ou operam a interface? Como o design pode ajudar a compensar isso? Você pode reduzir a complexidade ou o número de elementos, aumentar o contraste ou clicar / tocar em áreas?

7. Contexto temporal
O que acontece antes? O que os usuários costumam fazer antes de acessarem esse recurso? De quais partes do aplicativo elas poderiam vir? Você pode fornecer um caminho claro de volta à segurança, caso eles percebam que estão no caminho errado?

8. Trigger
O que desencadeia o uso desse recurso? Quando ou por que a necessidade ocorre? O acionador pode ser baseado em tempo, por exemplo, que há novo conteúdo atualizado semanalmente ou números que devem ser relatados no final de cada mês. Ou pode ser o próprio sistema solicitando que o usuário aja.
Em caso afirmativo, quão intrusivo o prompt deve ser? Como você pode evitar que o aplicativo chore lobo a menos que seja absolutamente necessário?

9. Configurações
Existem configurações que precisam ser configuradas antes que o recurso possa ser usado? O sistema lembra deles?

10. Condições Prévias
Existem condições prévias que precisam ser colocadas primeiro para que o recurso seja ativado? Ainda me lembro da frustração de tentar aprender Photoshop há meia vida: parecia que 80% das ferramentas não funcionavam, porque eu não sabia que era necessário selecionar uma parte da imagem primeiro para aplicar uma filtrar ou transformar. Como você comunica tal pré-requisito aos usuários?

11. Precisa saber
O usuário precisa de alguma informação para fazer escolhas sensatas antes de embarcar neste fluxo de trabalho? Existe alguma coisa que eles precisam ser capazes de ver para fazer escolhas apropriadas? Se você está levando o usuário para uma visão diferente, pode ser útil fornecer as informações necessárias?

12. Progresso
Existem operações envolvidas que levam tempo para serem executadas? Leva tempo para carregar certas informações ou inicializar um processo? Como você pode mostrar esse progresso para fazer os usuários se sentirem no controle? Os usuários podem continuar trabalhando nesse meio tempo ou é necessário impedi-los de mudar alguma coisa?
Se uma operação demorar mais que alguns segundos, fornecer uma maneira de cancelar é uma boa ideia. Onde o usuário é levado após o cancelamento? Você pode garantir que o sistema seja capaz de retornar ao estado anterior?

13. Feedback do sistema
Como os usuários sabem se uma operação foi bem-sucedida? O feedback é discreto, mas ainda é claro o suficiente? Existe uma maneira clara para os usuários desfazerem a ação?

14. Erros
Que tipo de erros podem ocorrer durante o uso do recurso? Se eles têm diferentes graus de severidade, isso se reflete em como eles são comunicados? Como você está ajudando os usuários a corrigir esses erros? Você incluiu atalhos para mais informações ou uma seção de ajuda? Temos uma piada em andamento na minha equipe sobre como incluiremos os números móveis pessoais de nossa equipe de suporte ao cliente para resolver casos de limite técnico, mas realmente você deseja fornecer todas as ferramentas e informações necessárias para as mãos dos usuários para que eles possam ajudar-se.

15. Freqüência
Com que frequência esse recurso será necessário? É algo que o usuário faz dez vezes por dia, uma vez por mês, ou algo que eles configuram uma vez e nunca olham de novo? Como consequência, quantos cliques, toques ou furtos devem ser executados? Você pode fornecer atalhos de teclado ou ações em massa para eliminar o imposto de navegação?

16. Acessibilidade
Em que medida a acessibilidade deve ser levada em conta? O recurso está acessível com um leitor de tela? Existe uma solução alternativa para operar sem um mouse? Não se esqueça de verificar novamente se há contraste suficiente, tamanhos de texto e daltonismo.

17. Funções do usuário
Se você tem diferentes funções de usuário no sistema, todos podem acessar esse recurso? Ou envolve informações confidenciais que apenas certas pessoas devem ter acesso? Os papéis não privados devem estar cientes de que há mais para ver, de modo que eles tenham a chance de pedir para serem atualizados?

18. Onboarding do usuário
Como será a primeira experiência de uso? Como os usuários devem ser integrados a esse recurso? Como você vai fazer com que eles entendam (e se importem) qual é o propósito do recurso e qual é o valor para eles? Como você vai fornecer apoio suficiente no começo sem atrapalhar? Novas listas de reprodução no Spotify, por exemplo, afirmam claramente que “esta lista de reprodução está vazia no momento”, seguida por um claro apelo à ação de onde encontrar novas músicas para adicionar.

19. estados vazios
Como deve o recurso se comportar quando não há dados, ou seja, seu estado vazio? Você pode ajudar os usuários a entenderem o que é a visão em questão, prenunciando o tipo de conteúdo que eles encontrarão aqui? Como você pode aproveitar esse momento para demonstrar como eles podem preencher a visão?

20. Restrições técnicas
Você já considerou problemas de hardware ou conectividade abaixo do ideal? A solução proposta ainda funciona quando usada em máquinas lentas ou telas de baixa resolução? Existe uma maneira de degradar graciosamente? Um exemplo clássico disso é desativar a reprodução automática de vídeos em conexões lentas.

21. Sistema de design
Se o recurso garantir um novo padrão de interação, você precisa atualizar o sistema de design ou a biblioteca de componentes?

22. Simplifique
É possível simplificar ainda mais o recurso? Corresponde ao resto da aplicação?

CONSIDERAÇÕES BONIFICADAS
23. Nomeação
Um recurso não tem nome? Bem, deveria. Seja deliberado sobre nomear as coisas desde o início, tanto na comunicação interna quanto externa (e torná-la a mesma coisa – escrever a documentação do usuário ou fornecer suporte é difícil o suficiente sem ter que lidar com a nomenclatura conflitante). Se você não fizer isso, alguém o rotulará de algo aleatório – e essas coisas tendem a se manter.

24. Publicidade
Como as pessoas aprenderão sobre esse recurso? Será por meio de um boletim informativo, uma atualização no site ou talvez uma notificação no aplicativo? Com base nisso, quais serão as expectativas deles? Será que eles já estão cientes do valor que essa atualização traz ou eles precisam experimentá-la para entendê-la completamente?
O risco inerente de material de marketing elaborado está definindo as expectativas erradas sobre os recursos ou a aparência e a funcionalidade do recurso. Então, quão bem a comunicação externa corresponde à experiência no produto?

25. Feedback do usuário
Como os usuários podem deixar comentários sobre esse recurso? É facilmente disponível, se eles vão procurá-lo? Como você pode solicitar feedback sem atrapalhar?

Naturalmente, algumas dessas perguntas podem não ser relevantes em certos casos. Basta ignorá-los para esta vez e passar para o próximo. Mas se consolar com o fato de que essa foi uma escolha consciente de sua parte, em vez de perder algo importante até depois do lançamento (porque confie em mim, essa não é uma sensação particularmente agradável).


Advertisement