DESIGNEARTH 1. INTRODUCTION

Most current design activities are conducted by employees in a company’s design office. However,

open design activities, which gather designers with different skills and backgrounds into a virtual

environment to execute a collaborative design, have begun to attract attention. In his book The Cathedral

and the Bazaar, Eric Raymond called the design activity performed in a closed organization, such as a

company’s design office, the “cathedral model,” whereas he called the design activity performed by

designers in an open environment the “bazaar model” [1]. The bazaar model has achieved remarkable

results in the development of open-source software such as the Linux kernel, the Firefox web browser,

and Apache OpenOffice [2].

Through the deployment of social network services that support the sharing of image and text files,

as well as cloud storage services that support the exchange of large files, the cost of information exchange

over the Internet has drastically decreased. Consequently, examples of the bazaar model have been seen

in which many designers belonging to different organizations attempt collaborative design activities using

Internet services.

In this paper, I refer to the design form in which designers collaborate and execute design activities

across the walls of their organizations as open design.

In open design, it is essential to have tools for information sharing and exchange between

geographically and organizationally distant designers. However, because the tools that are currently used

in open design, such as e-mail, chat, file exchange, and social network services, were not developed

specifically to support design activities, it is difficult to practice open design using only these tools.

In this paper, I examine the requirements of services and tools to support open design via the Internet

and propose a new service and software concept to support open design activities.

2. REQUIREMENTS OF OPEN DESIGN ACTIVITIES

GitHub, well known as a support environment for cooperative software development, provides an

environment for distributing the documents from software development to multiple developers so they

can work in parallel. Although design activities consist of many processes, such as planning, requirements

definition, design, prototyping, and testing, GitHub mainly supports the sharing and exchanging of design

documents (in this case, software code) in the prototyping and testing stages.

Discussion and information sharing to clarify a design goal and to manage requirements to reach the

goal are also important in the collaborative development of software, but these activities are conducted

using e-mail, instant messaging, or social network services, outside of GitHub. Task management services

also exist for progress management, as do various bug tracking systems for bug management.

Additionally open design activities for projects other than software do not have core tools or services such

as GitHub, open design practitioners are looking for useful open design environments such as cloud

storage services for information sharing.

While requirement definitions and product definitions are main stream of design activity, there are

miscellaneous information necessary to exchange among design team such as vague ideas, indirect

references, conversation related to task and schedule managements, many words that encourage

discussion and consensus building.

FIGURE 1: MAIN AND MISCELLANEOUS DESIGN FLOWS

In constructing an environment for open design activities, it is necessary to consider natures of design

processes. Making designs are iterative processes characterized by trial and error. It is thus difficult to

record design processes by descriptive methods that assume sequential progress, such as flow charts.

Additionally, the design information generated as work progresses is repeatedly corrected and

overwritten, and the amount of information gradually increases and matures. Therefore, services and tools

to support open design activities must be compatible with these specific natures of design processes.

A software user interface (UI) with a predetermined sequence of screen transitions is not suitable for

recording the design information generated from trial and error. For example, a designer would need to

reconstruct the information generated from the emergent thinking process into the input order required,

which can greatly hinder concentration on the design work itself. A UI is thus needed to record design

information regardless of its kind or order of generation. A timeline UI that stores information in order of

generation is suitable for recording a previously unexpected thought process. If all the generated design

information is recorded as a series along a timeline, incremental information could be recorded without

overwriting the data, and old and new data would become obvious. Additionally, a timeline UI has good

affinity with free-form comment recording, so this feature could easily become a place of communication

between designers.

Main stream of design flow

Requirement definitions

↓

Design definitions

Ideas Ideas

Task control Schedule control..

Although multiple timeline information sharing services and tools with free-form commenting and

chronological file preservation exist, these platforms are not intended to support open design activities. It

is difficult to establish a design process, which is a collection of rational decision-making processes to

document the structure of artifacts, that can be realized on a free-form timeline UI. Therefore, specialized

services and tools that satisfy the requirements mentioned above are required to support an open design.

Services and tools that support design activities must record design-specific processes such as goal

setting, requirements definition, design, and verification, and the recording functions must consider the

