115 Pratiques d'écoconception d'applications à architecture web, et plus...
Source CNUMR [BP_001_fr]GR491 - UX/UI 5. Less is More : Concentrez vous sur les fonctionnalités essentielles et simplifiez votre interface

Recommandation équivalente

Éliminer les fonctionnalités non essentielles

Identifiants

GreenITV2V3V4
10911

Catégories

Cycle de vieTiersResponsable
1. SpécificationUtilisateur/TerminalPO/AMOA

Indications

Degré de prioritéMise en oeuvreImpact écologique
545
Ressources Economisées
Processeur / Mémoire vive / Stockage / Réseau / Requêtes

Description

Plusieurs études (Cast Software et Standish Group, notamment) démontrent que 70 % des fonctionnalités demandées par les utilisateurs ne sont pas essentielles et que 45 % ne sont jamais utilisées. En réduisant la couverture et la profondeur fonctionnelle de l’application, on abaisse son coût de développement initial, sa dette technique et les impacts environnementaux associés.

On diminue ainsi mécaniquement l’infrastructure nécessaire à son exécution. Par ailleurs, à niveau ergonomique constant, plus l’application est pauvre fonctionnellement, plus elle sera simple à utiliser. Il faut donc réduire le plus possible la couverture fonctionnelle de l’application, en la centrant sur le besoin essentiel de l’utilisateur.

Détecter une fonctionnalité non essentielle est possible au moment de l’analyse de l’expression du besoin. La méthode MoSCoW, des ateliers, des wireframes (maquettes fonctionnelles) ou des prototypes avec tests utilisateurs permettent de vérifier l’utilité d’une fonctionnalité en amont de son développement.

Exemple

Les succès récents du Web – Google, Twitter, WhatsApp, Pinterest, Instagram, etc. – fournissent un seul service et misent sur une grande sobriété fonctionnelle.

Se poser, au moment de l’analyse de l’expression du besoin, la question : « Que se passe-t-il si on ne l’a pas ? ».

Respecter le principe YAGNI (You Ain’t Gonna Need It) de l’extreme programming : développez quand vous avez effectivement besoin d’une fonctionnalité, pas lorsque vous imaginez en avoir besoin.

Principe de validation

Le nombre …est inférieur ou égal à
de fonctionnalités dont l’utilité n’a pas été vérifiée avec un panel d’utilisateurs avant développement0 %