Regras de Ouro para Interfaces de usuários mal planejadas.


Artigo original: http://www.sapdesignguild.org/community/design/golden_rules.asp

Por Gerd Waloszek, Product Design Center, SAP AG – Last Update: 06/07/2006
O SAP Design Guild Website* esta cheio de 'dicas e truques' para desenvolvimento de boas interfaces, e ele não é o único na internet. Contudo podemos ver varios exemplos de péssimas interfaces em toda parte - muito mais do que os usuários gostariam de ver. Como pessoas que gostam de fazer exatamente o oposto do que se está propondo, pensamos que poderia ser uma boa idéia mostrar como desenvolver interfaces ruins. Assim selecionamos "Regras de ouro para interfaces de usuários mal planejadas" nesta página - por favor ajude a si mesmo (e faça o oposto). Iniciamos a página com 10 regras e estamos continuamente expandindo nossa coleção.
Nota: As regras são apresentadas na ordem inversa - as regras mais recentemente adicionadas vêm primeiramente. Em todos os outros aspectos, a ordem das regras é arbitrária e não reflete sua significancia.

*Nota do tradutor: [ros]

Regra de Ouro No. 15: Procure sempre o equilíbrio visual de sua aplicação.

external image ying-yang75.jpg

Razão: Fazer com que seus programas não se tornem distonados em relação ao Sistema Operacional e/ou outros Sistemas ou Utilitários fornecidos por você ou terceiros e mesmo que possam ser configurados não apresentem a qualidade visual ou funcionalidade equivalente.

Exemplo: Veja que comparando-se os programas e interfaces usados nos Windows 3 com o que se dispõe hoje em dia há uma diferença gritante em termos de aparência e funcionalidade. O mesmo ocorre em softwares de acesso a Internet ou Navegadores que a fim de implementar funcionalidades ou novidades acabam por comprometer a dinâmica de utilização ou posicionamento de componetes visuais em comparação com as versões anteriores e se tornam mais complexos de se utilizar se não acompanharem a mesma lógica dos Sistemas consagrados criados pelos hits do mercado.

Regra de Ouro No. 14: Não deixe usuários interromper processos demorados e/ou famintos por recursos.


external image hear_not.jpg


Razão: Fazer processos que coloquem o computador trabalhando ininterruptamente, garante aos usuários as paradas para um cafezinho e bate papo.

Exemplo: Iniciar um Backup ou reindexação quanto o usuário menos esperar. Não deixe que o usuário interrompa estes processos, ignore clicks do mouse e teclas pressionadas

    • Ta bom assim ai eu continuo
||


Regra de Ouro No. 13: Deixe de lado funcionalidades que facilitariam a vida dos usuários - Deixe-os fazerem da maneira mais difícil


external image tools.jpg


Razão: Funcionalidade adicional daria opções demais aos usuários e poderia confundí-los.

Exemplo: Quando os usuários querem adicionar itens a uma lista, permita que adicionem apenas no final da lista e então movam-nos para a posição correta. Isto é, não ofereça funcionalidade adicional para inserir itens em uma posição específica. Introduza erros que retornem o item para o final da lista quando os usuários já o moveu metade do caminho.

Exemplo: Não ofereça opção de selecionar múltiplos itens, por exemplo, para movê-los ou deletá-los. A opção de trabalhar em apenas um item é suficiente para os usuários - mesmo que demore um pouco mais.

Regra de Ouro No. 12: Destruir o contexto do trabalho depois de qualquer erro ou reação do sistema.

(Golden Rule No. 12: Destroy the work context after each system reaction.)
external image wischen.jpg

Reasoning: Destruindo o contexto do trabalho permite aos usuários que reflitam sobre o trabalho que está fazendo e perguntem para sí mesmo se está fazendo corretamente.

Example: Deselect selected screen elements after a system reaction (e.g. a round trip).
Example: Move HTML pages or tables that have been scrolled down by the user to the top after a system reaction (e.g. a round trip); in the case of multiple pages (e.g. in hit lists or document list) return the user to the first page.
||

Regra de Ouro No. 11: Take great care in setting bad defaults: contrary to the users' expectations, disastrous, annoying, useless – it's up to you!

external image aetsch.jpg

Reasoning: Bad defaults are a nice way to surprise users, be it immediately or – at best, unexpectedly – anytime.
Example: Set default options in Web forms so that users get unwanted newsletters or offers, have their addresses distributed, etc.
Example: Set the default option in dialog boxes on the most dangerous option, for example, on deleting a file or format the hard drive.
Example: In forms, set dates (or other data) on useless default values. For example, set the date for applying for a vacation on the current day.
||

Regra de Ouro No. 10: Spread the message of bad examples and live it!

external image cow.jpg

