The term design can mean many things to many people, so it’s important to understand what the design process actually is, what it entails and its intended purpose and objectives.
Functional design has a purpose and aims to solve a problem. The design that it delivers is a solution to that problem.
Aesthetic design on the other hand exists for its own purpose alone, and aims to simply produce something that looks nice, it creates art.
With functional design, we are addressing a problem and are arriving at a solution, so before we start putting pen to paper and start drawing up our designs, we need to do some critical preliminary work.
Before we even begin thinking of a design, we first need a design brief, which will determine what is designed.
The Design Brief
A design brief is defined by the project outcomes, and provides the designers with critical information they require to produce a design that achieves the requirements of the project.
As such, a design brief provides designers with the following information:
- Objectives and outcomes – what is the design meant to achieve?
These goals, objectives, intended outcomes and benefits are always detailed in the project proposal. - Budget – how much money is available?
The budget will restrict the size and scope of the project, and needs to be taken into account when embarking on producing a design. - Resources – what do we have to work with?
This can include both materials that are available and as such will not impact the budget, and ‘human resources’, people that can help with the design and construction process, such as volunteers, support personnel, advisors and subject matter experts. - Timelines – when each stage of the project must be delivered and when final completion is expected.
- Design Guidelines – how should the design look and feel, what things must be included, what things must be avoided, what restrictions exist?
Any additional information which helps define the framework or boundaries which the designer must work within.
The design brief essentially defines the project’s requirements and constraints, and enables the designer to focus on a solution that fits within the scope and framework of the project.
NOTE – the design brief, and all additional design information which will be discussed here, must be documented as permanent record to guide the project throughout the project life cycle and keep it on track until the intended outcomes are successfully delivered!
If we take a look at the information within the project proposal, we find the following objectives, which will define our design brief:
Project Objectives
- Increase food security for the local community.
- Demonstrate the possibilities for food production in Darebin.
- Trial possible species for growth in urban Melbourne.
- Demonstrate local edible and useful indigenous plants.
- Demonstrate less common edible and useful plants, including those used by local ethnic groups, perennial and heirloom varieties
- Demonstrate sustainable and chemical-free urban food production
- Increase local community cohesion and social inclusion
- Address global warming through carbon sequestration and reducing carbon pollution
We also find the additional information in the ‘Project Timeline 2013 and beyond’ section:
”…Community gardening workshops will contribute to the development of the food forest and community volunteers will be responsible for general weeding and maintenance of the site.”
In summary, the design brief informs the designer what we need to deliver, when, and with what resources.
With this information, it is the responsibility of the designer to produce a design strategy which will define how this will be achieved.
The Design Strategy
Since functional designs deliver a solution to a problem, and there are often many ways to solve a single problem, it is quite likely that many design solutions can work to deliver a project’s outcomes.
A design strategy is a plan or scheme which defines how each project objective will be delivered through each elements included in the design, as well as why this particular strategy is being chosen to deliver the project outcomes. This is the ‘big picture’ plan with a detailed explanation of how all the aspects of the design will work together as a unified and cohesive whole to deliver the benefits, objectives and outcomes in the project proposal.
For example, if a project’s objectives were to reskill and provide alternative employment to disadvantaged members of the community while addressing local food security issues, we could devise a strategy where we could hypothetically set up a community market garden in a lower socio-economic area, where we could employ intensive vegetable garden beds for mass production to allow for enough food production for use by the participants in the program, and generate enough surplus for them to sell.
Infrastructure and specifically designed areas could be included which would facilitate the running of reskilling workshops, and the garden could be designed in ways that make it more amenable to being used as an education facility by providing many examples of various gardening techniques and systems to offer demonstrations of different approaches to gardening that the community can gain practical first hand experience on.
The location could also sell plants to the community, and as such might include a seed saving program or community seed bank, and in such cases the site design will need to also include seedling raising and plant propagation facilities, such as a greenhouse and shade house, along with a cool, dry area where seeds can be stored.
This is just a brief example, and a real-life design strategy will be much more detailed and will explain the overall strategy of how the project as a whole will work, what it will include to achieve these ends, and how these aspects of the project will actually deliver the outcomes. In effect, a design strategy is a detailed, well-thought strategy which will drive the design.
The design strategy is only the ‘big picture’ plan though, it doesn’t deal with the fine details. To step down to the ‘nuts and bolts’ level, a designer will also need to produce a design rationale.
The Design Rationale
A rationale is defined as a reasoned exposition, one that defines the fundamental reasons for a course of action, and a design rationale is a detailed explanation, where the designer explains:
- why certain design elements (things in the design) have been put into the design
- why these design elements were located where they are in the design as opposed to somewhere else
- what function and purpose the design elements achieve in the design to contribute to delivering the objectives and outcomes of the project
Basically, there needs to a a reason for why everything in the design is there, and an explanation of what it does to delver the project outcomes.
For example, in a project looking to deliver the objective of “Demonstrating the possibilities for food production”, one strategy might involve community education based around a demonstration site, and if one of the areas of education was fruit tree maintenance, then different types of trees in various pruning styles and configurations would be included, but it would all have to be explained. The design rationale would explain which types of trees were selected and why, which way each tree will be trained and pruned, and what specific pruning style each is meant to demonstrate, the reason for their position in the site, the selected distance apart from other new or existing trees and other objects located on the site,
The design rationale does not only include explanations of choices made to deliver the design strategy, it also includes technical explanations, such as the requirements of trees and plants and the reason they are situated where they are.
For example, the design rationale includes reasons such as “…the citrus trees were situated on the opposite side of the site, even though the location was less than ideal in respect to north sun in winter, it was necessary to avoid having the citrus trees, which are naturally shallow rooted, from being outcompeted by the line of eucalyptus trees which have aggressive invasive root systems…” This is just a made-up example to illustrate the type of technical information included in design rationale documents, so if anyone looking at a design can understand the designer’s reasoning.
If no reasons are provided by a designer for what they have put where, other than “it looks good”, and there is no underlying design strategy as an overall plan for how the design works to deliver the stated outcomes, then they are just creating aesthetic design, or art, which on account of not having a rationale, cannot fulfil project outcomes.
To sum it all up so far, the design brief ensures that everyone is working towards the same goal and designing the project that was requested, the design strategy addresses the problem that the project is solving and provides a high level plan to solve them, and the design rationale explains the reasons for how the design is put together and what it is put together from. Once we have all of these steps completed, then we can put pen to paper and start drawing up the design schematic or layout. All these together constitute the overall design process.
Design Production
A schematic is a visual representation of the design which is produced to show what the design will look like. This can only happen after the previous steps of producing a design strategy and design rationale have been carried out, because a designer cannot have any idea of what the design will look like if they haven’t first worked out what the design will do, how it will work, and why it will be put together the way it will be.
It’s a common misconception that drawing the pictures, diagrams, maps, layouts and so on is the first stage of design, but it in fact is the last!
Another misconception is that once the design has been drawn up, and the project has been built, that is the end of the design process, but that is far from the truth. How do you know if the design worked? You have to go back and review it…
Design Review
With any design, it’s important after the design is constructed, to go back and review the project that is delivered to determine if the design was successful.
There are important questions that we need to be able to answer, such as:
- Did the design achieve the intended process outcomes?
- Did any shortcomings of the design make themselves apparent after the project was completed? Six months later? Two years later?
The design review process allows us to identify where the design fell short, went wrong, or failed outright. The results of the review process are gathered and used for the redesign – a chance to refine the design by making design changes, then reviewing the outcomes and if necessary, redesigning the project as many times as is necessary till the design delivers the projects intended outcomes.
NOTE: The review-redesign-review cycle is a critical process where all the learning in the project happens.
If we never review our designs, and never redesign the shortcomings, we will never improve the quality of our designs, and will continue to churn out mediocre quality designs for as long as we are designing. Lack of time is no excuse, for mediocrity and a failure to learn is inexcusable. There’s an old saying from the business world, “If you’re not making mistakes, you’re not learning”. Be prepared to make mistakes, acknowledge them, see them as learning opportunities, and be ready to learn and improve!
So, in summary, before we head for the sketch pad or design software to draw up our design, we need to:
- Understand what we’ve been asked to design as detailed in the design brief
- Formulate a design strategy to deliver the ‘big picture’ solution
- Work out the minutiae and provide valid, sound reasoning for our choices in the design rationale
With all this information documented to accompany the visual representation of the design which shows what the design will look like, we’re ready for business.
This covers the theory of what the design process involves, in the next article we’ll look at the practical aspects of design process for the All Nations Food Forest project.
Read the final article on this project here – All Nations Food Forest – A Project Not Realized