Lesson Monday

When we add a front end to an application, we need to consider how our users will need and want to use our app. We need to think in terms of human behaviors and interactions with our application before we ever begin coding. Just as we create tests with plain English descriptions, we should create user stories to identify the specific purposes of our app in non-technical language.

User stories often use this sentence structure:

As a < type of user >, I want < some goal > so that < some reason >.

Often it is the client or stakeholders, not the developers, that generate user stories as they identify what they want to see developed and why they want to see it. The developer then determines how to accomplish the work.

User Stories in Record Store

Let's use our record store application as an example. The owner of All Sales Vinyl has talked with her customers and come up with a series of user stories.

Here are some user stories she might present us with:

  • As a customer, I want to see a welcome page that includes a list of recent Albums and featured Artists.
  • As a customer, I want to click on an Album to see more information about it.
  • As a customer, I want to search for an Album by name.
  • As a business owner, I want to be able to add, update and delete Albums and Artists.

From these stories, we can begin to determine the final design of our views and how they will integrate with the code we have developed.

For the rest of this course section, project objectives will include user stories. As you implement these user stories in your application, consider adding your own and make sure to include them in your README.

Lesson 19 of 29
Last updated August 7, 2022