Should we write Acceptance Criteria of a User story before Starting with UX/UI Designs?

Question

I am currently working as a Business Engineer/Product owner in a company. We follow agile methodology. I want to discuss the challenges I faced during the Design and Development Process. As a Business Engineer, my job is to work with the requirements provided by stakeholders and transform them into User stories.

The process we follow right now:

Requirements -> User stories -> Acceptance criteria -> UX/UI Designs -> Refinement of User Stories -> Implementation of the requirements

My Questions are as follow:

1. Should Acceptance criteria be written before the UX/UI Designs?

The issue I face here is that I have to think like a UX/UI designer, who is hard as I don't have a design background. Based on a User Story and its Acceptance criteria, the design team is designing screens, leading to frequent changes in the Acceptance criteria.

It would be helpful if I could get suggestions on the same.

Answer 1

Based on your description of the process and the question, it seems like you're trying to fit things into a linear flow. That's not usually a good way to set the team up for success.

You should start writing the acceptance criteria alongside the user stories. However, performing the UX/UI design activities may result in modifications to the user stories and/or acceptance criteria. Similarly, refining the user stories may lead to splitting and merging the stories along with asking questions that result in new or changed acceptance criteria. In fact, you may even start asking some questions during implementation, in which you'll want to capture the answers as new stories to defer the work or new acceptance criteria to capture the intended behavior of the system.

Leave your process open to iteration. Don't try to get too many details too early in the process - do just enough work to reduce the risk to let the next activity start, and be open to discovering something new that changes the previous work.

Answer 2

Short Answer

yes

Detailed Answer

Creating a detailed mock-up can be a waste of time if the Product Owner determines the size of effort is too high to include the story in an iteration.

Risky Flow:

1. Acceptance Criteria written
2. Mock-up is created Team sizes story
3. Product Owner determines that the effort of the story doesn't justify its cost.

Outcome: time has been spent creating a mock-up that won't be used.

Lean Flow:

1. Draft acceptance criteria created
2. Team roughly sizes story (t-shirt)
3. Product Owner decides if the rough size is worth the cost of the story
4. Low-Fidelity Mock-up is created (when justified)
5. Acceptance criteria could likely be further refined during mockup creation
6. Team sizes the user story
7. Product Owner determines if the cost of the story justifies including it in a backlog

Answer 3

Keep your acceptance criteria independent of the solution. We shouldn’t have to change the specification for small changes in the UI requirements as the intent behind the system behaviour doesn’t change. The acceptance criteria capture the basic requirements associated with a standard feature without being tied too closely to the UI or the solution design. If I include details of what the UI should look like in the acceptance criteria, I’m taking the focus away from what the specification should really be capturing; behaviour of the system. Finally best way to describe UI requirements is through visual communication.