In digital product design, PM’s often autopilot UI/UX implementation through design system, but the process routinely fails in the long run.

As Product Manager, I revamped the POS website of my company. The goal was to deliver an exceptional user experience to elevate the status quo of design and product features in the industry.

It was a challenging project — in the limited time of 3 months we had to deliver 40 webpages working as normal in popular mobiles and browsers.

In the development of things, design has to complete first for functionality to come in.

For design not to become a bottleneck, I had a style guide and design system in place to move along implementation fast and with quality. But despite all the design guidelines — in every showcase we encountered.

• Pointless inconsistencies in UI elements
• Bad iconography
• Confusing forms and Pop-up
• Irrelevant or low-quality images.

… an inconsistent user experience overall.

Eventually, we figured the mistakes, and what follows are the same things you should know to get your design implementation 100% right the first time.

A design system is only a ticking bomb

PMs, designers rely on design systems and guidelines in place and assume developers to do the right thing. But most design systems are just Pattern Libraries and re-usable components:

A big box of UI Lego pieces that can be assembled in near-infinite ways. All the pieces may be consistent, but that doesn’t mean the assembled results will be. A product is more than just a pile of reusable UI elements. It has structure and meaning. It’s not a generic web page, it’s the embodiment of a system of concepts.

The design system does not advise the developer on where to place the object. Wireframes and Figma files are a ‘good reference’ but not obsolete. Alone dependency on the design system gradually leads to broken pages when the screen ratio changes.

Design deserves a seat on the table

Design as a discipline is maturing, but years behind software development. Our development workflows are airtight with various testing phases to not let a functional discrepancy reach the end customer, but for design, there are fundamental flaws in the process:

• The classic ‘feature works’ — companies settle for the functionality of the feature and do not understand or value design enough to create a process that fosters a good or consistent design outcome.
• ‘Eyes of the beholder’ — People don’t see the difference between design and poorly coded versions of it.
• ‘Don’t have time for it’ when the focus of teams is on fast delivery — visual integrity is easier to cut than coding.
• ‘Poker bet’ — tech debt always precedes design debt.

Product teams work together in a CI/CD mode to deliver as many features in each sprint. In these teams lose sight of the bigger picture and attention to detail, and create a scenario where the integrity of the design implementation falls to the wayside as a “timesaving” measure.

Know your Design debt…

As a product brings in additional features, slips from the actual design happen, certain inconsistencies inevitably edges in. Over time, it all adds up and turns into a ‘design debt’.

Design debt affects the integrity of the user experience. A bunch of incremental changes collects over time — yields a disjointed, inconsistent, and patched-together experience. — Austin Knight.

A large debt leads to a frustrated user who will eventually switch to the next alternative. While it’s difficult to address all the inconsistencies all the time, doing a formal design check is a big step towards combating design debt.

Collaboration is good, but it’s not enough

Designer and developer pairing, co-designing at the conceptual stage, using collaboration tools — Figma or Zeplin to bridge the gap between CSS and design; all these best practices help to limit the design slips, but they don’t take the place of having a designer formally sign-off on coded designs before we ship them.

This is where Design QA comes in!

What is Design QA?

Design Quality Assurance (QA) is an additional step, a pivotal step in the process of development and testing.

Design QA is a chance for the designer to come in

1) Review the coded version of the design before it goes for testing.

2) Closely work with the developer to make updates in UI code.

3) Verify if the design system was paid heed to and empathy design guidelines were followed. Make sure we do not use copyrighted artefacts without licensing.

How Design QA works?

A standard workflow of software development looks like some version of this. Teams operating in sprint move task/ticket from one state of the development cycle to another.

In a workflow like this, it leaves the integrity of the design up to the chances? It is usually up to the developer working on the ticket or product manager to move the ticket to test once completed. It’s up to the bias of the Product Manager or tester to decide for themselves that the design implementation is good.

By making Design QA a deliberate step in the workflow, it can’t be skipped. It also recognizes design implementation as an important part of the process that the team values.

Product design is a skill-dominated subject, a talented designer puts in bits that reduce visual stress and make it easier for the user’s brain to process the UI and complete their task.

These bits are difficult to express in acceptance criteria, hence hardly meet the eyes of the functional tester. Which makes Design QA so critical.

By introducing Design QA in our development workflow we were able to reduce sprint spillovers- as development didn’t have to stop to write fixes for customer-reported design bugs.

In the long haul Design QA alone won’t be enough. In my next article of this series — I am sharing how automation in UI testing helped us reaching ‘Zero-defect’ in UI implementation.