Sur quoi devrions-nous nous concentrer lors du storyboard? Interaction avec l'application ou objectifs utilisateur?
Je voudrais savoir dans quel contexte construisons-nous des histoires "Jobs-To-Be-Done". Nous allons construire un portail/système permettant aux enseignants de signaler certains incidents (ils n'en utilisent actuellement aucun).
Par exemple, j'utilise la méthode "Quand ..., je veux ..., donc je peux ...".
Plus je crée d'histoires, plus je suis confus. Dois-je écrire les histoires du point de vue lorsqu'ils interagissent avec le portail/système, ou dois-je écrire les histoires du point de vue sur une base quotidienne normale.
Histoires interagissant avec le portail: Lorsque je me connecte au système, je veux pouvoir voir ..., pour pouvoir ...
OR
Histoires sur une base quotidienne normale: Quand je veux surveiller une situation, je veux pouvoir ..., pour que je puisse ...
ou les deux sont-ils les mêmes choses?
=== EDIT === Je suis également dans un dilemme car actuellement, les enseignants ne surveillent aucune situation. Mais en raison d'un changement dans les processus scolaires, ils sont désormais tenus de suivre la situation. Ce n'est donc pas comme si je pouvais dire "Quand je veux suivre une situation, je veux voir qui sont les parties impliquées, pour que je puisse garder une trace", parce que, ce n'est pas quelque chose qu'ils "veulent faire", mais c'est un "règle" qui leur est demandée. Je ne sais pas si je pense trop profondément à cela.
Comment puis-je alors écrire JTBD?
Le but de ces types d'histoires est généralement de les ancrer dans les besoins réels des utilisateurs plutôt que dans les détails techniques de la façon dont le produit répond à ce besoin.
Par exemple, si l'objectif du produit est de permettre aux utilisateurs de signaler des incidents, le besoin est de signaler un incident, et non de "se connecter".
Mon conseil serait de mettre en place vos histoires comme:
Lorsqu'un incident se produit, je souhaite me connecter au portail afin de pouvoir enregistrer des détails importants sur l'incident.
L'avantage de ces histoires est qu'elles vous permettent plus tard de "tester" votre conception en demandant à un utilisateur potentiel quelque chose comme "OK alors supposons qu'un incident vient de se produire, et vous voulez utiliser ce portail pour enregistrer des détails à ce sujet." Cela se rattache directement à leur responsabilité de signaler les incidents. Si votre histoire était quelque chose comme "Lorsque je me connecte au système ...", cela ne se rattacherait pas à leur responsabilité de signaler les incidents.
Concernant le "changement de règle" et si c'est quelque chose que les utilisateurs "veulent" ou "sont obligés de faire" à la suite d'un changement de règle, je remplacerais "vouloir" par "besoin". Par exemple:
Lorsqu'un incident se produit, je dois me connecter au portail afin de pouvoir enregistrer l'incident conformément à la réglementation.
(La formulation "vouloir" est plus appropriée pour une utilisation dans le domaine commercial, où les clients sont rarement requis pour faire quoi que ce soit.)
Le storyboard, si je comprends bien, a pour but d'essayer de vous mettre à la place de votre utilisateur (en créant et en développant un personnage), et de façonner le design pour l'adapter au mieux à ses objectifs.
Ainsi, vos deux questions ont du mérite.
Ces questions, selon moi, semblent être ordonnées (cependant, dans le sens inverse de la façon dont vous les avez présentées). Tout d'abord, un utilisateur aura pour objectif de se connecter. Ensuite, un utilisateur peut avoir plusieurs objectifs différents à atteindre, dont l'un peut être de surveiller une situation.
First: Lorsque je me connecte au système, je veux pouvoir voir tous les outils disponibles afin de pouvoir trouver rapidement où je dois aller dans l'application.
Suivant: (l'utilisateur a de nombreuses options différentes à ce stade)
Lorsque je veux surveiller une situation, je veux pouvoir voir les incidents en suspens que j'ai signalés afin de pouvoir vérifier les statuts de chacun ou les mettre à jour avec des informations supplémentaires.
Lorsque je veux suivre un incident, je veux pouvoir trouver l'incident et accéder facilement aux coordonnées de la personne affectée à l'incident.
Il peut être utile d'essayer d'explorer d'autres configurations pour vos histoires, si " quand ..., je veux ..., donc je peux ... "n'aide pas. Par exemple, vous pouvez essayer d'établir un objectif, puis de concevoir la réponse la plus utile du système à partir de là (donc, plus d'un " je veux ..., donc ce serait utile pour que le système ... ".
Les besoins réels des utilisateurs dans le cadre JTBD doivent d'abord être séparés selon un modèle avec ces paramètres principaux:
Partenaires clés:
Who are your key partners?
Who are your key suppliers?
Which key resources are we acquiring from partners?
Which key activities do partners pereform?
Activités clés:
What Key activities do your Value Propositions require?
What are your Distributun channels?
How would you maintain your Customer Relationships?
What are your main Revenue streams?
Ressources clés:
What key resources do your Value propositions require?
Types of resources like Physical, Human, Financial,
Proposition de valeur:
What value do you deliver to the customer?
Which one of your customer problems are you solving?
What bundles of products and services are you offering to each **Customer Segment?**
Which customer needs are you satisfying?
Relation client:
What type of relationshp does each of your Customer Segments expect you to establish?
Which ones have you established?
Segments de clientèle:
From whom are we creating value?
Who are your most imortant customers?
Chaînes:
Phases are like Awareness, Evaluation, Purchase, Delivery, After Sales
How are we integrating the phases with customer routines?
Flux de revenus:
For what values are your customers willing to pay?
Structures de coûts:
You need to find whether your business is cost driven or value driven and then decide parameters to it
Cela vous aidera à créer l'ensemble de l'architecture de l'information et à identifier les scénarios. Maintenant, sur la base de ce modèle d'architecture, vous devez créer les fonctionnalités suivantes:
caractéristique 1
Fonction 2
caractéristique
Vous pouvez également opter pour la segmentation des fonctionnalités par thème. Des thèmes comme la viralité, la sécurité, les rapports, etc.
Donc, dans cette fonctionnalité 1, vous créez les histoires comme vous l'avez fait: en utilisant la méthode de "Quand ..., je veux ..., donc je peux ..."
Puisque vous avez suffisamment d'informations maintenant, vous pouvez facilement faire les histoires basées sur chaque point de vue des fonctionnalités et rien d'autre.