Keywords

1 Introduction

In design field, since design is a problem solving activity, so conflict cannot be avoided during the design practice. Compromise is usually used to solve it. In real design practice, these compromise during the design process leads to unsatisfactory design results which is not consistence with what designers plan at the starting point. The user experience of products will be reduced during the continuous compromise.

In Juhani’s law, the compromise will always be more expensive than either of the suggestions it is compromising. And from the literature review, few studies have be made on how to solve conflict in product experience design.

Thus, in this paper we are trying to solve it by making win-win design solution other than making compromise. This can help satisfy different needs and still target to have outstanding user experience.

In this paper, an analysis of this situation will be stated and in order to resolve it, our design process and a new thinking method will be introduced. It is the evaporating cloud of the theory of constraint (TOC)—a thinking method that commonly used in business management that will be employed to resolve the conflict during the design practice.

The structure of the paper is as below:

First, an analysis of conflict situation in design field will be made and we will have a discussion on why the compromise will reduce the product user experience.

Then we will conduct a survey on different elements of the measurement of user experience. In the discussion, it’s needed to differentiate the various measurement elements based on various products. In this paper, the sample for new thinking method of real project will be based on web-based product, so here we focus on clarifying the elements of the measurement of experience on web-based product. We will make analysis towards different metrics of user experience and find the one most suitable for web-based product.

After that, there will be a brief introduction of the theory of constraint (TOC) will be made and especially one of its thinking process—the evaporating cloud used in this paper to solve design conflict. The Evaporating Cloud (EC) is a logical diagram representing a problem that has no obvious satisfactory solution.

Finally, we will combine the evaporating cloud with the user experience metrics [11, 17] and set a real project to see to what extent it can solve the design conflict [1, 2, 7, 8, 13, 16]. A real project is a statement of this design process and conflict solution.

2 Background

2.1 Conflict Exists in Design Practice

According to definition in dictionary, conflict means an open clash between things, which can be two opposing groups (or individuals); a state of opposition between persons or ideas or interests; an incompatibility of dates or events; a disagreement or argument about something important. Conflict exists on everywhere. There has been a large amount of research concerning the resolution of conflict that occur between individuals or groups of individuals in contexts such as business, jurisprudence, international relations, and so on.

Since design is a problem solving activity, we cannot avoid conflict during the design practice. The complication and diversity of problem will definitely lead to conflict. Also, design activity is usually a cooperation one [9] with different kinds of people, the participants have different background which leads to different perspectives (e.g. different goals, different ways of achieving similar goals, etc), they will occasionally come into conflict concerning some aspect of the design.

2.2 The Compromise is not a Wise Way to Solve Design Conflict

Compromise means a middle way between two extremes in dictionary. It is a doctrine of the mean which means it never meet each side’s needs. To some extent, design process has been restricted considering the money and time cost during some real product development process. These limitation will cause designers choose compromise resolution towards conflict. Sometimes, it is ones who do not figure out a good conflict solution and believe that compromise is a wise way to solve the conflict problem. Sometimes, the decision made during the conflict mainly depends on current situation. When we are in the progress, we rarely think from an integrated point of view, resulting in shallow decision or sometimes consensus by sacrificing user experience, thus causing the final product not in accordance with our previous expectation. Thus, for many situation, the results of product will never meet each side’s expectation with unfriendly user experience.

2.3 Win-Win Solution

Conflict resolution plays a central role in making a satisfactory design and making win-win solution [10] is more better than consensus used for working out an agreement during design conflict resolution. Some authors have made a research on how to solve conflict in design practice like Mark Klein [3, 4, 6] - a research on describes the conflict resolution model and provides examples of its operation from an implemented cooperative design system. From the literature review, few studies have be made on how to solve conflict in product experience design. In this paper, design practice on making win-win solution towards conflict will be introduced.

3 Theoretical Background

3.1 The Evaporating Cloud of the Theory of Constraints

