JavaScript frameworks are the main culprit, with more and more business logic being moved from the back end to the front. Once covered by HTML, CSS and JS, the front end is now flooded with build chains, tooling, type-safe languages, integrations, state management and CSS modularisations. In a sentence: the front end is complicated.
Laying aside fundamental views on whether this is the right direction for the web or not, this degree of complexity isn't an issue in an of itself. In the same way back-end systems tend to have layers of redundancy and more thorough testing processes, If the front end is now doing more work, it stands to reason that it also needs more 'process' to prevent it from falling over when things go wrong.
However, as the roles of the front-end developer have stretched into the realms of 'engineering', it has created a split:
- Front-of-the-front-end: UI focused
- Back-of-the-front-end (referred to as 'Engineering' from now): Integration focused
(Terms coined by Brad Frost)
Again, this isn't a bad thing. It gives folks the choice to specialise in what they're good at. It can, however, become a problem when:
- Either party are forced to build in each others domain specialism
- It is assumed that the front-of-the-frontend can be bypassed
The latter issue is the one I'm going to focus on. It's becoming increasingly more common for organisations to jump straight from “design” to “engineering”, missing out the front-of-the-front-end altogether. After all, if the engineer codes, and the phase after design is code, so why not let the engineers build the UI?
Well, by jumping straight between the colossal gulf spanning the two functions, a huge wealth of design intention can disappear out of sight. The nuance of a design is built from layers of knowledge passed from Research to UX to Content to Design. The tiny details and systemised thinking that go into design all add up to a make great interface, and scalable front-end codebase.
The language that converts from a 'picture of a design' to a website is CSS. CSS is seen as such a contentious language because it's where design and engineering meet.
There needs to be a way to bridge the gap...
Design engineering
This is a quote taken from the excellent design engineering handbook, published by Invision:
Design engineering is the name for the discipline that finesses the overlap between design and engineering to speed delivery and idea validation. From prototyping to production-ready code, this function fast-tracks design decisions, mitigates risk, and establishes UI code quality. The design engineer’s work encapsulates the systems, workflows, and technology that empower designers and engineers to collaborate most effectively to optimise product development and innovation. Natalya Shelburne
In a team where there is friction between design and engineering, or even design, front-of-the-frontend, and back-of-the-front-end, a design engineer's job is to smooth the translation process between the disciplines.
A design engineer may be involved in:
- Idea validation
- Rapid prototyping
- Production code
- Ensuring UI code quality
- Creating useful tools
- Encapsulating systems
- Setting up project groundwork
- Empowering effective collaboration
In essence, a design engineer's primary aim is to be helpful. Helping UX come to sound decisions, helping research get the most useful insights from their testing, helping designers generate sound & deliverable ideas, and helping engineers understand the design intention. But the primary focus is on doing anything they can to help translate the design for the engineering team.
We talk of ‘creators’ and ‘maintainers’: those who do the work, and those who keep it running well. But I think it's a spectrum. Design engineers sit firmly in the most ‘creationy’ part of the creator camp, building rapidly, failing early and clearing a way through the bad ideas so the other creators can follow smoothly.
What does this mean at Clearleft?
As an agency, every project we undertake is different, so we know this function as a formal role may not be appropriate for all projects. However, the mindset of translating effectively between 'who designs it' to 'who builds it' is.
Although we've been practicing this way of working for a while; building with prototypes, collaboratively creating out design foundations, and helping clients build design systems, we've not formally dubbed it 'Design Engineering' till now.
We're going to continue to utilise this role on future projects, monitoring to see how it improves the overall design process.
This post was originally published on Trys’s website - you can find his next post on Design Engineering foundations here and all the articles from Trys’s incredible series here.
