2.2. Análise das especificações avaliativas do desenho de interface
Antes de se realizar qualquer protótipo de desenho de interface, deverão ser conhecidas as condicionantes que determinam todo o processo criativo. Esse cadernos de encargos de condicionantes a respeitar nasce da relação com o cliente, das linhas directrizes relacionadas com direitos de autor e das especificações do trabalho de conteúdos interactivos da equipa editorial. Considera-se que a seriação dessas mesmas condicionantes é o primeiro input do trabalho do designer e do engenheiro de software.

O segundo input de dados deve acontecer após a primeira fase de testes do protótipo, determinantes quanto a sua real exequibilidade. Como atrás se referiu, existem alguns métodos para testar a fluência interactiva de uma dada aplicação multimédia e de entre todos selecciona-se o método de Jakob Nielsen, um consultor e autor de obras sobre o tema. Nielsen descreve o seu método que se baseia num conjunto heurístico de parâmetros que servem como teste para a efectiva operacionalidade do desenho de interface e do respectivo sistema interactivo.

Status de visibilidade do sistema
Qualquer aplicação deve manter o utilizador sempre informado sobre o que está a ocorrer, proporcionando um feedback apropriado, em tempo razoável.

Coincidência entre output do sistema e o mundo real
O sistema deve "falar" o nível da linguagem dos seus utilizadores com palavras, frases e conceitos que lhe sejam familiares, em vez de adoptar termos orientados para a própria linguagem do sistema. Deverá ainda seguir as convenções do mundo real, fazendo com a informação surja de uma forma lógica e natural.

Controlo e liberdade do utilizador
Acontece com frequência que os utilizadores escolhem funções erradamente. Será necessário prever o erro bem como a estratégia de remediação que, neste caso, se traduz por uma "saída de emergência" que permite abandonar a função indesejada sem passar por um longo processo retroactivo. Neste aspecto são paradigmáticas as funções de "undo" e de "redo".

Consistência e normalização
Os utilizadores não deverão ser sujeitos a um esforço de descodificação para adivinharem se palavras, acções ou situações diferentes significam uma e a mesma coisa. Será importante respeitar as convenções que definem e caracterizam o suporte sobre o qual se desenvolve uma dada aplicação.

Prevenção do erro
Um design bem estruturado é sempre preferível a um bom conjunto de mensagens de erro, dado que uma estrutura aperfeiçoada de design é a primeira a prevenir a ocorrência do erro.

Prevalência do reconhecimento sobre a recordação
É necessário dar visibilidade total a objectos, acções e opções. O utilizador não deve ser obrigado a recordar informação ao transitar de uma secção da aplicação para outra. As instruções para o uso de uma aplicação devem ser visíveis e imediatamente acessíveis seja qual for o ponto da aplicação onde o utilizador se encontrar.

Flexibilidade e eficiência de utilização
Tanto a flexibilidade como a eficiência de utilização deverão ser parametrizadas para dois tipos de utilizadores: os caloiros e os veteranos. Aconselha-se a utilização de aceleradores (macros, shortcuts, etc.) que acelerem a eficácia de procedimentos do utilizador veterano e que poderão ser temporariamente invisíveis para o caloiro. Em ambas situações deve-se admitir que os dois grupos configurem a aplicação â medida das suas capacidades.

Informação objectiva e essencial
As janelas de diálogo nunca deverão conter informação irrelevante, ou raramente necessária. Cada unidade informativa a mais dentro de uma caixa de diálogo compete com unidades essenciais de informação e diminui a sua visibilidade de modo relativo.

Potenciação do reconhecimento, diagnóstico e recuperação de erros pelos utilizadores
As mensagens de erro devem ser expressas em linguagem padrão (sem qualquer espécie de codificações), devem identificar o problema com precisão e sugerir uma solução de forma construtiva.

Ajuda e documentação
Muito embora se considere que qualquer aplicação deve poder ser usada sem documentação escrita complementar, é de considerar o fornecimento de materiais escritos com ajuda e documentação. Esta forma de apoio deve ter um enfoque nas tarefas que o utilizador vai desempenhar, deve ser fácil de pesquisar e não deverá ser demasiado extensiva.

As regras de Jakob Nielsen devem ser combinadas com outras metodologias, tais como testes aos utilizadores, escolhidos dentro do público-alvo a que a aplicação se destina. Assim também se recomenda uma participação global da equipa de desenvolvimento nas opções de design. Esta participação assenta sobre as regras do brainstorming criativo e as linhas mestras das decisões deverão sempre ser pautadas pelas indicações saídas dos testes feitos por amostragem significativa junto dos utilizadores.
Muitas casas de edição de software consagraram o hábito de mandar proceder à divulgação e distribuição de versões beta de aplicações que ainda não estão 100% isentos de erros. Esperam que sejam os futuros utilizadores a procederem ao levantamento das falhas existentes na versão beta do programa, através da sua utilização experimental. Os erros existentes nessas versões beta, deverão ser assinalados e comunicados às casas de edição para correcção em versões posteriores, bem como o conjunto das sugestões que os futuros utilizadores entenderem como interessantes. Embora à primeira vista tal procedimento possa parecer pouco ético, a verdade é que a procura da novidade por parte do utilizador leva a que firmas como a Microsoft e outras de grande prestígio considerem ser "prova de distinção" feita a clientes especiais, a entrega de uma versão de um dado programa onde à partida se sabe existirem deficiências para sobre ele ser feita a experimentação formativa. É evidente que a distribuição da versão beta de um programa não irá ser testada da mesma forma por todos os utilizadores que a ela tiverem acesso. Competirá a quem tem responsabilidades na distribuição da aplicação estabelecer um painel coerente e suficientemente alargado de utilizadores capazes de responderem com eficácia às expectativas da equipa que desenvolveu o programa.
Neste tipo de experimentação as equipas de desenvolvimento definem um conjunto de objectivos a atingir com o lançamento do teste e procuram estabelecer um painel que tipifique o público-alvo e os objectos que é necessário atingir para poder concretizar versões finais na área do design e da engenharia de software.
Em lugar de controlar de modo rígido o tratamento da informação e as modificações que de versão para versão vão sendo feitas - tal como é prática habitual na experimentação convencional - a experimentação formativa, cria um dado modelo, entrega-o a uma amostragem do público-alvo a atingir e procura, através da observação sobre o modo como o programa é utilizado e das observações recebidas, determinar se os objectivos iniciais foram ou não concretizados. A eficácia deste processo depende naturalmente do grau de motivação do público-alvo escolhido para testar o programa. O teste realizado sobre o Windows 98, foi distribuído pela Microsoft a nível planetário, numa versão beta. A habilidosa campanha de marketing e as expectativas por ela geradas motivaram uma verdadeira corrida dos utilizadores que desejavam ter o privilégio de testar o novo sistema operativo. Esta experimentação formativa realizada individualmente e em muitos laboratórios por dezenas de milhares de utilizadores com configurações informáticas específicas permitiu uma revisão sistemática de conceitos e procedimentos aos seus autores. A ergonomia com que o sistema foi apresentado na sua versão definitiva só foi possível graças à contribuição de muitos milhares de utilizadores anónimos e de firmas de desenvolvimento de aplicações, que voluntariamente trabalharam para aumentar a eficácia do modelo e, de modo indirecto mas exponencial, a fortuna de quem é hoje considerado o homem mais rico do mundo.

Menu do curso

Menu principal