[vc_row parallax=”content-moving” parallax_image=”1189″ parallax_speed_bg=”2″ css=”.vc_custom_1541383104414{padding-top: 25% !important;}”][vc_column][/vc_column][/vc_row][vc_row el_class=”page_text”][vc_column][vc_column_text]
Design Process
Requirements Review
One of the most disheartening experiences as a design engineer is to work long and hard developing a gadget only to find out at the end that it does not do what the client wanted or what the end customer needs. How does this happen? In our experience, it stems from an unholy rush to start designing something without first taking the time to carefully consider what the product must do to satisfy the customer’s needs.
So how do you find out what the requirements for a product are? Often our client has a very good understanding of the needs and wants of the end customer, but this is often poorly documented, or stored only in the minds of a few key personnel. Sometimes, even they do not know, and it is imperative to commence the project with some well designed market research and customer surveys. The requirements for a product should be listed in a Product Specification.
Drafting a good Product Specification is without a doubt the toughest and most important part of the product development process. The challenge is to concisely and precisely list all of the things that the product must do. Common section headings in specifications are; Environment – the conditions the product must work in, Function – what it must do, Performance – how well it must do it, Durability – the life requirements, and User Interface – how it must interact with the user. It is vital to avoid prescriptive specifications that may limit the options at the next stage – Concept Generation. For instance, rather than saying “the trap shall incorporate a U shaped element constructed of steel wire which shall impact the neck of the mouse with impact energy of no less than 2 joules”, it is much more effective to say “1. The trap shall apply an impact loading to the neck of the mouse, 2. The impact load shall be adequate to cause immediate fracture of the spinal column”.The first approach pre-empts the design solution and may not produce the desired outcome which is, you guessed it, to build a better mousetrap. The second just lists what it is we want to achieve, and gives the designer flexibility in terms of how to achieve it. Note that even the second approach is prescriptive, as it dictates that the mouse must be killed by fracturing the spinal column. This may be because the animal welfarists dictate this method, otherwise a better approach may be to specify; “1. The trap shall cause the death of a mouse entering it. 2. Death shall occur in a humane manner” (maybe even refer to a generic standard here that specifies humane ways of killing things). Subsequent clauses may go on to specify that you don’t want blood splattered all over the walls, can’t involve the release of poison gases that cause all humans in the area to die also, etc.
When a detailed Product Specification has been drafted, it is imperative that the client signs off on it, to ensure that everyone is in agreement that it accurately and fully describes the product they desire. Keep in mind that the specification can be amended as new requirements come to mind during the design process. This is quite common, particularly for products requiring a significant amount of research and development (R&D) during the design process. Keep in mind also that it is likely that you (or the client more specifically) will want to test prototypes and the final product against these requirements, so it helps to structure the requirements in such a way that standard or simple tests can be employed wherever possible.
Also be warned; watch your words. Saying “the trap shall not corrode or otherwise be degraded after 100 hours of salt spray testing” means that avoidance of corrosion in these circumstances is mandatory, whereas replacing “shall” with “should” means that it is your preference for corrosion to be avoided in these circumstances but it is not essential. The alternative “it is desirable that the trap not corrode or otherwise be degraded after 100 hours of salt spray testing” means nothing more than this would be a nice bonus if it were to happen.
Concept Design
This is the fun bit where wild ideas are thrown around in a quest to identify different concepts that will address the requirements. We call these sessions “brainstorming” and they tend to get rather loud and just a bit silly at times, as we tend to involve everyone in the design office so that we get as many different ideas as possible.To keep some sort of structure to this chaotic process, and to assess whether ideas fall into the “crap”, “has merit”, or “ball-tearer” categories we assess them against a very special document. You guessed it – the Product Specification.
Once we have a short list of concepts we do some preliminary design work on these. This may consist of a few quick sums, more detailed sketches, or quick costings or other research to allow us to better assess the concepts. Generally this will result in one concept standing out clearly as the one to pursue.
Sometimes, two concepts may be neck and neck and we turn to the client for assistance in selecting the better concept. This is also often the stage where we start thinking about the intellectual property (IP) we are generating and that the client will wish to protect.
With very few exceptions, all IP we generate in the design process is assigned to the client. At this stage we recommend that patent novelty and infringement searches be conducted and that the drafting of a provisional patent specification commence. This is also the stage where technical risks inherent in the project need to be identified and a risk management plan put in place.
Preliminary Design
This is where we take the leading concept and add flesh to the bones.We will identify and perform the analysis, testing, preliminary prototyping and other R&D required to resolve any unknowns or significant technical risks. Most likely this is where we start laying out the basic product architecture, using computer aided design tools such as CAD.
The aim of this phase is to gain confidence that all the Product Specification requirements can be met. In the case where it becomes apparent that they cannot, it may necessitate revisiting the Concept Design stage to modify the concept or identify or select an alternative.
This stage will generally culminate in a Preliminary Design Review (PDR) where we methodically assess the design against the Product Specification to ensure that the design will work. .This is led by an experienced designer that has not been involved in the design, and also often involves the client.
Passing the PDR process is required before the next stage, detail design, commences.
Detail Design
This is where we get into the nitty gritty of what the product will look like and how it will be made.
During this phase more analysis, testing and R&D may occur, but the emphasis is on design optimisation rather than determining feasibility. We liaise with manufacturers to ensure that the design is optimised for manufacture and cost. Detailed drawings are prepared suitable for prototyping and manufacture.
At the culmination of this stage a Critical Design Review (CDR) is conducted to ensure that the design will meet all of the Product Specification requirements.
.Depending on the cost and complexity of prototyping this may be conducted before or after the CDR. If expensive, prototypes are generally built after the CDR. Thorough testing and evaluation of prototypes is conducted to provide further assurance that the design will meet all requirements prior to committing the design to the expensive tooling and manufacture phase.
Validation
Following tooling pre production prototypes will be produced.Prior to market release it is imperative to throughly test these to ensure that the product performs as intended. A test procedure, based on the product requirements specification, should be prepared and the product tested thoroughly to ensure compliance. Caught up in this will also be compliance testing to relevant standards and certifications such as CE mark, C tick, UL, TGA, etc requirements.
Often accelerated life testing and environmental testing will be part of this process. Sounds expensive and onerous? Well, yes it is, but not compared to a rash of warranty claims or a safety recall…..
[/vc_column_text][/vc_column][/vc_row]
Recent Comments