Recently, I was responsible for maintaining a static prototype. At the start we used it a lot and that was fantastic.
Everyone was on the same page. We were making some awesome progress.
But as we got closer and closer to the finish line, the prototype started to fall slowly out of sync from the production site.
The dev team was well versed in their CMS implementation. HTML and CSS not so much. Pretty soon, everything started to fall apart.
On one hand you could blame it on not having a strong understanding of web development basics. But in this case I believe that this team could have made much better progress with a solid set of Design Systems.
If the static prototype was kept in sync they would have always had something to refer back to. A coded styleguide would have allowed them to understand and plunk down generic modules, rather than burn a lot of time building things that had already been built.
Finally, a coding conventions document would have eliminated the need for constant code reviews and pair programming sessions. These often were called for things as simple as using double quotes over single quotes or not closing them. Basic WEB-101 stuff.
Now imagine you end up with a completely new team.
Not an impossible scenario given the volatility of todays world.
If you have developed a core set of documentation, you could bring the new team up to speed very fast and with more consistency. All without meetings upon meetings and group training sessions galore.
Design Systems Engineering allows teams to run smoother, with more consistency, and to largely be technology agnostic. If you need to swap in a new part, new team member(s), or a new module, you’ve got it handled.
