While simultaneously working in software engineering and completing my masters degree in HCDE, I started to notice a few overlaps in both the practice and conceptualization of engineering and design.
Both involve solving the problem of what to build. Both rely on a set of heuristics built by experience in the individual practitioners. Both are concerned with trade-offs.
What to build
Solving the problem of what to build in either discipline is about understanding the gap the solution needs to fill.
In engineering, this is usually framed as requirements gathering. They are typically structural requirements of the embodiment (how many cycles in how much time, how much work done with how much resources), restrictions of performance envelope (an upper limit of acceleration, a lower limit in total capacity), or functional conditions (some response must occur whenever an event occurs).
In design, deciding what to build is based on satisfying the judgement of a person. This could be the design themselves (intuitive design), an end user (user-centered design), or a stakeholder (a mixture).
These appear to be poised opposite each other on a spectrum of hard and soft requirements. But that assumes solving the problem of what to build is simply mechanical. Problem solving is creative and involves synthesizing existing solutions in appropriate combinations as well as introducing novel solutions to the context. Both a designer and an engineer rely on a set of heuristics to build a solution, including the introduction of any sort of formal design process.
It is this aspect that ties engineering and design together. Both require space for ideas to be pieced together and evaluated. In any non-trivial situation, the addition or subtraction of an element affects the performance of the solution in a complex way.
A user experience design is not simply a set of steps to walk through. It must consider the holistic experience of many different types of people. It needs to take into account what is practical.
Similarly, an engineering solution is not simply the set of components involved. It isn’t even the much larger set of combinatorial ways that the components could be arranged. It must consider flexibility to meet future conditions and extensibility. A solution must address maintenance and the skills and abilities of the team who will maintain it.
Learning from each other
Both design and engineering involve sending something out into the world, with all the complexities and messiness that exist there. Both disciplines can benefit from each others’ traditional approaches because of their commonality in purpose. Practicing design with an engineering background brings the strengths of formalism and frameworks. Solving engineering problems with the eye of a designer informs a holistic view of what engineering is and what it can do.
In my career experience, the most successful engineers are those that understand and can articulate the design-inspired, user-centric parts of their solution. I am curious to see if the reciprocal relationship exists in the world of design.