Sim­pli­city as a value

One month ago, Edward de Bono died. He lived for eighty-eight years, during which time he wrote a total of 50 books. He is best known for his lateral thinking and six thinking hats; Bono's methods are well suited to general systems design and organizational collaboration.

For almost a decade, a portrait of Edward de Bono has hung on the wall of Integral Vision, alongside the faces of Mihály Csíkszentmihályi and Seth Godin. His thoughts have provided one of the pillars for what has become Integral Vision, in which I reflect on Bono's thoughts on simplicity.

Bono's notion of lateral thinking refers to an intuitive, non-logical, creative mode. From everyday work to personal decisions, I have experienced moving forward without listening to common sense in many situations. Instead, I have acted on an idea, a connection, or insight from an uncertain source. In hindsight, the picture became more apparent, but it was not entirely clear why I had made the decision I did in the process.

It was a simple question of inspiration, a suggestion, a clue, a suggestion, a suggestion.

The attractive opportunity

It was one such story when, after finishing high school, I decided to follow my father's example and enroll in civil engineering. After six months, I got in on a scholarship and then dropped out and changed majors. Logic would have dictated that I should have graduated and then taken over my father's company, but I didn't. Instead, I moved back home after my six months of exams and started working, studying psychology in the process.

Recently I asked my father if he could have imagined a different career for himself. The answer was an unequivocal yes: he confessed bluntly that he had always been interested in physics and astronomy. I chose architecture, my son, because I didn't get into mathematics, and I was heading for a course where I had an excellent academic average.

I didn't know about it until then. A few days before his retirement, he told me, while we were philosophizing about what would have happened if I had stayed in Brasov to study civil engineering. I know now: I would have been like him; I look back around retirement and say that there would have been another path that I didn't take. An interesting side note is that I did not go to Cluj Napoca to study computer science for the same reason: I knew my maths average was not good enough. I copied my father's decision without knowing that I was doing so.

I struggled a lot about whether I should go through five years with all the skills I needed to be an architect-engineer, but no motivation to get stuck into concrete and its companions. Whenever I have analyzed the situation, I have consistently concluded that staying is the logical choice; it is correct. The thought structure was strong; I kept adding new motifs repeatedly to make sure I didn't break it up.

It's worth discarding well-constructed structures for a rough but appealing idea. I departed from the paternal path, and today I believe I could not have made a better decision.

Agility is a way to reduce complexity

I got my first primary job with a multinational company. I had to make the user interfaces of an already written software that was about to be delivered acceptable. To do this, I was expected to tune up the interfaces without going deep into the functionality. For overtime, I was given a  functional specification, access to the system, lots of coffee, and pizza. The task was to make the otherwise unacceptable software look better.

I was inexperienced, happy to be asked, so I took the job. I stayed up all night working over every graphical user interface for two weeks, but I still couldn't save the project from failure. It was a bitter experience for all of us. Many people were made redundant after the project was closed, but I was kept on and together with a new team; this time, we tackled the same business problem with an agile approach.

We built uncertainty into the process, working closely with the client to design and implement in three-week cycles. Instead of a project manager, we were assigned a scrum master who spared no energy and time to provide all the conditions we needed. At one point, we asked him to bring the client closer, with the expert from the other side sitting on the team to give us a deeper understanding of document management. He solved that, too: after a little while, we were working on the app alongside the greatest wizard in document management.

The need to over-proof projects often results in unnecessary complications. Complying with many stakeholders, a rigid, over-specified contract may seem financially secure, but the implementation usually pays the price. The focus on adequately accounting for a project diverts energy away from the efficient performance, introducing unnecessary mess into the process.

One of my insights from this period is that the pursuit of simplicity comes at a heavy price. You can't spare depth; you can't spare business knowledge without UX; the UI is just an empty form.

UX: the science of simplification

I just found Bono's book Simplicity. It was inspiring. It gave me a deeper understanding of how to simplify complex problems. We had been developing the Document Manager for some time, and my job was to translate a highly complex business process into clear, intuitive user interfaces. I pored over the literature (there wasn't much work on the subject at the time) and wrote down the most valuable principles that I kept in mind throughout my career.

Bono's tree metaphor is that the trunk is the goal, the fruit is the value. The purpose of any action is valuably applicable to its "user." Between trunk and fruit, the branches represent the realization: the totality of all the tree makes available to us the value it produces.

The semantic level is more complex than the formal. When I was designing the interface, I kept asking: what are we trying to achieve? What is our goal with this process? We could weed out the unnecessary folds that kept increasing in the designs by asking this question. Is this branch essential? Can the user find the desired action?

