On Design Thinking

According to Patnaik (2009), Design Thinking is “any process that applies the methods of industrial designers to problems beyond how a product should look.” The term was already used as early as 1987 by Rowe in his eponymous book in an architectural context and has lately become popular through research done at Stanford University and the Hasso Plattner Institute in Potsdam, Germany (Schmalzried, 2013). In his introductory article about Design Thinking, Brown (2008), the CEO and president of IDEO, uses the example of Thomas Edison to illustrate the underlying methodology. While Edison invented the lightbulb—which undoubtedly was a significant innovation in itself from a pure engineering perspective—he did not stop at that point. Rather, he understood that the lightbulb alone would be of no use to people, so he also created “a system of electric power generation and transmission to make it truly useful” (Brown, 2008). This means that “Edison’s genius lay in his ability to conceive a fully developed marketplace, not simply a discrete device” (Brown, 2008), which underpins that one of the prime principles of Design Thinking is to consider a broader context with the user at its center.

Three Requirements of Design Thinking

Brown (2008) characterizes Design Thinking as “a discipline that uses the designer’s sensibility and methods to match people’s need with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity”. Therefore, Design Thinking does not solely concentrate on users, but also takes into account the company perspective. This is necessary since without profitable companies, no human-centered products could be realized, which clearly do not come at no cost. Hence, Design Thinking focuses on people and industry to ultimately yield a methodology that serves both sides—if applied correctly; i.e., companies should not see designers as pure means to make existing products more beautiful, but to “create [new] ideas that better meet consumers’ needs and interests” (Brown, 2008). From all this, we can derive three requirements that have to be met if one wants to successfully apply Design Thinking for the creation of a new product. A product that is based on Design Thinking

  1. matches people’s needs (Brown, 2008),
  2. is based on feasible technological requirements (Brown, 2008), and
  3. creates customer value and market opportunity based on a viable business strategy (Brown, 2008).

According to Schmalzried (2013), these are similar to the “R-W-W” method by Day (2007), which can be summarized as: “Is it real? Can we win? Is it worth?”

To give an example, consider the Search Interaction Optimization methodology and toolkit that are at the heart of my PhD thesis. As for requirement (1) above, in the context of my thesis I had to consider two target groups. First, I developed means for human-centered design and development that are both, effective and efficient from a company’s point of view. Therefore, my primary target group were the stakeholders, designers and developers applying the new Search Interaction Optimization methodology and toolkit. Then, the secondary target group were the users who are ultimately provided with more usable products by the companies applying the approach. Hence, matching people’s needs corresponded to matching companies’ and users’ needs in that specific case.

What is a Design Thinker?

When it comes to the characterization of a person who applies Design Thinking, Brown (2008) specifies that Design Thinkers are empathic, which supports the successful application of a “people first” approach. Furthermore, they exert integrative thinking (Martin, 2009), i.e., thinking beyond the scope of purely analytical approaches in order to create “solutions that […] dramatically improve on existing alternatives” (Brown, 2008). Third, a Design Thinker is optimistic, which means they believe that there exists at least one solution that is better than the status quo Brown (2008). In addition, a certain amount of experimentalism is required, i.e., a Design Thinker must be happy to try out new (and potentially radical) things instead of just doing “incremental tweaks” (Brown, 2008). Finally, and probably most importantly, Design Thinkers collaborate, particularly in an interdisciplinary manner and also have experience in multiple fields (Brown, 2008).

Three Spaces of Design Thinking

Contrary to existing processes and methodologies that are established and predominantly used in today’s IT industry—i.e., “linear, milestone-based processes” (Brown, 2008)—, Design Thinking does not happen sequentially. Rather, Brown (2008) states that it “is best described metaphorically as a system of spaces rather than a pre-defined series of orderly steps.” These spaces are given as follows:

Inspiration relates to actions such as investigating the status quo, defining potential target audiences, exploring the context the new product will be embedded in, going beyond that context to obtain a broader view, observing people, observing the current market situation etc. All of these are actions that “motivate the search for solutions” (Brown, 2008).

Ideation In the ideation space, scenarios and user stories are created, prototypes are built and tested (both informally and formally), outcomes are communicated etc., all in multiple iterations. That is, the “generati[on], develop[ment], and testing [of] ideas that may lead to solutions” (Brown, 2008).

Implementation The implementation space does not correspond to the technical implementation alone, i.e., programming tasks carried out by developers. Rather, it again involves a huge amount of interdisciplinary communication to pave the path to a usable product that is put into a broader context. This particularly includes business solutions and marketing, i.e., the implementation space “chart[s] […] a path to market” (Brown, 2008).

