Arrête de faire ton Homer !

La semaine dernière j’ai lu Subcompact Publishing, une très longue et très complète analyse par Craig Mod des applications de magazines numériques.  Il part de l’exemple de la version iPad du magazine Vanity Fair qui nécessite plusieurs écrans d’explications pour comprendre comment s’en servir. Et il répond alors magnifiquement à la question : « Comment en sommes-nous arrivés à des interfaces si complexes ? »

Peut-être que nous avons fait nos Homer.

Quand il a été demandé à Homer Simpson de créer sa voiture idéale, il a créé The Homer. Sans retenue, le processus d’Homer était additif. Il ajouta trois klaxons et une bulle spéciale insonorisée pour les enfants. Il ajouta plus à tout ce que les voitures étaient déjà. Plus de klaxons, plus de porte-gobelets.

La voiture d'Homer Simpson

Dans le design de produit, l’exercice le plus facile est de faire des ajouts. C’est le moyen le plus facile pour faire d’un vieux truc un nouveau truc. L’exercice le plus difficile est de reconsidérer le produit dans le cadre du présent. Un cadre qui peut être très différent de ce moment où le produit avait été initialement conçu.

C’est une parfaite illustration. La prochaine fois que je me surprendrais ou surprendrais l’un de mes collaborateurs à vouloir ajouter des fonctionnalités sans queue ni tête à un site, je n’aurais qu’une chose à dire : « Arrête de faire ton Homer ! ».

  1. Wan, le

    « Il semble que la perfection soit atteinte, non quand il n’y a plus rien à ajouter mais quand il n’y a plus rien à retrancher » Saint-Exupéry

  2. Chris, le

    Etant dans le développement logiciel c’est un un débat que je rencontre souvent !

    Au fil du temps on essaie de rationaliser les choses :
    – créer dès le départ un produit « ouvert » et essayer d’anticiper au maximum les changements
    – éviter de tomber dans la surenchère de fonctionnalités et se poser la bonne question : « cette fonctionnalité est-elle réellement utile ? Ne va-t-elle pas ajouter trop de complexité pour finalement un gain minime ? »

    Malgré cela arrive le moment où on est obligé d’ajouter des fonctionnalités « nécessaires » et qui s’inséreront difficilement à notre produit de départ, c’est inévitable.
    Au bout d’un moment on se retrouve donc avec un produit « patché » qui devient de plus en plus difficile à maintenir et difficilement compréhensible par l’utilisateur.

    Au final il n’y a pas 36 solutions : si on veut éviter d’en arriver là il faut tout reprendre du début, « reconsidérer le produit dans le cadre du présent ».

    Le problème c’est : à quel moment prendre cette décision qui demande du courage et de l’investissement ?

    Car au final ça coûte moins cher de rajouter des patch par-ci par-là que de redévelopper un produit de 0.
    Il est également moins perturbant pour un ancien utilisateur de voir apparaître une nouvelle fonctionnalité dans une interface existante que de voir un changement complet de toute l’interface !

    C’est donc un sujet qui est loin d’être simple, surtout quand on prend en compte les intérêts économiques (à courts termes).