• Home
  • About
  • Thoughts
  • Transportation designing to live and living to transportation design

Transportation designing to live and living to transportation design.

I am designer and engineer: A dangerous half truth.

… come on Christos, you the designers are all the same; you cannot understand our work. We are facing various problems with the designs; they’re causing unexpected delays and we’re losing money. In my opinion there is a lack of professionalism in your industry worldwide… But how is that possible? Designers and contractors we are both engineers after all…

Simos seemed skeptical and maybe repentant for what he had just said. He was a renowned executive leader in the construction industry and his company was - and still is - one of our big clients. I was… cool; it was something that I had heard quite a few times during my career as a transportation designer and somehow, I had been used to it. Quite a few times I had received that same feedback in different variations, despite of the project outcome.

I smiled at him as he was turning his back to me in order to receive some more warm congratulations from the project owners’ representatives. We were celebrating the completion of a well known project. Our design firm and his construction company had just successfully completed the redesign and reconstruction of the original classic Marathon route, a major transportation project for the Athens Olympics 2004, a project that I had given everything for its success.

It was that same night, when I was driving back home from the celebration party, with Simos’ last words nagging in my mind Designers and contractors we are both engineers after all… And it was that very moment that I realised the essence of the problem I was facing for so many years. A designer and an engineer cannot coexist at the same mind. Yes, I had studied transportation engineering, but I was not an engineer, I had always been a designer.

Years after that summer night of July 2004, and a river of design work, experiments, tries, mistakes, failures and successes, here are my insights and my view on questions like:

  • What are the true challenges of a transportation designer?
  • What types of brain, reasoning and mindset can successfully engage in transportation design?

Two challenges

What is transportation design? As R. Buchanan beautifully explains, designers are professionals from different disciplines that share a mutual interest on a common theme: the conception and planning of the artificial.

In other words, we as transportation designers, aim to change existing (or non-existing) transportation situations into new ones, coping with two great challenges.

Challenge no 1: The gulf of evaluation.

To better understand this challenge, it helps to think that a main difference between design and science is that of time. Scientists operate in a world that exists in the present; mathematicians are independent of historical time (abstract); designers treat what exists in the (not their) imagined future as real.

It is exactly the intangible nature of our projects that creates communication failures between the designer and his clients, when they try to describe something intangible. What the clients describe is often very different from how the designer could interpret it. I call this semantic gap the gulf of evaluation, borrowing the term from D. Norman.

A guiding policy that we use to this first challenge is rapid prototyping. Clients should have an early look at prototypes (3D printings, simulations, etc.) so as to confirm whether our approach is suitable. We often use the term IKIWISI (I’ll Know It When I See It) because the true requirements may only emerge once the concept has been demonstrated, and even better has been experienced. For example, the real safety performance of a transportation system will be known only after its first period of operation (black spots identification, etc.)

Challenge no 2: The VI factor.

During the last years I have had the opportunity to run repeatedly the following two experiments and I have always received the same results.

Experiment V: Two transportation designers with the same technical knowledge, the same experience, who are working together for years, are delivering - separately from each other – designs to the same client for the same project. The two designs most of the times are very different. I named the first experiment V - for Variability. The design outcome is highly variable, because the design services depend on who the designer is.

Experiment I: One transportation designer is working with two different clients, in two projects that are very similar (actually two consequent sections of the same corridor). Again the two designs are very different. I named the second experiment I - for Inseparability. The design outcome is inseparable, because it is the result of close collaboration between the client and the designer.

Two project types

Transportation projects, since they affect directly people’s lives, are by definition complex projects with varying degrees of uncertainty and ambiguity. I have a particular preference in categorising transportation design projects. I am not interested in the size of the project, its budget etc., instead I look closely for two things: for the number of stakeholders and for the degree of definitive conditions that the project has. Since the effect that an increased number of stakeholders has to a project is straight forward, some emphasis will be given next on the degree of definitive conditions.

Transportation design projects of Type I:

In this category fall the projects that have a small number of stakeholders and a high degree of definitive conditions. Most of time the design requirements for this category are described in detail and the definition of the design success has to do with the compliance of detailed criteria, specifications, etc. (criteria-based transportation designs). I call these projects DTP – Determinate Transportation Projects.

Transportation design projects of Type II:

In this category I place the projects with a big number of stakeholders and a low degree (and sometimes almost a total absence) of definitive conditions and limits. These designs are (or should be) most of the time performance-based designs (not criteria-based designs). I call these projects ITP – Indeterminate Transportation Projects.

The guiding policies that I apply in the engagement with these two project types are the following:

For determinate design projects, the classic linear model can be followed: (1) Problem definition. It is an analytic sequence that determines all the facets of the project and clarifies all the detailed requirements. (2) Problem solution. It is a synthetic sequence that identifies conflicts among requirements and comes up with the final design proposal. In this type of projects traditional project management methodologies (waterfall approach) may have some chance.

For indeterminate design projects, the linear model is not working. Iterative models work much-much better. In this project type, designers go beyond the analytical process, in order to produce new alternatives using a different intelligence that will be introduced to you in the following chapter. In indeterminate design projects traditional project management methodologies (waterfall approach) have no chance at all. Value-driven agile project management methodologies, like Scrum, have given us very encouraging and in some cases great results. 

Three brains

Deductive brain and Inductive brain

Type I design projects require designers with deductive reasoning while in some cases they may require inductive reasoning as well. Analysis and synthesis are both required for as the main roles in this project type. Engineers that have a left brain may fit well in this category. Many of them award themselves the title of transportation designer. They are wrong. In the best case they actually act as transportation consultants or transportation engineers.

