La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Aller au contenu | Aller au menu | Aller à la recherche

vendredi, septembre 17 2010

La MOA doit-elle définir ses écrans en mode fil de fer ?

Le processus qui amène à la spécification détaillée des écrans d'une application de gestion, n'est pas principalement un travail sur le graphisme. C'est essentiellement un travail de conception fonctionnelle centrée sur l'utilisateur. Et avant de définir le design final de l'application, il peut être intéressant de concevoir ses écrans en mode fil de fer (wireframe). Voilà un petit schéma revu sur le blog de usercentric.fr - Suivez le chemin de l’User Experience :

Valider la sémantique

En mode fil de fer, les écrans seront représentés avec tous les contrôles nécessaires, avec la vraie sémantique. Mais par contre on évitera de mettre trop d'éléments graphiques. Ainsi cela permet de se concentrer sur le fonctionnel. Le premier avantage est de faire valider par les utilisateurs la sémantique utilisée, avec son contexte.

Vérifier la compréhension des exigences

Les besoins exprimés par les utilisateurs pendant les entretiens de recueil des besoins ne sont pas toujours bien analysés et compris par la MOA. Discuter d'une exigence sur un écran dépouillé du superflu permet de vérifier qu'on a bien compris le fond du problème.

Le storyboard pour valider le processus métier

Un tout petit peu plus loin qu'un simple écran en mode fil de fer, le storyboard permet de valider que la solution prévue permettra bien de supporter le processus métier concerné. En effet, montrer les enchainements qui seront possibles entre les écrans de l'application permet de concrétiser l'informatisation d'un processus métier. Ainsi on peut dérouler le processus avec les utilisateurs et valider que cela fonctionne comme imaginé.

Améliorer l'utilisabilité

Une fois qu'on a validé l'efficacité de la réponse au besoin, on peut commencer à penser à l'utilisabilité. Les ergonomes et les graphistes auront bien évidemment un grand rôle à jouer dans ce travail, car là on rentre dans leur domaine. Mais la MOA doit avoir des notions sur cette utilisabilité pour éviter de proposer des solutions trop nuisibles. Voilà quelques pistes de lecture sur le sujet de de l'utilisabilité :

Définir ses écrans en mode fil de fer, avant de passer à la spécification détaillée des écrans, offre donc de grands bénéfices. On peut en revanche se demander si c'est à la MOA de définir de manière très détaillée les écrans. Si dans l'organisation il n'y a ni ergonome, ni designer, ni développeur sensibilisés à l'utilisabilité, alors il faut bien que quelqu'un le fasse. Mais si il existe ces spécialistes dans votre organisation, restez concentrés sur votre expertise : le métier et le fonctionnel. Laissez alors le graphisme et l'ergonomie aux vrais experts.

vendredi, août 27 2010

La MOA doit-elle donner du relief ?

Nous avons vécu beaucoup d'innovations dans les interfaces homme-machine ces dernières années : terminal tactile multipoint, moniteurs informatiques et téléviseurs en 3D relief, réalité augmentée (pour faire son shopping par exemple), retour des "tablettes"... Mais est-ce que la MOA doit s'intéresser à ces technologies ?

Pas de Système d'Information sans technologie...

Sur ce blog, je traite plutôt du rôle de MOA vis à vis du système d'information. Il est de plus en plus difficile de trouver un processus métier dans une entreprise qui n'utilise pas l'informatique. Et le premier contact des utilisateurs avec leur SI, c'est via les interfaces graphiques des systèmes. Il est donc très important d'être curieux dans ce domaine : essayer les dernières versions des navigateurs Internet, suivre l'évolution des applications open source majeures... et également assurer une veille technologique ! Même si la MOA analyse le fonctionnel ou le métier, il est bon de savoir ce qu'il est possible ou sera possible de faire avec l'outil informatique. Par exemple, la puissance des téléphones portables permet aujourd'hui de développer de nouvelles interfaces en 3D plus immersives (voir cette news sur pcinpact .com : Intel et Nokia travaillent sur des téléphones à interface 3D). Ne voyez-vous pas des applications possibles dans votre domaine ?

... mais n'oublions pas nos objectifs

Mais attention, on croit que les rêves, c'est fait pour se réaliser. C'est ça, le problème des rêves : c'est que c'est fait pour être rêvé (Coluche). Car vous avez un budget à tenir, et les stratégies IT des grands groupes ne doivent pas simplement suivre les modes. Inutile donc de lancer des POC (Proof Of Concept) à tout va, il faut savoir cibler en fonction de la stratégie du SI. N'oubliez pas également que vos utilisateurs sont toujours réfractaires au changement. Alors, évitez les interfaces trop éloignées des standards de fait.

Vidéo : Hiro III, un robot hyptique et une interface tactile en trois dimensions

dimanche, janvier 24 2010

Comment spécifier une interface graphique sur un terminal à écran tactile multipoint ?

L'informatique est un secteur où les technologies évoluent très rapidement. Et en ce moment, la mode est aux terminaux à écrans tactiles multipoints : Apple iPhone, Palm Pixi, Microsoft Surface...