Reasoning: Examples are a perfect teaching method. But as we all know, bad examples are the best – they allure most.
Example: Just follow any of the other golden rules on this page, that's a perfect start.
Example: If you have to make presentations make sure that you include your bad examples in the presentations.
Note: Good examples are hard to find and typically criticized until nobody appreciates them anymore. Why waste time with unproductive discussions?
||

Regra de Ouro No. 9: Keep away from end users!

external image site_visit.jpg

Reasoning: You are the expert and know what users need – because you know what you need. Why should they need something else?
Example: If you think that a certain functionality is not needed don't implement it – why should other people need it?
Example: Many end users have many opinions, you have one. That's far easier and faster to implement.
Note: Doing without site visits saves your company a lot of time and money.
||

Regra de Ouro No. 8: Faça o uso de sua aplicação um desafio real !

(Golden Rule No. 8: Make using your application a real challenge!)
external image rocket.jpg

Reasoning: This teaches people to take more risks, which is important particularly in economically harder times.
Example: Do not offer an Undo function.
Example: Do not warn users if actions can have severe consequences.
Note
: If you want to top this and make using your application like playing Russian roulette, change the names of important functions, such as Save and Delete, temporarily from time to time...
||

Regra de Ouro No. 7: Faça com que sua aplicação funcione apenas com o mouse – Não permita qualquer tipo de atalho.

(Golden Rule No. 7: Make your application mouse-only – do not offer any keyboard shortcuts.)

external image mouse.jpg

Reason 1: This will make your application completely inaccessible to visually impaired users. Therefore, you can leave out all the other accessibility stuff as well. That will save you a lot of development time.
Reason 2: This will drive many experts crazy who used to accelerate their work with keyboard shortcuts. Now, they will have more empathy for beginners because they are thrown back to their speed.
||

Regra de Ouro No. 6: Hide important and often-used functionality from the users' view.

external image closed_eyes.jpg

Reasoning: This strategy stimulates users to explore your application and learn a lot about it.
Example: Place buttons for important functions off-screen so that users have to scroll in order to access them.
Example: Hide important functions in menus where users would never expect them.
||

Regra de Ouro No. 5: Eduque os usuários em Linguagem Técnica.

(Golden Rule No. 5: Educate users in technical language.)

external image laempel.jpg

Reasoning: Lifelong learning is hip. As many of us spend a lot of their time at the computer, it's the ideal stage for learning. Moreover, sociologists bemoan that people's vocabulary is more and more reducing. Applications with a challenging vocabulary can go against this trend.
Example: Always send URLs as UTF-8 (requires restart) (advanced settings in MS Internet Explorer)
||

Regra de Ouro No. 4: Use abreviação o máximo possível, particularmente onde não houver espaço suficiente para o termo completo a ser usado.

(Golden Rule No. 4: Use abbreviations wherever possible, particularly where there would be space enough for the complete term.)
external image abbrev.gif

Razão: Abreviações faz uma aplicação parecer mais profissional, principalmente se vc criar abreviações que são novas ou substituir as usadas normalmente.
Exemplo: Usar abreviações para nome do campos, colunas de titulos, botões textos mesmo se o espaço restrito não necessitar.
Exemplos: Use "dat." em vez de "data", "TolKy" em vez de "Tolerance Key", "NxOb" em vez de "Next Object" e muito mais.
||

Regra de Ouro No. 3: Faça o mais devagar possível o processamento !

(Golden Rule No. 3: Make it slow!)


external image snail.jpg

Example: Existem quase infinitas possibilidades de "como fazer" um software lento. Por exemplo, você pode incluir longas verificações finais ou loops depois de cada entrada de dados. Ou você pode forçar usuários passar por várias caixas de diálogos encadiados.
||


Regra de Ouro No. 2: Não obedeça padrões!


external image bad_designers2.gif

Exemplo: Não use elementos padrões da tela para a sua real finalidade, como uma simples seleção (ex.: use CheckBoxes em vez de RadioButtons porque eles parecem mais bonitos).
Example: Do not place menu items into the categories and locations they typically belong to (e.g. place "Save" in the "Edit Menu").
Example: Não coloque itens de Menu nas categorias e local onde eles normalmente deveriam ficar (ex.: Coloque "Salvar" no menu "Menu Editar").
||


Regra de Ouro No. 1: Mantenha os usuários ocupados fazendo trabalho desnecessários


external image bad_designer.jpg

Exemplo: É um "bom" hábito deixar os usuários entrar com dados que o sistema já sabe e poderia ter providos(os dados).
Exemplo: Deixar usuários entrar dados nos campo somente para falar p eles depois que não pode entrar c dados la (no campo). (ex: um aplicativo deixar voce entrar com datas no feriado ou fim de semanas e diz apenas depois que vc não pode trabalhar com essas datas).

||