Are we designing or experimenting improvements to socio-technical systems?

Complexity! unsplash-logoBilly Huynh

Over the last few days, I’ve been having some wonderful conversations with my colleagues at the Wits School of Mechanical, Industrial and Aeronautical Engineering about the difference between our Research and Design projects. They’ve led me to the following thought:

Designing complex socio-technical systems may be more “research” than it is “design,” and therefore maybe far more “experimental” in nature than is we typically think. The traditional systems engineering approach promotes understanding the stakeholders, the environment and the problem in significant detail very early on, before even beginning to think of design solutions (INCOSE, 2015).  So, it’s very heavy on upfront “research”[1]. However, in a complex socio-technical system, it’s probably impossible to understand everything that has an impact on the design of the solution upfront, before starting the design process proper. Trying to map all requirement in a CSTS (complex socio-technical system) would probably end up being an infinite and exhausting exercise.

What is to be done then? The answer perhaps lies in the lean start-up approach. This approach employs a “build-measure-learn” mechanism (Ries, 2011), which seems (in my view) to place less emphasis on understanding the stakeholder/environment/problem upfront, and more emphasis on learning from placing a partial solution into the stakeholder’s hands/ environment and testing (measuring) how that works. From the results (learnings) of that test, the solution is improved, and the build-measure-learn approach starts again. There’s less emphasis on a lengthy upfront “requirements analysis process”

The “design thinking” methodology, in vogue over the last few years when it comes to tackling complex socio-technical problems (or wicked problems in design thinking parlance), has a similar emphasis on building prototypes, and iterating through improvements via user feedback. I found an insightful piece on the differences between “systems thinking” and “design thinking” over here (“​Beyond Design Thinking,” 2017) by Amy Ahearn who helped launch’s famous Intro to Human-Centered Design Course.  which I think is highly relevant to the arguments I set out here.

A key point made in that piece is the “systems thinking” is a really useful and powerful methodology, even though it “requires patiently collecting input from stakeholders and time to synthesize how individual factors tie together into larger dynamics.” Similarly, while I’ve highlighted the short-comings of the traditional system engineering approach here, I don’t think it’s entirely without merit. And therefore, I think a hybrid approach is probably best[2].

In practical terms, for the design of complex socio-technical terms, I think this translates into upfront research being necessary, but perhaps a lighter version that does not seek to be entirely comprehensive or extremely structured[3]. This then leads to various “high-level” solutions (or solution architectures, in system engineering parlance) which are then tested (implemented) in the system almost as an experiment, are measured (i.e. researched), and then adjusted based on the knowledge gained.

Measuring the performance of these high-level solutions (or experiments) in the context of complex socio-technical solutions is classical research (at least in my understanding). It is potentially the meat of the “design” process[4], and so perhaps designing (improving) complex socio-technical systems is more “research” than it is “design”. Or put differently, designing complex socio-technical systems is primarily an exercise in conducting a large experiment.

A final thought: while in product design the iterative learning process (build-measure-learn) is conducted via prototypes, in the design of complex systems, the learning process is conducted via “pilot projects.” (my thesis topic!)

I am well aware that this piece is almost entirely devoid of real examples. This is, no doubt, a major shortcoming. I will endeavour to add some examples in time to come, but for now I shall hide under behind the “half-baked” label under which I place these thoughts into the public domain for critique.


[1] As a colleague of mine pointed out, researching to understand a problem for design purposes is not necessarily academic research. After all, merely collecting facts is not research. However, in my view that’s more applicable to product development research. In complex socio-technical systems, upfront research is very much proper research, since one is trying to understand relationships between ideas/ behaviours etc., and not just collating facts.

[2] Hybrid approaches are not new at all. SpaceX  have built an interested hybrid process merging traditional systems engineering and lean start-up approaches. See a presentation here for more (Space Exploration Technologies Corp, 2012).

[3] An example of the structure that might be dropped is the classical system engineering emphasis on how to write requirements (use of the word “shall” for example).

[4] Generating the actual design solutions (architectures) may be less about creative/lateral thinking in the case of complex sociotechnical systems (as it is in the case of product design), but rather merely a synthesis of the known design solutions in the minds of the various stakeholders.


​Beyond Design Thinking: Why Education Entrepreneurs Need to Think in Systems – EdSurge News [WWW Document], 2017. . EdSurge. URL (accessed 1.19.18).

INCOSE, 2015. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. John Wiley & Sons.

Ries, E., 2011. The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. Penguin UK.

Space Exploration Technologies Corp, 2012. SpaceX: System Engineering: A Traditional Discipline in  a Non-traditional organization.


Please enter your comment!
Please enter your name here