- **Epistemic status:** #seedlings For teams to build successful [[Design Language System]] front-end development needs to be treated as a core part of the design process. Creating a division between designers and developers when the core of building user interfaces is [[HTML (HyperText Markup Language)]], [[Cascading Style Sheets (CSS)]], and [[JavaScript]] is a terrible idea. Showing [[Stakeholders]] only static pictures of websites sets the wrong expectations, since they can only comment on what they are seeing. Getting these designs as fast as possible on a browser, [[Stakeholders]] are shown the reality of the final medium much sooner in the process. This also reduces the times when designs are unrealistic or difficult to be achieved in code, making the designer go back to the drawing board. There are other key aspects that can be measured when designs are done on the browser: - flexibility - impact of the network - interaction - motion - ergonomics - color and text rendering - pixel density - scrolling performance - device and browser quirks - user preferences That being said, design doesn't have to be entirely on the browser. Having the design done in the browser in addition to other design artifacts gives teams the ability to see a more realistic picture of the user interface they are crafting. Front end developers even when not having a clear direction on what the user interface can look like can be doing code day 1 by doing prep work. The prep work can be the following: - Setting the compiler - Creating crude components like headers, footers, search bars with barely any styling - CI/CD pipelines - Logical aspects like how to log in and register a user - Theme systems - Setting up a testing environment - etc By allowing the front end developers to do this prep work, they will have more time available to collaborate with the designers, helping validate UX decisions and working on prototypes. --- ## References - “Atomic Design by Brad Frost.” Accessed Jun 15, 2022. <http://atomicdesign.bradfrost.com/>.