L’apparition du concept de séparation

Durant la première guerre des navigateurs (dans les 90′s), face aux problèmes d’interopérabilités et d’homogénéités du code des sites web, le W3C s’est mobilisé afin de définir des standards. Pour gagner la bataille, il a défendu les technologies comme CSS et xHTML qui concernent pour l’une la présentation et pour l’autre la structure. c’est actuellement de cette manière qu’on code les sites.

Dans les années 2000, cette idée de « séparation » s’est affirmée dans la rédaction de la spécification xHTML 2. L’idée était de défendre une pureté fonctionnelle entre la structure (HTML), la présentation (CSS) et le comportement (JS). Sauf que…

Les couches ne sont pas vraiment séparées

Quand, on rédige une feuille CSS, on dispose de comportement comme :hover (changement de propriété au survol de la souris) ou encore :before & :after (ajout d’un élément dans le document avant ou après une zone de contenu).

Il s’agit donc d’1 élément de comportement & de 2 éléments de structure présents dans la CSS => la séparation n’est pas stricte.

Comment cela ce fait-il que les couches ne soient pas séparées ? Tout simplement parce que les constructeurs de navigateurs l’ont décidé, ce n’est pas (plus) un objectif. Ils pensent que cela n’a pas lieu d’être. Et les spécifications le prouvent ; xHTML 2 est morte.

La divergence

Prenons l’exemple d’un lien avec un effet visuel lors du survol de la souris. Vous avez le choix entre passer par la CSS pour un effet :hover et/ou utiliser une petite pincée de JavaScript pour la gestion d’un comportement plus complexe.

Avec un changement de couleur géré en CSS et un effet (une opacité par exemple) en JavaScript, le comportement du lien est spécifié dans deux couches différentes : c’est ce qu’on appelle la « divergence ». Ce lieu de gestion subtile de l’effet de survol par deux couches différentes.

Avec la logique de « séparation », on est dans le noir&blanc ; avec la logique de « divergence », il y a du noir&blanc mais aussi un peu de gris.

L’intégration n’est pas la collage grossier de différentes couches mais plutôt l’emboîtement subtile de plusieurs technologies (ce qui définit, à mon avis, le principe de l’artisanat).

Conclusion

L’idée de « séparation » a été indispensable pour la défense des standards du web. Cette idée a permis de passer outre les soupes de tags (HTML), les CSS ou JavaScript en lignes. Cependant, l’expérience montre qu’il existe des zones de chevauchements entre ces couches ; qu’on peut nommer « Divergence ».

Si on doit encore défendre les standards avec fougue, il est réaliste d’accepter ce concept de « divergence ». Accepter la tournure prise par les technologies du web, c’est aussi comprendre pourquoi un intégrateur n’arrive à exprimer ses difficultés, pourquoi il faut avoir codé pour les comprendre…

Encore une fois le métier d’intégrateur n’est pas simple. Il faut de l’expérience et de la rigueur pour dompter la « divergence ». Après quelques années, il sera compétent pour faire de la conception d’interfaces à partir de ces principes. C’est pour cette raison qu’il doit devenir concepteur.

Je vous laisse lire l’article en anglais, bien plus complet que celui-ci : The separation of structure, presentation and behavior is dead.

Une idée simple

A la maison de l’outil à Troyes, on peut y visiter une succession de vitrines présentant les outils relatifs à un métier. Dans mon cas, je me suis imaginé gimp à la place du marteau, textmate à la place de l’établi ou encore l’explorateur de fichier en guise de ceinture pour ranger les clous.

Et puis je suis tombé sur cette phrase :

Travailler sur des systèmes abstraits de grande envergure nécessite d’avoir l’ensemble dudit système en tête. Quelqu’un a un jour comparé ce processus à la construction d’une maison faite en cristal précieux. Dès que quelqu’un vous distrait, l’édifice s’écroule et se brise en mille morceaux.

