An Introduction to User Stories: thinking from a user’s perspective

Posted by Andrew Schwartz on 14 06 2017. 1 Comment on An Introduction to User Stories: thinking from a user’s perspective

So what are user stories anyway?

Detailed plans often go unread. With little time to review specific and intimidating plans, workers often start projects first and review plans as they go. Most plans are deciphered as the program is built and as a result, key features are often overlooked. If you’re thinking about developing an application [ninja-popup ID=1227] download our User Story Template [/ninja-popup]to help think through your project before you get started. It can also help when accurately quoting a project and setting milestones.

In today’s fast-paced development environment, we begin creating and understanding our ideas only as fast as we can get them down. Writing detailed plans can get in the way of creativity. This is why we’ve always found it best to design and think first, then explain our thoughts from a user’s perspective. Using what’s commonly referred to as “user stories” from the agile development approach. These user stories allow us to create the perfect combination of technique and planning when it comes to application development.

 

Technical Specifications

User stories don’t have any of the normal technical specifications that we’re used to seeing in documents that outline a mobile application’s technical spec and uses. Instead, by breaking down each and every function into a structured statement, user stories give an idea of how the end-user will be using the application, and the functions it requires. This work requires a knowledgeable developer to decipher the true needs in terms of hours coding, budget, and time-frame. Any additional requirements can be noted under what is called the ‘general requirements.’

 

 

Structure

An example of a user story would be structured into three lines as shown below:

As a User who just downloaded the app,
I want to see an introductory splash screen with copy (provided),
so that I am greeted after signing up.

Sometimes the bullet is colored to show importance into of each task by group; for example: Necessary, Nice to Have, and Reach Features.

 

Inferred Information

As you can see from the example above, there are no “technical details.” Instead we’re provided with some very basic inferred information:

• Who (what user) cares about this feature?
  • The end-user or a specific type of user.
• What do they need/want to do?
  • See the splash screen when some information when they start the app for the first time.
• Why do they need the feature being described?
  • Well, this one is a necessity, but the next story requires “login”- something widely used by the majority of apps that need to store information.

A skilled developer will only need the general requirements in reference to these plans and the designs provided in order to understand and begin developing the frameworks of the project. These general requirements resemble a list of conditions that must be completed along with the functions provided, and they help to determine how the functions will behave when completed.

Here are some examples for the user story above:

[one_second]

• See a background image on the splash screen
• Click to view sign in page

[/one_second]

[one_second]

• Include Facebook Sign In
• Include a “Forgot my password” link

[/one_second]

 

 

Getting to the nitty-gritty

Although the action of repetitively writing “As a User…. I want ….” can be boring, it has proven to be quite useful when helping others to understand your concept. Let’s break down the user story into three digestible pieces that help explain how to fully complete a set of user stories.

Keep in mind, however, that we never want to try completing a user story in three parts. User stories take brainstorming, reworking, restructuring, and revising to become complete.

As a User… who selected the navigation bar,

The first statement, “As a User,” can be used to express the user’s persona: who the user is. This can be an end-user. Specific end-users include end-users or administrators. These can also get more complex with specific users for each department of a company, or a club with different levels of members.

The user personification is used to show the specific user receiving value from an action taken through the program. Ultimately this will help you determine exactly what that specific user is looking for and why it is necessary.

Examples could be, “As a User who accessed their profile” or “As a User that is selecting another user’s profile.”

I want… to see a list of options containing: Feed, Search, Liked, Friends, & My Profile.

This is what the user is looking for, and what they care about. It may even be the reason the user is using your application. For this example, I’m just keeping it simple with a general navigation story. This tells the developer a great deal about the project combined with the design files. Now the developer can see what they’re working with visually and understand how it works programmatically.

An example could be, “I want to be able to select my profile picture,” or “I want to be able to select another user’s profile and view their statistics and friends.” What the user wants can range anywhere from having a splash screen to saving banking information, and more.

So that… I can navigate around the application easily and it’s visually appealing.

The final portion of the user story is the why; what the user wants or what they get out of the feature listed. It also tells the developers what intent the user has with the specific function. This portion of the user story can vary the drastically throughout the complete set of user stories because they are specific to each function.

Examples could be, “So that other users can identify me through my profile picture,” or “so that I can compare my profile to theirs and view their friends.” The why can indicate why the users need the function. This gives us insight as to how the app will function and thus how we will set it up during development.

Revise, revise, revise!

We recommend grouping the user stories by section, screen, user type, or any other relevant method of sorting. Once you’ve gone through listing out the completed set of user stories, it will take several revisions to get them up to par with any routine development plan. These user stories along with the general requirements, and the design files are the key ingredients to a successful application. Without proper planning, area and function are often overlooked, leading to increased costs down the road and a narrow vision for the project.

 

 

Why we use this structure

User stories help to create a easy structure for your project’s specifications, all without limiting the potential functionality. They allow for rapid and coordinated changes to the overall scope of work without shifting the entire project or losing the bigger picture. User stories can be broken down into small digestible chunks of content that every member of your team can understand.

If you’re looking to try this technique of your project or if you’re just trying to get a idea for your projects, [ninja-popup ID=1227]download our User Story Template[/ninja-popup].