Le paradoxe de la réalisation de sites

En effet, la longue expérience montre un étrange paradoxe qui est que malgré la méticuleuse attention portée à la réalisation, il arrive parfois que le résultat ne soit pas à la hauteur des espérances. On prévoit de belles pages avec visuels et niveau de titre et au final, le rédacteur laisse trois pauvres lignes avec du style en ligne.

La technique ne répond pas à toutes les demandes et situation, il est nécessaire d’établir une stratégie, et dans notre cas une stratégie éditoriale.

Les besoins des intervenants

Le chef de projet : Comment s’y prend-t-on ?

Le développeur : J’attends le graphisme

Le concepteur : J’attends le contenu

Le rédacteur : J’attends la gestion de projet

Attitude aberrante de chacun des protagonistes ? Pas tellement si aucune stratégie n’a été élaborée. Le développeur (back) a besoin de la structure de la base pour commencer, le concepteur (front) a besoin de la structure de la page et le rédacteur a besoin de la liste des contenus disponible sur le site.

Tout ce beau monde a donc besoin des mêmes éléments pour démarrer :

1. La liste de types de contenus
2. La liste des contenus

Définition de la stratégie éditoriale

Si on place le besoin de mettre en valeur les contenus du site de la meilleure manière ; il convient de les placer au centre de la conception. Voire même commencer par la phase de définition de l’ensemble des contenus du site.

Dans le déroulement d’un projet, tout devrait débuter par l’organisation des contenus et de la stratégie éditoriale. Travail attribué généralement à ce qu’on nomme un architecte de l’information et un directeur de rédaction web. Ces noms majestueux montrent la valeur importante de cette phase de définition.

Un projet peut donc se découper comme suit :

1. Définition de l’organisation des contenus et de la stratégie éditoriale
2. Définition de l’organisation de l’information (wireframe)
3. Définition de la navigation (arborescence)

Chacune des phases étant cadrées par les objectifs généraux du site en terme d’audience, de qualité, de coûts…(une phase 0 de prérequis)

Conclusion

Un projet web (itération plus précisément) peut se découper en 3 phases distinctes : la définition, la conception et la réalisation (+ test). Une phase ne peut pas commencer sans que la précédente soit finie ; sinon le projet patauge et les intervenants ne savent pas dans quelle direction aller.

La réussite d’un projet tiendra à une phase de définition complétée ; phase comprenant la définition de la stratégie éditoriale.

Le principe de content first évoque cette structuration de projet nécessaire aux problématiques de la compatibilité multi-supports.

Article inspiré par Content Strategy Within The Design Process.

Articles similaires :

1. La discipline de la stratégie du contenu par Kristina Halvorson
2. Stratégie pour la conception web orientée contenu
3. Stratégie pour l’accessibilité web
4. Comprendre les CMS (Content Management System)
5. Commencer par le contenu, pas par le créatif

En cette période d’évangélisme chevronnée, la mode du mobile/content first fait rage. Cependant, placer le contenu comme préalable à la conception, à la discussion avec un client n’est pas chose facile.

Dans les agences encore attachées à la vente de papier, il importe de pourvoir montrer à un client qu’on peut tout lui faire et qu’il ne sera pas déçu.

Pour palier ce travers, on voit apparaitre le principe de renoncement. Une sorte de réflexion sur soi-même (sur un site web en réalité) pour abandonner les fonctionnalités qui nous tenaient à cœur mais qui ne sont malheureusement pas du tout utilisées. Une grande période d’auto-flagellation numérique.

Si cette période de remise en cause peut être longue, vous allez voir que les suivantes ne vont pas couler de source. Si on se réfère à Jeff, il le met en gras : la clef de la réussite est la transparence.

Key to this promotion is transparency. Let the team into the designer’s world. Let them see what they do and how they do it, and let them experience the benefits that come from doing UX and design work. When all members of a cross-functional team can articulate the benefits of design activities such as,

• speaking with customers,
• understanding the business and competitive landscapes,
• constructing the information hierarchy,
• assessing visual communication,

On a une équipe, on a des clients/usagers, et l’équipe connait tout du projet, voire discute avec le client pour définir son besoin.