J’ai regardé mon code, je me suis relevé et je me suis dit : « en fait, je suis quoi, un orfèvre ? un calligraphe ? ». Et pensant à un reportage sur les cathédrales diffusés il y a quelques semaines, l’idée m’est revenue qu’on pouvait effectivement nous cataloguer comme des artisans.

Ils étaient bien payés, respectés, valorisés.

On sait que l’artisanat était composé de corporations, de confréries ; la formation de apprentis passait par le compagnonnage ; on y respectait des maîtres (une autorité).

Un centre de formation

Pourquoi pas alors reproduire ce principe de maître/apprenti ? C’est une idée, bien entendu, il faudrait le faire à la sauce web et technologie numérique.

Sans y coller le côté pompeux de titres, grades, etc ; on pourrait imaginer, plutôt que d’attendre qu’un cursus professionnel se mette en place, établir un principe d’apprentissage à partir de niveaux de maîtrise.

Sur des périodes diverses, 2 jours, 3 jours, 2 semaines ; proposer des types de sites (des oeuvres) à réaliser sous l’assistance d’un maître (oui, qu’il faudra trouver des maîtres de la force). Contrairement au milieu d’apprentissage habituel d’agence dans lequel on joue avec le temps ; l’accent serait cette fois mis sur l’excellence, c’est-à-dire la mise en pratique de notions comme l’accessibilité, le référencement, la maintenabilité, l’interopérabilité…

Ce serait un moyen de réfléchir aux méthodologies de travail idéales pour la fabrique de sites web. Cela permettrait de sensibiliser certains, de perfectionner d’autres ou encore de se lancer dans des projets de recherche… tout est permis.

Je vous propose l’idée pour ceux que ça intéresse. Je réfléchis très sérieusement à me lancer dans la formation et à animer ce genre de lieu. Je me dis que plutôt que d’avoir une équipe de développeurs qui développent, avec un telle considération, on pourrait plutôt avoir des équipes dans lesquelles les intervenants seraient réellement mis en valeur pour leurs compétences.

A suivre…

Le principe d’organisation

Dans une agence, voire dans beaucoup de sociétés françaises, on ne sait pas trop comment organiser les projets. Alors quand on est submergé et qu’on n’a pas envie de gérer le quotidien, on engage une personne pour gérer tous les à côtés ; selon moi, une sorte de super secrétaire de luxe mais en plus cher (je ne me moque pas je l’ai fait et c’est horrible).

Avec son poste de gestionnaire des « projets », le chef de projet se trouve confronter aux pôles techniques avec lesquels il a du mal à discuter. Son rôle est de suivre l’évolution du projet (budget et planning) tout en faisant l’interface avec un client ; pour cela on lui donne le pouvoir d’arbitrer. Son manque de connaissance du métier dans lequel il travaille fait qu’il oublie de noter des choses, n’anticipe pas suffisamment, ne rend pas compréhensible sa demande, devient contradictoire…

Au final, les produits livrés sont d’une qualité insuffisante, arrivent dans des délais non conformes, les projets ne sont pas rentables ; On tente de comprendre pourquoi le système ne fonctionne pas.

L’analyse des déficiences du système

Suite à de grandes réunions, entretiens (…), les managers arrivent à deux conclusions :

1. Les chefs de projets ne connaissent pas suffisamment la technique
2. Les pôles techniques ne sont pas assez impliqués en amont

La solution appliquée

Comme les chefs de projets ne peuvent pas devenir technicien et que les chef de projets techniques sont chers, on choisit d’appliquer la deuxième option. Hors, la deuxième option ne peut pas marcher à cause de la première.

En effet, dans une organisation par pôle technique, chaque pôle est défini par une expertise technique que justement ne possède pas le pôle des chefs de projets. Dans le cas où on demande d’impliquer les pôles techniques plus en amont, le chef de projets se retrouve dans une situation où il n’a plus de légitimité car les pôles experts deviennent plus compétents que lui pour prendre les décisions.

Si le chef de projets veut, de manière naturelle, conserver de l’importance, il devra s’arranger pour ne pas intégrer les pôles techniques trop en amont. D’autant plus que quand on est chef de projets, on est chef.

