Como anda a resposta do seu software?

Olá!

Ao mexer num software interessante, você clica em um botão e espera, espera, espera…. logo vai pensando: Será que travou? Clico de novo? Fecho o software? Ctrl+Alt+Del? kill process? E de repende a operação é executada. Com certeza esse software tem um problema de resposta.

Antes de tudo vamos falar sobre o tempo. Para não ser muito filosófico, falarei sobre o tempo do relógio e o tempo percebido.

O tempo do relógio é o tempo absoluto: 2 minutos, 1 hora, 4 segundos… esse tempo é absoluto e medido por meios físicos. Óbviamente quando mais rápido um software executar uma tarefa melhor .

O tempo percebido é quando tempo alguma pessoa sente que demorou um evento. É totalmente relativo ao evento e à pessoa. Vamos simplificar a medida apenas com os valores “rápido” e “devagar“. Por exemplo, você passar o dia inteiro com a pessoa que você ama, na sua cabeça o dia passou muito rápido. Mas ficar esperando 1 hora alguém chegar, o evento aconteceu muito devagar. A melhor definição de software lento que eu vi de um usuário foi que o uso do software era “um suicídio” .

Nesse sentido, a resposta do software é muito importante diminuir o tempo percebido de uma tarefa. Como? No livro Gui Bloompers, dá umas dicas baseado na percepção humana para tempos absolutos para respostas:

• 0.1 segundos : Esse é  tempo de causa-e-efeito da percepção humana. Por exemplo, se algum objeto vier em sua direção, você irá demorar aproximadamente 0.1 segundo para iniciar a reação de defesa. Para UX, deve ser a resposta para as ações simples, como a indicação que um botão foi clicado ou uma caixa de diálogo apareça.

• 1 segundo: Esse é o espaço de tempo na mudança de um interlocutor de uma conversa. É o tempo que você processa a informação que uma pessoa de passou e começa a responder. Logo, uma tarefa simples é ideal que demore em torno de um segundo, como a validação de um cadastro.

• 10 segundos: Esse é o tempo limite que o ser humano se concentra numa espera de uma resposta. Depois disso a concentração é perdida. Por isso que um processamento complexo tem que dar respostas em 10 e 10 segundos, como um processamento muito pesado (atualizar a barra de progresso). Depois de 10 segundos sem resposta, o usuário vai achar que o software está com bug ou morreu de vez e pode tentar reexecutar a tarefa ou fechar o software.

Logo, uma tarefa demorada, é muito importante que avisamos ao usuário que tal operação vai demorar mas que o software está trabalhando no momento. Se avisar em quanto tempo irá terminar a tarefa melhor ainda.

Um detalhe muito importante também levantado no livro Gui Bloompers é o fato que desenvolvedores têm computadores melhores que os usuários reais. Em casa ou nas empresas de TI o desenvolvedor tem uma máquina parruda, pois ter programas servidores, IDES e o processo de compilação consomem muito recurso, mas o usuário comum tem muitas vezes computadores medíocres, telas minúsculas e conexões lentas. Portanto, é muito importante testar a resposta do software no ambiente real e sempre avise que a tarefa pode demorar!

Finalizando, sempre dê um enfoque maior ao tempo percebido do que o tempo real em software que o foco de uso é o usuário, se ele acha que o seu software é lento ou é devagar , ele com certeza vai perder a paciência! Faça-o perceber que é rápido que o usuário não irá reclamar de performance.