A green wall is a vertical structure covered in plant life, also referred to as “living walls” or “vertical gardens”. The greenery is often planted in a growth medium […]
The act of creating user stories lays in the nature of the Agile technique. User stories in the form of simple constructs help to clarify the functionalities of the product from a user’s point of view. Putting users’ needs at the center of brainstorm, the chances are to come up with new desired features that help the product meet the expectations. However, the question is, how to write user stories so they favor your company?
To be able to write something meaningful first you need to know who are the customers (your target group) and what problem does your product solve? Having an answer to the question means you know why people would like to use it.
Study your users to capture their point of view and expectations regarding the product. It can be done by performing interviews with them, survey them or by monitoring their behavior online. Tools that might be helpful here are Client Heartbeat or Survicate. After gaining an understanding of their needs, you no longer speculate but know for sure. Of course, at times when there is no budget for studying the behavior of your customers and asking them what features they need, there has to be someone who simply invents all the functionalities. A person responsible for creating user stories is then a business analyst. His work is usually supported by the knowledge of designers and developers.
Stories must be written using simple and accurate language. Avoid tech terminology and other difficult to understand phrases. The stories should be short but at the same time carry enough information. The general scheme follows:
As a (role), I can (do something needed) to then (why do I need the function).
For instance:
You can also create specific personas characterized to play different roles in your target group. Let’s say, Monica who is tidy likes to know everything wants to monitor what’s going on in the company. Then the story would look like this:
Apart from short user stories, you can build up longer ones called epics. They serve to explain more complex functionalities and usually can be broken down into several smaller user stories. They are helpful when you stick too much to the details of your app and forget about the bigger picture. Some features are more complicated and won’t be reached by clicking one button. The need for such functionalities takes more time to be explained hence the epics.
Developers should add tech specifications to the written stories. Functionalities with references are more readable during the programming part. Software engineers can link given stories with their tech requirements which eventually leads to a better understanding and smooth working. What’s more, tech specifications help to clarify the valuation of the project as they show how much time was needed to finish a given task or what tools were used to finish them.
Usually, user stories are placed on a board in the form of sticky notes. It’s good at the beginning but you should start a system of prioritizing the most important functionalities to control the workflow and the final product. For sure you will have there some stories that were not accepted. Don’t reject them but separate from the main plan because they are a good source of inspiration. Sometimes a given function needs so-called acceptance criteria. They are the conditions under which the function will work. For instance, in a taxi app, a passenger has the ability to add a driver to his favorites. Acceptance criteria here may be:
To manage the number of ideas and to keep them readable you can check out Product Canvas.
The reason why you need a set of good user stories is that you want to define your product. Usually, there is a lot of people engaged in the process of creating. You should bear in mind that all of them must have a similar picture of the final project to keep the consistency of it. User stories help achieve that, providing an understanding of the users’ needs. They create a room for meaningful discussions between the software engineers and non-technical people. The simplicity of the method enables to entirely define the product despite its complexity.
Tools linked to direct user feedback, provide you with information about the success or failure of the given feature. Use them wisely and monitor the acceptance rate of your customers online. This way you’ll be able to not only define their satisfaction with the product but also the future of it.
User stories are a good tactic that enables to analyze the way app works, create better design, test with better accuracy and develop better application overall. They help in brainstorming ideas and prioritizing features. Also, because of their simple structure, there are more non-technical people who can join the discussion. However, the stories itself are just one of the steps needed to create user experience (UX) or the architecture (technical aspects) of a mobile app. If you want to visualize the users’ journey and rethink the design read: How to improve functionality and UX of your app?