Literature Review on the Theory of Constraints and Its Thinking Processes. The theory of constraints (TOC) [5, 15] has been widely known as a management philosophy coined by Goldratt (1990) that aims to initiate and implement breakthrough improvement through focusing on a constraint that prevents a system from achieving a higher level of performance. Goldratt and Cox (1992) define a constraint as any element or factor that limits the system from doing more of what it was designed to accomplish.

According to Goldratt [14] (1990), in order to deal with constraints, three generic decisions need to be made. (1) Decide what to change; (2) Decide what to change to; (3) Decide how to cause the change. These three provide the framework for what’s called the TOC Thinking Processes, a suite of logic trees that provide a roadmap for change. They guide the user through the decision making process of problem structuring, problem identification, solution building, identification of barriers to be overcome, and implementation of the solution.

The Thinking Processes comprise a suite of five logic diagrams (four trees and a “cloud”) and a set of logic rules. The five logic tools are: current reality tree (CRT), The Evaporating Cloud (EC), future reality tree (FRT), prerequisite tree (PRT), and transition tree (TT). The development of the TOC and accounts of its application have been existed for many years. Rahman (1998) reviews the TOC approach on manufacturing firms. Siha (1999) applies the TOC approach to addressing problems in different types of service organizations. Beyond business firms, Klein and Debruine (1995) and Dettmer (1998) used the TOC thinking processes to identify core problems in public policies. Womack and Flowers (1999) applied the TOC approach to the healthcare system to improve its performance [19].

The Evaporating Cloud. The Evaporating Cloud (EC) [18] - also referred to in the literature as “the cloud”, or as a “conflict resolution diagram” - is a logical diagram representing a problem that has no obvious satisfactory solution. The EC was designed to address conflict or dilemma situations (trade-off situations where there is no acceptable compromise) by diagramming the logic behind the conflict and methodically examining the assumptions behind the logic.

The EC has a set format with five boxes, labelled A, B, C, D, D’, that are usually laid out as follows:

The boxes represent two opposing wants that represent the conflict (D, D’), the needs that each want is trying to satisfy (B, C), and a common goal (A) that both needs are trying to fulfill. The lines or arrows connecting the nodes represent the rationale or causal assumptions that are used to link the nodes. Underlying each of the arrows in the EC [20] is one or more assumptions explaining the conditions under which the relationship between two entities in the cloud is valid. Assumptions underlying arrow C–D’ in Fig. 1 explain why D’ is a necessary condition in order for the need C to be met. In the event that a necessary assumption under arrow C–D’ can be rendered invalid, D’ will no longer be a necessary condition for achieving need C. By removing D’ as a necessary condition for C, the conflict between D and D’ is eliminated.

Fig. 1.
figure 1figure 1

The generic structure of an evaporating cloud diagram

Full size image

In the EC, assumptions are statements about reality that are accepted as true even if the statement is untested. One way to invalidate an assumption is thus to provide evidence that the assumption is not valid, that is, that the entity at the base of the arrow is not actually necessary in order to have the entity at the head of the arrow. When the assumption is valid, another approach is to come up with an action or change in conditions (referred to as an injection) that will make the assumption invalid. When the relation between A–B or A–C is broken, D or D’ is no longer a reasonable action.

The general process for applying an EC to problem solving is described by Cohen (2010) as follows:

  1. (a)

    Identify the type of problem (there are variations in the way the diagrams are constructed for different types of problems.)

  2. (b)

    Write a storyline of this problem in a factual, objective way, even if the problem causes an emotional upset.

  3. (c)

    Build the Cloud.

  4. (d)

    Check the logical statements of the Cloud and make necessary corrections and upgrades.

  5. (e)

    Surface the assumptions behind the logical connections to find the one that is supporting the conflict.

  6. (f)

    Construct your solution and check it for win-win.

Communicate the solution to the people involved in dealing with the problem.

Goldratt claims that each of the logical connections in the EC represent an (often hidden) assumption. One of the most basic fundamentals of logic is that behind any logical connection there is an assumption. The way to break conflict is to break these assumption existing on the logical connections. The end result of this process of analyzing the cloud should be at least one feasible injection that invalidates an assumption and breaks an arrow between any two entities in the cloud (Goldratt 1990).

