For more than a year now, we, as a company and as a team, have been debating and studying Design QA. We define design QA as a quality assurance assignment focused on maintaining commonalities between a mock-up and the finished product.
Heads up: If you are unfamiliar with Design QA, explore the basics on our blog.
Lately, the vision of product design has become a determining factor for product success and customer satisfaction. Due to that trend, design QA is being taken more seriously these days. The product teams now feel the compulsion to execute the vision of product design accurately. And who better tackle it than the product designers themselves?
Steps of Design QA
So, what are the steps of Design QA? It’s simple:
- Ensure that the material on the development is faithful to the mock-up we initially prepared.
- If scenarios were not pre-imagined in the mock-up, ensure their purposeful implementation.
Design QA necessitates an examination of responsive designs as well as browser testing. And, because all the check boxes are difficult to check, we ensure that the most critical ones are.
Design QA in a project
Let’s look at how Design QA may be used in a project.
A GitLab board for a project is provided below. Let us take a moment to define these boards and how they work.
- Open: Any tickets developed in open are migrated to the To-do bucket at the start of each sprint. Alternatively, designers will transfer related tickets to the Design bucket before the sprint to ensure that mocks and designs are available.
- Design: Designers select a ticket from the Open in Design bucket to begin working on it. This bucket can be put before or after the To-do bucket, depending on how the design tickets are arranged in the project. If the design is included in the sprint, this bucket will be put after the To-do bucket.
- To-do: This is a list of all the tickets that are not allowed to be completed during that sprint.
- In progress: This is a list of all the tickets that are presently being worked on.
- Development: This list contains all the tickets being pushed to development and ready for testing. These tickets can be picked up by design QA and tested.
- QA: Here are all the tickets that the QAs are testing at present.
- Staging: All authorized tickets from QA are subsequently submitted to staging.
- Done: A ticket is moved to done when the feature is deployed to production.
- Closed: The tickets are finally closed because they have been completed and need no further action.
As a Design QA, we excel in the Development and QA Buckets and occasionally in staging. We test the tickets in these buckets using the following test techniques.
You might also like: Information Architecture in User Experience
Accuracy: How close are the initial design and the final developed product? How much have we deviated from our initial vision?
Responsive: How the product behaves when viewed on different screen sizes and orientations. Does the product behave consistently and correctly in different visual environments?
Browser Testing: Examining how the product behaves in various browsers. A product might run smoothly in one browser while failing to run on another. An inconsistent product is a design failure.
If a test fails in any situation, we mark it as failed in Design QA, point out the errors or concerns, and provide guidance on what to do in such instances. Find a sample ticket below:
See how the calendar from the development differs from that of the mock-up and how these things are different in different browsers. Here we list out the bugging factor and list out the required changes. If any designs are not changeable, we discuss them and make the changes to the mocks instead in case of necessity.
Frequently Asked Questions
Who is the InCharge of Design QA process in product design?
QA engineers and even UI designers can be incharge of design QA Process.
Conclusion
Design QA has been an essential part of the workflow at Gurzu these days. We ensure all our sprints are equipped with Design QA and our product is honest to the initial design.
Our experience says it is a useful tool that will create a better-quality product with better design. That concludes the Design QA as a system.
At Gurzu, we make powerful softwares based on Ruby on Rails. Explore some of our awesome projects here. Need help with software development? Book a free consulting call!
