Frontend Architecture for Design Systems

Part III. The Process Pillar

The process pillar was created in order to define the steps required to get code from the developer’s brain to the user’s browser. It encompasses each permutation the code goes through, from qualified idea to validated design to accepted commit to deployed code.

If you’ve been doing development for long enough, you’ll probably notice that our processes have evolved immensely in the past several years. My first experience in web development involved being asked to digest two months’ worth of email correspondence, determine what the client was asking for, and then FTP into their server and make the necessary changes.

This, in hindsight, was a horrible way to perform updates to a website. What would have happened if I misread the email and changed the wrong thing? What if I had accidentally deleted a large chunk of CSS, inadvertently breaking other pages on the site? What would have happened if I fixed a JavaScript bug, but it introduced two other bugs? Now, by itself, these problems would be annoying, and a prime example of why you never use FTP to edit the live site! But what happens if you aren’t backing up often enough, and you are left with a broken website to fix, and you still have a list of tasks to complete?

Fortunately, for most of us, we’ve learned from these mistakes and are following much better practices these days. Instead of FTPing changes sent in an email, we now:

1. Use issue tracking and user stories to properly track workflows and mark ...