Design QA; minimising design debt in a fast paced world.

Working in a tech startup can be pretty hectic. Your priorities often change on a weekly or even daily basis. The latter can happen at pivotal yet exciting and busy times at the company, such as during an investment round or when the business experiences sudden growth.

The prospect of swivelling from project to project is thrilling. It can often make you feel more connected to your workplace and coworkers, and requires constant improvement. However, pivoting from one project to another based on the needs of a growing business presents challenges besides just a packed calendar.

Managing design debt

Maintaining design quality through to completion can be very challenging. It requires collaborative solutions. For each two-week sprint, there is pressure on the team to complete an ambitious amount of tasks, and fix bugs that materialise from out of nowhere, impacting the amount that can be achieved within the allotted time frame. Amidst all of this, a designer on an agile product team needs to set some time with the team to ensure what’s been designed is working visually and will work programmatically in the hands of the user.

Quality assurance (QA) engineers

If you’re lucky enough to have a QA on your team — awesome! However, while QAs are the custodians of quality, they are not responsible for ensuring what the engineers build looks exactly as it does in Figma or Sketch. It is a common misconception to assume that because QAs test the feature the engineering team has built, that it is also their responsibility to ensure the design is up to scratch. QAs will reference the team’s specs, but it’s not their top priority. There are plenty of requirements QAs test for that you may not even be aware of.

These are listed below. Note how much needs to be tested and consider how much of your QA’s time is likely to be spent on design validation:

• edge cases
• design validation
• accessibility
• compatibility on different screens
• different network conditions
• error states and validations
• integration with other features
• regression
• localisation (Here at Monese, we translate all our features into 14 different languages. This presents a unique challenge for the QA chapter.)

Regression

Regression is discussed a lot once a sprint has ended. It’s a phase of testing in which all the QAs from all product teams test and verify if the new features developed haven’t broken any existing features. During regression, QAs also make sure the critical functionalities work as expected. All new features that have been thoroughly tested make it into the release candidate, which is then released to our users.

Using Jira

If your product team works in Jira, you should try to get familiar with it too. Otherwise, you could be at a disadvantage. You can use Jira to ensure design quality and minimise design debt. While the experience isn’t exactly intuitive, it’s still the most widely used software for agile development teams. It may look a little intimidating, but learning it shouldn’t be too much of a problem — it’s not exactly After Effects. As a designer, you also pick up new software regularly, so think of it as adding another string to your bow.

Once you’ve become familiar with Jira, you’ll feel better aligned with what’s going on during each sprint, the goals of the sprint and what each of your teammates is working on. This, in turn, will help you better support your colleagues and be proactive rather than reactive in problem-solving.

Methodology

Here at Monese, we use a Design QA methodology for our sprints. What this means is that in Jira, when an engineer completes a ticket, rather than moving it straight to the QA phase on our team kanban board, the ticket is instead moved into Design QA first for design approval. It’s then up to the designer to manage the flow of tickets by reviewing them. Once approved, the ticket is then moved into the dedicated QA column for testing.

Sometimes during a sprint, design improvements need to be made due to unexpected or new requirements that come to light. Communication and collaboration with the engineers are crucial, considering the limitations on time and capacity. I’d recommend sitting down with the engineer responsible for building the change, walk them through your thought process and ask for any insights.

I have found that the most valuable improvements often come out of a collaboration between design and engineering, especially “in sprint” solutions. Engineers will have a better idea of their capacity for what’s achievable, so speaking with them before designing an improvement will save everyone time and promote collaboration among the team.

Design QA helps us here too. Once you’ve completed the design improvement, a new ticket needs to be raised, ideally with a visual of the design improvement, and assigned to the engineer.

Test builds

Understanding how the use of Jira can optimise your design impact is just one half of Design QA. The other is being involved in testing. Abigail Hart Grey, Director of UX at Google, perfectly summarises the importance of designers being involved in QA and what it’s all about: “Taking it [your design] to the finish line”.

Design QA ensures that all the time you’ve invested in your work is well spent. If you’re not involved in testing, you’re running the risk of your QA having the final say on whether the design is good enough to release. Choosing to be actively involved in testing features allows you to fully own the quality of your designs right up to the end of the project.

Testing the latest builds involves collaboration, but this time with your QA. Ensure you’re checking in with them regularly, so you know how they are progressing with testing. This should give you an indication of when it’s most likely they’ll require your time to test the build.

Sachin (our team’s QA) and I often block out an hour to go through a build and log the design improvements. Logging the improvements is done through Jira, the same way as new requirements. Testing builds can also be done independently, but do ensure you have the latest version of the build and log the tickets correctly. Your QA can guide you on how to do this if you’re first starting out.

In sum

This way of working means you can’t solely be working on future features, but it does mean you can ensure the quality of your work is reflected directly to the users you’re designing for.

This workflow may not suit every team or every business using agile methodologies, but all the designers I have met and had the pleasure of working with strive for quality and want only the best for their users. This way of working does involve cross-discipline collaboration (and learning the basics of Jira). However, the time invested in understanding your colleagues’ ways of working is invaluable, especially if it converts into a process that reduces design debt. This workflow ensures that no matter how busy you are or how hectic your working environment might be, design quality will be assured because you, as the designer, are in control of the design quality shipped to your users.

Shout out to Sachin for working with me and contributing his QA knowhow towards this article. 🙌 Find out more about Monese and how we work on our Insights blog. Stay tuned for more articles on design, collaboration and self-improvement. 😀