
Hear me out, but building we should be planning and building robust systems before we ever touch a design package..
For the last 5 or so years i've been upskilling a lot. Not just because traditional expectations about what it means to be a designer are changing, but because i'm hitting a ceiling. I've been a senior designer for a while, and i've been crying out for my first real taste of leadership.
The problem is.. our leaders aren't going anywhere.. and why would they? A 50-something creative director plans to have their bum in that seat for another 15 years minimum, and i'm aware that'll be me at some stage too.
So, i'm learning the skills that I would otherwise have been gathering so that I can do the things I want to do by myself. This multidisciplinary journey has had a huge impact on how I work as a creative, and if I hadn't been on this journey, I would not have spared a second thought for things like Modularity, Efficiency, Resilience and Security.
I'd still just be throwing pretty ideas at the wall and hoping something sticks. These days, when i'm sat in that initial meeting with a client talking to them about their new site, i'm planning how their checkout is going to work before i've given a single thought to the visuals.
I think that's a good thing, and here's why...
In saying that, I don't mean to diminish the importance of creative. Far from it, at the end of the day, we rely as much on visuals for usability as we do for engineering.
What I am saying however, is that Designers (or at least Designers without the right chops) shouldn't be making functionality decisions. There is precisely 0 use in putting something in front of a client that can't work as good as it looks.
This is something i've learned in my experience as an Indie Game Developer.. At our last Jam, my team and I decided to make an isometric platformer. And to be absolutely fair, it looked good! However, if we'd put more thought into the system before building the game for aesthetics, we'd have realised how bloody hard it is to judge distance from an orthographic projection.
Something that's.. uh.. pretty important when you're a green blob of slime trying to jump a gap.
I don't think I speak just for myself when I say that once you get into the flow, it's easy to get carried away. It starts with a quick visual to stick on a mockup, and next thing you know it's 1am and you've blown the scope out of the water.
It's also very easy, especially when designers and engineers fail to communicate, to create situations where the only way forward for a project is for both 'sides' to compromise on their priorities to get to an outcome nobody is happy with.
Something that I have encountered in my dives into object-oriented programming is the concept of Modularity. In short, the idea here is to reduce repitition as much as humanly possible but following sensible hierarchies of inheritance - Class B extends Class A and inherits its properties, constructors and methods. This is absolutely a trick that Creatives are missing.
The closest analogy I can think of in the design world is the idea of component hierarchies.. you shouldn't have to change a value more than once in order to apply it everywhere it needs to be applied. That doesn't mean absolute rigidity, taking an intentionally modular approach is about planning for flexibility, not rigidity. Planning what can change and what can't, setting ourselves up for both creativity and consistency.
Taking an engineering first approach forces a level of Intentionality and Modularity that Creatives often lack, and enables them to generate design systems and visuals that extend the product instead of breaking it.
Unless you've been living under a rock or in some sort of creative utopia, you'll know how important it is to get to a minimum viable product as quickly as possible.
Taking an engineering first approach forces us to think about what systems are actually critical, and which can wait. These parts are often as important for the user as they are for the engineer, and are often the last places to get the creative attention they require and deserve.
You are always going to need a working, accessible and reponsive checkout flow more than you're going to need that slick 3D product demo, no matter how pretty it has the potential to be. Also, budgets have a habit of running dry when we obsess over the details instead of nailing the must-haves.
That doesn't mean that you can't come back to the nice stuff down the line, but you can go back to it with a realistic leftover budget instead of over servicing a less than functional project. It's easier to sell a phase 2 in to a client who is happy with the basics, and nailing the modular approach means you can bolt that stuff on as profitably as possible further down the roadmap.

To sum up, I think that taking an Engineering-first approach forces us to design with Intent. It keeps us focussed on a goal, and allows us to add value to the parts of a project that most need our attention.
Every designer I know wants to do good work, myself included. But the how is as important as the what. Design with intent and do your best!
lauren@laurenipsum.co.uk
(+44)1234534172