While a Design Thinking process usually starts in the inspiration space, transition between any two of the spaces is possible at any time (Brown, 2008), which clearly distinguishes it from established business processes. One example could be that while working in the implementation space, a Design Thinker notices that the new product can not be well communicated to customers, which might make it necessary to enter the inspiration space (again) and perform a new analysis of the current market situation and customers needs. If it turns out that a different marketing strategy would be sufficient, they can then return to the implementation space. A second example would be a series of several paper prototypes that all indicate the previously developed user stories to be irrelevant. This could result in a return to the inspiration space for defining new target audiences or paying closer attention to specific groups of users.

Design Thinking as a Process

A more concrete implementation of the Design Thinking methodology has been realized in the Human-Centered Design Toolkit by IDEO.org (2011). That is, although the underlying principles remain the same, they build on a more defined process. The toolkit guides designers (which, according to the Design Thinking methodology, can be project managers, developers etc.) through a three-step process, i.e., “Hear”, “Create” and “Deliver”. This happens in order to provide solutions that are “desirable, feasible and viable” (IDEO.org, 2011) from a human-centered point of view.

Complementary to this, David Kelley, the founder of IDEO and d.school, defines five elements for the Design Thinking process: Empathize, Define, Ideate, Prototype and Test (Kliever, 2015). By empathizing, you understand “the beliefs, values, and needs that make your audience tick” (Kliever, 2015). In the next step, the collected information are analyzed and translated into insights about the audience and the challenge to be faced (Kliever, 2015). Once the challenge has been defined, in the Ideation phase (which is also one of Brown’s Design Thinking spaces), everything is about finding possible solutions, i.e., it “is a brain dump of ideas, and nothing is off limits” (Kliever, 2015). Finally, in the last two stages, multiple ideas are translated into prototypes and tested with the audience (Kliever, 2015). Depending on whether or not a prototyped and tested solution proves suitable, it might be necessary to iterate one or more of the previous steps (Kliever, 2015).

It might seem counterintuitive to talk about Design Thinking processes after having introduced Design Thinking spaces earlier (“Design Thinking does not happen sequentially”). However, Kelley’s process is perfectly in line with the concept of Design Thinking spaces, where you do not follow a predefined path. The spaces and processes of Design Thinking go hand in hand. While you follow the above process, you necessarily move through the three spaces of Inspiration, Ideation and Implementation in no particular order, iterating previous steps if required.

The Design Thinking Process
The Design Thinking Process visualized by the K12 Lab.


To conclude, I would like to quote Steve Jobs, who said:

Design is a funny word. Some people think design is how it looks. But of course, if you dig deeper, it’s really how it works.

Moreover, I would like to refer to Google’s principle

Focus on the user and else will follow.

To give just one example for this, if you write a blog post, it will not become popular because you are using some fancy SEO tools. It will become popular if and only if you have created a piece of great content that fulfills the needs of your audience. As a Design Thinker, be bold, be unpredictable, be creative! You do not (necessarily) have to be a Photoshop artist for this. Hypothesize, but make your hypotheses testable—and test them. But still, do not rely on data alone as a starting point, which might prevent radical and potentially better solutions. Finally—and most importantly—do not let legacy processes restrict yourself. Yet, at the same time make sure that Design Thinking remains too unpredictable to become a legacy process itself.

(This article has also been published in theuxblog.com on Medium.)


Brown, Tim (2008). “Design Thinking”. In: Harvard Business Review 86(6), pp. 84–92.

Day, George S. (2007). “Is It Real? Can We Win? Is It Worth Doing?” In: Harvard Business Review 85(12), pp. 110–120.

IDEO.org (2011). Human-Centered Design Toolkit. isbn: 978-0-9914063-0-2.

Kliever, Janie (2015). “Design Thinking: Learn How to Solve Problems Like a Designer”. https://designschool.canva.com/blog/design-thinking/ (July 9, 2015).

Martin, R.L. (2009). The Opposable Mind: Winning Through Integrative Thinking. Cambridge, ma: Harvard Business School Press.

Patnaik, Dev (2009). “Forget Design Thinking and try Hybrid Thinking”. http://www.fastcompany.com/1338960/forget-design-thinking-and-try-hybrid-thinking (July 9, 2016).

Rowe, Peter G. (1987). Design Thinking. Cambridge, ma: MIT Press.

Schmalzried, Dirk (2013). In-Memory-basierte Real-Time Supply Chain Planung [In-Memory-based Real-Time Supply Chain Planning]. PhD thesis. University of Leipzig.


What is ›Usability‹?

What is Usability?Earlier this year, I submitted a research paper about a concept called usability-based split testing1 to a web engineering conference (Speicher et al., 2014). My evaluation involved a questionnaire that asked for ratings of different usability aspects—such as informativeness, readability etc.—of web interfaces. So obviously, I use the word “usability” in that paper a lot; however, without having thought of its exact connotation in the context of my research before. Of course I was aware of the differences compared to User eXperience, but just assumed that the used questionnaire and description of my analyses would make clear what my paper understands as usability.

