A good product is a lot about the problem that you pick & the ideas that you implement. But a well-sorted & deliberate design-development process can play more than a handy role; ironing out quite a few wrinkles that can cause unnecessary escalations and ad-hoc duct-taping later during the execution phase.
As designers, we are the guardians of execution and thus equally responsible for the air bubbles that might exist in the finished product. Thus before every release, it’s imperative for the designer to sign off the build. But it’s not always that Design Quality Check is given it’s due place in the process, and most product releases burdened by tight timelines end up bypassing this or at the most subset it under exercises like Dogfooding. The problem with bypassing Design Quality Check is that it looks like an easier trade-off to make instead of squeezing in those precious few hours before the release — More than the immediate quality loss what’s even more harmful is the legacy it carries onto the upcoming releases & sometimes it almost lingers throughout the lifecycle of the product, either as a function of team’s mindset or the actual workflow.
Having underscored the importance of a design quality check, there’s a responsibility that designers have too, which could lighten the burden of quality check & bug bashing later on, which is —
How were the designs shared?
For the most part, it really does depend on how comprehensively were the designs published by the designer to the stakeholders. Designers, more often than not, want to see themselves as Thinkers but not so much as Executionists. It helps to learn a thing or two looking at the way Developers operate. The Version Control rigour, Namespacing of the files/modules, Documenting iterations or Commit messages or Patch notes etc. It would only help us designers get more productive & useful at our job.