Création des groupes

3 personnes maximum, définissez qui aura le rôle de l'UX Designer, du Product Owner et du Développeur.

Trouvez un nom pour votre groupe !

Déroulement des journées

Comment identifier un problème ?

UX Research

Design Thinking

Interviews

Comment rédiger la définition du problème ?

Who has the problem ?

What is the problem ?

When / Where does the problem occur ?

Why is it important to address for the customer ?

Exemple :

Students taking more than four modules find it challenging to see when their assignments are due if they have more than 5 due dates, meaning they miss deadlines and lose marks.

Lean UX

Hypothèses

Analyse

Résoudre le problème et identifier un besoin

Comment rédiger la définition du besoin ?

Format :

[type d'utilisateur] a besoin [le besoin] afin d'accomplir [objectif].

L'objectif est très important ici, car il va vous permettre de vérifier que l'utilisateur arrive à accomplir son objectif avec votre produit.

Mise en relation entre particulier et artisan

Proposer toutes les prestations d'artisanats

Proposer les artisans proches du chantier

Arty, l'artisanat de demain.

Arty, l'artisanat de demain.

Le problème à résoudre :

Les particuliers qui ont besoin de réaliser des travaux ont du mal à trouver des artisans de confiance et leurs tarifs ; Cela peut conduire à des frais non prévus ou des dégâts quand l'artisan n'est pas professionnel.

Un système de recommendation

Un système de suggestion sur les critères du particulier

Offre détaillée de chaque artisan sur sa prestation

Arty, l'artisanat de demain.

Progresser rapidement grâce à des formations de seniors

Proposer toutes les catégories de formation professionnelle

Formation interactive avec exercices et corrections

Wisdom, devenir meilleur.

Wisdom, devenir meilleur.

Le problème à résoudre :

Les particuliers qui ont un plan de carrière difficile à atteindre ont du mal à monter en compétence quand ils sont isolés dans leur entreprise ; Cela ne leur permet pas de développer leurs compétences aussi vite qu'avec un senior dans leur équipe.

Un système d'éditeur de formation en ligne

Une IA qui réponds aux questions les plus posées ou redirige vers le senior

Notation des formations & recommendation

Wisdom, devenir meilleur.

Résoudre un escape game seul ou à plusieurs en VR de chez soi

Proposer les meilleurs escape games créés par des agences

Un système d'énigme et de mini-jeu poussé

Vscape, l'escape game chez soi.

Vscape, l'escape game chez soi.

Le problème à résoudre :

Les agences d'escape game ont du mal à avoir des revenues récurrents en fidélisant leurs joueurs ; La location de l'espace et du personnels est très coûteux et il n'y a pas beaucoup de re-jouabilité quand le joueur termine un escape game.

Un système d'éditeur d'escape game VR pour les agences

Un système de paiement par abonnement ou d'achat à l'unité

Notation des escape games & recommendation

Vscape, l'escape game chez soi.

Template des ateliers

Nous allons utiliser Miro pour réaliser nos ateliers, copier la template et inviter votre groupe.

Comment collecter un besoin et définir les fonctionnalités ?

1. Identifications des parties prenantes, des besoins fonctionnels et non-fonctionnels.
2.  Brainstorming (Problems / Needs /Opportunities) et Output minimizer.
3. Définir les cas d'usages et réaliser les sketchs.
4. Définir les User stories, leurs règles et exemples.

Le client ne connaît pas son besoin

Attention, le client connaît son problème.

C'est à un expert de définir son besoin et sa solution.

Comment identifier les parties prenantes ?

Identifier le type de partie prenante

Identifier les relations entre les parties prenantes et le projet

Définir le persona des utilisateurs finaux

Comment identifier les besoins fonctionnels ?

• Se mettre dans la peau des personas identifiés : quelles actions sont-ils capable de faire ? Comment ?
• Voir large, rester simple. On évitera le besoin "L'utilisateur doit pouvoir changer son mot de passe en cas d'oubli" mais plus "Système d'authentification"
• C'est un brainstorming, ne vous limitez pas, cela sera une prochaine étape.

Comment identifier les besoins non fonctionnels ?

• Se mettre dans la peau des personas identifiés : Dans quel contexte font-ils leur actions sur le produit ? Quelles sont leurs priorités et leurs souffrances ? 
• Voir large, rester simple. On évitera le besoin "L'utilisateur doit pouvoir sauvegarder une version locale de son projet" mais plus "Version offline"
• N'oubliez pas de questionner le client ou directement les stakeholders !

Comment identifier les problématiques à résoudre ?

• Partez des besoins fonctionnels et non fonctionnels pour en déduire des sous problèmes de la définition du problème du client. Ex: en partant de "Système de recommandation de contenu" on peut en déduire la problématique suivante : "Comment rendre la recommandation pertinente ?".
• Les problématiques doivent être en rapport avec le problème du client, évitons les problématiques générales comme "Comment rendre l'interface érgonomique ?"
• N'hésitez pas à vous renseigner sur la logique métier. Cela représente le fonctionnement d'une activité du client.

Comment identifier les besoins utilisateurs ?

• Développez les besoins fonctionnels et non fonctionnels du point de vue d'un des personas. Ex: "Système de recommendation", on peut en déduire le besoin suivant "L'utilisateur doit pouvoir personnaliser ses recommendations".
• Mettez-vous à la place de vos personas, essayez de faire quelques scénarios en rapport avec le produit.

Comment identifier les opportunités ?

• Les opportunités surgissent durant le brainstorming, ce sont souvent des solutions pour raccourcir la charge de travail ou pour améliorer l'expérience utilisateur.
• Cela peut aussi être une chance d'être force de proposition face au client et d'innover.

Comment définir une activité ?

• Les activités découpent plus finement les besoins fonctionnels et non fonctionnels. Une activité est un grand groupe de fonctionnalités qui symbolise une tâche ou une action que doit réaliser l'utilisateur. Ex: 'Authentification' qui symbolise les fonctionnalités comme s'identifier ou s'inscrire.
• Le dialogue est très important avec le client, parfois on découvre des activités clés dans la conception de la solution qui n'était pas identifiée comme telle à la base. Ex: Facebook, l'activité clé est la publicité, on peut donc vite découvrir une activité clé qui sera la récupération des informations et comportements utilisateurs.

Comment trier et prioriser les activités ?

Vous devez trier les activités par ordre d'importance pour votre produit. Plusieurs techniques sont possibles, l'une d'entre elles priorisent les activités qui ont le meilleur ratio valeur / effort.

Ensuite, prioriser les activités dans plusieurs phases de développement du produit : la Preuve de concept, le Prototype et le Minimum Viable Product.

Comment définir les cas d'usages ?

• Posez-vous des questions, faites des hypothèses sur la résolution des problèmes ou la valeur que vous apportez à vos utilisateurs avec ce cas d'usage.
• N'allez pas trop loin, n'oubliez pas que vous devez d'abord faire une preuve de concept.
• Ne testez pas l'ergonomie de votre solution avant de valider le concept. Ex: "Est-ce que le bouton "S'inscrire avec Google" est bien placé ?" sera du travail obsolète si "Est-ce que l'utilisateur veut s'inscrire avec son compte Google pour gagner du temps ?" n'est pas valider en amont.

Les logiciels pour réaliser les sketchs ?

• Figma
• Whimiscal
• Miro
• Balsamiq
• Et beaucoup d'autres !

N'hésitez pas aussi à tout simplement utiliser un papier et un crayon ;-)

Comment réaliser un sketch ?

• Le but d'un sketch est d'être une représentation "Lo-fi" de votre solution finale. Le but ici est de gagner un maximum de temps pour être un support à l'idéation et la conception de votre solution.
• N'hésitez pas à définir des zones à l'écran comme "Présentation du produit" au lieu d'ajouter tous les détails, ceux-ci seront définis plus tard.
• Ici nous l'utilisons dans le cadre du "Zoning", une pratique qui permet via les cas d'usages de se rendre compte de la charge de travail et des fonctionnalités à produire en dessinant "à main levée".

Quel format ?

Si votre produit a de fortes chances d'être une application mobile, je vous conseille de partir sur une stratégie "Mobile-first". Cette stratégie prône le fait de faire en priorité les cas d'usages sur le format mobile pour ensuite adapté au format Desktop.

Quand on peut avec le moins, on peut avec le plus !

C'est quoi une User Story ?

Pour réaliser votre Example Mapping, on va choisir une User Story pour le faire. Mais qu'est-ce qu'une User Story ?

Créé dans Extreme Programming en 1999

Une fonctionnalité la plus minimale possible

Un support de validation du Product Owner et de l'utilisateur

Le format d'une User Story

Format :

 En tant que <qui>, je veux <quoi> afin de <pourquoi>.

Exemple :

 En tant que particulier, je veux chercher des artisans autour de   chez moi pour une intervention rapide.

Que je résume dans mes propres US sous le format :

Titre - Particulier cherche des artisans autour de sa position

Description - Pour une intervention plus rapide, un particulier va chercher les artisans qui sont le plus proche de la position qu'il a enregistré comme étant son logement.

La Definition of Done.

La Definition of Done (DOD) permet à l'équipe de savoir quand est-ce qu'on considère une US terminée, elle permet de lister toutes les choses qui sont à faire pour chaque US.

Exemple :

• Les Wireframes ont été vérifiés par le Product Owner
• Les tests unitaires et d'intégrations ont été vérifiés par le Lead
• La documentation a été rédigée.

La DOD permet de vérifier qu'une qualité minimale est respectée pour chaque US.

Les critères d'acceptation

Les critères d'acceptation (AC) permet à l'équipe de savoir les critères spécifiques à une US pour être validée. Par exemple, lorsque vous réalisez une identification :

• L'User peut choisir entre la connexion avec e-mail ou compte Google.
• Un message d'erreur apparaît quand l'email n'est pas du bon format.
• L'User peut utiliser le lien "J'ai oublié mon mot de passe" pour récupérer son mot de passe.
• Un message d'erreur apparaît quand l'User n'a pas utilisé le bon mot de passe ou le bon email.

User Story Map mais UX.

User Story Map mais UX.

Dans cet exemple, on peut traduire par :

• Les activités : des Epics, ou des domaines (DDD).
• Les steps : des User Stories.
• Les details : des Critères d'acceptations.

Si pour vous une Step est trop grande, qu'elle ressemble plus à une Epic, diviser la à nouveau, créer une Activité si besoin et rajouter des nouvelles Steps qui ressembleront plus à une vraie US.

Et l'Example Mapping ?

Quand vous avez identifié des US, maintenant il vous faut un moyen de facilement rédiger leur fonctionnement et les critères d'acceptation. Pour cela, regrouper autour d'une table le Product Owner, un UX Designer ou un Testeur et un Développeur pour identifier tous les besoins et problématiques.

On appelle cette configuration les "Three amigos!" en référence au film du même nom.

Pourquoi ? Pour éviter que seulement une personne avec sa vision métier ne soit responsable de la création des US, là on est sûr d'avoir le point de vu de tout le monde.

Qu'est-ce que l'Example Mapping ?

Exemple d'un atelier

Comment bien rédiger les exemples ?

Pour standardiser et éviter d'avoir des exemples différents pour chacun, on utilise alors le Gherkin. Cela permet de se rapprocher d'une syntaxe plus algorithmique et permet à toute l'équipe de participer à la réflexion de la logique de l'US.

Voyons ensemble sa syntaxe et son fonctionnement :

 https://cucumber.io/docs/gherkin/reference/

Exercice - Define

1. Choisissez 2 activités de la Preuve de concept et débuter l'atelier Define pour chacune d'elle pour définir des cas d'usages.
2. Vérifiez que vous répondez aux problèmes que vous avez relevés dans les ateliers précédents et que votre solution réponde vraiment aux besoins.
3. Réalisez les Wireframes Lo-fi et notez sur des post-its ce que vous vous dites à l'oral en terme de fonctionnement et des détails à avoir pour ne pas perdre des informations sur le fonctionnement final.

Venez me voir pour valider ensemble.

Exercice - Example Mapping

1. Réalisez 2 activités dans votre "Proto-User Story Map".
2. Choisissez 4 User Stories et réalisez leurs Example Mapping.
3. Rédigez les User Stories dans l'USM (User Story Map).
4. Rédigez les gherkins pour les critères d'acceptation d'une US.

Venez me voir pour valider ensemble.

Bravo, vos US peuvent rejoindre le Backlog Produit si vous êtes en Agile et vous avez terminé la conception fonctionnelle !

Continuez à améliorer vos différents ateliers

N'oubliez pas que votre notation finale dépends de la qualité du rendu et de la présentation du travail réalisé durant nos séances !

N'hésitez pas à me demander de vérifier des parties pour voir les correctifs et améliorations à faire.

Vous pouvez aussi débuter la présentation finale que vous allez réaliser en fin de module.

Qu'est-ce que le Domain Driven Design ?

Première fois cité dans le livre de Eric Evans du même titre publié en 2003

Le DDD est une architecture pour la conception de logiciels

Place la logique métier au centre des préoccupations.

Pourquoi utiliser le Domain Driven Design ?

Isoler la logique métier de la logique applicative / infrastructure.

Abstraire les outils et technologies utilisés.

Un seul et même langage pour toute l'équipe, il est très facile de collaborer.

Identifier les domaines d'activités de l'entreprise

Domain Driven Design - 1

Domain Driven Design - 2

La couche domaine met en œuvre la logique commerciale centrale, indépendante des cas d'utilisation, du domaine/système.
La couche application met en œuvre les cas d'utilisation de l'application basés sur le domaine. Un cas d'utilisation peut être considéré comme une interaction de l'utilisateur avec l'interface utilisateur (UI).
La couche présentation contient les éléments de l'interface utilisateur (pages, composants) de l'application.
La couche infrastructure soutient les autres couches en mettant en œuvre les abstractions et les intégrations avec les bibliothèques et les systèmes tiers.

Domain Driven Design - 3

Domain Driven Design - 4

Entity - une entité est un objet doté de ses propres propriétés (état, données) et de méthodes qui mettent en œuvre la business logic. Une entité est représentée par un Id.
Value-Object - un objet de valeur est un autre type d'objet de domaine qui est identifié par ses propriétés plutôt que par un identifiant unique. Cela signifie que deux objets de valeur ayant les mêmes propriétés sont considérés comme le même objet.
Repository - un repository est une interface de type collection utilisée par les couches domaine et application pour accéder au système de persistance des données (la base de données).
Domain service - un service sans état qui met en œuvre les règles fondamentales du domaine en utilisant les entities et repositories.

Domain Driven Design - Tactical

Le DDD utilise l'architecture hexagonale

Définir les choix techniques et justifier

Après avoir identifié les activités à réaliser, on peut alors commencer à choisir les outils et technologies que l'on va utiliser pour notre solution.

Cela demande de la veille et des tests sous forme de POC (Preuve de concept) pour valider l'intérêt de l'outil ou de la technologie.

Ensuite, vous devez définir les justifications de ces choix techniques pour garder la ligne directrice de pourquoi ce choix.

Ex : Nous utiliserons une base de donnée MongoDB en NoSQL pour réaliser la persistance des données car nous ne connaissons pas à l'avance la data qui va être à stocker de nos clients.

Définir votre solution en DDD

J'ai réalisé une template Miro vous permettant d'être guidé sur la réalisation stratégique et tactique de votre Domain Driven Design pour votre solution :

https://miro.com/app/board/uXjVKUKRDus=/?share_link_id=736458064572

Réalisez ces étapes pour la solution que vous êtes entrain de construire.

Appelez-moi quand vous avez terminé que l'on puisse valider avant d'attaquer la suite.

Réaliser les choix techniques

Créez une présentation où vous allez définir tous les outils et technologies que vous allez utilisés pour créer votre solution.

Bien sûr, tout doit être justifié (résout un problème, une limite, qu'en interne vous avez déjà cette expérience, etc).

Il faut définir des sujets comme :

1. La technologie pour le frontend / backend ou fullstack.
2. La persistance des données.
3. L'infrastructure (Auto-hébergé, AWS, Google Cloud, OVH...).
4. Les outils et services (L'e-mailing, la gestion des incidents...).
5. Mêmes les outils ou méthodes utilisés par l'équipe de développement.
6. L'architecture que vous allez mettre en place pour le projet (MVC, Hexagonal, Micro-Services...)

Réaliser la vue tactique du DDD

Maintenant, vous pouvez vous lancer dans le coeur de la conception technique en réalisant l'UML de votre solution dans un dépôt.

Vous utiliserez l'outil Mermaid en utilisant les Diagrammes de Classes.

Définissez vos entités, vos repositories et vos services pour les activités que vous avez identifiés avec les différentes communications entre chacun.

N'oubliez pas ensuite d'ajouter les Adapters pour suivre l'architecture Hexagonale pour abstraire les services externes dont vous avez besoin. (AWS SES, S3, etc...)

Appelez-moi quand vous avez terminé que l'on puisse valider avant d'attaquer la suite.

Réaliser l'architecture de votre infrastructure

Maintenant, vous pouvez vous lancer sur l'architecture de votre infrastructure que vous allez déployer en réalisant dans un dépôt un diagramme avec l'outil Mermaid.

Utilisez le diagramme d'Architecture.

Définissez vos serveurs, vos bases de données, vos storages, les services que vous allez utilisez pour gérer vos clusters et l'équilibreur de charge etc.

Appelez-moi quand vous avez terminé que l'on puisse valider avant d'attaquer la suite.

Réaliser la présentation finale

Vous avez terminé la conception fonctionnelle et technique, il est maintenant temps de synthétiser tout votre travail en une présentation impactante pour votre client.

Vous devez aussi quantifier le nombre d'heures de travail ou le coût de certaines parties projets dans un devis pour votre client.

Attention, le but ici est d'être le plus réaliste possible pour vous entraîner.

N'hésitez pas à utiliser des outils comme Pitch pour réaliser votre support de présentation.