This is the sixteenth article in a series about the Design Process.
This is the sixteenth article in a series about the Design Process.
As the build phase winds down, the team shifts into review mode. This is the time to carefully go through the developed work and confirm that everything has been done as intended. It might sound simple, but it’s one of the most critical steps in the entire process.
Designers often have an eye for detail that not every developer shares. That’s not a slight; it’s just a difference in focus. This review is less about assigning blame and more about double-checking that what’s been built actually aligns with the original vision.
By now, testing should be familiar territory for the team. Ideally, everyone has been testing in smaller increments throughout development. This final sweep, though, is a broader and more formal check. It’s not enough to glance at the site in Chrome and call it good. The team needs to see how the site behaves across a variety of browsers, devices, and platforms. It’s important to actively try to break the experience, because if something can go wrong, it’s better that you find it before your users do.
Sometimes, despite all the documentation and conversations, the development can drift off course. Maybe something was missed. Maybe there was miscommunication. Or maybe the developer thought they were improving on the design by doing something differently. Whatever the cause, these are the moments where communication becomes even more important.
If you notice something off, bring it up. Calmly. Don’t assume bad intent. There could be a perfectly valid reason behind the change. It’s possible that a decision was made by the project owner and not shared with the entire team. Or maybe a developer ran into a technical challenge and had to adjust on the fly. It might even be that someone misunderstood the specs and did their best with the information they had.
When things still feel unresolved after that initial conversation, it’s time to bring in the project owner. They’re responsible for making the final call and ensuring that what goes live is a faithful execution of what was agreed upon.
Potential Pitfalls
If you skip this kind of final review, you’re gambling with the quality of the product. Bugs go unnoticed. Details slip through the cracks. And the final result might feel rushed or broken, especially to the people who poured themselves into the design from the very beginning. It’s frustrating when the visual integrity of the design is compromised, and understandably so.
That said, it’s important for the entire team to approach this phase with empathy. Before assuming that something was done wrong, ask what happened. Seek understanding. A broken outcome doesn’t always mean someone made a bad decision. It just means a conversation needs to happen… ideally before your users are the ones to notice the gap.
This is step 16 of 17 from the Design Process Playbook
Next: Small Misses, Big Mistakes: The Designer’s Pre-Launch Review
Comments ()