Designers should own the front-of-the-frontend
Ever since JavaScript frameworks became the go-to method to build complex web applications, the term “front-end development” has expanded to cover a skillset so diverse that can hardly be grouped into one category.
In a React-based tech stack, these include:
- Defining pages and components
- Building component UIs with JSX and CSS
- Defining and implementing responsive behavior
- Writing event handlers for user interaction
- Managing state within and across components
- Writing client-side business logic for functionality
Categorizing front-end development
These tasks require vastly different skills, and they should be categorized better to reflect the differences between them. I’m a big fan of Brad Frost’s article on the distinction between the front-of-the-frontend and the back-of-the-frontend.
“A front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked”
This breakdown separates the UI of a component from the functionality that enables it to actually be used.
Design
Function: Determine what a feature looks like and how a user should interact with it
Tools: Figma
From the ideation stage, product designers work with product managers to define feature specifications based on user needs. Through increasingly high-fidelity designs in continuous collaboration with product and engineering, designers ultimately hand off to engineering to implement their designs.
Front-of-the-frontend
Function: Implement the UI that designers have defined.
Tools: HTML (or JSX), CSS, basic JavaScript
An engineer receives a Figma file from a designer and writes the JSX that will render components exactly how the designer has designed them.
Back-of-the-frontend
Function: Build the functionality that enables a user to use the application
Tools: React, JavaScript/TypeScript
An engineer writes the logic that enables this feature to actually used by a user: managing state, integrating with data sources, and optimizing performance.
Where do designers fit in?
When broken down like this, the differences between these functions becomes immediately apparent. Design requires the ability to communicate with users, understand user behavior, and create visually appealing flows that make the product intuitive for the user. Back-of-the-frontend work is pure engineering work to power the application logic that happens to be done on the client-side.
But what about the front-of-the-frontend? A large part of this work is translating a designer’s vision into the language of production: code. Anyone learning web development starts with learning these basic skills—there is no shortage of freelancers on platforms like Upwork proficient in these skills.
As designers on product team expand their skill set, they can take on responsibility for most of the decisions made in the front-of-the-frontend — componentization and responsiveness to name a few. Recent Figma features like variants, autolayout, and component properties have made this transition much faster.
Designers who do understand the front-of-the-frontend (often called design engineers) are always in huge demand, as they can cut out a huge source of miscommunication on a team between developers and designers.
So what stops designers at all companies from taking over the front-of-the-frontend? They aren’t familiar with the world of development.
We noticed that designers creating high-fidelity, responsive designs using components, variants, and component properties are already handling the logic of front-of-the-frontend development. So we built Vivid to translate the logic they’ve built in Figma into logic built in React.
Why did we build Vivid?
Vivid goes beyond the promise of “Figma to code”. Vivid allows designers to truly define the front-of-their-frontend in Figma, bringing them closer to production.
We noticed that the biggest problem with existing tools in this space is that they don’t abide by the workflow product teams are used to, so engineering leaders hesitate to trust them. We built Vivid to follow practices we use ourselves — generating modular components, automatically integrating with the GitHub review process, and enabling the use of components already present in the codebase. With Vivid, designers can hand off consumable components in code to engineering, so developers can focus on functionality within the back-of-the-frontend.
For design leaders, Vivid provides a strong motivation to follow state-of-the-art design standards. If Figma is defining your frontend, design conventions like semantic naming and component modularity aren’t just for readability within Figma — they’re necessary to create a maintainable frontend. Vivid also guarantees that your UI in code will match your designs as closely as possible.
If you’re a designer, front-end engineer, or product leader interested in empowering designers to own the UI of your product from start-to-finish, we’d love to chat with you! Vivid is currently accepting pilot customers for early access to the product — just fill out this form. You’ll get to shape the direction of the product along with first access!