As Baba Shiv nicely describes in his seminal lectures in the CFI program (between Stanford’s GSB and Stanford’s d.school), this type of design projects can work with the type 1 mindset, which is fearful of making mistakes. The brain becomes very risk averse under this line of thinking, and innovation and new ideas generation is almost impossible. These people are not wired to be designers. In project Type I, reason leads to conclusions and this is enough for the most project cases.

Abductive brain

Type II design projects can be successfully delivered only from designers with abductive reasoning. In this project type, designers go beyond the analytical process that produces either/or choices to produce new alternatives using their integrative thinking and abductive intelligence. Most of the time they use a right brain and a type 2 mindset.

Baba Shiv describes this mindset: “the type 2 mindset is fearful of losing out on opportunities. Places like Silicon Valley are full of type 2s. What is shameful to these people is sitting on the sidelines while someone else runs away with a great idea. Failure is not bad; it can actually be exciting. From so-called "failures" emerge those valuable gold nuggets - the "aha!" moments of insight that guide you toward your next innovation.” In project Type II, it is emotion that leads to actions and not reasoning.

My experience tells me that only these people are wired to be designers. Only these brains can successfully solve problems with a high degree of ambiguity. Transportation designers with their abductive brain can find solutions in problems that is almost impossible to be solved from transportation engineers.


Wicked problems

In the linear design process model that is used on determinate projects, our task as designers is to identify the definitive conditions and then calculate a solution. But what about the problems that do not have definitive conditions or even limits? The term “wicked problems” coined by philosopher Karl Popper and borrowed by H. Rittel, is used to describe design problems that have not definitive conditions; problems that have an inherent indeterminacy (different than undetermined). Rittel had initially identified ten attributes of wicked design problems, the most important of which are presented below.

  • Wicked problems have no definitive formulation, but every formulation of a wicked problem corresponds to the formulation of a solution.
  • Solutions to wicked problems cannot be true or false, only good or bad.
  • For every wicked problem there is always more than one possible explanation, with explanations depending on the weltanschauung (simplistically translated as worldview) of the designer.
  • No formulation and solution of a wicked problem has a definitive test.

Batch vs. Real-time

The world runs in real-time, but infrastructure projects run in batch. Every few weeks or months contractors or project owners are receiving a new release of the ongoing transportation design and then everybody adjusts. I was fortunate to experience the great value that is created for all stakeholders, when we put the design data, used by the contractors, into a big stream and shift through the data the moment these are created and make immediate, incremental adjustments to the construction process.

Code builders

I started my professional career as a passionate programmer, and I am still programming. Maybe that is the reason why when I look at transportation drawings I see code everywhere. I also see a system, an architecture, user stories, data bases, etc.

Many times I have thought that there is not much difference between the designing of a transportation project and an IT platform or app. Tim Brown has said it beautifully “… and somehow we design by coding things, but with somewhat predictable ways, not all the possible predictable ways.” So yes, we are code builders.


We are not blueprint producers. The ‘blue print’ concept is a grave mistake. Blue-prints ‘freeze’ the designs. Designs are transformed and are continuously adapted throughout their life-cycle. Transportation projects are by definition complex projects, and only ‘live designs’ evolving iteratively can create value for the stakeholders.



Performance-based vs. Criteria-based design

The NCHRP rep 785, when it was published in 2014 gave me great satisfaction, since in my view it brings road designers in the middle of the stage again. According to this report “Being able to identify and articulate the intended project outcomes will help clarify the key project performance measures, including transportation performance measures, and the associated design elements and decisions most likely to influence whether a project will fulfill those desired outcomes. The intended project outcomes are often closely linked to who the project is intended to serve.”

And furthermore, “Performance-based analysis of geometric design provides a principles-focused approach that looks at the outcomes of design decisions as the primary measure of design effectiveness… An overall project performance goal may be to reduce crash frequency and severity. Geometric design performance goals may be to reduce conflict points and vehicle speeds… Overall project performance may influence and may be influenced by geometric design decisions and their resultant performance.”


And as infrastructure projects designers, most of the time, we live by the triple-f credo “form follows function” keeping in mind the road users as well as the construction engineers. 

Three concluding thoughts

Transportation design is concerned with the particular, and there is no science of the particular.

Transportation design ideas eat engineering technology for breakfast.

We the transportation designers, have to become better not in solutions, but in understanding problems.


… and back to Simos

Different walks of life never gave me the chance to continue our conversation with Simos; he passed away few years later.

I have never had the chance,

  • to argue that transportation design is not an “applied science,”
  • to argue that each of the technical disciplines that participate in a transportation design project tend to regard it as an “applied” version of its own knowledge (geometry experts, ITS experts, EMP experts, structural experts, etc.),
  • to argue that contractors regard transportation design as a well defined demonstration of the principles of their subject matter only (constructability, minimal technical solution, minimal construction costs, etc.)

And Simos has never had the chance to smile, look me in the eye, pause for a second, and say something like, “It is one thing to think you are generating great designs and another thing entirely to have your clients confirm this.”

No wonder transportation designers and contractors have difficult conversations in project celebration parties.

Christos Rados is an executive leader in the professional engineering services industry. He is an entrepreneur, ambitious giver, designer, programmer, scrum fun, and value creation lover. He has studied engineering, design, business and finance. He has abductive reasoning and synthetic intelligence.

Tags: transportation, for clients, Design