This is how user interface design became the science of simplification for me. I was able to design "Swiss Army knife" style interfaces relatively quickly. Still, a simple, clean user experience usually requires a lot of dialogue between the business, development, and UX sides. That's where Edward de Bono's system came in handy. He's one of the few authors who can talk about simplification at a meta-level, so I've gained more profound knowledge by reading him.

The team is more intelligent than the expert

I've been through many unproductive meetings where senior developers have repeatedly exposed their greatness and solved difficult situations. The hero's myth was spun around the team, while the creative energies of the more inexperienced staff found it harder to manifest. At one point, I suggested we try Bono's five-step thinking system. The idea is to delay coming up with solutions, but first to formulate in a separate round where we want to go, our current situation, and our options. This phase was my favorite here. We brought in several foreign examples; we could also develop abstract associations because we did not let the critical voice into the process here. Sometimes we left the collection of options open for days; we did background research to have enough background material to find the right direction for us.

We did not allow for scathing criticism to be put forward.

Once all the ideas were on the table, we organized and prioritized them. We narrowed down the options, highlighting those that seemed more relevant in some way than others. At this point, I was far enough away from my ideas to be too hurt by criticism. Since we all changed attitudes simultaneously, it was safe to brainstorm and later critique. The battle of egos took a back seat, and many new ideas surfaced.

Solutions emerged almost unnoticed, out of the process, and emerged as teamwork rather than the final word of authority. It was suitable for all of us, and even people with less experience felt like they were an active part of the process.

Clear rules of the game

When Integral Vision was founded, I believed that the principles I had experienced in my narrow professional field could work at an organizational level. Instead of an over-regulated environment, I envisioned a readily transparent, value-focused team.

In IV, we decide together on issues that affect us all. For the sake of transparency, we keep our decisions in a jointly created spreadsheet so that they can be tracked and retrieved by everyone. At the same time, we all know that no one likes to rummage through policies; we much prefer to rely on our memories. We have also experienced that too many rules are more of a hindrance than a help, so we carefully review the proposals. Only those seen as valuable by all parties involved, or at least not vetoed, will become policies. This is why proposals are difficult to pass, preceded by many rounds of clarification, during which it may turn out that they are not needed at all, or we may simplify them, describing them in more precise terms.

Simple or primitive?

The other lesson from the above story is that only someone who knows the subject in depth can distinguish between simple and primitive. An expert becomes a master when presenting the complex simple, not trivial. The master does not need jargon to express himself on the subject.

We needed a master who could convey the concepts of document management in a way that also knew the language of the experts, who could speak about it in terms we could understand, and who could depart from it. We gradually acquired the concepts in conversations with him, which were reflected in the application.

In our company, we try to keep everything simple, we value delivering quickly and not complicating the workflow and collaboration framework. One of the foundational books that many of us read in the early years of the company was Simplicity. Bono's thoughts also underpin the agile approach and can be useful background material in formulating UX/UI design principles. Anyone interested in how to tackle complex problems should read his books.

Related literature

Edward de Bono: Simplicity, Viking Publishing, 1998
One of Bono's least known books. He argues that simple things are easy to use but hard to design. Simplicity is something you have to strive for, it usually doesn't evolve by itself. How do things become clear? What do we need to look for if we want to live in a simple, usable world?

Edward de Bono: Teach Yourself to Think, HVG Books 2007

The Art of Software Development (Part 1, Part 2, Part 3)
Interview with István Marhefka. What is the connection between literature and software development? What languages should a programmer speak? Why is it important what to call a function? I interviewed the lead developer of our team during the period referred to in the article.

Bono Quotes

"Simplicity without understanding is primitive, simplicity after understanding is simple."

If the rules of the game are clear, people will play the game very well. The rules of the game of simplicity must be laid down as clearly as the rules of the game of quality were laid down before.(Bono, p.16)

Bono argues that simplicity is so important that an Institute for Simplicity should be set up in every country to comment on new laws, regulations and procedures. Ministries would have to meet simplicity criteria in addition to professional quality compliance before issuing regulations.

This seems relatively straightforward. In reality, however, few people really appreciate simplicity. It is valued to some extent, but it is more of a "second-rate" value. Our actions must be effective or lead to saving money. If, in addition, they are simple, that is good, but only as long as that simplicity does not interfere with the other two values. If something is complicated, we rarely seek to simplify it further. Simplicity rarely emerges as a primary consideration. So if we don't place a high value on simplicity, it will come naturally. (Bono, 287, o).

We need to be very clear about what we want. We need to be clear about our values and we need to be clear about the criteria to be taken into account. If we want to understand a situation or a process, we need to be experts in the subject. If not, the result of our efforts will be primitive rather than simple. The driving force of simplicity is understanding. Without understanding there is no simplicity. Only the simplicity that comes from understanding has value (Bono, p. 289).