If you want to rent a flat, you don’t just come to a real estate agent and say, “I am looking for a place to rent.”. You go to the real estate agency, and you tell the broker what your requirements are. Are you looking for a first-floor or top-floor flat? How many rooms do you need? Where is the neighborhood? Is there a school nearby? Is there a supermarket nearby? As we know, the house must meet some specific requirements so it will fit our needs.

The same is true of product design; explaining what we need to do is not enough. All the requirements for the feature must be written down. Without this list, the designer will not be able to create a solution. In this article, I explain why acceptance criteria exist, how they are related to user stories, and why from my point of view the product manager and designer must write them together.

What is a user story?

A user story is a brief description or definition of a feature or product. It is written from the perspective of the user and describes what the user wants.

What should a user story contain?

• Who is the user?
• What do they want?
• Why do they want it?

The most common way to describe these three things is with this user story template:

“As a (user), I (want to), (so that).”

Let’s say we make a recipe app. The users say they have a lot of recipes they love, but it’s difficult for them to find the ones they like when they want to cook them.

A user story could be: As an amateur cook, I want to save all my favorite recipes so I will be able to know what ingredients I need to have to cook them.

• The user: an amateur cook. By conducting user research and creating a user persona, we can define the user.
• What do they want? Saving recipes they like.
• Why do they want it? They want to know what ingredients are needed for his favorite recipes faster.

Why do we need user stories?

A user story enables every agile team member to be on the same page and to understand the project. So they can understand why they do the task, and everyone is aligned with that purpose.

What are the acceptance criteria?

Acceptance criteria are requirements the user needs to accept in order to use a feature. You can see it as an agreement between the user and the team about the user requirements and what the team will deliver.

Remember the house I mentioned in the intro?

The user story can be

As a young family, we want to rent a new house because we moved to a new city.

The acceptance criteria can be

• The house needs to have at least 3 bedrooms.
• The house needs to be close to the metro station.
• The house must be close to the city center.
• The house has to have 2 bathrooms.

Why do we need acceptance criteria?

The acceptance criteria help to focus the team and help them determine what to prioritize. Due to that, everyone understands what they need to deliver and it gives them an idea of what the feature should look like.

• The AC helps with estimating effort and time (for the development team, designers, and testers).
• The acceptance criteria help the team figure out if the feature meets the user’s needs.
• The AC is there to help the testers review the feature and see if it works properly.

The acceptance criteria help with estimating effort and time

Difference between a user story and an acceptance criteria

User stories aren’t the same thing as acceptance criteria. User stories tell us who the users are, what they want, and why they want it. The acceptance criteria describe in more detail what the feature must contain to be valuable.

How to write acceptance criteria

There are two common ways to write AC, one called Rule-oriented and one called Scenario-oriented also known as bdd acceptance criteria (behavior driven development).

I am going to describe only the rule-oriented way because I like it more than the other way. There is no right or wrong here, just that from a product designer’s perspective this is the format I am more comfortable with.

Rule-oriented basically a list where we write all the basic things the user needs so we can deliver value.

Remember the recipe app I mentioned above?

The user story is:
As an amateur cook, I want to save all my favorite recipes so I will be able to know what ingredients I need to have to cook them.

The acceptance criteria can be:

• The user must add the recipe from anywhere the recipe appears.
• The user can delete a recipe from the list.
• The list should be accessible from anywhere in the app.

As you can see, it is simply a list of text that defines what the feature must contain in more detail.

Best practices for writing acceptance criteria

Write short sentences

There is no need to write long sentences here, just do it in a way that explains the criteria in a sentence or two.

Use simple words

Use simple words that everyone on the team can understand. It will make understanding each line easier.

It is easy to measure

Write it down so you can ask, is it in the design? Yes or no?

One criterion per line

Break the need for multiple lines, and try to make each line contain one criterion. In that way, it will be easier to understand.

Every criterion must have a clear WHY

You must know the answer to a simple question. “Why is that a criterion?” If you don’t know WHY, people won’t get why they need to design or develop it.

Sometimes it is necessary to split into another user story

