The feature spec is a document that is a walk-though of your project from the users perspective. It provides a listing of all the features you are envisioning for the product. The feature spec functions as your overall plan for the project. Rather than thinking about it as locking you in, use this as an opportunity to think through your product in detail.
To help us think through features, it is useful to start with the users.
You should have your teams and first repo already set up, if not see first-meeting.
You’re going to need a list of features that you will work off of. To get to this list of features — we’re going to first make up some users. Their needs and desires will drive our features — so they need to exist first. Expecto Patronum.
More broadly speaking, stakeholders are anybody who gives a damn about what you are building. These can be your end users, founding team, investors, clients, customers, parents, and professor. Regardless of what you are building, there are most likely humans involved. Stakeholders can even be non-humans in the case where you are building something for animals or aliens. Regardless, identifying who they are and what they want will help you figure out what to build.
User stories are short scenarios about how your product is used. User personas are the fictional individuals who comprise your product’s users. Your personas should have names and believable backgrounds. They should have specific demonstrated use cases for your product. You will refer to them as you work on the product and you’ll find they will be quite useful! The aim of user stories is to codify specific use cases for your product and allow them to be easily communicated as you build the product. They help keep the team focused on the functionality of the product for specific people rather than getting sidetracked by features that seem “cool” or “look good”. For every feature in your spec you should have a user persona that would find it useful or compelling.
🚀 Seek out the github issue titled Project 2: Feature Spec and add each persona as a comment on this issue. You should aim for each person on your team to have created 1 persona.
Structure your user persona like so:
# UserPersonaName
## Background and Demographic Information
* _Fictional Name_:
* _Demographics_: (short)
* _Overheard quote_:
## Narrative
*Short narrative or description about the user and why they're using your product/service (try to capture their attitudes, needs, problems/concerns, and experience)*
## Behavioral and Dimensional Information
* __Goals and Motivations:__
*(goals should directly relate to product/service)*
* __Tasks:__
*(break goals down into tasks — what does the user need to do to accomplish a particular goal)*
* __Pain Points, Concerns, and Challenges:__
*(what are they worried about? what do they have trouble with?)*
* _User Flow_
*(describe a typical scenario of the user interacting with your product – this is a short ordered list of actions)*
Once you have the user personas they will help a great deal in figuring out your essential features and thinking more deeply about what you are building.
🚀 add another comment to your Feature Spec github issue with this outline.
This does not need to be exhaustive by any means, but will be a place for you to start prioritizing and choosing how and what to work on. In fact, please keep it short and to the point - we don’t need every button listed, just the very primary features that are important to your users.
# Feature Spec
## User Personas
*links to persona issues*
* [the thinker](github/link/to/person)
* [the walker](github/link/to/person)
## Feature List
* list of features
* <font style="color:red">[ 🔥 primary feature]</font>
* some more
* <font style="color:orange">[ 💼 secondary feature]</font>
* maybe even some stretch goals here
* <font style="color:lightblue">[ 🏹 stretch feature]</font>