Selon le grand dictionnaire terminologique de l'office québécois de la langue française une écran tactile multipoint est un

Écran qui possède le matériel nécessaire pour détecter simultanément à plusieurs points de sa surface les pressions ou les déplacements des doigts, des mains ou des stylets, et qui est relié à un système informatique capable d'interpréter ces actions séparément et en même temps tout en coordonnant l'information.

Avec ces technologies, la sémantique de l'IHM est forcément différente. Si vous utilisez la tableau ICAR (Intention, Contrôle, Action, Réponse), vous devez oubliez les classiques Cliquer, Double cliquer...

Toucher
Cette action reste valable pour tout écran tactile. L'action de base c'est donc de toucher l'écran pour lancer une commande.

Pincer / Ecarter
Sur l'iPhone pour zoomer ou dézoomer, il suffit de pincer virtuellement avec deux doigts ou d'écarter ces mêmes doigts.

Secouer
Ces nouveaux terminaux mobiles amènent également des fonctions annexes comme un accéléromètre. Ainsi, secouer son terminal peut permettre de retourner à l'écran d'accueil par exemple.

Pencher
En penchant son terminal on va également pouvoir activer des commandes. Par exemple en penchant à droite ou à gauche, on va contrôler un personnage dans un jeu de plateforme pour le faire aller à droite ou à gauche.

A peine commençons-nous à nous faire à ces nouvelles interfaces que les chercheurs sont déjà sur des nouveaux systèmes de "pointage" comme par exemple le "Vision-based Input interface" qui consiste à reconnaitre les mouvements du doigt afin de permettre un pointage en "3D". Gageons que l'informatique ambiante (Ubiquitous computing) saura utiliser ces nouvelles technologies.

vendredi, février 27 2009

Comment spécifier une interface graphique de manière détaillée ?

L'étude fonctionnelle de cette application de gestion a été faite. Vous avez un beau cahier des charges. La spécification générale a été réalisée, vous connaissez vos cas d'utilisation sur le bout des doigts. Il est donc temps de passer à la spécification fonctionnelle détaillée, et l'un des éléments clé, quelque soit la méthodologie mise en œuvre, c'est la spécification des écrans.

1) Le papier et le crayon :

Pour mettre un peu ses idées au clair, rien de tel qu'une feuille, un crayon à papier et une gomme. Commencer par dessiner au brouillon ses IHM permet de poser ses idées.

2) L'outil pour designer ses écrans :

Une fois qu'on voit grosso modo ce que l'on souhaite faire, on peut utiliser un outil pour dessiner ses écrans en mode "fil de fer" voire pour effectuer un story board (un genre de prototype pour illustrer la navigation).

Une suite bureautique standard permet de réaliser des dessins sommaires (OpenOffice.org - http://fr.openoffice.org/) de même qu'un outil dédié à la réalisation de schémas (Visio - http://office.microsoft.com/fr-fr/visio/default.aspx). Seulement ces outils très généralistes ne sont pas les plus performants pour cette tâche spécifique.

Il est beaucoup plus efficace d'utiliser un outil dédié à la réalisation de maquettes et de prototypes d'écrans comme par exemple :
Axure RP - http://www.axure.com/.

Cet outil est plutôt fait pour les applications Web à la base, mais fait très bien son office pour les applications "lourdes" également. Il vous permettra :
- De designer vos écrans à l'aide contrôles simples et d'autres personnalisés que vous pouvez créer et réutiliser.
- De spécifier le fonctionnement de vos écrans à l'aide d'annotations personnalisables.
Par exemple, vous pouvez créer des annotations pour créer un tableau ICAR (Intention - Contrôle - Action - Réponse). Exemple :
Intention = Supprimer un billet du blog
Contrôle
= Menu contextuel, Item supprimer
Action
= Clic
Réponse
= Ouverture d'une fenêtre de confirmation "Etes vous sur de vouloir supprimer ce billet", puis suppression du billet si bouton OK cliqué.
- De définir la navigation entre vos écrans.
- De créer un prototype navigable en HTML pour présenter la navigation entre les écrans à vos utilisateurs par exemple.
- De générer un dossier de spécification fonctionnelle détaillée des écrans au format Word par exemple, à partir d'un template personnalisable.

Axure permet donc d'industrialiser la gestion des spécifications fonctionnelles détaillées des écrans. Il permet également de réaliser des prototypes à moindre coût. Les écrans sont une excellente base pour valider des concepts au départ un peu abstrait avec des utilisateurs. Organiser une réunion de validation des écrans permet de corriger certaines erreurs en tout début de projet, ce qui coute beaucoup moins cher que lorsque tous les développements on été effectués. Bien sur les écrans ne sont que la partie visible de l'iceberg, mais je pense que pour des projets d'applications de gestion classiques, une bonne spécification de l'IHM est un élément clé de la réussite. Un outil comme Axure est une bonne assurance contre les échecs dus à des spécifications trop imprécises.