Sometimes a user story has so many ACs that it is difficult to design and develop. If that is the case, split the US into multiple user stories and prioritize what needs to be designed and developed first and what will go to the product backlog.

Don’t be too specific

You can’t be too specific about the solution at that point. Let’s take the recipe app. Avoid writing something like this:

• When the user clicks on the list on the first page, the recipe opens.
• The user clicks on the red button to delete the recipe.
• The button will appear on the right side of the screen.

Instead, write this:

• The user will be able to delete recipes from the list.

In the design phase, the designer have to figure out how to meet the criteria. If you write acceptance criteria in a very specific way, the designer will not have to think about the solution. In another word, the designer needs to think about how to give a solution for the need.

Out of scope

This point is very important. We all have a lot of ideas, but we need to focus on what is important. We might end up adding more complexity than we need if we don’t write what’s out of scope. Let’s look at the recipe app again. Here is what we can write out of scope:

• The user will not be able to create a lot of lists, just one.
• The user will not be able to share the list.

Writing what is out of scope is necessary

Examples of acceptance criteria:

Below you will find some examples of different user stories with different acceptance criteria. I hope that these examples will help you better understand how to write them.

Example-1

As a vendor, I want to use email temples, so I can save time.

AC

• The vendor will be able to create templates.
• The vendor will be able to add the templates to an email.
• The vendor will be able to edit the templates after adding them to a mail.

Example-2

As a client, I want to purchase products from the mobile app so that I can do it wherever I am.

AC

• The client will be able to add products to the list.
• The client will be able to delete products from the list.
• The client will be able to pay by credit card.
• The client will be able to set a default direction.

Example-3

As an amateur runner, I want to set goals so I can improve my running abilities.

AC

• The amateur runner will be able to select one goal.
• The amateur runner can modify the goal.
• When the goal is achieved, the app will offer him/her a new goal.
• If the user does not complete the goal, the app will offer him/her a new goal.

Who is responsible for writing acceptance criteria?

In many teams, the person who writes the AC is the product manager or the product owner. I believe the product manager or product owner should write it along with the designer. It is because the PM can come up with an idea about what the user needs. The product manager /product owner and designer can work together to see other products that solve the issue (benchmarking) and build some basic mockups together to shape the solution and prioritize what’s important. In that way they create a common understanding of the problem, the value they have to deliver, and how they can solve it. I believe this is work that must be done together since that is the best way to work on a solution and avoid misalignments.

When writing acceptance criteria

We have to write the AC before we design the solution. It’s because if we don’t have a user story and acceptance criteria, we will not know what to design. The most powerful way for me is to write the idea and then start shaping it. You can begin by reviewing other products, making a prototype, and presenting it to the development team to get feedback. Once you do all this, you will see that it is easy to write it. In addition, if the PM works with the product designer at that time, the design of the solution will start taking shape before the design phase begins and both will have a shared understanding of the problem and possible solutiones.

If you don’t write it before the design phase, it is like getting into a car and driving without a plan, you will not get anywhere.

More Tips

• You may change some criteria as you design: sometimes we start with some acceptance criteria, but then we realize that the scope is bigger than we thought. At that point, we can change the scope. Another solution is to split the story into two or more.
• It is recommended to read it with the team before each sprint: when a new user story is added to the sprint, it is more than recommended to review the user story and its acceptance criteria. That way, we can ensure that all team members are aware of its scope.
• Everything should be documented: you can document it in a Jira ticket or on Confluence (Or on any other tool). Remember that the only way to remember the acceptance criteria is to write them down.

To summary

By using acceptance criteria, we can describe in detail what are the requirements for the feature or the product we need to be able to design a solution that meets the needs of the user.

We discuss why acceptance criteria are useful for aligning the product owner, product manager, designer, development team, and QA tester around a task.

We saw some best practices for writing acceptance criteria, such as the need to write them in an easy-to-understand way.

Finally, we look at some examples of user stories and acceptance criteria. In addition, we understood why the product manager or the product owner should write them with the designer before starting the design stage.

Resources

For more information about acceptance criteria, I recommend that you review the sources that helped me to write this article.