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.

  • Am I right to assume that when you say user story, you actually mean something like JIRA ticket? Otherwise "Requirements -> User stories" doesn't make sense. Commented Apr 13, 2023 at 20:56
  • @abetteroliver They might mean requirements gathering? At my work we sit down with the customer to see what they need. Then we have to translate those into user stores. Commented Jul 18, 2023 at 20:24
  • @MiniRagnarok A user story is literally what the user tells you: "I want to have X", or "I need to be able to do Y". User stories are an alternative(!) to traditional requirements. That's why they are considered agile. If you have requirements already, then what's the point of making up a fake user story? Developers will simply implement the requirements. The story has little purpose. Commented Aug 16, 2023 at 13:08
  • @abetteroliver Either way there's a translation happening from a meeting with a customer into user stories. The name is immaterial to the step. Commented Aug 16, 2023 at 15:01
  • @MiniRagnarok In the case of a user story, what users tell you IS the story. There is nothing to translate. You can "translate" user stories into features or derive requirements. Commented Oct 16, 2023 at 12:12

3 Answers 3


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.

  • Hi Thomas, Thank you for your answer. I believe User story is a process (also debatable though), which requires brainstorming and iterations. Your answer gave me a clarity and direction. Thank you once again Commented Mar 23, 2022 at 14:57

Short Answer


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
  • Thank you for your suggestion, Ryan. Commented Mar 23, 2022 at 14:57

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.

  • Thank you for your suggestion, Mish. Definitely a good point here, Acceptance criteria should be independent of the solution. Commented Mar 23, 2022 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.