Learn about how prototypes function in the design process as learning tools. The most effective prototypes provide critical information to support decision-making in the design process.
- [Instructor] The design process is almost always iterative. We test an idea with a prototype, assess the results, and repeat. In this video, I'll be talking through the benefits of this approach in more detail, specifically focusing on why it is so important for architectural problems to ensure prototypes are effective. Architecture is a wicked problem in that we cannot reliably compute a perfectly optimal solution for most scenarios. This is a good thing. It ensures some job security for designers.
It is also fundamental to architecture or any scenario with a similar wide range of design requirements. These design requirements may come from clients, end users, building codes, or other stakeholders, and they are typically poorly defined. A first step is to clarify, prioritize, and hopefully quantify those requirements. When prototyping, requirements are meaningful only if you can determine whether they have been met. When requirements are clear, they're incredibly useful, helping the iterative process converge towards a solution.
At the other end of the prototype are the inputs or parameters, the degrees of freedom the designer has to work within. It is often assumed, when developing a parametric prototype, that more degrees of freedom are better. But, in most cases, the opposite is true. As the number pf inputs increases, the flexibility increases, but as does the complexity, or to be more accurate, the dimensionality of the solution space, which must be explored through the prototyping process. So what is the solution space? Any solution is some combination of inputs whose appropriateness or value is measured by the degree to which it meets the designer requirements.
As a variety of solutions are prototyped, the results can be visualized as a multidimensional solution space or landscape. This metaphor in visualization is useful because it allows a perceptive designer to identify patterns, peaks, and valleys to focus on with further prototyping. The goal for any individual prototype is a better understanding of the designer requirements or a better understanding of how different inputs interact to meet those requirements. But typically, many prototypes are needed to fully understand a complex problem.
The power of parametric software, like Grasshopper, is its ability to dramatically reduce the effort required to generate many prototypes quickly and fully explore solution space. Before exploring the solution space, however, it is usually necessary to clarify the requirements that will define the space with stakeholders by showing them simple prototypes that confirm or modify how those requirements are defined and quantified. Once requirements are clear, prototypes can then be used to test the interactions between the input parameters in the appropriateness of various configurations to those designer requirements.
For example, interaction between car size, other design inputs, and the overall safety of the car can be quite complex. So how do we quantify subjective requirements? One easy way to produce a range of alternatives as images or physical prototypes, and let a client or stakeholder rank or value each. This process confirms or modifies the understanding of the requirements. It helps to quantify the prototype's performance against those requirements.
In addition to quantifying the range of prototype performance along a single requirement, it's also important to use a similar process of reviewing prototypes with a client or stakeholder to weigh or prioritize requirements against one another. Typically, there are trade-offs. And as you optimize for one requirement, you sacrifice performance against another requirement. By prioritizing and assigning weight to different requirements, you can compare performance against different requirements and develop a single fitness score for our prototypes that incorporate all requirements.
Once the requirements are quantified and prioritized, prototype fitness can be mapped and visualized as a fitness landscape. The dimensionality of the landscape matches the number of inputs plus the fitness value. For example, if you're prototyping with a single input parameter, your solution landscape is a 2D space, in xy Cartesian grid, typically with the input as the x-axis. In the fitness, the degree with which the prototype meets the requirements along the y-axis. As the number of inputs increases, the dimensionality of the solution landscape increases.
If you're using two inputs for testing, the solution will propagate into a 3D space and generate a landscape that looks more like a surface. The x- and y-axis are the inputs, and the z-axis is the fitness. So peaks and valleys on that surface represent fitness extremes or optimal prototype configurations. This solution landscape exists only as a product of measuring the prototype's fitness, as the two design inputs vary. The landscape is not generated by an existing function and can be arbitrarily complex in detail, depending on the interactions between those inputs.
Exploring a new problem typically means building a new solution landscape from scratch, though similar problems will tend to generate similar landscapes. This is the most common way fitness landscapes are visualized because it is easy for people to see and interpret. As the number of inputs increases past two, the dimensionality increases, and the complete landscape becomes harder to represent. In these cases, it is common to visualize two input parameters at a time, which is basically like cutting a three-dimensional section through a higher dimensional solution space.
Architectural designers use prototypes as learning tools to understand the wicked problems typical of architecture. We prototype to clarify requirements and to map solution spaces. Ideally, requirements can be quantified and weighed so they can be combined into a single fitness value to use, to compare the suitability of prototypes. Though many design inputs provide flexibility, the most effective prototypes have few inputs, ideally one or two, so they can generate a solution space that can visualized and easily explored.
- Useful prototype examples
- Modifying an existing prototype
- Adding modularity with clusters
- Planning outputs and inputs
- Planning data flow
- Finding and wiring components
- Using and sharing your prototype