A missing step in the development process

Delivering good, bug-free software is something every product team strives for. And I think it’s pretty safe to say that doing a code review before shipping can go a long way to help achieve that goal.

Code reviews are by no means a new concepts - the idea of a formalized code inspection was introduced by Fagan in 1976. But that process was too cumbersome, time consuming, and synchronous, which prevented it from being widely adopted.

It wasn’t until tools like Github became available and code reviews were incorporated as part of the pull request that it became relatively easy to adopt them as part of the process. These modern day code reviews are more lightweight and asynchronous than the code inspections proposed by Fagan, making them much less time intensive.

But code reviews focus on functional bugs, which are only half the story. Visual bugs - when things don’t match the design - can be just as big of a problem.

Sometimes visual bugs will show up because the person building it felt it was “close enough”, but most often they’re just things that slip through the cracks. It’s fairly easy to miss the fact that there’s slightly more white space between elements or that the font size is a bit smaller than it’s supposed to be.

And even if everything is built according to spec, there's rarely designs for more than 2-3 screen sizes. Anything in between usually ends up being something the developer has to make a decision on and try to get it to match the designs as closely as possible.

The problem is that design decisions are rarely random. Every choice on colour, spacing, font size, or layout is made with a specific purpose in mind, whether that’s to drive an action, elicit an emotion, or to be in line with the brand. Leaving visual bugs unaddressed can cause a myriad of problems and that’s why having designers involved throughout the process is extremely important - our CTO even wrote a whole blog on this.

Now, having designers take a look at the finished product before shipping is not a new concept either. People do this all the time, and with good reason. If a visual bug is caught before the new code is shipped, it’s much easier to fix. The developer is already in the context of fixing bugs on that particular page or feature, and there’s usually time set aside to do so.

If a visual bug is caught after something is shipped on the other hand, the experience might not be as pleasant - it’s not fun for anyone when there’s a bug in production.

A developer may feel frustrated that they have to redo something that was already done and approved. That sentiment is understandable, especially if they’ve already moved onto other tasks and there’s time pressure to finish those.

At the same time, a designer might feel bad for bringing something up, especially if it’s seems like a minor difference to others. And if the issue is minor enough, they may just leave it as is, in order to avoid taking time away from other tasks. However, that can lead to design debt over time, which can take even longer to fix down the road.

So, if having designers review visual changes before shipping is much better, why doesn’t everyone do it all the time?

The problem is that, in most teams, it’s not a codified part of their process. Prior to incorporating code reviews in pull requests, they could often be skipped if there was time pressure. Everyone knew that they were good and should be done, but when push comes to shove, they could easily be skipped.

Making it a formal part of the process meant you couldn’t ship something without a code review, and as a result sufficient time was set aside in the project’s timeline to get it done.

The same way code reviews became a standard part of the process, I believe having designers review visual changes should be a part of the process for any team that cares about good design.

If you budget time for this step, which for a lack of a better term I’ll call a design review, then it can be done consistently and reduce design debt in the long term.

The ideal way to do this, in my mind, would be to add it to the pull request the same way code reviews and automated tests are currently done. This way, you can have a developer initiate it once they’re ready to have the visual aspect of what they’ve built checked, and the pull request can’t be merged until a designer gives the go ahead.

Obviously, this would be done only for changes that have a visual component. However, this presents a bit of a challenge. Reviewing code is environment agnostic - you can view it on any machine without having to setup a dev environment. Visual changes, on the other hand, can be more problematic.

If you have a staging server set up or you can deploy behind a feature flag, it’s not too big of an issue. The developer can push the new version and the designer can review the changes and give feedback. With tools like Pastel, this process can become even easier.

But, if there is no staging server and the only way to view the new changes is on the developer’s machine or by pushing it to production, you run into a problem. Having a design review becomes more cumbersome, time consuming, and synchronous - the same way code reviews were before Github and tools like it became common.

This means that for design reviews to become a standard part of the process for the majority of teams, either they’ll need to set up some sort of staging environment, or, new tools will need to be built to facilitate design reviews. In either case, I think it’s worth it.

What are your thoughts? Do you do design reviews? Are there perhaps tools that already facilitate this? I’d love to continue the conversation in comments.