The ambition of combining systems engineering and design thinking
Arnaud Durantin, Gauthier Fanmuy, Ségolène Miet, Valérie Pegon
1. Introduction and scope
1.1 Why this paper
The goal of this paper is to report on a dialogue and experimentations between design thinkers and systems engineers, to improve both practices through each other’s approaches. This journey started almost three years ago through personal contact and curiosity towards each other. We soon came to the conclusion that we had similar perspectives on some aspects. The key revelation about the importance of this topic happened during an industrial project. The Design Studio works closely with companies from different industries, helping them to transform their innovation process through methodologies borrowed from design thinking. By doing so, we explore and test approaches that include methods, tools, and demonstrators. During this project, we understood the current situation and the needs we will explain in this article.
Our focus will be on the early stages of innovation, also called “operational phase”, when companies identify the opportunities they may want to pursue and define their product and / or service propositions. We will not develop the following phases of design development. We will also address complex systems containing products and services. This heterogeneity is more and more common and very difficult to manage – hence the need for new approaches.
1.3 Design Thinking
What is Design Thinking
Design thinking is an approach that encompasses project organisation, posture, methodologies and tools, used by companies to create new products and services. The growing complexity of businesses and their systems requires a flexible way to explore desirability (what people want and value), feasibility (what is technically possible) and viability (how it could be a successful business).   To do so, design thinking stands out through user empathy, collaboration and iteration (using prototypes).
The design thinking methodology
While the ambitions of design thinking are often overemphasised, its results are as good as the people practicing it and the context it lives in.  It is by no means a magic recipe, where a process can be applied to reach amazing results.
One of its key strengths is to enable space and time to question the brief. This is the first phase, Understanding, where digging deep behind the challenge is essential to success. To do so, design thinkers need to explore the relevant topics with a wide lens, covering social, technology, business and identity. Several methods are combined: desk research, trend research (critical for longer term innovation), qualitative user research (necessary for short term innovation) and expert interviews. They are completed by a creative, collaborative and diverging phase to imagine opportunities.
The result is a clear brief, objectives and success criteria that will drive the next phases.
It is then time to define a strategy; i.e. how to tackle a specific opportunity. In this phase, Definition, collaboration is key to lead to propositions desirable, viable and feasible. At our Design Studio, we use creative one to two-day sessions mixing a diversity of profiles, from within the company and outside. The challenge is to move from knowledge to new ideas. This requires a creative process that cannot be controlled but can be facilitated with inspiration, rhythm, state of mind and a methodology to move on step by step towards concrete scenarios of projected futures.
The next phase, Conception, is getting closer to the industrial design process, where teams work on more focused user research, creative sessions with many design proposals (a second phase of divergence), early mock-ups, tests and yet more iteration.
For a robust design thinking approach, this phase must also be done in a collaborative way, ensuring coherence between the different elements of the puzzle.
Development, production & promotion
The last phases, Development, Production and Promotion, are continuing on the same approach: collaboration and iteration. Because they are not the focus of this paper, we will not develop them. The design thinking alternates divergence and convergence.
Design thinking representations
The raison d’être of design thinking is innovation, to propose new products and services that can bring value to the market. Design thinking can serve both disruptive innovation – by focusing on foresight and longer-term vision – and incremental innovation – by focusing on current usage and context. To communicate ideas for future user experiences, the Design Studio uses storytelling tools such as user journeys, scenarios, storyboards, movies and demonstrators. These tools describe elements of a system from users perspectives,.
1.4 Systems engineering
What is systems engineering
Systems engineering is an interdisciplinary collaborative approach meant to enable the realisation of successful systems by considering its complete lifecycle. It is based on the concept of “a system”: “an interacting combination of elements to accomplish a defined objective” . In order to manage complexity, it organises project datasets into several levels of abstraction from a general overview of the problem to solve, to the most concrete and detailed description of the system.
Systems engineering methodology
There are various methodologies used in industry, such as :
• IBM Harmony for systems engineering
• INCOSE Object-Oriented systems engineering Method (OOSEM)
• Vitech Model-Based System Engineering Methodology
• JPL State Analysis (SA)
• Cofluent methodology
• CESAMES Matrix methodology
Dassault Systèmes has developed its own methodology – Modelling Methodology for Systems – based on state-of-the-art systems engineering practices, to address all disciplines involved in engineering a system. The table below summarises its structure, and is followed by its principles.
Separation of the outside (black box) and the inside (white box) of a system.
• Management of layers of abstraction, integrating life cycles and business objects.
• At each layer, a set of views for different perspectives, ensuring a consistent and complete definition with states and modes, architectures and contexts (static), scenarios (dynamic), physical environments (topology) and requirements.
A language to support the methodology
When modelling systems, it is necessary to use a language that enables all the people involved to understand each other. Several languages exist, depending on what is expected at any given step and for certain areas of the system.
• Semantic languages (e.g. English): the main type of language used to describe a system in documents such as specifications or design descriptions.
• Modelica: used to create and simulate multi-physics models
• UML (Unified Modelling Language): describes a software behaviour with a set of diagrams, and SysML (SYStem Modelling Language): derived from UML
and adapted to systems
• FFBD (Enhanced Function Flow Block Diagram): a systems engineering model representing the system’s behaviour.
• IDEF (Integration DEFinition): family of modeling languages in systems and software engineering, that covers a wide range of uses, including functional
modeling, simulation, object-oriented design and knowledge acquisition.
Natural languages are widely used for communication but, because of its variety, they often lead to misunderstandings. In Model Based Systems Engineering (MBSE), the goal was to create a language that can be understood in only one way: SysML .
Regarding the use of SysML language on complex system projects, we can say that there are two practices: strict use of SysML or derivation of a language based on SysML adapted to the industrial methodology (example: Thales with the Arcadia methodology). Nowadays, these representations start being used to describe systems in the industry. Here are a few examples of representations in different languages:
• System overview: models the system’s context and perimeter, with relevant stakeholders, effective interactions and interfaces with the system.
• Sequence diagrams: a set of models showing the sequence of actions between stakeholders and system.
• Functional chain: for a service, the functional chain describes the interactions between internal functions
These diagrams provide a complete description of the system. However, many project stakeholders see them as a language specific to systems and electronic architects, difficult to read and understand. We believe this point is nowadays a limit to the development of MBSE in the industry. On the chart below, you can see that these kinds of representations cover less than 25% of project’s stakeholders in industrial engineering projects. It is clear that these representations are far from covering the real needs. They enable experts to design the system but the result of the design is not understandable to the majority.
Insights from our comparison
Diversity of people
As mentioned in the introduction, complex systems made of products and services are getting more common. Our industrial experience has shown us that currently, around 40 disciplines are involved in complex systems designs, such as a car, a rocket or an airplane. Also, many industrial companies offer services rather than just selling products. For example, the business of Rolls Royce is to sell flight hours, not jet engines. This means new disciplines must be brought to the innovation process, to conceive products and services together, as a coherent whole, as a system of systems. However, these disciplines are not all from the engineering family. In addition, the increased complexity and heterogeneity in companies’ offers also make it harder to make decisions. For example, board members may have a robust experience in a few areas, but they can’t be experts in all disciplines involved in complex projects. They need a clear overview and means to explore the systems their teams are working on, without the burden of deciphering an unfamiliar language and without a broken view where the whole is not legible. The same applies to other wide scope roles such as project managers, product managers, service designers, marketers, buyers, etc. Also, in the last two decades, we have seen user centred approaches develop, involving disciplines beyond traditional engineering, marketing and design mix. Social scientists, experience designers and even end users are integrated in the innovation effort. Finally, companies need to work together, in ecosystems to imagine, conceive and develop future systems that go beyond their expertise. This multiplies diversity by adding a corporate culture layer; hence a divergence of language, approach and motivation. Linking all these perspectives is a major challenge and calls for a change of paradigm in design, opening an era of “architecture”, as defined in the Oxford Dictionary of English: “the complex or carefully designed structure of something.”
Most industries are seeing deep disruptions as the digitalisation of business is going forward. Many old truths are replaced by new ones. The taxis’ stronghold is threatened by Uber whose model will probably be disrupted again by new offers made possible by technologies such as autonomous cars and block chain. These radical and deep changes make it very hard for established companies to adapt. They have invested years and millions in specific sets of competences, technologies and other assets. Yet, these can become irrelevant. One option is to wait and see, the other is to rebuild. Walmart has chosen this second route, as it plans to close 269 stores in 2016 and open 405 new ones to adapt their offer to the new context. In this kind of dynamic context, questioning a company’s offer has become a priority. Many companies are turning to design thinking, among other approaches, to define a vision on their potential future and imagine new systems.
Interaction with computers
As described above, the current modelling languages for engineering systems are not universal and are understood by a small minority only. In addition, they haven’t been optimised for human legibility, but for computer readability. For example, texts are often small, there is no visual hierarchy and content is in black on white. In the last ten years, trends in user interface and data visualisation have given us innovative alternatives with visual representations and interactivity. Our personal interfaces have become visually easier to read and have influenced most professionals who are starting to expect this level at work too. Designers and platforms such as Gephi have explored visually clear and appealing ways to represent complex data.
However, many professional tools haven’t harnessed these new possibilities. Users still need to adapt to them. For example, sequence diagrams (SysML) are describing events in a way that is easy to read by computers, but totally unappealing and difficult to read, at a cognitive level, for fellow humans. It is dangerous to think this is superficial matter. We conducted interviews with a range of professionals in different technical disciplines who identified visualisation as a problem. If something is not appealing, nobody will make the effort to read it. Visual models need to be at the same time appealing and easy to read. The improved ability of computers to decipher our content (image recognition, semantic analysis, etc.) and to interact with humans (through voice, movement, touch, etc.), make today the perfect time to revisit these representations.
There is something else at stake – a need for motivation to work together in collaborative ways. People from different disciplines and cultures value different things and are motivated differently. In particular, emotions can get in the way or tremendously boost imagination, team productivity and happiness. Emotions cannot be controlled, but marketing and science have explored this area well enough to teach us that perception through all our senses are critical to nudge us towards a “desired” mood. Providing a refreshing pause in day-to-day operations to think about the future, is often cited as the best part of the design thinking workshops we organise at the Design Studio. These moments enable people to build a team, a community that can last beyond these sessions and that has learned to work together. Besides, humans with all their senses and behaviours need to be considered as part of the system, not only as elements interacting with the system.
Systems engineering and design thinking share a few intentions; mainly a collaborative and holistic approach. It seems that systems engineering has reached a plateau in regards to teamwork, and needs to reassess its approach and tools. This is one of the key domains where design thinking can bring value, as we will see in the following chapter. Equally, design thinking has limits when it comes to being holistic. While it performs well at balancing desirability, feasibility, viability and identity, it doesn’t achieve full exhaustiveness. For example, some life cycles, contexts or stakeholders won’t be considered, while a strong focus will be made on others. Design thinking is rarely neutral, but adopts a posture that introduces a bias. Without losing this unique perspective, systems engineering can bring great value by organising information and helping reach more exhaustiveness. It will also enable to make a bridge for a continuous engineering between innovation and development phases. The visual below shows how the definition of a system moves forward during the innovation process.
2.2 Strengths and weaknesses
With all these insights in mind, we noticed that, often, strength in one discipline could be balanced by a weakness in the other, and vice versa. The table below summarises this comparison.
(a): Design thinking emerged recently (in the 1980’s) and is not widely studied in an academic context. While design is much older, it has been mostly considered a practice not suitable for research. However, design research has started to take off in
the last ten years.
(b): Design thinkers focus largely on the end users and often forget about the other stakeholders who also need a positive experience to satisfy the end users. The service design discipline, close to design thinking, has focused efforts on solving this issue in the last ten years, adopting a systemic approach.
(c): The vocabulary used in systems engineering is standardised, very precise and specific. This is a double-edged sword: people in the know – fellow systems and software engineers – understand it around the globe; while others see it as a foreign language, as is the case SysML (understood and accepted by a small portion of stakeholders, as described above). Learning a language without daily practice is extremely difficult, so forcing a minority’s language onto the majority is probably not the most realistic approach.
(d): We consider systems engineering lacks methodology to work in teams, as a patchwork of humans. Its only mean is sharing structured information. For example, there is no methodology to generate information such as stakeholders, contexts, use cases, etc.
(e) It is very interesting to note the difference in achieving a holistic approach. Systems engineering provides a structured framework for many people to structure the information within, looking for exhaustiveness. On the other side, design thinkers imagine (with others) a coherent whole, in one picture. However incomplete and unstructured as it may be, this picture of the whole communicates a vision to reach – as opposed to boxes to fill.
After comparing each other’s practice at a theoretical level, we did a few internal experiments along with customer workshops and deliverables to test and practice how the other team would work at specific stages of projects. In doing so, we ran into difficulties that helped us build the following hypotheses.
If there is one insight to remember when trying to combine our approaches, it is the difference in time. Design thinking is most useful when approaching “wicked problems” . This means, there is a set of challenges, often intertwined and ill defined, that need a fresh look at. This is the core of our design thinking work at the Design Studio, where we answer open questions with no focus on products (physical of digital). It can often be summarised as “how can we reinvent our industry sector?” The result of our approach is an incomplete but coherent picture of a desired future. In the industrial context, systems engineering very rarely starts from a blank sheet of paper and opening up to challenges outside the system. More importantly, its capacity to model and simulate a system requires a certain level of stability and top-level definition. It is most powerful at supporting convergence, but doesn’t have means to deal with divergence phases where information is generated. For these reasons, systems engineering naturally comes after the first phase (divergence) of design thinking, to structure the system that has started to emerge. Later in the process, Dduring the second divergence phase, systems engineering can go on near stand-by, waiting for elements to be defined. This is exactly how it happened on one of our recent design innovation project. The Design Studio helped the client create scenarios for a future product and service system. After this creative and storytelling phase, the design thinkers worked with systems engineers to structure missions, stakeholders and services, giving a first structured view to the client and supporting their decision making process. The illustration below shows the involvement of each discipline along the innovation process.
Each discipline has its own culture and ways of working. Designers and design thinkers suggest a lot of ideas, iterate, throw them away, turn them upside down, give them to someone else, etc. At some point, they need to select one to develop, but they will continue to iterate significantly for quite some time. They even go through a second divergence phase in the development phase. Engineering is focused on finding the right answer to study closely and prove right. However, systems engineers try to keep the possibilities open as late as possible to avoid limiting possibilities. For example, rather than defining the system as a specific robot (solution), they abstract a “System Under Development” – SUD. This leaves the possibility for expert disciplines to fill in the blanks. On the other side, design thinkers leverage the evocative power of imaginaries (evolving sets of narratives and forms ) to describe early ideas. While engineers speak about the SUD – an immensely neutral expression– design thinkers are more expressive by speaking of a compass, for example. This value-oriented approach helps kicking off creativity and alternative solutions. In the client project mentioned in 3.1, early component concepts helped the client identify a wider set of services and business opportunities. This difference is easily understood when we consider the ultimate aim of each discipline. Design thinking provides and describes a vision to reach, while systems engineering provides a structure to define and link many elements. These are two different ways to work we don’t believe should be muddled together. Their differences bring richness in a combined approach.
Vocabulary and approaches
Another point of difference related to culture, is the differing ways of “breaking down” information into categories, exact terms and points of view. This is best explained through an example. We imagined the following scenario: the early design phase of a system to remove mines in busy touristic areas in Cambodia. Both teams, design thinkers and systems engineers, agreed in the value of identifying the stakeholders, but didn’t agree on who they should be. Design thinkers added dogs and dog masters to the list of stakeholders, while systems engineers had listed dogs in the components because they are part of the system to develop. For design thinkers, the stakeholders can be equally inside or around the system.
Our design thinking process primarily takes place before the systems engineering method. The design thinking methodology helps imagine the system, whereas systems engineering grounds it. Both methodologies can act side by side and turn out to be complementary. The design thinking approach performs well in leading and expanding divergent thinking, but it lacks tools to collect and organise the results in a real content structure. In contrast, systems engineering benefits from a structuration of content but doesn’t have the means to diverge – a barrier to include more disparate and alternative content. However, different steps in these methodologies match and present the same types of content, sometimes at different scales. For example:
In systems engineering, context diagrams presenting the stakeholders and their interface with the system is close to the design thinking system
overview showing the system and the ecosystem around it.
• In systems engineering, missions and service scenarios are close to the synopsis and scenarios in design thinking. All describe the actions between
the stakeholders and the system.
Below is a summary of how our processes run in parallel, starting in the first phase of convergence. It is important to note that both processes are iterative within each phase. The scenarios and the first elements of the design thinking phase 2 correspond to a pivot moment as they communicate a non-exhaustive set of system elements. From this, systems engineers can start structuring information into a robust model. In the client project mentioned earlier, we represented, in the same model, the “traditional” elements listed above in 3.1 (missions, stakeholders and services) and two types of information from the design discipline: experiences lived by specific stakeholders in the scenario and component opportunities. These bring a point of view on how to design the system and start to form briefs and specifications for the project.
Edgar Morin said complex thinking is aimed at “encompassing rather than separating, linking rather than segmenting”  (our translation). Design thinking imagines the whole in a global coherence, accelerating innovation with illustrations of a few potential bits of what we could expect to become. Systems engineering models and simulates products (all the bits and links) to make it happen. To make Edgar Morin’s vision a reality in innovation, both design thinkers and systems engineers have to work together, with combined methodologies and shared elements of language. Following our experimentation, we believe it is also important to develop tools that link both approaches. Systems engineering has two major needs: modelling systems architectures in an accessible and ergonomic way, and helping convergence. Equally, design thinking also has two critical needs: tools to accelerate the creation of deliverables and structuring content to facilitate hand-over. What if there was a “repository” that provided continuity from design innovation to engineering? We believe it could serve different kinds of profiles, which we organise in four categories:
Integrators: people who link disciplines and elements of systems (e.g. project managers, experience designers, product managers)
• Approvers: people who decide (e.g. CEOs)
• Contributors: people who create (e.g. systems engineers, product designers)
• Advisers: people who are consulted (e.g. legal advisers, technical experts,
In this adventure ahead of us, we have identified three key challenges. The first is to create common definitions and a unique language; hence building bridges between disciplines, in particular between systems engineers and novices. Next, we need to create accessible and relevant representations for different levels, from macro to expert views. The last challenge is to define representations that are actually adequate in the real context of use; hence understanding the actual workings of systems architecture and the needs of different users, not compromising experts’ views. However, ultimately, the main stretch is to combine contrasting approaches bringing us back to the meaning of “technology”: the alliance of art and science.
- Tim Brown, Change by Design, 2009
- Jon Kolko, Design Thinking Comes of Age, HBR September 2015
- Kevin McCullagh, Beyond Design Thinking, Plan
- ISO/IEC 24765 Systems and software vocabulary
- INCOSE-TD-2007-003-02 – Survey of Model-Based Systems Engineering (MBSE)
- OMG Systems Modeling language – http://www.omgsysml.org
- Horst Rittel and Melvin M. Webber, 1973 characteristics of wicked problems
- Chaire Des Imaginaires, TelecomParisTech & Rennes 2 University, manifesto
- Edgar Morin, L’An
Gauthier Fanmuy – Gauthier.FANMUY(at)3ds.com
Arnaud Durantin – Arnaud.DURANTIN(at)3ds.com
Dassault Systèmes – Systems Engineering
Valérie Pegon – Valerie.PEGON(at)3ds.com
Ségolène Miet – Segolene.MIET(at)3ds.com
Dassault Systèmes – Design Studio
Anne Asensio, Etienne Boulanger, Joseph Cavé, Stan Edde, Morgan Lartigue and our
To listen more on this topic, please register for nour next 2023 GLOBAL CATIA MBSE CYBER EXPERIENCE SYMPOSIUM
Registration and info here: https://mbsecyberexperience.3ds.com/mces2023/
Powered by WPeMatico