Then came the reviews and one reviewer noted:

“There is a weak characterization of what Usability is in the context of Web Interface Quality, quality models and views. Usability in this paper is a key word. However, it is weakly defined and modeled w.r.t. quality.”

This confused me at first since I thought it was pretty clear what usability is and that my paper was pretty well understandable in this respect. In particular, I thought Usability has already been defined and characterized before, so why does this reviewer demand me to characterize it again? Figuratively, they asked me: “When you talk about usability, what is that ›usability‹?”

A definition of usability

As I could not just ignore the review, I did some more research on definitions of usability. I remembered that Nielsen defined usability to comprise five quality components—Learnability, Efficiency, Memorability, Errors, and Satisfaction. Moreover, I had already made use of the definition given in ISO 9241–11 for developing the usability questionnaire used in my evaluation: 

“The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”

For designing the questionnaire I had only focused on reflecting the mentioned high-level factors of usability—effectiveness, efficiency, and satisfaction—by the contained items. However, the rest of the definition is not less interesting. Particularly, it contains the phrases

  1. “a product”;
  2. “specified users”;
  3. “specified goals”; and
  4. “specified context of use”.

As can be seen, the word “specified” is used three times—and also “a product” is a rather vague description here.

This makes it clear that usability is a difficult-to-grasp concept and even the ISO definition gives ample scope for different interpretations. Also, in his paper on the System Usability Scale, Brooke (1996) refers to ISO 9241–11 and notes that “Usability does not exist in any absolute sense; it can only be defined with reference to particular contexts.” Thus, one has to explicitly specify the four vague phrases mentioned above to characterize the exact manifestation of usability they are referring to. Despite my initial skepticism, that reviewer was absolutely right!

Levels of usability

As the reviewer explicitly referred to “Web Interface Quality”, we also have to take ISO/IEC 9126 into account. That standard is concerned with software engineering and product quality and defines three different levels of quality metrics: 

  • Internal metrics: Metrics that do not rely on software execution (i.e., they are a static measure)
  • External metrics: Metrics that are applicable to running software
  • Quality in use metrics: Metrics that are only available when the final product is used in real conditions

As usability clearly is one aspect of product quality, these metrics can be transferred into the context of usability evaluation. In analogy, this gives us three levels of usability: Internal usability, external usability, and usability in use.

This means that if we want to evaluate usability, we first have to state which of the above levels we are investigating. The first one might be assessed with a static code analysis, as for example carried out by accessibility tools. The second might be assessed in terms of an expert going through a rendered interface without actually using the product. Finally, usability in use is commonly assessed with user studies, either on a live website, or in a more controlled setting.

Bringing it all together

Once we have decided for one of the above levels of usability, we have to give further detail on the four vague phrases contained in ISO 9241–11. Mathematically speaking, we have to find values for the variables product, users, goals, and context of use, which are sets of characteristics. Together with the level of usability, this gives us a quintuple defined by the following cross product: 

level of usability × product × users × goals × context of use.

We already know the possible values for level of usability:

level of usability ∈ { internal usability, external usability, usability in use },

so what are the possible values for the remaining variables contained in the “quintuple of usability”?


The first one is rather straightforward. Product is the actual product you are evaluating, or at least the type thereof. Particularly, web interface usability is different from desktop software or mobile app usability. Also, it is important to state whether one evaluates only a part of an application (e.g., a single webpage contained in a larger web app), or the application as a whole. Therefore: 

product ⊆ { desktop application, mobile application, web application, online shop, WordPress blog, individual web page, … }. 

Since product is a subset of the potential values, it is possible to use any number of them for a precise characterization of the variable, for instance, product = { mobile application, WordPress blog } if you are evaluating the mobile version of your blog. This should not be thought of as a strict formalism, but is rather intended as a convenient way to express the combined attributes of the variable. However, not all values can be meaningfully combined (e.g., desktop application and WordPress blog). The same holds for the remaining variables explained in the following.


Next comes the variable users, which relates to the target group of your product (if evaluating in a real-world setting) or the participants involved in a controlled usability evaluation (such as a lab study). To distinguish between these is highly important as different kinds of users might perceive a product completely differently. Also, real users are more likely unbiased compared to participants in a usability study.

users ⊆ { visually impaired users, female users, users aged 19–49, test participants, inexperienced users, experienced users, novice users, frequent users, … }.

In particular, when evaluating usability in a study with participants, this variable should contain all demographic characteristics of that group. Yet, when using methods such as expert inspections, users should not contain “usability experts,” as your interface is most probably not exclusively designed for that very specific group. Rather, it contains the characteristics of the target group the expert has in mind when performing, for instance, a cognitive walkthrough. This is due to the fact that usability experts are usually well-trained in simulating a user with specific attributes.


