Photo by Headway on Unsplash

Make Design Quality Control a Priority and Make Your Work Better

As designers, we are responsible for defining and championing the visual language and user experience for a given product. Collaboration tools like Invision and Zeplin help to reduce the delta between design and development by finding common ground in cross-disciplinary workflows, but there will always be changes and adjustments to make as a project nears the finish line. Visual Quality Control (vQC) is a crucial step in every project’s lifecycle.

Although vQC is relatively straightforward, there are many factors — both human and external — to consider when forming a strategy with your team. Picking a process that works for everyone is half the battle, so don’t be discouraged at the outset.

To help ease the discussions around your project’s vQC plan, here are some tips and takeaways from the teams at Myplanet to ensure proper fit and finish at the end of a project.

Primary Screens

Sections of a product that represent primary user goals and key features are often referred to as Primary Screens.

The number of unique screens with unique components must be considered when estimating effort. Some pages may be templates, others may include detailed custom elements, but accounting for them all is an important step in creating your vQC plan.

Takeaway

  • Identify and review key screens first. This will make it a lot easier when working through subpages.
A primary screen captures the most important parts of a design system

Number of Components

Just like the number of primary screens, the number of individual unique components can greatly impact the extent of vQC. A Component refers to multiple interface elements that are visually grouped, working together to solve a user goal.

When developers work, they often think in terms of components and reusability. A component focused approach refers to the creation of a system of reusable objects for the purpose of maintaining consistency during deployment. When starting you next project, think in

Takeaways

  • Discuss developing a Component Library with your team; document components and variants/states and keep this updated so the developers have a source of truth.
  • Review global styles & components first — then focus on one-offs
  • Use a component focused approach when documenting notes; group your feedback and reference components whenever possible.
  • Use a shared naming convention when referring to components. This way devs will know where to look.
A Component Library should act as a source of truth for both designers and developers

Responsive Breakpoints

To provide the user with the best layout for consuming content, designers and developers will define dimensions at which the site will respond and reorder/reduce content. Some teams will create mobile-only component variants — we need to check all breakpoints when doing vQC for design and content inconsistencies.

Takeaways

  • Confirm if your engagement is mobile first vs. desktop only
  • Determine the breakpoints that have been accommodated for
  • Look closely for changes to component layout/content at each major breakpoint
Your design changes across platforms and breakpoints

Interaction Patterns & Development Strategy

How a product behaves and responds to user input can’t always be captured with static assets. It is important to note examples where behaviour might not be apparent in the flat designs provided. Affordance considerations such as hover and input transitions can be more difficult to callout without a working prototype.

Takeaways

  • Screenshot or record any interactions and animations. Include reference to these to provide more context
  • Run the build locally — having the product dev environment running on your local machine means you can dig into the interactions, and transitions
  • Confirm the intended interaction of the site with the designer/developer to ensure things behave as intended
  • Confirm that xQC is part of the overall vQC review for your engagement
  • Create a clickable prototype to help the dev team understand the flow and IA of the app. This will save development and vQC time.

Documentation Requirements

Different teams or clients have different expectations for deliverables. If you aren’t able to set expectations at the outset, it’s important to at least confirm the expected workflow and decide as a team the best way to deliver the vQC findings.

Takeaways

  • Provide visual cross references. More visual deliverables work with visual learners, while some clients will always prefer a spreadsheet. Provide both if needed or discuss a strategy with your team
  • Group vQC stories around components.
  • Work with your Project Manager to establish a workflow for approving vQC fixes in browser
Providing both text and visual references will help account for different workflows

Other Considerations

Cross-Browser Requirements

Checking for cross-browser compatibility is becoming increasingly important as developers and designers are forced to contend with an ever-expanding sea of options. The most important aspect of this for a designer is ensuring visual regressions don’t occur as a result of browser incompatibility.

It may be in fashion to apply that texture, or that shadow, but consider the implications once it’s rendered on an outdated browser. While we can’t always control how our work is viewed and on what device, we can ensure our work is considerate of the audience and landscape for which it is designed.

  • Confirm the required browsers and test on as many devices as possible in your given timeframe.
  • Know your audience — design with the end user in mind (that includes both where and how they use your product).

Timeframe

Time should be a retainer for how much effort we place on individual items. In some cases we must limit our scope of review to ensure breadth.

  • Consider limiting your review to primary screens and global elements. These will have the most impact.
  • Define done. Have a shared understanding of the design requirements and user goals.

“The best QC process is one that doesn’t have to happen”.

There will always be vQC requirements on a project. The amount, including details around what kinds of vQC will need to be prioritized, will differ across engagements. As product people we can’t ensure every detail is perfect based on constraints (time, money, people, etc.). What we can do is ensure we take the necessary steps to determine and capture the most valuable feedback so we can maximize the impact of our effort. By thinking clearly about the project needs up front, we’ll be in a better position to perform the required checks throughout the project, ensuring a better end result for all involved.


Have any vQC tips of your own? Share them in the comments below and be sure to 👏 and share the piece if you found it useful!