properties of the design information generated from these processes. Therefore, I propose a timeline UI

for recording design information classified by the design work elements of the systematic

Requirement-Definition-Confirmation (RDC) model [4][5]. The resulting service could support an open

design activity that has both flexibility and a form suitable for design information.

3. A SUGGESTED SOLUTION

The systematic RDC model roughly classifies the design process into a concept design phase and a

detailed design phase and identifies the design information created during each phase. The concept design

phase consists of external requirements recognition, concept design, and confirmation of suppositions

from both processes. The detailed design phase consists of internal requirements definition, detailed

design, and confirmation work for suppositions from both processes (Fig. 2).

FIGURE 2: DESIGN INFORMATION IN THE SYSTEMATIC RDC MODEL. (Arrows indicate the

direction of dependencies between design information.)

Consider the systematic RDC model for the following case example: A customer at an architectural

Design Phase

Concept phase

Confirmation Confirmation

External requirement

Concept definition

Confirmation Confirmation

Internal requirement

Design definition

design office wants a house that will not freeze during winter in a cold region while using as little external

power as possible.

The designer of the architectural design office first must clarify the client’s requirements, including

the layout and size of the house, the budget, the construction site, and the target power consumption. The

changes of outside air temperature at the construction site must also be investigated. Because these

requirements arise from outside the design activity, they are called external requirements in the systematic

RDC model. To recognize the external requirements, customer interviews and construction site surveys

are necessary. Confirmation of external requirements information is also an important process element in

the initial stage of the design process (Fig. 3).

FIGURE 3: EXTERNAL REQUIREMENTS AND CONFIRMATION

After the external requirements are recognized, design concepts that satisfy these requirements are

intuitively generated and evaluated. For example, the power consumption requirement could lead to plans

for the use of solar power or geothermal heat. External information would then be collected for each plan,

such as the annual sunshine at the construction site for solar power and the changes in underground

temperature at the construction site for geothermal heat. The design process thus contains many iterations,

and its modeling also progresses iteratively. An initial heat balance calculation and construction cost

assessment cost are conducted to determine which of the planned concepts is superior (Fig. 4).

Design objective - Design a house

not to be frozen in winter in cold areas without using external power as much as possible.

Concept phase

Confirmation - Customer interviews - Construction site surveys

External requirements - House layout and size - Budget - Construction site - Power consumption

target - Changes in outside air

temperature at the construction site

FIGURE 4: CONCEPTS AND CONFIRMATIONS

If this evaluation at the concept design stage determines that a concept is superior, the concept

proceeds to the detailed design stage. At this stage, the target values of various design characteristics are

set by the designer. For example, assuming that the concept of constructing a basement and circulating

the air in the building is selected, the heat exchange coefficient between the basement space and the

underground wall, the heat exchange coefficient between the upper floor space and the outer wall, the

assumed solar radiation heat, the required air circulation, and other characteristics are determined as

design requirements. Because these requirements are determined by the designer, they are called internal

requirements. In calculating the internal requirements values, verification using a more accurate

numerical model may be necessary.

Once these internal requirements are determined, design parameters such as the heat exchanging

structure on the ground floor wall, the insulation and radiant heat adjustment structure on the upper floor

wall, the fan installation position for air circulation, and the fan size are determined. Ultimately, an

integrated system is evaluated using numerical calculation models and actual tests (Fig. 5).

The systematic RDC model thus breaks down the design process into external requirements

recognition, conceptual design definition, internal requirements recognition, and detailed design

definition phases. The model describes the work performed in each phase, the resultant design

information, and the interrelations within this information.

The systematic RDC model also requires time and labor to input data, which was previously

mentioned as an issue of existing design process recording methods. Although the RDC model is an

effective method for organizing and describing completed design processes, a method of dynamically

applying the model to in-progress design work has not been proposed. Appropriately designed software is

necessary to record dynamically the design process and its resulting design information, which consists of

Concept phase

Confirmation - Customer interviews - Construction site surveys

External requirements - House layout and size - Budget - Construction site - Power consumption target - Changes in outside air temperature at the

construction site - Annual sunshine at the construction site - Changes in underground temperature at the

construction site

Concepts - Use solar power - Use geothermal heat