Some scholars have demonstrated the EC application. Gupta et al. (2011) demonstrated that the evaporating cloud incorporates well-accepted principles of achieving win–win solutions, such as separating the people from the problem, focusing on needs but not on positions, and helping identify the assumptions blocking win–win solutions (Fisher and Ury 1982).

3.2 The Experience Design Target of Web-Based Product

Design nowadays is not only about designing the product itself, but also about dealing with the relationship between user and product. Designers need to demystify and classify the specific design goals of product experience. These measurement on experience can help design better user experience during the process and make wise decision towards conflict. Product experience goals should be set on the first step towards product development, thus leading product progress [12] in the right ways and driving product decisions.

In this paper, the real project we employed is based on web-based product, so here we will focus on clarifying the measurement elements of experience on web-based product. Owing to the rapid development of internet, there will be more products being deployed on the web which boardens the vision for measurement of experience on a large scale.

Literature Review. Researchers have proposed many different dimensions towards experience measurement. Gehrke and Turban (1999) identified five major categories of factors that ought to be considered while designing web sites for business: page loading, content, navigation efficiency, security, and a consumer/marketing focus [21]. These factors only focus on website for business. The most commonly used large-scale metrics are focused on business or technical aspects of a product, and they (or similar variations) are widely used by many organizations to track overall product health. We call these PULSE metrics: Page views, Uptime, Latency, Seven-day active users (i.e. the number of unique users who used the product at least once in the last week), and Earnings. The PULSE has its limitation for use. For the page views measurement, it is suitable for business website but not applicant to backend system .The Microsoft Usability Guidelines (MUG) are providing a comprehensive basis for the heuristic evaluation of Web sites, the Microsoft Usability Guidelines are organized around five major categories: content, ease of use, promotion, made-for-the-medium, and emotion. These categories are expected to cover the range of usability-related aspects of a Web site. The MUG provide a comprehensive range of categories and subcategory, it is a standard web analytics metrics may be too generic to apply to a particular product goal or research question. For some small system, we do not need to make such more measurement. Instead, some key measurement and reduce the experience goals to some specific and clear target could be made and thus leads to swift product development.

The Google HEART METRICS. Google has introduced practical process of HEART framework for user-centered metrics, as well as a process for mapping product goals to metrics. It can help product teams make decisions.

HEART METRICS is created by Google Research based on the shortcomings in PULSE, the framework of HEART is: Happiness, Engagement, Adoption, Retention, and Task success.

Happiness. We use the term “Happiness” to describe metrics that are attitudinal in nature. These relate to subjective aspects of user experience, like satisfaction, visual appeal, likelihood to recommend, and perceived ease of use. Engagement is the user’s level of involvement with a product; in the metrics context, the term is normally used to refer to behavioral proxies such as the frequency, intensity, or depth of interaction over some time period. “Adoption and Retention” metrics can be used to provide stronger insight into counts of the number of unique users in a given time period (e.g. seven-day active users), addressing the problem of distinguishing new users from existing users. “Task Success” category encompasses several traditional behavioral metrics of user experience, such as efficiency (e.g. time to complete a task), effectiveness (e.g. percent of tasks completed), and error rate. The HEART METRICS,simple and clear, has achieved well progress during the google product development. But as the author said in the paper, It is not always appropriate to employ metrics from every category, but referring to the framework helps to make an explicit decision about including or excluding a particular category.

3.3 Our Design Process

  • Research. We will make research on the project background, such as project goals, user need, project resource. After that, competitive analysis will be employed to explore our vision towards this new project.

  • Define Experience goals. When all of the research is completed, the experience goals will come to our design aspect. Our experience goals only focus on two or three goals since it is impossible to focus on too many things at one time based on some research findings.

  • Collect User Needs and Discuss Information Architecture. In this process, we will meet some conflict during the decision-making. So we employed the new thinking method towards this decision-making process- The evaporating cloud from TOC which is used to clarify the conflict and resolve it on the company management.

  • Make Detail Page Design. The design process mainly complies with the experience goals we made before.