Soit, mais la transparence ne se décrète pas, elle s’assume. Elle doit faire partie du fonctionnement globale de l’entreprise (salaires, avantages, horaires…) ; comment avoir de la transparence dans les projets si les informations ne sont pas diffusées ?

Articles similaires :

1. La culture de la conception web, l’information
2. Stratégie pour la conception web orientée contenu

Concernant les sites d’informations

Un journal papier comporte les informations relatives à une journée. Ces informations perdent de la valeur avec le temps. Ainsi, les lecteurs ont tendance à se tourner de plus en plus vers les applications mobiles pour avoir des informations fraîches.
Le besoin d’interface « responsive » se fait sentir.

Les trois ingrédients d’un graphisme adaptable sont :

• Une grille flexible
• Des images/media flexibles
• Des media queries

Cependant ces trois éléments se rapportent à la structure ; la structure n’est constitue pas la conception. La conception est un rapport entre la forme et le contenu.

Comment peut on se pencher sur des sites adaptables ?

Travailler adaptable

Le travail de production se résume souvent à une succession de tâches. Une après l’autre de manière linéaire.
Pour un site adaptable, la procédure ne peut pas être similaire étant donnée la multiplicité des supports de visualisation (mobile, tablette…). Le process doit être différent.

Pour le site du Boston Globe, la phase de conception a été ponctuée de nombreuses questions de la part des développeurs à propos de la manière de naviguer : à quoi ça sert ? comment le contenu s’adapte ? Si je navigue au doigt ?… Un travail collaboratif.
L’équipe s’est principalement penchée sur la question de l’affichage sur mobile : importance des zones et contenus affichés…

En anglais dans le texte : Mobile First

Mobile First

Pourquoi le mobile avant tout ?

• Le trafic a explosé
• Nouvelles manière de naviguer
• Ecran étroit oblige à aller à l’essentiel

La question de contexte de pose-t-elle vraiment ? A-t-on de réelles volontés différentes sur un mobile ou sur un ordinateur de bureau ? A vrai dire, pas forcément, la question de contexte peut être (presque) éludée.

En effet, sur un ordinateur de bureau, les utilisateurs cliquent sur certaines zones d’un site tout simplement parce qu’ils sont perdus.
Sur un mobile, on s’approprie directement le contenu, tout est là.

Le contenu va déterminer ce que la conception doit mettre en valeur. La vision « mobile first » est une façon de simplifier l’expérience à son maximum.

Maquettage

Une étape à ne pas négliger est certainement celle du maquettage afin de pouvoir apprécier ses idées. Utiliser les dernières techniques de redimensionnement automatique des contenus.

Vérifier le résultat de son travail.. Comment le contenu s’adapte ? Comment un élément peut être mis en valeur ?
Tester, vérifier, refaire, répéter, et corriger.

La fondation flexible

L’orientation graphisme adaptable permet d’affiner les points bloquants d’une page. Cela signifie surtout, moins de code à écrire et une meilleure conformité.
Le web mobile permet de discuter de l’ajout d’éléments de manière progressive. Ce qui signifie une meilleur intégration au projet pour chacun.

Les choix d’un concepteur en chef se rapproche d’une certaine forme de tyrannie. Ses décisions pour une conception adaptable pourraient ne pas correspondre aux attentes des utilisateurs.
S’orienter vers la conception adaptable c’est en grande partie laisser à une équipe la possibilité de l’expérimentation.

Lire An Event Apart: The Responsive Designer’s Workflow.

Articles similaires :

1. 5 astuces pour la conception d’interfaces mobiles
2. TYPO3 : créer une version mobile de son site
3. Comment ruiner un design Web
4. ColorBox, plugin lightbox pour jquery
5. Trousse à outils pour commencer HTML5

Le site exemple

Le site pris pour exemple présente un logo trop petit, une navigation peu claire, un colonnage trop constant… des objectifs non affirmés (tient ça me rappelle des trucs).

Les propositions

Quelles sont les propositions des différents groupes, faites pour cette page d’accueil :

• Devenir membre
• Appel au don
• Proposition d’un jeu pour se familiariser avec le produit
• Navigation explicative sur les objectifs du site

