“Storytelling is the essential human activity. The harder the situation, the more

essential it is.” - Tim O’Brien

It’s your turn! Your request for a new report is at the top of the queue! You’re getting ready to sit down with an analyst and design a report that you have been waiting for since go-live. How do you tell the analyst what you want? You don’t know how to create a new report from scratch yourself, so how are you supposed to tell her what to do?

You’re not. (I’m serious.)

Don’t worry - the analyst knows how to create a new report. Rather than telling her what to build, your job is to help her understand how the new report should function and what it should show you. The best way to start the design off right is to explain what you do, and why you need to do it. User Stories give us the ability to explain our actions, express frustration or passion, and influence others to help us. The best stories tend to follow a formula, as do the best User Stories (think: the “coming-of-age saga,” the “epic journey,” or the “year-over-year participation comparison”...).

So let’s consider the art of a good User Story:

Our goal is to explain who we are, what we do, why we do it, and how we currently do it or need to do it in the future. The purpose of writing User Stories is to set the stage for how we use our tools, and define our requirements for building new functionality. Tools are built with a certain usage in mind, but there is no guarantee that it will feel natural to go about it that way, or that it even makes sense for our business (creating a gap). It may seem tedious, but a User Story essentially narrates your work, task by task.

It’s best to break up User Stories into bite-sized pieces like that. Like many tales, you will want to pick a single subject as the basis for each story. Keeping the plot simple will help your readers organize your stories into a more comprehensive illustration of what you need to do your job. If the User Stories are too broad, they lose the power to inform a design that is tailor-made for you.

User Stories also become critically helpful later, when assessing if a tool meets your needs. Although they are often used for testing, User Stories define what we want the tool to do, rather than asking you to walk through the steps of running a report as a Test Script would. User Stories also do not test the accuracy of the data presented on-screen or in a report, the way Unit Testing or Functional Testing might.

When writing your User Stories, consider the four elements:

Who am I?

The best way to introduce yourself to your reader is by your job role. This situates you within the organizational context, and provides a framework for others to understand at what level you need to function. As a Program Coordinator, for example, you may need to interact with data entry staff as well as the leadership. As an Administrative Assistant, you may need to understand your organization’s fundraising practice in order to accurately track activity. For these two examples, we have already begun our user stories:

“As a Program Coordinator, I need to…”

What do I do?

It’s difficult, I know… but try not to write stories listing every report that you pull today. When you say that you pull report “FR_327,” it doesn’t explain what that report says, or what you do with it once you pull it. It also doesn’t make for a very interesting story for your analysts if they are reading through a list of reports that are foreign to them. Try instead to explain what the report does, or what information you want to capture:

“As a Program Coordinator, I need to understand the dollars raised by Fundraiser...”

Why do I?

So now that we know your role, and the information that you need to capture, tell us why you want it. What are you going to do with the information once you have it? What do you do with report “FR_327” after you pull it? Who gets to see it? How often do you pull it? The answer to “why” is always the most valuable part of the User Story, and believe it or not, it’s this part that determines the ultimate solution:

“As a Program Coordinator, I need to understand the dollars raised by Fundraiser so that I can provide each with their total dollars raised every month…”

Can it be better?

Here’s the tricky part: this is your opportunity to explain how this task should work, not just how it works today. That’s difficult because you need to envision what else you might need to make the task easier or the report more informative. You need to figure out what doesn’t work as efficiently as you would like, and tell the story of a better way. For this, you will need to think about the task as you perform it, and others who might benefit from this information in way that they cannot today:

“As a Program Coordinator, I need to understand the dollars raised by Fundraiser so that I can provide each with their total dollars raised every month, and ultimately be able to roll-up those dollars to a department total for our Director.”

Now it’s time to write your User Story journey!

You will probably have many stories like this example, but they should be easy to write. We recommend that, as you go about your workday, take a minute to narrate the tasks you perform. Pay careful attention to how frequently you do the work, and who needs to see it. This will give your analysts an illustration of what you do and why you do it, and give them an opportunity to design valuable solutions. The more well defined and captivating the stories, the more helpful the tools and solutions will be designed for you.

If you need help collecting, organizing, or editing your User Stories, reach out to the wordsmiths at BrightVine Consulting at info@brightvinesolutions.com or complete our online contact form.