Build your app: List all app features.
In the previous post of the series, we discussed the importance of researching your competition.
Now that you have a proper background check, you can jump into the next step – defining your app functionality.
How not to do it
There are two types of mistakes when people start bringing their app ideas into life:
- The Writer approach
- The Designer approach
The writer would sit down and start writing lengthy app usage descriptions. He would create a long document of scenarios, maybe add some nice pictures of people using the app on a subway. The problem with this approach is that it takes really long to understand what the app is actually doing and also it’s really hard to change anything later when you want to add or drop some features.
The designer, on the other hand, would start by choosing branding colors, creating a logo and would try to describe the app with screens and all the interactions. He has a clear vision of how the app should look and he wants to put it all on paper. I must say it’s an improvement when we compare it to the ‘Writer’ way, but still, it doesn’t give a quick answer on what the app actually does. Not to mention that changing anything in the process is also time-consuming.
User stories to the rescue
The best way to describe your app functionality is to write short little sentences called User Stories.
As a <Role>, I want <Feature>, so that I <Benefit>
As a User, I want to get news from my neighborhood, so that I don’t have to look for them in multiple sources
It’s a simple, yet powerful, tool which will help you define your app idea in more detail and still allow you to easily redefine it when you progress with your work. The biggest benefit of using user stories is having a high-level documentation of your project, which acts as a foundation for future work. Whenever you create a wireframe or consider some design changes you can always get back to your user stories and see if you’re on the right track.
How to write user stories
When you look at the user story template you might think that writing user stories for your app is simple. But when you actually sit down and start writing them, you’ll probably have a ton of questions. Where to start? What is the benefit in this case? What level of detail should I have with them?
First of all, you shouldn’t worry too much about the quality of your stories – this is the kind of tool that works best without too much thinking about the details. Just do it. Most likely you’re writing them for a handful of people and when you get a feedback that something isn’t clear, you can always get back and redefine the story. Some people would disagree, but I feel that there’s no such thing as the bad user story.
The other thing that might concern you is the level of detail. Consider the example above
As a User, I want to get news from my neighborhood, so that I don’t have to look for them in multiple sources
This can be broken down into several different user stories
As a User, I want to select local news providers, so that I get only relevant news
As a User, I want to be notified when new provider is available, so that I don’t miss the opportunity to follow them
As a User, I want to filter my news list, so that I can easily browse through important data
Again, there is no right-or-wrong way here, do whatever feels right for you. In general, I suggest sticking to a higher level of user stories at this point, so you don’t get buried in details and focus on what’s important. But if you feel that some detailed user story is really important, just write it down.
When I was writing these examples I had to put some extra time to come up with the answer to the question: what is the benefit of this story. Very often the benefit is obvious or hard to define. Consider this example from my Mobingo app.
As a User, I want to choose multiple locations, so that I receive information from different locations
As you can see the feature itself is a benefit, so there’s not much sense in writing it down again. This is why I suggest using simplified user story format, where you skip the benefits part and just write down the features. It’ll make your life easier, and you’ll still be able to understand why you want them. As a User, I want to choose multiple locations is a perfectly fine user story. No need to over-think it.
Mobingo Case-Study
In the last post, I defined my Mobingo app idea with this:
Mobingo is a mobile app for getting news and notifications relevant to specific location, like alerts about scheduled power outage in your home.
So the next step is to drill down a bit deeper. It’s a good idea to write down all app features you can think of, even if you don’t want to include them in the first release of your app as we’ll be picking the ones for your Minimal Viable Product later.
Here is what I’ve come up with for the app User role
- As a User, I want to get news from my neighborhood, so that I don’t have to look for data in multiple sources
- As a User, I want to choose my location, so that I receive only relevant information regardless of my current location
- As a User, I want to select my location on map, so that I don’t have to type in the address
- As a User, I want to choose information providers, so that I receive only relevant information
- As a User, I want to choose multiple locations, so that I receive information from different locations
- As a User, I want to get alerts only about important information, so that I don’t get too many distractions
- As a User, I want to send messages to providers, so that I can notify them about my problems
- As a User, I want to share my preferences on different devices, so that I only setup the app once
- As a User, I want to share information with my friends, so that I can notify them about interesting news
- As a User, I want to get service provider address, so that I can get driving directions to their office
- As a User, I want to visit service provider website, so that I can get more information about them
There is another actor in this app – Provider. He’s the one putting all the content into our app, so he also has some user stories. Let’s write the user stories in a simplified format.
- As a Provider, I want to provide news messages to my subscribers
- As a Provider, I want to delete news items
- As a Provider, I want to connect my existing RSS feed
- As a Provider, I want to mark messages as important
- As a Provider, I want to view stats about my subscribed Users
- As a Provider, I want to view stats about Users reading my messages
- As a Provider, I want to publish different kind of messages (pdf, images)
- As a Provider, I want to have a preview of my current news feed
As you can see – provider will require some kind of web dashboard, where he can manage all of the data. The mobile app is growing, not sure if I can do it within the budget, so let’s trim things down in the next episode.