I wanted to know how you deal with similar situations. We are working using agile methodology so we design piece by piece of the designs. But it happened a lot that when later QA wants to check if what it is developed with our designs of course since we have been doing the work iteratively, there are pieces of the right things everywhere in JIRA tickets (we use JIRA tool). For example: There is one user story ticket that covers only the filters so it has attached the filters but the rest of the page it could be outdated since later we might have continued working in sprints on other parts of the same page. In another user story we were working on the header so the only right thing is the header.

So we end with pieces of the whole puzzle in different tickets and QA cant understand how the whole puzzle should look like. And this results in them asking us: what is the wireframes we should look to?

How do you manage the same issue with your teams? should we have a separate wireframes that has the experience updated? this would mean that the designer does more work. S/he not only has to design the wireframes for the user story but ALSO update other wireframes so QA understands how the page should be (and this one is the updated one).

Thank you in advance!

  • I keep a set of wireframes updated to the latest comments - decisions for reference by developer teams and QA. It's also really useful to revisit some decisions later in the project. Commented Sep 3, 2018 at 23:28

1 Answer 1


First, there is no "right" answer to this. There are, however, many things teams have done to effectively address this and get even better UI/UX in the process.

1) Focus on experiences, not components

When you have a user story that reads "As a user searching for products, I would like to filter the results to focus them on the items I'm looking for." The UI/UX designer should focus on how that interaction should work. The developers then try to create that experience. I see the filtering in your example, but I also see the header, which seems more like a component.

2) Use the whole page wireframes as context, not direction

When you're looking at whole pages, use basic boxes and icons. This means a page can come together in a matter of seconds. This makes it easier to change as needed.

3) Style guides!!!

Ask your designer to create a style guide with heuristics to follow instead of designs for everything. Most developers working with application front-ends have a basic understanding of design and can use a style guide to make good choices even without consulting the designer.

4) Rapid prototyping tools

Tools like Zeplin blur the line between design and code. I've worked with a number of teams where both the designers and developers use tools like this to collaborate more effectively with each other.

All of these approaches can really help either on their own or used together. I hope there are some options in there your team finds helpful.

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.