Confirmation - Heat balance calculation - Assessment of construction

cost

many elements with complicated relationships. Therefore, this paper describes how the UI of software for

dynamically recording design information should function based on the systematic RDC model. The

paper also reports on the development of software and reports the results of its implementation.

FIGURE 5: CONCEPTS AND CONFIRMATIONS

The software was designed to adapt to the following dynamic features of new design processes and

record the resulting design information: 1. Certain work may be caused by the results of the previous

work and can be unpredictable in advance. 2. To search for a better design solution, the process branches

temporarily and creates multiple design solutions from which the optimal solution is selected. 3. A

process that creates design information may be broken down into several steps separated in time. 4. Work

iteration (or process backtracking) occurs in the process, and the created design information may be

deleted or edited.

Hundreds of design information items can be created during one design process, even in the design of

relatively simple products. Furthermore, the creation order of these items is not arranged in a one-way

flow chart from upstream to downstream, but instead becomes a complicated network structure that grows

Concept phase

Confirmation - Customer interviews - Construction site surveys

External requirements - House layout and size - Budget - Construction site - Targeted power consumption - Changes of outside air temperature at

the construction site - Annual sunshine at the construction site - Changes in underground temperature at

the construction site

Confirmation - Heat balance calculation

- Assessment of construction cost

Concepts - Use solar power - Use geothermal heat

Design phase

Confirmation - Accurate numerical calculation model

Internal requirements - Heat exchange coefficient between the

basement space and the underground wall

- Heat exchange coefficient between the upper floor space and the outer wall

- Assumed solar radiation heat - Required air circulation

Designs - Heat exchanging structure

on the ground floor wall - Insulation and radiant

heat adjustment structure on the upper floor wall

- Fan installation position for air circulation

- Fan size

Confirmation - Numerical calculation

models and actual tests

with repeated branching and backtracking, like nerve cells searching for the best linkages. Attempting to

describe this process dynamically in a flow chart requires the frequent replacement of element blocks and

the rewriting of dependency relationships, which consumes many man-hours. When performing this

description work, a designer must do the actual design while creating and editing the design process flow

chart in parallel, thus losing focus on the design work itself. Additionally, if the designer does not feel

that the process description is profitable, he will not be motivated to describe the process while designing.

Therefore, the following nonfunctional requirements are important in the UI design: 1. The design

description process does not interfere with the actual design work, and 2. The software realizes the

benefits of recording the design process.

4. A SUGGESTED SOFTWARE UI

To satisfy the above functional and nonfunctional requirements, I suggest a UI that records items of

design information in order of creation but does not capture their relationships. Instead of recording

indiscriminately, the UI captures the type of work that created the design information and records it on

two timelines with time differences according to the work classification of the systematic RDC model

(Fig. 6).

FIGURE 6: DESIGN INFORMATION POSTED ON THE TIMELINE

Because of the time lag between the occurrence of confirmation work and the resulting information,

these items can be entered separately and at different times.

Design information categorized by the work elements of the systematic RDC model in Fig. 1 have

dependency relationships according to the systematic design thinking process defined by the model. By

displaying previously recorded design information that may be dependent on new information being

entered, the UI encourages consideration of these relationships. For example, when a designer enters

design information for concept definition work, the UI displays a list of external requirements from

previously recorded external requirements recognition work, allowing the designer to record the concept

design information while considering the necessary external requirements information. This dependency

Timeline Time

External requirement

Concept

Internal requirement

Detail design

relationship can be updated when a new external request is recorded. Dependency relationships between

recorded concept definitions and external requirements can thus be added even if the input order is

reversed (Fig. 7).

FIGURE 7: DEPENDENCIES OF A CONCEPT

Furthermore, because confirmation work is performed on recorded design information, the menu for

recording confirmation information specifies the design information to be confirmed. Because the

information created from confirmation work is highly dependent on the design information to be

confirmed, a confirmation is displayed beside the confirmed design information regardless of the input

date and time (Fig. 8).

FIGURE 8: DEPENDENCIES OF CONFIRMATIONS

Design information recorded on the timeline can be commented on and edited so that the information

can be gradually matured by revisions. Additionally, any number of pieces of information of the same

