Modeling Language Spotlight
Design Build Use
March 16, 1997


Like the other models of the MG Taylor Modeling Language, the Design Build Use Model is protected by copyright. You can use it only by meeting these four conditions.

The Traditional Model
The most common approach to designing, building or using most anything is linear. In its extreme incarnations, not only is there no feedback between stages, but the individuals involved in each stage are different as well and do not communicate across the boundaries between stages. In construction there are cases where the architect creates the plans and hands them off to the builder who executes the plans, making modifications on his own. When the builder has finished erecting the structure, the user or occupant takes over. Sometimes they never meet.

Actually the user--as a user--plays no role of any significance in the traditional model at all. Even though the future occupant may engage with the architect and the builder during design and construction, he or she is engaging not as a user (the space is not finished, so how could it be in use?), but as a co-designer. This is a task for which most users are ill-suited. Once the building is occupied, the only viable means for feedback to the process usually come wrapped in lawsuits. Because of the cost and time involved, the user is stuck with all the things that don't work--that couldn't possibly have been foreseen, but which cannot not be modified. The user now begins a gut-wrenching lifelong process of accomplishing the work of the enterprise, while fighting the space that her enterprise inhabits!

The traditional approach generates static, non-living artifacts which can only be torn down in response to a wide range of demands upon their flexibility.

Life becomes an unending compromise.

The Design/Build Method
Over the past several decades the construction industry has moved to a more feedback-driven model. Here the architect and builder work as a team from the early stages of design through the completion of the structure. The user is involved as well, but again, not as a true user and occupant but as an unskilled co-designer. All too often the user's ignorance of the technical issues renders him something of a nuisance to be tolerated rather than a collaborator to be engaged with.

There are certainly a number of exceptions to this bleak assessment of the current situation, however a casual glance at the majority of the cities that we occupy only confirms that whatever process is being employed is inadequate to the challenge. We live and work in graceless, unforgiving, unyielding structures that only seem to frustrate our ambitions and attenuate our visions.

Adding All of the Feedback Loops
The model below illustrates the requisite relationship between design, build and use. The designer and the design process is connected to both the user and the builder. The builder and the building process is connected to the user and designer. The user and the processes employed by the user in the conduct of the business of the enterprise is connected to the designer and builder. These interconnecting feedback loops imply that the designer, builder and user remain connected throughout the lifespan of the enterprise. It also requires that the products of this collaboration be stable enough to provide day-to-day integrity and flexible enough to allow radical, rapid redesign to fit the changing needs of the user over time. It means that the environment is never "finished" and that it is constantly able to provide a "just enough, just in time" solution. Things that are "finished" in our emerging world are dead.

It's important to reemphasize that not only must the three different entities communicate and collaborate, but their processes must dovetail as well. That means that the design, build and using processes should not inhibit each other or create confusion. For the user it indicates a mental shift in understanding that a design and build capability occupy a permanent part of the larger web of the enterprise. It also changes the way that equity, debt and cash flow are treated within the value web between the builder, designer and user.

glyph info Element Description
Design Create sketches, models, plans, schedules, and budgets to convey a sense of the scope of the project in many different dimensions. This is not done merely at the beginning of the project, but as a sort of continuous process throughout the life of the building. The design takes into account past and present work process requirements, and the uncertainty associated with the future as well.
Build There must be a process for rapid execution of the design that allows frequent adjustments to the realities of a build-out and the changing perceptions of the user as the design unfolds. The process and the product (space) must provide for this speed throughout the occupancy so that the enterprise of users does not have to waste time and talent in reconfiguring itself to meet changing conditions.
Use As the environment is used, it will change the processes that take place within it. These changes, in addition to events in the external environment will drive a demand for the work space to adjust its function, and to do so rapidly. The design and build capacities must always be readily at hand.

Management Center Applications
It should be obvious that a Management Center® environment must follow this model in a strict fashion. The environment is often radically redesigned within a matter of minutes--walls, workstations, tools and equipment all must move to accommodate changes in the process. One area that supported clusters of teams one minute will have to support a large group session of a hundred or more in theater seating the next. And yet the environment must not have a look of disarray about it, for this will adversely affect the processes taking place within it. This rapid flexibility and integrity of the space is a primary feature that allows the users of Management Center environments to radically compress the time required to invent and deliver new enterprises and new products.

DesignShop® Applications
Design Build Use is also a powerful model to use when designing an event, even though we frequently employ Scan Focus Act as the standard template. When using Scan Focus Act, it's common to assign the stages to successive time periods of the event: Scan is day one, Focus day two and Act day three. Design Build Use calls for a slightly different, non-linear approach. Of course, day one could be Design; day two Build and day three Use. But this misses the point, and also destroys the feedback loops.

Upon the completion of any module of work during a DesignShop event, the participants and KreW must be able to engage with the product as designers, builders and users--not as designers only. Successive modules iterate the design, the building and the use. This means that every activity must have some output and that the output of one activity is designed to feed into the activities to come.

Other, Non-Architectural Applications
Any type of work that calls for rapid prototyping, production, evaluation and iteration should employ this model. Remember to not separate the designer, builder and user from each other or from direct feedback of how the work of one affects the others.

copyright © 1997, MG Taylor Corporation. All rights reserved
copyrights, terms and conditions


© MG Taylor Corporation, 1995 - 2002

iteration 3.5