La conclusion

La proposition de différentes idées pour la refonte de cette page a permis de dégager de réels parti pris. Même si on ne peut pas se réduire à penser que chaque idée est une bonne idée ou que le cumul de toutes les idées peut favoriser l’optimisation de cette page ; le dialogue a été très porteur.

D’ailleurs bien plus que quand une seule personne se charge de la conception.

If one person in charge of this page only relied on their own ideas, we may not [be] able to achieve the highest level of success,”

Il est fort probable que la refonte d’une page laissée à une seule personne ne permette pas d’atteindre un succès optimal. Le web est collaboratif, il est possible que la conception des sites doivent l’être aussi.

Articles similaires :

1. TYPO3 : les avancées après le T3UXW09
2. WhiteHouse.gov : la maison blanche participe au développement de Drupal
3. Un FrameWork mobile, mb.ile
4. Un calendrier partagé dans Thunderbird

Le FrameWork mb.ile permet aussi de mettre en forme des applications pour le mobile. Si on fait un tour sur les pages proposées, on trouve des exemples d’intégration très intéressants : mb.ile.

• Menu – menu déroulants, big menu, menu recherche avancée…
• Video player – lecteur vidéo en fond de zone de contenu
• Vertical slider – menu déroulant vertical de style carrousel
• Extruder – menu latéral fixe, rétractable

Articles similaires :

1. TYPO3 : créer une version mobile de son site
2. OpenFaces, un FrameWork ajax
3. Instant Blueprint, FrameWork CSS express
4. Easy, un FrameWork CSS/HTML/JavaScript
5. CSS FrameWork : Scaffold pour le développement rapide

Getting Agile with User Experience Research

L’expérience utilisateur s’attarde sur la recherche, la planification, la conception, et les tests. La méthode agile cherche la rédaction d’un meilleur code. Comment appliquer la méthode Agile à l’expérience utilisateur.

Quelles sont les différences :

Ces deux pratiques sont très proches et ne doivent être confondues. Ne pas se méprendre entre les méthodes comme celle du scrum (point éclair régulier) et celle de la conception orientée utilisateur (user-centred design). Avec l’UCD (user-centred design), les résultats d’un étape enrichissent directement la prochaine (étape) ; pour la méthode Agile, l’objectif est de créer un ensemble de briques (de code fonctionnel) pour ensuite les assembler : d’abord créer les feuilles de l’arbre pour ensuite les assembler aux branches.

Comment intégrer l’expérience utilisateur à un sprint de la méthode Agile ?

De manière générale, l’attrait pour la méthode Agile se révèle plutôt chez un concepteur UX que chez un chercheur en expérience utilisateur. La conception se rapporte à la réalisation de maquette (wireframe), de plans de sites et parfois de prototypes. La recherche s’applique à l’étude des pré-requis, à l’étude utilisateur, aux personas, aux scénarios et aux tests. Difficile de relier la recherche et la méthode Agile. La principe appliqué et partir d’un « Sprint 0″, qui démarre par la recherche et la conception (1 mois).

1 mois ? Fichtre, c’est pas très important. Ainsi, on part le plus souvent d’idée préconçues, et des avis de ses collègues. La majorité des structures partent d’un FrameWork Agile pour leur intranet et continue le travail sur l’UX en parallèle. La réalisation est facilité par le fait que les concepteurs sont aussi les utilisateurs finaux.

Comment qu’on fait, pour poursuivre la recherche durant la réalisation ?

On imagine très ben la conception s’intégrer à chaque sprint, mais pour la recherche ? En effet, souvent la recherche se place dans une opposition face à un fonctionnement existant.

Voici quelques exemples :

1. Tester avec un minimum de fonctionnalités, ou se focaliser uniquement sur le développement du sprint en question. Les sessions n’ont donc pas besoin d’être trop longues et les tests peuvent être réalisés avec plus de personnes.
2. A d’autres moments, tester l’ensemble du site, pour vérifier la cohérence générale, pour voir la modification des variables (de test)>
3. Au final, la méthode RITE (Rapid Iterative Testing and Evaluation) s’adapte à chaque éventualité.