Dans une agence web, alors même que tout le monde peut être d’accord sur le fait qu’un intégrateur ne peut pas gérer des principes d’accessibilité et de qualité s’il n’est pas sollicité en amont, on ne fera pas appel à ce même intégrateur car il va ralentir la conception de projet avec ses processus et rentrer de ce fait en confrontation direct avec les besoins du chef de projets.

On arrive donc toujours à la même conclusion, les chefs de projets sont incompétents dans leur domaine technique. Comme ils n’ont pas de statut d’autorité qui les légitimise, ils n’appliqueront pas la solution 2, pour ne pas perdre la face.

Les points d’achoppement en agence web

Pour en avoir été témoin de la situation, se met en place une guerre de tranchée très dure entre les chefs de projets et les intégrateurs. Elle est entretenue par deux oppositions

1. Les chefs de projets n’informent pas suffisamment les intégrateurs en amont / les intégrateurs sont réfractaires à exécuter les tâches
2. Les chefs de projets ne progressent pas techniquement, alors que les intégrateurs le font constamment / les intégrateurs demandent aux chefs de projets d’avoir des connaissances dans un périmètre qui n’est pas le leur

Les systèmes d’opposition font rarement avancer les choses. Pour moi le système n’est pas bon. Pour des raisons très simples :

1. Les entreprises ont des domaines de compétences, des métiers ; il est normal de maîtriser le métier de l’entreprise dans laquelle on travaille pour la faire fonctionner ; ce n’est pas le cas des chefs de projets
2. On confond souvent expertise et compétence ; pas besoin d’être expert comptable pour gérer un budget, pas besoin d’être chargé d’opération pour gérer un planning, pas besoin d’être chef de projets pour discuter avec un client

Le système qui marche

Le problème réel du système d’opposition est qu’alors que l’évolution naturelle de l’intégrateur est d’améliorer ses compétences en conception, de devenir responsable interface (voir l’explosion des offres d’embauche des concepteurs UX aux US), le chef de projets, pour conserver son statut, va bloquer la monté en compétence de l’intégrateur.

Pour moi, il est évident que la personne qui connait le mieux les principes de réalisation dans un domaine est le plus a même de pouvoir les concevoir (les interfaces dans notre cas). Hors ce n’est pas ce qu’on met en place dans certaines agences et c’est pour cette raison que la qualité reste moyenne.

Je pense qu’il est indispensable de passer à plus de transparence et donner plus de responsabilités à des équipes projets. Relire des articles comme La culture de la conception web, la transparence ou Trois règles de management piochées chez Favi.

Articles similaires :

1. Introduction à la Gestion de Projet avec Eric Di Pol
2. Pourquoi le micro blogging ?

La génèse

Une des première dans le genre (à ma connaissance) fut bien évidemment « Ben the bodyguard », dont voici la vidéo :

On se servira de ce genre de présentation pour mettre en avant un contenu scénarisé avec des étapes bien déterminées.

Le principe

Techniquement, comment cela marche-t-il ? On met en place une grande page, avec un décor statique (fond) et des éléments animés. On place dans cette page des ancres, comme autant d’éléments de votre scénario : étape 1, étape 2, étape 3… Puis à chaque ancre, on associe une animation (ou plusieurs animations).

Donc pendant que vous descendez dans la page, votre navigateur détecte des bornes (ancres), à chaque borne une fonction permet d’activer un événement. Visitez la page de Google green – Better web. Better for the environment..

Les plugins

Je vous propose de regarder deux plugins jQuery

1. jQuery waypoints :
Un plugin qui permet de détecter l’activation d’ancres et de pouvoir lancer un événément JavaScript de son choix. Peut-être utile pour du scroll infini, la détection de bas de page…
jQuery Waypoints

2. jQuery scrollorama :
Un peu plus fin, il pointe directement un élément et permet d’appliquer un événement d’animation sur cet élément. Il semble plus destiné à des effets visuels.
jQuery scrollorama

Articles similaires :

