On Design Engineering: The designer & developer relationship

In 2012, I interviewed for the role of “Junior Web Developer / Designer” at a small agency. I distinctly remember the moment where I took a deep breath and said: “Just one thing to mention… I’m not a designer, I’m a developer”, fully expecting that to be the end of the engagement. Thankfully it wasn’t, and I was fortunate enough to assume my first position in this fine industry of web: “Junior Web Developer”.

In those early days, I recall observing the relationship between our designer and the freelance developers we used. There was an invisible trust between the two roles: the designer knew their creation would be realised accurately, and the developer knew they’d be given all they’d need to achieve the design. They were in harmony.

But in time, I found my own groove with our designer and we designed and built many sites together. We developed our own shared understanding and common language between us, through the formative process of client work. By understanding his design intention, and him understanding my development capabilities, we could build with serious efficiency and accuracy.

Interestingly, this was also the time when I realised I was designing after all. When there’s fluidity and understanding between design and development, design also happens at the development stage.

As soon as his design ideas were in the browser, we’d be iterating together and feeding back into the original design file. Live tweaks in dev tools and early prototypes to prove concepts were my medium for design. It wasn’t photoshop fireworks sketch Figma, but it was still design.

Reset

Every new job after this has felt like a ‘relationship reset’. It takes time to understand how each other work, the nuances we put into our craft, and the best way to critique each others creations.

You can learn a lot about a designer by looking at their design files. I take time to pore over their Figma files and learned about how they ‘organise' their designs, how they use grids to lay out new work, and how they iterate ideas rapidly.

Large organisations and design systems

I’ve never had the opportunity to work in an organisation larger that 25 people, but I can imagine how difficult it is to scale this type of relationship. It’s no-doubt why bureaucracy and process has to exist when a company grows beyond the size of a family.

I could wager a fair amount this is why design systems came about. A design system tries to capture the “shared understanding” and “common language” of a good relationship, and fills it out with documentation, examples and rules. It’s not as personal as a respectful, human relationship, but it’s something.

It’s also one of the driving factors behind the design foundations we’ve started using on projects. But rather than replacing that relationship, they’re created collaboratively between the two disciplines, working as an accelerator to help new designers and developers speak the same language.