Have you ever handed off designs to development only to see the demo a few weeks later look a bit off?

I’ve personally noticed subtle differences between my designs and the actual implementation. Perhaps text is spelled in Capital Case instead of Sentence case, or the spacing between certain elements is off.

I have to take note of the differences and work with the developers to fix the errors or improve the implementation. No big deal, right?

However, the feature has already been demoed to the team where other members, including my team lead and director, might have noticed these details as well.

I hate it when this happens.

But this has taught me an important lesson to always conduct design quality assurance (QA) after I handoff my designs.

Think about it

Developers debug their code to ensure it runs properly.

Designers conduct design critiques to ensure their designs make sense and align with design systems.

Writers edit and proofread their copy before publishing to correct grammar and spelling mistakes.

But what is the activity for ensuring that developed features match the intended designs?

Introducing design QA: Desk checks

Desk checks are an informal manual activity for software developers to review each others’ code to spot defects and verify algorithm logic before shipping.

In agile, continuous feedback plays a big role in helping teams streamline work and respond to change. With desk checks, teams are able to capture UX and interaction errors, as well as fix implementation details.

The term “desk check” comes from getting up and walking over to another person’s desk (back when people actually worked in offices).

Nowadays, it’s as simple as getting on a Zoom call with your teammates and walking through the developed feature. It doesn’t have to be a formal meeting. The point is to align design and development to fix mistakes and avoid miscommunication during handoff.

Designer and Developer checklists

Here are some of the things I’ve discussed with developers during a desk check.

Designer concerns

• Does the feature work as expected? Is it easy to use?
• Is it pixel-perfect according to the designs? Ie. Does the feature have correct spacing, alignment, colours, headings, etc.
• Is copy formatted correctly?
• Are the proper design system components being used?
• Are accessibility features implemented properly?
• Does the user flow still make sense?

Developer concerns

• Has the acceptance criteria been satisfied?
• Does the functionality work as intended?
• Does the program pass all tests, including edge cases and validation?
• Do the designs lack proper documentation around interaction details or accessibility?
• Is it feasible to implement the designs in time? If not, can the designs be modified or scaled back to be able to deliver a more incremental feature on time?
• Is there a technical limitation that would prevent the designs from being implemented as designed? Ie. Lack of technical knowledge

Prioritize and iterate

After conducting the desk check, summarize your next steps, which include creating tickets and prioritizing the feedback to iterate on the feature. Continue the review cycle of desk checking with your developers until the feature is ready to be released.

Benefits of desk checks

The team I work on has adopted desk checks to include designers, which I have found to be extremely helpful. I encourage developers to have desk checks with me to ask questions about the design, compare the designs with the implementation, and discuss technical limitations or feasibility concerns.

Design quality

Desk checks remind me, a designer, to document my work properly, so that there is less ambiguity around the interactions and UX of the design flows.

It also encourages me to explore different design decisions, so that I feel confident handing off the best designs. Going back and changing designs is never a fun thing to do.

Efficiency

In the long run, desk checks save time by catching defects early on while features are still under development, rather than having to do rework that carries over to the next sprint.

It allows designers and developers to focus on the next priority without worrying about fixing something they worked on in a previous sprint.

Continuous learning

Each time I desk check with my developers, I learn about the technical blockers that they commonly face when developing our product. I keep these limitations in mind when designing other features to avoid facing the same issues again.

Desk checks aren’t foolproof

Just because designs are implemented to spec doesn’t mean that there isn’t room for improvement.

Include your developers early in the design process

To avoid major blockers, it’s best to include your developers early on in the design process to talk about the technical side of things.

Brainstorm with your developers to get a better idea of what’s feasible and what will take longer to develop. This way, there are less surprises later on when the deadline is about to hit.

Incorporate desk checks into your sprint

By getting into the habit of desk checking with your developers throughout your sprints, it builds accountability among teammates and ensures quality output is delivered each time. This leads to stronger collaboration and a better overall product experience for your users.