I recently had the pleasure of reading Brad Frost’s post on the role of the emerging frontend designer. It’s a bridge between two traditionally separate roles: designer and developer. While a designer would create static mockups for the developer to build with real code, the frontend designer designs in code and builds the frontend UI in digestible components for the developer to bring to life.
It’s a role that encompasses what Brad coins as the “front of the frontend.” And it’s perfect for the way today’s web development works.
Long before I heard this term, this concept described many of my responsibilities as product lead at Veritonic. In a small but growing tech team, having the versatility to work beyond the fixed boundaries of design, development, or management is essential. I often find myself bouncing between organizing and planning, designing, and diving into code.
Like the frontend designer role described in Brad’s post, I don’t just build static designs in photoshop. And at the same time, I’m not always coding. Instead, any design work I do focuses primarily on designing in code and for code. This approach produces “consumable” components in HTML/CSS/JS that can be easily adapted to a real application while leaving the functionality to a full stack or frontend developer.
As Brad summarizes, “Frontend design deliverables should look a lot like fully-functioning React Bootstrap-style systems custom tailored for your clients’ needs.”
This method seamlessly plugs into the development process and means the developer no longer needs to interpret or rebuild the design in functional code.
These components (things like navigation bars, headers, modals, sidebars, and cards) are plug and play elements that are part of a design system which makes adding new features using consistent design language effortless.
The next step for us at Veritonic, as we continue to integrate Vue into our platform, is to build out a component library based on this design system that is readily “consumable” in development.
It ideally includes an API for each of these components and is maintained as a separate product alongside our platform. That way, as the number of developers using our component library to build out Veritonic features increases, we’ll have the foundation to scale by importing and implementing designs at any pace.
This echoes my previous post on building systems that scale. Like physical workflows and processes that make interdepartmental collaboration more efficient, designing in code and for code bridges the gap between design and development to ship product more effectively at scale.