A touchy subject
When doing outreach for the games industry, I'm often asked what the difference is between a 'designer' and a 'coder'. My answer depends on who I'm talking to.
To some, what matters is the degree certificate - if you were trained as an engineer, that is what you are, so you should go and do it. Some might say design is more "creative", whereas engineering is more "logical", or "mathsy".
To others, a design precedes engineering - engineering is the act of fulfilling a design, the 'how' to its 'what' and 'why'. In practice, unless you're acting as a "code monkey", the lines are more blurry; a single person can both design and implement a system, and a self-described designer can consider the engineering process while designing just as a self-described engineer can consider the design process while programming. In agile companies, this relationship is necessarily bi-directional.
But what, then, distinguishes the role of design from engineering? After all, they have different career paths, salary bands and job descriptions. I believe the most important distinction is in the nature of problems presented to each discipline, particularly in their objectivity.
Objectivity
A game should run with as high FPS as possible. Everybody wants that. Given that task, engineer A's solution resulting in 120FPS is objectively better than engineer B's solution of 60FPS, if there are no other side effects to consider such as cost or code clarity.
Designers, on the other hand, work in percentiles and target demographics. They must consider the emotions of potential players when designing a system, and consider that what works for one group mightn't work for another. Elden Ring is simultaneously described as obtuse and underwhelming by some, and the best game of all time by others. In this sense, designers have a greater responsibility to consider who they are trying to please, whereas engineers have a greater and riskier responsibility for the quality of execution based on supposed 'facts' - this is sometimes referred to as 'deductive' vs. 'inductive' reasoning.
Generally, designers spend their days considering what adjoining groups problems are worth solving (or, to invert that optimistically, what cohesive opportunities can be taken advantage of to provide a positive experience), and engineers spend their days attempting to find an objectively "best", practical solution for those same things. Engineers carry the burden of upholding a set of objective, culturally sensitive principles that create a significant enough workload to "leave the ideas to designers", e.g. ensuring any given system is secure, observable, and redundant. This split of responsibilities feeds a complementary cycle of refinement whereby together, each "level" of thought (abstractly, "high" and "low") are hopefully covered.
Over time, these modes of thinking are cemented by experience and productivity boons. Engineers learn patterns in software architecture to streamline their implementations, while designers establish paradigms and build systems of documentation to communicate their ideas to both stakeholders and engineers alike. In a career-long effort to work smarter, not harder, so beckons forth the caricatures of asocial senior engineers with long, grizzled beards, and flat-cap clad lead designers constantly opining.
Overlap
There are, of course, exceptions to these rules. Whose responsibility is a poor design executed perfectly? Oftentimes, an engineer will have to consider how an incomplete solution may disproportionately affect some users. For example, there is no current implementation of anti-cheat that can be universally regarded as 'correct' - it's an unsolvable problem for which false positives and negatives upset players. As any elective algorithm could be considered to have been 'designed', the implementation is the realisation of a design that mightn't have needed specifying - is an idea an aspect of design limited to designers?
Given a brief that could originate from anywhere (clients, research, production teams), such as “make a backpack system”, designers and engineers can parallelise their work. One can program a generic backpack system based on items and weights to display using a rudimentary text console, while a designer researches and considers whether the player would prefer items to have realistic weight, which measurement system should be displayed in the front-end, and how the maximum weight should be determined as a factor of other game systems. Both parties influence the scope of the outcome, and specifications are suggestions, unless written by egomaniacs.
The overlap between these terminologies, and the fact that they can't meaningfully exist without each other, is why I and many others prefer to disregard this kind of discussion altogether, and why we have an emerging trend of 'technical designers' and 'technical artists' occupying the space in-between. After all, plumbers don't conform to a binary "pipe schematic designer", or "wrench wielder" - plumbers are plumbers, as on the front page of this website, I'm a "game developer".
