Le gouvernement de Sa Majesté a produit, après un long congrès sur la question, le document Government Digital Service Design Principles — actuellement en version bêta — pour expliciter les principes qui devraient régir la conception des services en ligne en direction du public. Il ne s’agit pas de règles à prendre au pied de la lettre ni d’une liste des mauvaises pratiques à éviter. Il s’agit simplement d’un ensemble de 10 recommandations accompagnées d’exemples d’application pour inspirer les éditeurs de sites et les inciter à mieux travailler pour les citoyens.
Partez des besoins (des utilisateurs, pas du gouvernement)
Commençons identifier les besoins réels des utilisateurs au lieu de se focaliser sur les processus officiels de l’administration. Nous devons nous pencher sur ces besoins en interrogeant les informations dont nous disposons, sans parti-pris ni suppositions. Nous devons aussi nous rappeler que les utilisateurs ne demandent pas toujours ce dont ils ont besoin. Lire Introducing the Needotron.
Faites-en moins
Les sites du gouvernement ne devraient proposer que ce que le gouvernement peut faire. Si quelqu’un d’autre le fait déjà, faites un lien vers cette organisation. Si nous pouvons fournir des ressources (comme des API’s) pour aider les gens à faire des choses, fournissons-les ! Nous devons nous concentrer sur le noyau dur de notre action et éviter la dispersion pour faire des économies.
Partez des données
En général, on ne démarre pas un projet dans le vide : des personnes utilisent déjà nos services. Ce qui signifie que nous pouvons apprendre de leurs habitudes en situation réelle. Nous devons partir de là, mais aussi nous assurer de revenir sur le comportement réel des utilisateurs à chaque étape du projet, à commencer par les prototypes et les premiers tests.
Nous devons à chaque fois faire le lien entre les données et la manière dont nous les mettons en scène dans notre design. C’est un des grands avantages des services en ligne de pouvoir observer le comportement des utilisateurs et de modeler les services afin qu’ils correspondent à ce que les gens attendent.
Faites simple
Il est plus facile de simplifier l’apparence que l’utilisation, surtout lorsque l’architecture des systèmes est complexe — et c’est souvent le cas. De grands pouvoirs impliquent de grandes responsabilités : les gens n’ont souvent pas d’autres choix que d’utiliser nos services. Si nous ne travaillons pas durement pour les simplifier, nous abusons de notre pouvoir et faisons perdre du temps aux gens.
Faites des itérations encore et encore
La meilleure façon de construire des services efficaces est de commencer à petite échelle et d’améliorer au fur et à mesure. Sortez des versions minimum viables le plus tôt possible et testez-les avec des vrais utilisateurs. Passez de la version Alpha à la version Beta en ajoutant des nouvelles fonctions selon les retours utilisateurs. C’est une bonne manière de prendre en compte des besoins exprimés.
Les itérations réduisent les risques : elles rendent les échecs improbables et transforment les erreurs en leçons. On évite ainsi les spécifications de 200 pages qui se transforment en goulot d’étranglement. C’est encore un avantage du numérique : on ne construit pas des ponts ; on peut laisser tomber ce qui ne fonctionne pas et recommencer.
Tenez compte de l’ensemble de la population
Un design accessible est un bon design. Nous devrions fabriquer des produits aussi lisibles et accessibles que possible. Si nous devons pour cela sacrifier l’élégance, alors, sacrifions. Nous ne devons pas craindre l’évidence, nous de devons pas essayer de réinventer les conventions du web design. Nous travaillons pour l’ensemble des citoyens et pas seulement pour ceux qui ont l’habitude du web.
En fait, les gens qui ont le plus besoin de nos services sont souvent ceux qui les trouvent difficile à utiliser. Si nous pensons d’abord à eux au début du projet, alors nous ferons un site efficace pour tous les autres.
→ Lire How ARIA landmark roles help screen reader users
Comprenez le contexte
Nous ne concevons pas pour un écran, mais pour des personnes. Nous devons réfléchir longuement sur le contexte dans lequel nos services sont utilisés. Les utilisateurs se trouvent-ils dans une bibliothèque ? Surfent-ils depuis leur smartphone ? Connaissent-ils seulement Facebook ? Ont-ils tout simplement déjà utilisé le web auparavant ?
Nous créons des designs pour des groupes d’utilisateurs très divers avec des besoins et des technologies variés. Nous devons nous assurer de bien comprendre les aspects pratiques et circonstanciels dans lesquels nos sites web sont consultés. Sinon, nous risquons de faire de beaux sites inutiles.
Faites des services en ligne, pas des sites web.
Notre service ne commence ni ne finit sur nos sites. Tout peut débuter par un moteur de recherche et se terminer au bureau de poste. Nous devons en tenir compte, même si nous ne pouvons pas tout contrôler. Notre mission n’est pas de créer des sites web, mais des services en ligne. Ok, aujourd’hui le meilleur vecteur est le web, mais cela pourrait changer — et plus rapidement que nous l’envisageons.
Soyez cohérent, pas ennuyeux
Nous devons utiliser le même langage et les mêmes schémas directeur pour aider les gens à se familiariser avec nos services. A minima, il faut s’assurer que notre approche est cohérente pour que nos utilisateurs s’y retrouvent. Nous n’allons pas édicter des règles pour tout. Chaque projet possède sa propre identité. Ce qui unit les choses, c’est une approche cohérente qui facilite la compréhension et la confiance, quel que soit le médium utilisé.
Soyez ouvert, ça fonctionne mieux
Nous devons partager ce que nous faisons à chaque fois que nous le pouvons. Avec les collègues, les utilisateurs, avec le monde entier. Partagez le code, le design, les idées, les intentions, les échecs. Plus il y a de monde qui s’intéresse à votre travail et mieux il se porte : les bugs sont découverts, des alternatives sont suggérées. Le travail est plus facile.
La plupart des choses que nous faisons est possible grâce à la communauté open source et à la générosité des web designers du monde entier. Nous devons rembourser notre dette le plus souvent possible. Si nous distribuons notre code, nous obtiendrons un meilleur code en retour.
Traduit de l’article Government Digital Service Design Principles mis en ligne par Government Digital Service. Merci à ma timeline Twitter pour tout ses bons liens et en particulier à @Thierry_G pour celui-ci. Suivez-moi avec @br1o !
Ça se confirme, travailler pour les institutionnels c’est l’enfer : ils ont des tas de recommandations superbes… Mais impossibles à tenir quand on a lu le cahier des charges ! Je parle même pas du chapitre sur l’open source, en France ça se résume à du vol pur et simple des codes sources de vos CMS : affligeant !