From the four steps above, we can finish a project as we expected. Below we employ a real project to discuss how we activate our development progress and apply the evaporating cloud thinking method.

4 Application Evaporating Cloud to Conflict Resolution in Design Process

This real project is a web-based software that aims at making communication with App user, the APP operator can send messages to their end App user through this software.

The real design process is stated as below:

4.1 Research

We will make research on the project background, such as project goals, user need, and project resource. After we collect enough information and make competitive analysis, design target will be made on what problem this software aims to solve.

4.2 Define Product Experience Goals

Combing the research and Google HEART METRICS, we set two objective as targets of this product experience: Happiness and Task Success and each one has its further detail targets as below:

Happiness

  • Simple: this product focus on user action, so we want make the user interface simple to highlight the content.

Task Success

  • Efficiency: user can make switch between business operations effectively and swiftly.

  • Clear: clear scenario enables user to clearly know where he is and where to go.

4.3 Collect User Needs and Discuss Information Architecture

During this process, we use the new method of evaporating cloud to solve our conflict. In order to clarify the application of new method, I only capture part of design process. Let us see the progress below.

On this stage, we need to build the information architecture with the information we collected before and experience target we defined before.

We can see here (Fig. 2 show example), in order to satisfy the target of efficiency, we make design solution—swiftly operation between the interfaces. In order to satisfy the target of clearity, we make design solution—clearly classified navigation structure. There is a conflict between to the two wants—swiftly operation between interface and clearly classified navigation structure. We cannot satisfy both because the first wants mainly means it needs a flat navigation structure which has a conflict with the clearly classified navigation structure. So we can use the EC cloud logic to solve this conflict.

Fig. 2.
figure 2figure 2

The logic of real design thinking

Full size image

For clearly statement, I use number to mark them. They will be Objective, Need1, Need 2, Want 1, Want 2. (Fig. 3 show example).

Fig. 3.
figure 3figure 3

The logic of real design thinking

Full size image

  • Think the logic between want 1 and need 1, is there any other interpretation of wants for need1, has it got want1–1, want 1–2.

  • Likewise, Think the logic between want 2 and need 2, is there any other interpretation of wants for need 2, has it got other wants based on need 2, we can call it—want 2–1, want 2–2.

  • After we check the two, we also need to check the logic between Need1 to Objective and Need 2 to Objective. Does it anything else that can satisfy the objective, we can called it —Need1–1, Need1–2, Need 2–1, Need 2–2, etc.

  • After we check all, we can make a win-win solution to remove conflict between want1 and want 2. In this case, we find that efficiency can also means the flow that conform with user operation and it does not conflict with clearly classified navigation structure. It will be a navigation design that conform to user operation flow as well as classified navigation structure. Thus, it perfectly solved the conflict.

  • Then we will use the three targets and its action wants to direct information architecture design.

From the real example, the core thinking method of evaporating cloud is to break the logic of interpretation between two things and question the link logic in order to find the third way to remove the conflict. That is how we use the evaporating cloud to solve the conflict and make win-win solution. This thinking method teaches us not to think from one-way facet. You need to question the logic between the two reasonable links and make design solution towards core target.

5 Conclusion and Future Direction

The findings obtained in this paper include a new approach thinking method and process in design practice. Also in the project development, many unexpected conflicts cannot be avoided during the progress. We rarely think from an integrated point of view and question the logic of our interpretation, resulting in shallow decision or sometimes consensus by sacrificing user experience. This thinking method which always keep the core target builds a broadly new vision towards our previous thinking one. An expectable product results can be made under such vision.

The impacts of our obtained results are reducing the prejudice towards compromise in design practice other than win-win solution existing on the complicated design practice. The thinking method of evaporating cloud which question the logic of interpretation and make a try to break it in order to remove the conflict and make win-win solution can be used into a wide range of detail design.