La recherche représente une opportunité de parler avec les personnes qui vont utiliser le produit.

L’utiliser pour :

1. Découvrir des besoins
2. Tester une nouveauté face un existant

Comment je fais pour appliquer des tests à des sprint court ?Un sprint d’une semaine commence, souvent, un mardi, ainsi, les délivrables peuvent être prêts pour le vendredi. Les tests sont effectués le lundi matin, les résultats sont disponibles le lundi après-midi pour la revue.

L’équipe peut, de cette manière, faire le point sur les « issues » et les planifier pour le sprint suivant. Le responsable UX peut conseiller les problématiques de conception et proposer des mock-ups pour couvrir les manques dans le processus (suite à l’abandon de fonctionnalités lors du sprint).

Il est même envisageable de placer des besoins lors du test et créer des cas avec des nouveaux personas. Celà aide grandement à mettre en valeur les différents comportements parmi les utilisateurs du produit.

Merci, comment je fais ?

Un manière de faire est d’anticiper chaque délivrable tels que les objectifs business, les personas, les scénarios, et les revoir sans cesse de manière itérative.

Tant que le responsable UX reste malgré tout humain et peut se tromper dans ses choix, cette approche vous encourage à insister sur les éléments (réellement) importants. Les gens préfèrent parfois donner une réponse à un problème plutôt que de le résoudre durablement.

Cela arrive aux projets bancaires dans la création d’un tableau de bord à l’usage de quatre secteurs d’investissement. Au départ l’équipe projet furent sollicité à propos d’un processus générique, quelques personas rudimentaires et quelques maquettes. Les utilisateurs furent eux questionnés et les indicateurs à afficher furent revus. Après trois semaines et trois conceptions successives (itératives), la banque en sélectionna un seul. L’équipe de développement présenta un bandeau d’outils catégorisés par étape du cycle de vie.

Qu’est-ce que cela signifie ?

L’expérience utilisateur et la méthode Agile ont beaucoup à apprendre l’une de l’autre.

D’un point de vue expérience utilisateur, quand vous lancer une équipe sur un développement, en leur présentant des recherches préalables ; elles ont pleinement connaissances du contexte des évolution et leur utilité. Poursuivre les recherches durant la réalisation permet de garder l’équipe soucieuse des besoins des utilisateurs finaux.

D’un point de vue Agile, il n’y a pas de raison que la recherche et la planification se soit pas intégrée au sprint, afin de vérifier que la correspondance des fonctionnalités avec les considérations business, techniques, de conception. Les livraisons peuvent être dépendantes de réalités par rapport au besoin, aux spécification plutôt qu’être juste du code qui marche.

La recherche UX peut s’intégrer à un sprint aussi petit soit-il, pour assurer des tests aussi bien globaux que sur de petites fonctions.

Articles similaires :

1. Agile Carousel, insertion de données en JSON
2. TYPO3 : la conception agile
3. Appliquer les règles apportées par les FrameWorks CSS
4. L’expérience utilisateur aux orties, préférer l’objectif utilisateur
5. Stratégie pour l’accessibilité web

Lire Why Designers Should Learn Programming. Now.

Articles similaires :

1. L’ipad modifie la façon de coder les sites
2. CSS – Orienté Objet, ce qu’il faut savoir
3. La petite histoire de Mainframe
4. L’histoire des jeux videos
5. Tobias Stretch Reel I

Passionnant le quotidien des intégrateurs HTML et CSS qui chaque jour s’aventurent sur le terrain du HTML5 et du CSS3. Comment je fais pour la compatibilité navigateur, fournir du contenu accessible pour l’ensemble de mes utilisateurs ou laisser sur le bord de la route les victimes de la politique de Microsoft ?

Des solutions alternatives pullulent sur le web, certaines sont alléchantes mais peuvent demander des ressources humaine pour la mise en place ou bien des ressources matérielles pour garantir le temps d’affichage de ses pages. Chaque cas est unique, c’est la remise en cause de sa manière de travailler qui évolue, sa manière d’aborder la création de sites.

Voici quelques ressources pour passer à HTML5 en respectant la compatibilité multi-navigateurs.

