Um amigo pode estar confuso, um amigo pode não entender o programa. Um amigo não é um programador, não é um desenvolvedor, ele não trabalhou por muitas horas no programa e, portanto, não conhece todas as nuances do programa (às vezes os desenvolvedores não conhecem todas as nuances de seu programa). No estágio inicial de trabalho com o aplicativo, um amigo não sabe como usar o aplicativo. Somente com o acúmulo de experiência com o aplicativo, o usuário aumenta seu nível de proficiência no aplicativo.
Deixe um amigo estar confiante em trabalhar com seu aplicativo, esteja confiante
O amigo pode estar confuso sobre o que está acontecendo atualmente no programa. Isso cria incerteza para o amigo no curso de seu trabalho. Torne as informações sobre o estado do programa óbvias para um amigo, não para um programador. Isso lhe dará confiança no que o aplicativo está fazendo agora e, assim, permitirá que você tenha confiança em suas ações com o aplicativo para seu amigo. Certo.
Crie um cenário de comunicação lógica e óbvia entre um amigo e seu aplicativo
Um amigo executa uma ação e o aplicativo responde à ação. Forneça feedback sobre as ações de um amigo com seu aplicativo. A ação realmente ocorreu ou ocorreram alguns erros, o amigo obteve o resultado esperado ou apenas parte do resultado e outras ações são exigidas do outro? Quais ações? O amigo sabe sobre essas ações? Seu amigo se esqueceu dessas ações?
Um amigo pode estar nervoso, com pressa, ou simplesmente essa informação "sumiu" por um momento e não foi lembrada por um amigo naquele momento.
O aplicativo fornece mensagens consistentes para que um amigo seja guiado não apenas pela natureza do feedback, mas também pelas características externas do feedback, e pode entender muito por atributos externos? As características do feedback de um amigo se confundem ao longo do tempo, em diferentes partes do aplicativo, com ações diferentes?
Um amigo pode olhar rapidamente a mensagem, na interface, ficar desatento, distrair-se.
, , , ? , ?
. , . , , .
, , , - « »?
?
, . , , , . , , , .
, , , . . .
, . , .
.
? ? ? ? DNS ?
, , , , . .
, , . , . , , . .
, , ? ( .)
, , . ?
, , , , , ( ).
? ? ? ?
, – . .
, , .
. . . . . .
« ». - . , . , , , - , .
, ?
« ». , . .
, « ». , . -, , .
, , , ? , , ?
. . , .
.
, , , . , .
, , . , , .
. . , , , . , , . , .
, «» «», , , , , . , .. .
. .
.
, . , , , , .
, , , , ?
, .
, , . , .
, , , . .
, , , .
Deixe seu amigo saber que você cometeu um erro e descubra como se recuperar de um erro
Um amigo tem o direito de cometer erros. O programador pode dizer quando um amigo pode cometer um erro e a melhor forma de se recuperar do erro.
Deixe um amigo explorar o aplicativo de maneiras diferentes. Vamos até ler a documentação
Um bom aplicativo não requer documentação, mas um amigo pode querer saber como atingir seus objetivos em seu aplicativo.
PS Como você entendeu, essas são as 10 heurísticas clássicas de Jacob Nielsen . Apenas de um ângulo ligeiramente diferente. Obrigado a quem leu.