The VQA process is slow

Before the world of Zeplin and Figma, you had redline docs, which were images produced by a designer, and what you’d use to translate the design into something tangible. It had mockups, specs, heights, widths, text sizes, and everything in-between. This is a slow process with lots of back and forth, and the final result was something that roughly looked like what you want. But, what if the redline doc was missing dimensions? What if it just had wrong information? That meant waiting for an update from design #5pmOnFriday.

Today we have powerful tools like Zeplin to help with the redline process. These tools use the dimensions of the labels & images in the source document (Sketch or Photoshop file). This allows you to measure anything in the design, leaving any redline doc in the dust. Zeplin is still dependent on the designer to upload new versions, but it does a good job at removing the risk of having incorrect specs when it’s time to implement.

And then we have Figma. Figma is a very powerful tool, essentially combining Photoshop / Sketch & Zeplin into one product. The source file (the design) is the same file that developer uses to spec out measurements. If there are changes, they are immediately shown. There is one single source of truth, so no need to hand off files and lose track of the most recent one. The comment feature and file history lets you see what’s changed and why. The only thing you need to pass between a designer and developer is a URL.

Whichever design tool we choose, we still need to polish ( 🇵🇱 ಠ‿ಠ). Why? The UI-components measured in PS / Sketch / Figma may not measure to the exact height & width on Android, making this the most tedious step. We have to place what’s shown on screen next to our design and use rulers to make sure our components align.

In this step, we need to make sure the design size matches the devices’s size. You’re ready to go if you have a design that is the same resolution and size of the device. You will need to compensate if this is not the case. If the design is on a 360 x 640 artboard (MDPI), the device must also match that spec so that the width is 360dp and the height is 640dp. Example: Nexus 5 and Nexus 5x both have screen resolutions of 1080 x 1920. Both lie in the same density bucket (XXHDPI). However, the physical screen size on the Nexus 5x is 2" larger. This brings the width of the Nexus 5x, in dips, to 411 - not the 360 that we’d expect like that on the Nexus 5.

This is the most common issue at this step. It trips me up when I forget which Emulator I’m running. Luckily, you can create an emulator with a custom screen size to avoid this. A guide like material.io gives important screen spec information.

Now that we have a device that matches our design’s size and resolution, we can scale the design to match the screenshot resolution and compare. We go through the process of dragging a ruler onto screen, and measuring image bounds and text baselines. We screenshot, compare, adjust, build, wait, and repeat.

This is where Window comes into the picture (kind of a pun?). Window reduces the time it takes to VQA because it confirms the placement of UI elements via grids, rulers, and measurements on the device. Developer time is expensive, so the goal is to reduce the frequency of generating builds.

You can download Window from the Google Play Store for free! This project was built with lots of open source software, so my hopes are to open source the project soon too!