App processes: how to describe them with User Stories

by Andrea Maioli on 10/27/2016

In my last article dedicated to app design, we saw how to create a User Profile, which is the document that describes the user types, the obstacles they have to overcome, and the advantages they can gain by using the app.

However, before we proceed with making the mockup, there’s another step we have to take: describing the processes that the app can optimize, and the best way to do that is to provide examples of those processes in a document called a User Story.

A user story is short, one page at most, and it describes a possible app-usage situation in which it’s easy to identify with the user and experience along with them the advantages they gain.

A user story consists of the following parts:

  1. The context, which describes the conditions surrounding the action that’s about to occur.
  2. The problem to be solved.
  3. The solution the app offers.
  4. The processes that the app allows users to perform.
  5. A conclusion that summarizes the value of the app in the situation described.

How many user stories do we need to write? At least one for each primary process for each app user type. In the ToBuy example app, the primary processes are putting together the shopping list and checking it off in the supermarket, so we should write at least two user stories. A complete description also includes examples of the secondary processes, but this can also be done later.

Now let’s look at the first of the two cases as a user story example. We’ll have the fictional “Giovanni” as a user; his profile is illustrated here.

It’s Saturday morning, and Giovanni is getting ready to go to the supermarket. No one else is home, so it’s up to him to decide what to buy.

Fortunately, he uses ToBuy, so the other members of his family no longer have to write down what they need on that slip of paper near the microwave when they’re running out of something. Through the list sharing feature, Giovanni finds the missing items already on this week’s list.

Last night his wife put together the menu for the week, and using the virtual pantry she has already added everything she needs to Giovanni’s list without even having to type anything. She simply ticked off the things she usually buys to make the meals in the menu.

Giovanni’s list is nearly ready, and he opens the virtual pantry as well. It’s organized by type, and checking in the pantry closet, the bathroom, and the kitchen, he adds everything that’s running low without forgetting a thing. To be sure he gets the right kind of detergent that his wife uses, he snaps a photo of the package and attaches it to the list.

Now Giovanni is ready to go, with his list already reorganized in the order that the merchandise is set up in the store, and he skips the nuisance of having to copy it out again.

While Giovanni is on his way to the store, his wife remembers that she invited some friends to dinner, so she adds some appetizers and extra drinks directly to the list. Now Giovanni won’t receive any more of those little messages that used to complicate things in the store. Some times he flat out missed them anyway!

Giovanni enters the store knowing that he has done all he needs to to get everything his family needs. And if anything was forgotten, his wife could definitely remind him!

Do you see the advantage of this method? With this kind of story it’s easy to understand whether the mockup we’re imagining satisfies real needs, and therefore it puts us in the best position to design an app that will make our users happy.

Next week I’ll continue with the third design document: the Business Model that describes how the app will be monetized. In the meantime, if you want, you can try to complete the ToBuy user stories as an exercise. I’m curious to discuss it with you.

Leave a Comment

Previous post:

Next post: