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

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

Tag - Storyboard

Fil des billets - Fil des commentaires

mardi, avril 12 2011

Quelles astuces pour l'utilisation d'Axure RP Pro par la MOA ?

Par Olivier Durand le mardi, avril 12 2011, 21:42 - Spécifier

Comment utiliser au mieux un outil comme Axure RP Pro ? Le mieux c'est d'être curieux et fouiller dans les menus ! Mais voici quand même quelques petites "astuces" concernant l'utilisation des Widgets dans Axure.

Développez vos storyboards avec les composants Wireframe par défaut

Pour commencer, il faut utiliser les quelques composants disponibles par défaut dans Axure. Ceux-ci permettent d'effectuer des storyboards en mode fil de fer, c'est à dire sans prendre en compte l'aspect design (d'où le terme wireframe).

Axure

Axure

Utilisez des librairies de composants réalisés par d'autres pour vos spécifications détaillées - Axureland

Une fois que vous voulez passer dans une phase de spécifications fonctionnelles détaillées, les composants de base dans Axure sont un peu limitatifs. Mais vous pouvez étendre la liste de ces composants grâce aux librairies. Pour l'exemple, nous allons prendre la librairie Axure Better Defaults Library. Il vous faut télécharger cette librairie en cliquant sur le bouton Download Axure File à cette adresse :
http://axureland.com/index.php/site/entry/axure_better_defaults_library
Une fois le .zip téléchargé, dézippez le dans le répertoire :
...\Mes Documents\My Axure RP Libraries

Vous voyez alors apparaitre votre nouvel ensemble de widgets :

Axure

Ainsi vous aurez alors accès à de nouveaux composants pour définir vos écrans :

Axure

Créez vos propres librairies

Si vous avez un framework graphique maison, des best practices au niveau des IHM... vous pouvez créer vos propres librairies de composants à partager entre projets. Pour cela, dans le menu Widgets, cliquez sur Create library... :

Axure

Axure

Vous avez ainsi accès à un projet Axure qui représente votre librairie de Widgets :

Axure

Renommez le "New Widget 1" et dessinez votre propre widget :

Axure

Vous pouvez créer plusieurs widgets dans votre librairie. Ensuite vos widgets seront accessibles dans les autres projets :

Axure

J'espère que ces petites astuces vous seront utiles. En fait ce sont simplement des fonctionnalités standard de l'outil plus que de vraies astuces, mais parfois on oublie un peu de fouiller dans ce que permet de faire l'outil faute de temps, et on passe à côté de beaucoup de choses qui permettent pourtant de gagner un temps précieux.

vendredi, septembre 17 2010

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

Par Olivier Durand le vendredi, septembre 17 2010, 14:04 - Spécifier

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, février 27 2009

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

Par Olivier Durand le vendredi, février 27 2009, 10:12 - Spécifier

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.