classification can be recorded, allowing information for multiple design choices in the middle of the work

to be stored.

Detailed designs are created from concept definition information recorded in timelines. With an

intuitive UI, each detail design can thus be made to depend on one or more concept definitions. When

Timeline

External requirement1

External requirement2

External requirement3

Concept

Order of input

External requirement

Concept

Confirmation

Confirmation

Timeline

multiple concepts are proposed, the concepts being studied in detail can be identified by concepts

advanced to the detailed design phase (Fig. 9).

FIGURE 9: A DETAIL DESIGN CREATED FROM A CONCEPT

Based on the above principles, software was developed that gradually classifies and

records design information with their dependencies for design information storage and sharing.

In the software, simplified terms, such as ‘need,’ ‘idea,’ ‘target,’ and ‘design,’ are used instead of the

terms ‘external requirement,’ ‘concept,’ ‘internal requirement,’ and ‘detail design’.

As shown in Fig. 10, when posting an idea (concept) on the timeline, the user is asked to check a box

for a related need (external requirement) and target (internal requirement) if they have been pre-posted

before. By repeating this posting work, interrelations between posts are recorded.

FIGURE 10: POSTING A CONCEPT ON THE TIMELINE

5. EXPERIMENT AND RESULTS

The design and implementation of the software has been executed since the end of 2017. The first

usable version was released on the web for testing in mid-2018 (https://designearth.com). Since the first

Timeline Concept

Internal requirement

Detail design

Confirmation

release, our development team has used this software for the development and testing of the software

itself.

In this experiment, a designer and a software engineer at remote places used the software for the

concept design development by sharing and discussing the external requirements and concepts of the

software. We decided to store and manage versions of the code in GitHub, because GitHub is the de facto

tool for software development, and we understood that software development processes do not have a

detail design phase to define internal requirements or design parameters separately from the coding

process. Fig. 11 shows the timeline of a concept design phase. Posts are interlinked with each other

depending on the type of design information in accordance with the definition of the systematic RDC

model.

Between the end of 2017 and middle of 2018 before the release of the first usable version, the

development team used a commercially available chat tool for the non-systematic discussion and

exchange of design decisions and information. After the first version of our developed software was

available, all information exchanges have been on the new software, except for one face-to-face meeting

at each development phase in order to complement the inefficiency of text-based communications.

FIGURE 11: PROJECT TIMELINE OF A PHASE OF THE SOFTWARE DEVELOPMENT

Table 1 shows the items of each development phase, the estimated workloads before the start of

coding, and the actual workloads. Graph 1 shows the planned work days based on the pre-discussed

design definitions on the existing commercially available chat tool (phases 1–3) and on the newly

developed software (phases 4–6). This comparison shows the dramatic effect of newly developed

software for preventing a surplus of working days.

TABLE 1: DEVELOPMENT ITEM AND WORKLOAD

GRAPH 1: PLANNED AND SURPLUS WORKDAYS

We believe that the systematic and piecewise information sharing and discussion provided by this

software facilitates a mutual understanding between designer and engineer, improves the accuracy of

thinking processes and exchanged information, and as a result, prevents reworks.

6. CONCLUSION

We confirmed that the majority of communication among designers in upstream design can take place on software implementing the systematic RDC model, and its method and design definitions can improve design quality in a systematic way.

7. FUTURE STUDIES

Currently, the developed software is being used to conduct multiple product development projects.

We will continue to research and improve the software functions through these experiments in order to

support designers in open design activities.

REFERENCES

[1]Raymond, E.S.,2001," The Cathedral and the Bazaar", Oreilly & Associates Inc.

[2] https://en.wikipedia.org/wiki/Open-source_software

_development

[3.] Https://github.com

[4] Nakazawa,T., and Masuda, H., 2006 " Requirement-Definition-Confirmation Modeling approach

for identifying uncertainties in product design processes ", ASME 2006 International Design

Engineering Technical Conferences & Computers and Information in Engineering Conference.

[5] Nakazawa,T., and Masuda, H., 2011 "Design Process Planning for Design Quality Control and

Research on One Method for Verification and Request Development", Journal of the Japanese Society

for Quality Control 41 (2), pp.