The next one is a bit tricky, as goals are not simply the tasks a specified user shall accomplish (such as completing a checkout process). Rather, there are two types of goals according to Hassenzahl (2008): do-goals and be-goals. 

Do-goals refer to pragmatic usability, which means “the product’s perceived ability to support the achievement of [tasks]” (Hassenzahl, 2008), as for example the aforementioned completion of a checkout process.

Contrary, be-goals refer to hedonic usability, which “calls for a focus on the Self” (Hassenzahl, 2008). To give just one example, the ISO 9241–11 definition contains “satisfaction” as one component of usability. Therefore, “feeling satisfied” is a be-goal that can be achieved by users. The achievement of be-goals must not necessarily be connected to the achievement of corresponding do-goals (Hassenzahl, 2008). In particular, a user can be satisfied even if they failed to accomplish certain tasks and vice versa.

Thus, it is necessary to take these differences into account when defining the specific goals to be achieved by a user. The variable goals can be specified either by the concrete tasks the user shall achieve or by Hassenzahl’s more general notions if no specific tasks are defined:

goals ⊆ { do-goals, be-goals, completed checkout process, writing a blog post, feeling satisfied, having fun, … }.

Context of use

Last comes the variable context of use. This one describes the setting in which you want to evaluate the usability of your product. It can be something rather general—such as “real world” or “lab study” to indicate a potential bias of the users involved—, device-related (desktop PC vs. touch device) or some other more specific information about context. In general, your setting/context should be described as precisely as possible. 

context of use ⊆ { real world, lab study, expert inspection, desktop PC, mobile phone, tablet PC, at day, at night, at home, at work, user is walking, user is sitting, … }.

Case study

For testing a research prototype in the context of my industrial PhD thesis, we have evaluated a novel search engine results page (SERP) designed for use with desktop PCs (Speicher et al., 2014). The test was carried out as a remote asynchronous user study with participants being recruited via internal mailing lists of the cooperating company. They were asked to find a birthday present for a good friend that costs not more than €50, which is a semi-open task (i.e., a do-goal). According to our above formalization of usability, the precise type of usability assessed in that evaluation is therefore given by the following (for the sake of readability, the quintuple is given in list form): 

  • level of usability = usability in use
  • product = {web application, SERP}
  • users = {company employees, novice users, experienced searchers (several times a day), average age ≈ 31, 62% male, 38% female}
  • goals = {formulate search query, comprehend presented information, identify relevant piece(s) of information}
  • context of use = {desktop PC, HD screen, at work, remote asynchronous user study}

In case the same SERP is inspected by a team of usability experts in terms of screenshots, the assessed type of usability changes accordingly. In particular, users changes to the actual target group of the web application, as defined by the cooperating company and explained to the experts beforehand. Also, goals must be reformulated to what the experts pay attention to (only certain aspects of a system can be assessed through screenshots). Overall, the assessed type of usability is then expressed by the following:

  • level of usability = external usability
  • product = {web application, SERP}
  • users = {German-speaking Internet users, any level of searching experience, age 14–69}
  • goals = {identify relevant piece(s) of information, be satisfied with presentation of results, feel pleased by visual aesthetics}
  • context of use = {desktop PC, screen width ≥ 1225 px, expert inspection}


Usability is a term that spans a wide variety of potential manifestations. For example, usability evaluated in a real-world setting with real users might be a totally different kind of usability than usability evaluated in a controlled lab study—even with the same product. Therefore, a given set of characteristics must be specified or otherwise, the notion of “usability” is meaningless due to its high degree of ambiguity. It is necessary to provide specific information on five variables that have been identified based on ISO 9241–11 and ISO/IEC 9126: level of usability, product, users, goals, and context of use. Although I have introduced a mathematically seeming formalism for characterizing the precise type of usability one is assessing, it is not necessary to provide that information in the form of a quintuple. Rather, my primary objective is to raise awareness for careful specifications of usability, as many reports on usability evaluations—including the original version of my research paper (Speicher et al., 2014)—lack a complete description of what they understand as ›usability‹.

(This article has also been published on Medium and as a technical report.)

1 “Usability-based split testing” means comparing two variations of the same web interface based on a quantitative usability score (e.g., usability of interface A = 97%, usability of interface B = 42%). The split test can be carried out as a user study or under real-world conditions.


John Brooke. SUS: A “quick and dirty” usability scale. In Usability Evaluation in Industry. Taylor and Francis, 1996. 

Marc Hassenzahl. User Experience (UX): Towards an experiential perspective on product quality. In Proc. IHM, 2008.

Maximilian Speicher, Andreas Both, and Martin Gaedke. Ensuring Web Interface Quality through Usability-based Split Testing. In Proc. ICWE, 2014.


Special thanks go to Jürgen Cito, Sebastian Nuck, Sascha Nitsch & Tim Church, who provided feedback on drafts of this article 🙂