Why Design Process, and What Makes it Good? 

        Engineering design involves a team which needs to complete a series of tasks efficiently. To achieve this objective, a guideline is needed. The guideline, which tailors to a wide range of design areas, should organize the fundamental design activities in a sequential and systematic manner, thus designers are able to have an overall picture in mind. Without losing any generality, it should also be detailed enough so the designers can follow every step easily. 

 

My process Vs. French's Model

        It is easy to notice that my process bears some resemblances to French's model. For example, both include considerations to stakeholders. Since the ultimate goal of designing a product is to improve their lives, we have to truly understand their needs, and try to prioritize them. Moreover, both regard "Feedback" as an essential element in design process, since it corrects our mistakes in an early stage, helps make sound decisions, and can even improve team dynamics. 

        Meanwhile, there are some striking differences. First, my process seems to be cyclic rather than linear. It doesn't mean we get stuck in an infinite loop. Instead, it indicates even our design is finalized, it is still necessary to return to the starting point and ask ourselves whether our design addresses the stakeholders' needs or not. If the answer is no, we still have chance to refine it until the answer becomes yes. In addition, the French's model only incorporates "Feedback" into three stages but mine includes all. The reason is "Feedback" in my definition, has an additional meaning - applying judgment. After each step in the design process, we should ask ourselves or other team members a few questions to ensure we are on the right track, then use our judgment to answer them. 

 

Decomposition of Each Step

1. Understand Potential Stakeholders 

        To produce a good design, it is important to know what stakeholders actually need. This can be done in two ways: 

        The first way I would like to call it "problem-centric". Namely, we try to find a problem which causes "widespread" concern. Then, identify the stakeholders involved in this problem and collect their opinions. From their opinions, try to extract their needs, therefore we will know their relationships and hence have a rough idea about which stakeholder is regarded as primary. 

        The other way is called "community-centric". Namely, we select a community which can be composed of a group of stakeholders interacting together, or a person with his/her surrounding environment, to name a few. Instead of focusing on problems, we try to (thoroughly) understand how the community operates, its shared values and needs. 

        Both approaches work fine. Notice the first one can be used when the problem is in a small-scale and only affects our private, daily lives; whereas using the second approach is better when we want to make something accessible to public (such as redesign infrastructures, user interface...etc.)

 

2. Identify the Problem

        Based on the stakeholders' needs, we may formally choose a problem. Once decide, we need to answer the following questions:

1. Is the problem too broad, or too trivial?

        Too broad means the problem also consists of many sub-problems, whereas too trivial means the solution based on this problem may not have practical use, or generates new problems. 

2. Is the problem solvable? 

        Solvability is measured by whether a team can be equipped with the knowledge required to solve this problem within time constraint. 

3. Given the problem, is it possible to come up with divergent solutions?

        Try to brainstorm some solutions within a short time. Notice they have to be completely different. 

If the answers to those questions are "No", we may pay more attention on changing the wording, re-scoping, or finding a new problem. 

 

Relevant application is:

 

3. Reframe the Problem 

        Once the problem is framed in the form of Design Brief, or Request For Proposal, we should ensure that:

1. There should be one focused problem, rather than many;

2. The writing in Design Brief, or RFP should be clear to readers;

3. Criteria can reflect on the product's performance;

4. Constraints do not limit the diversity of solutions.

 

Relevant application is:  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5. Test and Select the Best Solution 

        In this phase, our primary goal is to select the best solution for future development. To prepare for this, we need to make our selection process credible. 

        First, we should revisit the criteria and constraints in the problem statement. For criteria, merge the ones having similar meanings. Prioritize them by utilizing Pairwise Comparison Matrix, and assign a weight for each. For constraints, make sure they draw a "bottom-line" clearly, and none of them is redundant. 

        Next, use simple tools such as Borda Count to get a rough idea about which design is better. Then, try Pugh Chart with weightings as an aid to determine the best design. Notice that we cannot make final decisions by Pugh Chart, but it does provide a good indication on which design is superior, if used properly. 

 

Relevant application is: 

 

 

6. Make Detailed Design Decision 

        Several aspects should be considered to make the selected design high fidelity. These includes but not limited to: material for each component, dimensions and cost estimations. Decisions can be made by consulting relevant handbooks, codes and standards, and other Internet resources. 

 

Relevant applications are: 

 

7. Refine the Solution

        The best way to see our design's performance is to make prototypes, which range from simple sketches to high-fidelity physical models. Simple sketches or models made by handy materials are considered as low-fidelity. This type of prototype conveys basic ideas about our designs, allows rapid exchange of information and is easy to modify. Computer sketches and partially functional models are regarded as medium-fidelity, which integrates various detailed design decisions we have made earlier. This type of prototype is able to simulate the user experience well, so we usually use this to find out the problems that haven't been discovered before. High-fidelity prototyped is made as we are very confident about our design. Although this can be used as idea refinement, we should be aware that making change on this stage tends to be more difficult. 

 

Relevant application is: 

 

 

 

Here we complete the entire design process. For more detailed information about my process, please refer to my Design Handbook.

 

 

 

 

 

 

References:

[1]  D. Wynn and J. Clarkson, "Chapter 1 Models of designing," page 42, University of Cambridge, 5 November 2004. [Online]. Available: http://www-edc.eng.cam.ac.uk/~nc266/RC15/Wynn%2BClarkson.pdf

[Accessed] 18th, April, 2014.

 

[2]  J. Foster, "Lecture 6", Praxis I, Toronto, 2013