2

I'd like to know in what context do we build "Jobs-To-Be-Done" stories. We are going to build a portal/system for teachers to report certain incidents (currently they are not using any).

For example, I'm using the method of "When..., I want to..., So I can...".

The more I create the stories, the most confused I get. Do I write the stories in the point of view when they are interacting with the portal/system, or do I write the stories in the point of view on their normal day-to-day basis.

Stories interacting with the portal: When I login to the system, I want to be able to see ..., so that I can ...

OR

Stories on a normal day to day basis: When I want to monitor a situation, I want to be able to ..., so that I can...

or are both of them the same things?

===EDIT=== I'm also in a dilemma because currently, teachers are not monitoring any situation. But due to a change in school processes, they are now required to monitor the situation. So it's not like I can say "When I want to monitor a situation, I want to see who are the parties involved, so that I can keep track", because, it's not something that they "want to do", but it's a "rule" that is required of them. Not sure if I'm thinking too deep into this.

How then, do I go about writing JTBD?

  • seems both are similar! – Yasintha Mar 29 at 12:12
  • I hope you don't mind, I've edited your question's title to make it a bit more expressive of your question's purpose so that hopefully more users will be able to contribute. Feel free to edit the question again if I've misinterpreted the spirit of your question. – maxathousand Mar 29 at 14:09
1

The goal of these kinds of stories is usually to ground them in the actual needs of users rather than the technicalities of how the product answers this need.

For example, if the goal of the product is to allow users to report incidents, the need is to report an incident, not to "log in".

My advice would be to set up your stories as:

When an incident happens, I want to sign in to the portal so that I can record important details about the incident.

The benefit of these stories is that they allow you to later "test" your design by asking a prospective user something like "OK so let's pretend that an incident just happened, and you want to use this portal to record details about it." This directly attaches to their responsibility to report incidents. If your story was something like "When I login to the system..." then it would not attach to their responsibility to report incidents.

Regarding the "rule change" and whether this is something that users "want" or are "forced to do" as a result of a rule change, I would replace "want" by "need". For example:

When an incident happens, I need to sign in to the portal so that I can record the incident according to the regulations.

(The "want" phrasing is more appropriate for use in the commercial realm, where customers are rarely required to do anything.)

  • 1
    Hi qoba, thank you for your explanations. I believe your answer has helped me the most in coming up with my JTBD stories. I agree with what you said that "want" is more appropriate for the commercial realm, and I should use the word "need" as it is required of them. Thank you, and I'll work on my stories based on your advice. – DoubleClickOnThis Mar 31 at 8:53
  • @DoubleClickOnThis glad it helped! – qoba Mar 31 at 15:48
1

The purpose of storyboarding, as I understand it, is to try and put yourself in the position of your user (by creating and developing a persona), and shape the design to best fit their goals.

Thus, both of your questions have merit.

These questions, to me, seem to be ordered (though, in the reverse of how you have presented them). First, a user will have the goal of logging in. Next, a user might have multiple different goals to achieve, one of which may be to monitor a situation.

First: When I log in to the system, I want to be able to see all available tools so that I can quickly find where I need to go in the application.

Next: (user has many different options at this point)

  • When I wan to monitor a situation, I want to be able to see the outstanding incidents that I've reported so that I can check on the statuses of each, or update them with additional information.

  • When I want to follow up on an incident, I want to be able to find the incident and easily access contact information for the person assigned to the incident.

It may help to try to explore other setups for your stories, if "when ..., I want to ..., so I can..." isn't helping. For example, you could experiment with establishing a goal, then designing the most helpful response from the system from there (so, more of a "I want to ..., so it'd be helpful for the system to ...".

  • Hi there, thanks for your response. I guess the "When.. I want to... so I can" isn't really working well for me. The issue that I have now is that, currently teachers are not monitoring the incident. However, due to some change in school processes, teachers are now required to monitor the incident. In such cases, how do I go about JTBD? I've edited my question to make the situation much clearer. – DoubleClickOnThis Mar 30 at 13:35
1

The Actual needs of the users in JTBD framework first needs to be segregated according to a model with these main parameters :

Key partners:

            Who are your key partners?
            Who are your key suppliers?
            Which key resources are we acquiring from partners?
            Which key activities do partners pereform?

Key Activities:

            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?             

Key Resources:

            What key resources do your Value propositions require?
            Types of resources like Physical, Human, Financial, 

Value Proposition:

                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?

Customer Reltionship:

                What type of relationshp does each of your Customer Segments expect you to establish?
                Which ones have you established?

Customer Segments:

                From whom are we creating value?
                Who are your most imortant customers?

Channels:

        Phases are like Awareness, Evaluation, Purchase, Delivery, After Sales
        How are we integrating the phases with customer routines?

Revenue Streams:

        For what values are your customers willing to pay?

Cost Structures:

       You need to find whether your business is cost driven or value driven and then decide parameters to it

This will help you to make the entire Information Architecture and identify the scenarios. Now based on this architecture model you need to make the features like this:

Feature 1

Feature 2

Feature 3

You can also go for theme segmentation of features. Themes like Virality, Security, Reports etc.

So inside this Feature 1 you make the stories like you did : using the method of "When..., I want to..., So I can..."

Since you have enough of information now you can easily make the stories based of each features point of view and not anything alse.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.