The Design Process: A Follow-up

I was recently binge-listening to a new-to-me podcast called The Engineering Commons Podcast. In episode 109, the panel discussed the process of design.

In our Utilizing Design Process to Eliminate Waste and Create Custom Machinery series of articles, I discussed the various Idea-to-Launch methods for creating a custom machine. However, I did not discuss the “30,000-foot” concepts of the design process.

The Engineering Commons panel broke them down into two basic models: the rational model and the action-centric model.

The rational model design process (as they and Simon, Pahl, and Beitz posit), utilizes the following tenants.

1. Designers try to optimize a design for known constraints and objectives.
2. The process is plan-driven.
3. The process is a discrete sequence of events.

Many of you may know this process by other names like the waterfall or stage-gate method. These methods dictate that each step in the process is discreet and you can’t move on to another stage without the completing prior.

They described the action-centric model as having the following tenants.

1. Designers use creativity and emotion to develop design candidates.
2. The process is improvised.
3. No defined stages with analysis, design and implementation considered to be one.

Many of you may see the Agile methodology being described. It’s smooth and allows for multiple “reality checks” along the way to ensure the outcome is the best it can be.

As I listened to the podcast, and re-read the literature on both models, I was led to believe that

• the rational model removes all creativity from the process because it is so regimented, and
• the action-centric model removes all process structures allowing the designer freedom and to feel their way to completion.

One opinion piece I read equated the models’ differences as those who think versus those that act.

The rational (thinker) model needs to work within a constrained set of objectives to almost guarantee success, or at least have a few things to point to if the design fails. Whereas, in the action-centric (doing) model allows the process to take risks and “roll with the punches” to change direction as needed.

In my opinion, a good design process is a blend both.

A designer must be able to identify the desired outcomes and the constraints within to work (especially financial and time). At the same time, they need to be able to “think outside the box,” but there needs to be a person (or group) that confirms the deliverables are being met.

Also, developing a new product shouldn’t be left to an individual designer because it’s a group effort. So, why should there be just one way to do it?

To further the design process discussion, let’s take a look us some excellent questions relating to the action-centric models, like Agile, from Philip P.

Personally, I don’t have a chart showing the process start to finish, but the phases I described in the series gives you a general map of the process. The reason for no chart is because the method used to develop the machine may differ from customer to customer. Some may want to be more hands-on than others ─ and they may have their own methodology they wish to use. While others just want to see the end product, whether that is in drawings or models, or the finished physical product.

The use of simulated models is increasing for design review.

My previous employer ─ I ran the R&D department ─ began using more simulations for the products we were developing. We mainly did this because the stakeholders were located across the globe.

Yes, the major design programs are memory intensive. However, animations can be made that do not use many resources. If we needed to allow for a “fly through,” we would use a video chat service to allow for the others to look at the workstation, eliminating the end-user resource issues. I usually use video conferencing to communicate with my customers during the process when they aren’t within driving distance.

Custom machinery design can benefit from using the Scrum framework.

Each machine requirement is put into a backlog and prioritized by its importance to the product. Once the requirement is ready to be tackled, a sprint can be used to make sure it’s processed quickly.

Brief, daily meetings can capture what was done since the last meeting, what is planned to be done before the next, and issues can be raised.

Reporting failures is just as important as the successes.

Upon completion of the sprint, the overall results can be presented, and changes can be made, if necessary. Remember, one requirement may affect others during the process.

Since I am currently only working with one-off custom machinery, the use of lean techniques proves to be a challenge.

The concepts of Kanban, Poka-yoke, and others within the realm of lean usually require some repeating characteristics. Hardware and other commonly used parts are controlled through a pseudo-Kanban, but I don’t use any of the automatic triggers that larger companies employ.

To me, this question relates to previous questions of simulated models and Agile.

As I stated before, I do attempt to simulate the model as best I can, especially when it comes to the movement to ensure there are no issues and the mechanics are going to work. However, the frequent release principle isn’t applicable in my business except when breaking down the product/project into smaller pieces and my customer wishes to use the Scrum framework.

Which base product design model do you employ? Let me know your thoughts in the comments section below.

[yasr_visitor_votes]