Rules for Web Design

While some companies strive to make the web experience of their users better, this is not the goal of airlines companies, banks and other large administrations. For those entities, discouraging user is a far more important goal, and web design must be aligned with this objective. To achieve this goal, the following rules of web design must be strictly adhered to:

  • Use flash – in particular for interactions that are mostly text based. The expensive marketing campaign must be amortised. For best results, have an heavy, loud, and complex animation that can only be skipped once it has loaded on the front-page.
  • Request the users selects a country on the front-page. Afterwards, redirect them to a web-site with a different url but basically the same content. This effectively destroys the cookies and passwords saved by the browser. Security is important!
  • Use multiple identifiers. Your internal system has three different databases with different primary keys. The user must be made aware of that. You company is only a single entity for corporate reasons, not to make the user’s life easier.
  • Even when the user is logged in, and has provided you with profile data including name, address and identifiers, do not pre-populate the form with this data. This form of auto-population is not accessible to the worker in the call-center in India, you do not want the users to have a different experience. Remember the data you collected is needed for doing marketing research on why the users are unhappy, not make them happy.
  • Maximise the latency for the various form controls. For instance use a drop down with all the countries, this effectively prevents the browser from auto-filing, add indentations in the text so typing a letter to jump to a country will not work. Do not pre-select the country the user was forced to selected earlier.
  • Add form validation code, but avoid any type of normalisation, do not tolerate spaces or dashes in phone numbers: there is no dash or space key on a phone, for bob’s sake!
  • Avoid using the Html5 e-mail and number specific input fields. If the user uses a tablet or mobile phone, they should use the full size keyboard. If the user is prevented from entering characters that are illegal in e-mail addresses, then your validation code will be useless.
  • Avoid any form of automatic form filling, if the user entered a postal-code, he knows the name of the city, and pre-filling it would be an insult to their intelligence.
  • When a form is entered, send an e-mail with an incident number, but make sure nothing can be done with the incident number, no web tracking, no field to enter it in web form.
  • When answering the user by e-mail, do not let the user answer to the e-mail. Instead require them to use a web-form. Do not refer to the web-form using an url, instead explain in the email’s text how to navigate to the form in web’s site hierarchy.

This list is of course not exhaustive, the key is to maximise the annoyance. Remember that a user than managed to communicate once has a higher probability of trying to communicate again.

5 thoughts on “Rules for Web Design”

  1. Pfff, tout ça est de la petite bière à côté du site de SAP.

    Pas grand public certes, mais rien ne vaut un site qui redemande utilisateur et mot de passe à chaque fois qu’on change de serveur dans son cluster de serveurs web ; qui indique les liens en écrivant où il faut cliquer ; où chaque texte semble écrit par un communicant payé au caractère ; où un quart des pages pointe vers des têtes de site web ; où un moteur de recherche est incapable de trouver une simple note publique par son numéro ; qui permet de télécharger des exécutables nommés 512368.zip (et il y en a des modules à télécharger, dans un produit SAP ; ensuite on s’amuse à identifier les zip de ce qu’on a téléchargé) ; où le téléchargement échoue une fois sur deux silencieusement, y compris avec l’outil de téléchargement maison (lequel est incapable de connaître tout seul l’URL de son serveur) ; etc.

    Y a des webmasters à fusiller…

  2. Suggestion : empêcher toute forme de deep linking afin d’empêcher l’utilisateur de revenir rapidement à une ressource utile.

  3. @July : Non, ne pas empêcher le deep linking. Juste changer la structure du site de manière aléatoire pour qu’ils ne fonctionnent plus après 2 semaines.

    Y compris depuis les applications livrées par l’entreprise (je sais pas, moi, comme quand BusinessObject a été bouffé par SAP et que toute l’aide en ligne de Webi a été remplacé par un Powerpoint de 40 pages sur comment naviguer dans le site de SAP).

    J’oubliais : tous les liens doivent s’ouvrir dans une fenêtre séparée ouverte en Javascript pour interdire toute navigation par onglet. Comme sur Priceminister.

Leave a Reply to Jess GrinneiserCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.