Before you start drawing some sketches of your app screens the first step should always be understanding your user stories. Better yet, creating a whole product architecture. And this is exactly what we will be talking about.
So what is a user story? There are multiple definitions for it depending on where you look. If you google it right now you will find something like this “A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.”. Quite a lot of words with not a lot of substance, right? In much simpler terms a user story is a description of something you want your user to be able to achieve.
For example: “As a passenger, I want to be able to book a ride to get to my destination.” Or: “As a user, I want to be able to find new interesting content related to my interests”.
If you break those user story sentences down you will find that they consist of three important components: users, their goals, and steps they’re taking to achieve them.
The first thing to know about users is that your app might have multiple types of them. For example, Uber has two main types of users: drivers and passengers. Seamless food delivery has two as well: restaurants and… Well… Let’s call them eaters. And if you think about it, even Instagram has two types of users: content creators and viewers. It’s just that with Instagram one person can function as either type of the user.
Therefore, the first step in writing your user stories is to identify all user types that you’ll have. In the end, you will need to ensure that you’ve outlines user stories for each of those types.
Now to goals. Each user has a specific goal that they want to achieve. This is the reason why they are using your app. Is the goal to get to your destination? Is the goal to communicate with your friends? Or is the goal of finding the love of your life?
Now that as you start thinking about it you might find that your users have multiple goals. That’s ok. Divide them into primary goals and secondary goals. And then – move on to understanding the steps.
Now that you know what types of users you have and what goals do they have it’s time to understand how to get there. What action does your user need to take in order to achieve their goal?
For example, in order to get a ride to pick you up and get you to your destination you probably need to do at least a few things:
- Select your pickup location
- Select your destination
- Initiate the booking process
Now that we have described all of the elements of good user stories we can put them together to create a detailed user story and then a project architecture.
So first, if we combine all of the elements then one of the user stories can sound like:
As a passenger (user type) I want to be able to get to a certain destination (the goal) by booking a ride from my location to the specific address (steps).
Once you will write all of your user stories you can now create what we, at Messapps, call a project architecture. Project architecture is a unified collection of user stories organized in a form of a flow chart. When we were creating user stories we were thinking in terms of abstract steps and goals. Now we will put it all in more precise terms suitable for your app.
When writing the project architecture imagine yourself downloading or opening your app for the first time. What should a user see? Likely they will first see some onboarding screens. Then they will likely see a login & registration screen. If they can log in they will head straight to the main screen of the app. If not they will need to first go through a series of registration screens. Once they get to the main screen what do they see? Perhaps it will show their location and will prompt to enter the address of where they want to go. And so on and so forth.
In other words, the project architecture will allow you to create a step-by-step guide of every action user can take and every screen they can visit in the app.
Don’t worry if initially you won’t be able to identify all of the screens and actions. That’s absolutely fine and your project architecture was made to be adjusted as you move forward.