1. jQuery : 5 nouveaux plugins de novembre
2. jQuery Accessible RIA : fonctionnalités jQuery accessibles
3. Galerie d’images avec bxGallery sous jQuery
4. ColorBox, plugin lightbox pour jquery
5. jQuery : plugin ARIA

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

1. La simplicité
2. Découverte progressive des fonctionnalités
3. Vitesse
4. Libellé et organisation des éléments
5. Lisibilité
6. Beauté, esthétique

Ce qui est marrant, c’est que depuis que je fais du web, on commence toujours par le dernier critère ; et encore c’est un assez subjectif.

Lire Comment les visiteurs jugent votre site : 6 facteurs liés à l’intuition et aux émotions

Articles similaires :

1. Magento SEO – optimisez le référencement de votre site E-commerce
2. 8 outils pour tester l’accessibilité de votre site
3. Plugin jsPlumb, diagrammes avec éléments HTML liés
4. Comment ruiner un design Web
5. Ava 7 Patterns : des fonds de page pour site web

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

Il y a trois mois, nous avons décidé de refondre le FrameWork que nous utilisions pour notre tableau de bord ; tout à été refait du côté client grâce à node.js.

Ce choix a été dirigé face après la constatation que la structure LAMP (Linux-Apache-MySQL-PHP) était morte. Depuis une vingtaine d’années que cette structure existe, beaucoup de virages ont déjà été réalisés concernant les contenus, les protocoles, les serveurs ou encore les clients.

Nous pouvons dégager, d’ailleurs, trois âges du web :

1991-1999 : l’âge du HTML

La vision originale de Tim Berners-Lee du web fut celle d’une grande bibliothèque en ligne. Le web était défini comme un corpus de documents statiques, codés en dur, en grande partie formatés par le niveau de rendu des navigateurs clients.

Pour résumer, nous avions des documents statiques disponibles pour des clients statiques.

2000-2009 : l’âge LAMP

La période LAMP fut très lié à celui des bases de données. La conception du web n’était plus orienté sur les documents, mais plutôt sur les principes LAMP, ou similaire. C’est-à-dire, une série de gabarit HTML intégrant des données provenant d’une base de données.

Nous avions bien un contenu dynamique, mais toujours un client statique.

2010-?? : l’âge du JavasScript

Dans cette troisième décennie nous entrons dans l’ère du flux. La page web n’est plus une page. Le modèle basé sur l’objet document existe toujours, mais plus en tant que structure (fixe). Le DOM (arbre structurelle d’une page) est chargé dans la mémoire du navigateur et une partie de celui-ci peut être modifié à l’aide de JavaScript.

L’architecture LAMP est morte en raison dans la mesure où, désormais, peu d’applications proposent d’actualiser l’ensemble d’un page en réponse à un événement (demande utilisateur minime) ; il suffit d’actualiser une partie du DOM grâce à JavaScript.

Nous passons de l’âge du document (HTML), à celui de l’affichage d’un gabarit (LAMP), pour arriver à celui de l’envoie de données. Le rôle principal du server est de passer d’une application vers un client (JavaScript), en passant par un formatage de données (JSON), et insérer ce contenu dans le document, ou plutôt le DOM.

Le deuxième rôle du serveur est d’être à l’écoute des événements côté client (édition, message…) et de renvoyer une réponse correspondante.

Node.js correspond aux demandes qu’on peut faire à un serveur en 2010. Il est asynchrone et très rapide. Il utilise HTTP 1.1, garde les connections ouvertes, il peut gérer des centaines de connections.

Les données deviennent de simples paquets, JSON semble s’imposer pour leur transfert. Il s’agit d’un format géré nativement par node.js.

Le JavaScript nous rapproche du web qui ne se résume plus à la grande bibliothèque numérique, mais plutôt à un système nerveux numérique.

Articles similaires :

1. dygraphs JavaScript Visualization Library
2. Graphiques (Charts) avec JavaScript
3. Easy, un FrameWork CSS/HTML/JavaScript
4. 15 Carrousels d’images en Javascript
5. Calendrier d’insertion de date en JavaScript avec raccourci clavier

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