What should we focus on when storyboarding? Application interaction or user goals?

Question

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?

Answer 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.)

Answer 2

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 ...".

Answer 3

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.