Basics of Design Thinking

Design thinking is (yet another) methodology that can be used to design something. The key point of it is, that it’s human centered. To say it im my words: It provides patterns and techniques to identify and understand the different human viewpoints that influence the design. This provides the major foundation for whatever we’re going to build.

“Focusing on the people affected by your design decisions helps you concentrate on the exact problems that must be solved. It also grounds your solution exploration by reminding you that your purpose is to build software that helps people.”

The second sentence seems to be especially important. “it grounds the solution exploration”. We often see that we’re influenced very much by all the shiny blogposts from netflix or google and so on. They tell us how they’re doing it right and solve all problems. We can do that too, if we only do it like these blogposts suggest!1

To prevent us from falling into that trap (and probably numerous others), Design Thinking want’s to help us to always return to our purpose and re-focus on the actual target we want to hit, by focusing on the people for who we want to make life easier.

Principles, rules, etc.

“while design thinking is not a process, there are still rules to guide our design activities”

Here we go. The four principles are:

  • Human rule: All design is social in nature.
  • Ambiguity rule: Preserve ambiguity.
  • Redesign rule: All design is redesign.
  • Tangibility rule: Make ideas tangible to facilitate communication.

Human centered

Emphasize with all stakeholders!. I’m afraid that gets forgotten very quickly!

“Architects must emphasize with all stakeholders. We care about end users as much as the people the end users help, the programmers who write the code, the testers who verify it, and aeven the managers who keep tabs on the development schedule.”

“Empathizing with the humans who directly and indirectly interact with the architecture makes us a better designer, communicator, and leader.”

Preserve Ambiguity

That one is the hardest for me to get right, let’s try it:

“Allowing requirements, design decisions, and commitments to remain ambiguous is the best way to destroy a project.”

Erm, yes. I agree :D

“A minimimalist architecture only shows how high-priority quality attributes are achieved and reduces risks for promoting those quality attributes.”

Ah, so this is more about focusing on the right level or something?

“Design decisions that do not directly influence a quality attribute or reduce risks threatening our ability to deliver software are more about detailed design than architecture.”

Hm, okay. It seems to be about preserving options when the system (or architecture) needs to change in the future. So currently I understand that rule as “be aware of too detailed decisions early on. Instead, rather focus on the really important things and try to get them right, as they’re hard to change later on”.

Design is Redesign

This is a nice sidenote:

“If you you’ve ever enjoyed a perfect pring morning while sipping coffee at a sidewalk cafe, then you can thank Christopher Alexander for documenting the sidewalk cafe pattern as a community building solution.”

From the book A Pattern Language: Towns, Buildings, Construction, which is allegedly the inspiration for the famous Design Patterns book by the gang of four.

I think the key point is, that (almost) everything has been designed before in some way or another, and is probably documented somewhere. Problems occur over and over again, and hoardes of people have been trying to solve them ever since. We can take advantage from considering previous designs (concepts, frameworks, patterns, libraries, etc)

“One of the least effective ways to design software architectures is to ignore the software systems that came before us.”

Yup, a lot of stuff has been thought of before. Sometimes the cynic in me says “it’s all the same shit again and again”, this is probably when I recognize refined designs of something. Also, a lot of stuff has been identified and named before, for example things like “Data Warehouse” as a way to make analytics easy using relational databases.

If we recognize requirements matching to things previously designed, it does not automatically mean that we have to use the first concept/framework/library/language/ecosystem that we find in the internet. Instead, I think looking at previous designs helps phrase us to:

  • phrase our problems and possible solutions more precisely.
  • increase the chance to pick the right solutions for the problems at hand.

Make it tangible

Whatever “the design” or “the architecture” is, it must be made tangible. The barrier for (all sorts of) people to look at it and understand it must be as low as possible:

“The tangibility rule is closely related to the Human rule. Humans must be able to relate to ideas to internalize them. The only way to share an architecture is to make in tangible.”