• HTML5 ★ Boilerplate
• HTML5 Reset
• HTML5 form
• 28 HTML5 Features, Tips, and Techniques you Must Know

Articles similaires :

1. Les outils indispensables pour le HTML5 et le CSS3
2. HTML5, add-on pour Adobe Illustrator
3. HTML5 et la vidéo, Open Standard Media Player
4. Exemples de structure HTML5
5. Humble Finance: graphiques dynamiques avec HTML5

Le test A/B permet de sonder un nombre plus important de personnes, donc d’avoir un retour plus fiable sur la performance de certaines interfaces. Ce type de test propose l’avantage d’avoir un retour de la performance dans des conditions de production, sans perturber le fonctionnement global du site, puisque seule une petite partie des visiteurs est soumise aux tests.

Fixer les objectifs principaux

Pour mesurer le succès d’une batterie de tests, il est important de définir au préalable les objectifs à atteindre, par exemple :

• Augmenter le trafic
• Augmenter l’engagement utilisateur
• Améliorer la rentabilité de la publicité
• …

Quel que soit le test à mettre en place, insister pour appliquer qu’un seul type de test à la fois. C’est la seule façon de mesurer et de garantir les résultats : quand je mets le bouton à droite, la conversion utilisateurs augmente de 22%.

Le A/B testing n’est pas facile, non seulement, il faut définir les objectifs (un seul à la fois), mais aussi ne modifier qu’un seul élément à la fois. Cette manière de procéder est la seule permettant de bien valider si une modification est bénéfique et surtout d’en déterminer la raison véritable.

Oui, mais quoi tester ?

Une page bourrée de liens devant vous, des choix divers pour chacun des visiteurs du site, par quoi faut-il commencer ? Plusieurs pistes pour décider de la fonctionnalité à passer au banc d’essai.

• Séance de tests utilisateurs pour faire un bilan du site
• Solliciter ses meilleurs amis et ses collègues
• Fouiller les statistiques (analytics) du site
• User de la carte de chaleur (heatmap) pour voir où les usagers cliquent

Construire son test

On a l’objectif, on a les recommandations sur les améliorations à apporter ; maintenant, il faut définir le test. Pour cela déterminer les variations possibles de l’élément à tester.

Attention car trop de variations augmente les temps de tests et trop peu de variations peut donner des résultats peu significatifs. Il faut trouver le juste milieu.

Le test dépend de chaque site. Il est possible de s’inspirer de la concurrence pour commencer. L’exercice sera un savant mélange entre pertinence et créativité.

Conclusion

Le test A/B est très séduisant dans la forme, il peut permettre d’avoir des certitudes sur la mise en place d’une évolution sur le site de production : ça marche moins bien ou ça marche mieux. Seulement, pour qu’un test soit significatif, il faut que le protocole soit défini de manière rigoureuse par rapport à un objectif précis. D’une certaine manière, il faut que le gain par rapport au temps passé soit positif.

Lire Gathering variables for A/B split testing.

Articles similaires :

1. Specular et Selenium
2. RMLL Accessibilité des CMS
3. Interview du Guru de l’utilisabilité : Jakob Nielsen

Voici, les 10 principes en or pour le développement d’applications web par Fred Wilson :

1. Rapidité
2. Utilité immédiate du service
3. Le logiciel est le média
4. Le moins est plus
5. Programmable (par des développeurs)
6. Facile d’adoption (par des développeurs)
7. Architecture REST
8. Visible dans les moteurs de recherche
9. Propre
10. Ludique

Encore une fois, on a l’impression qu’une Web App doit ressembler à une interface de jeu vidéo. Pourquoi pas ? Mais c’est quand même l’utilité d’un service, la possibilité de le modifier, la cohérence de son architecture qui feront son succès.

Lire Fred Wilson’s 10 Golden Principles of Successful Web Apps.

Articles similaires :

1. CSS FrameWork : Scaffold pour le développement rapide
2. Rosemary, gestion de filtres pour le développement CSS
3. Ideose : le numérique pour le développement durable
4. ColorBox, plugin lightbox pour jquery
5. TYPO3 : Web Service / iPhone App