For Chinese version, please see further down below.

Start with Design Inputs: How to Reduce Rework in Industrial Product Development 

In industrial product development, rework does not always begin with a design mistake. 

In many cases, the root cause of rework is already present before the actual design work even starts. 

Incomplete customer requirements, inconsistent parameters across different documents, unclear operating conditions, undefined interface boundaries, or different interpretations of the same requirement can all lead engineers to move forward based on incorrect or incomplete information. 

The problem may not become visible immediately. 

It may only surface during a design review, prototype manufacturing, testing, or even on-site installation. By then, the required changes may no longer be limited to a single drawing. They can affect components, procurement, manufacturing, testing, technical documentation, and ultimately the project schedule. 

That is why the first step toward reducing rework is not simply to design faster, but to improve the quality of design inputs. 

What Are Design Inputs? 

Design inputs form the foundation of engineering work. 

They include not only drawings, models, and technical parameters provided by the customer, but also the required product functions, operating environment, applicable regulations and standards, interface conditions, manufacturing constraints, and acceptance criteria. 

A reasonably complete set of design inputs should answer several fundamental questions: 

• What problem is the product expected to solve? 
• In what environment will the product operate? 
• What performance and safety requirements must it meet? 
• What equipment, systems, or components must it connect to? 
• Which dimensions, materials, and technical solutions have already been defined? 
• Which areas can still be optimized by the engineering team? 
• What drawings, models, and technical documents need to be delivered? 
• What criteria will the customer use to determine whether the design is acceptable? 

Only when these questions are understood consistently can the engineering team move forward in the right direction. 

Why Do Design Inputs Often Cause Problems? 

Industrial product development typically involves customers, project managers, design engineers, procurement teams, manufacturing, testing, suppliers, and other stakeholders. 

As information moves between different people and systems, omissions, misunderstandings, and version inconsistencies can easily occur. 

Requirements are too vague 

Requirements such as “the structure must be sufficiently stable,” “the equipment should be easy to maintain,” or “the weight should be minimized” may sound reasonable, but they are not directly usable for engineering design or verification. 

The team still needs to clarify questions such as: 

• What loads and operating conditions define “stable”? 
• What operating or access conditions define “easy to maintain”? 
• Is there a specific weight target? 
• Which requirements are mandatory, and which are optimization goals? 

If these requirements are not quantified or converted into verifiable conditions, different team members may interpret them differently. 

Information is scattered across multiple sources 

Some requirements may be recorded in technical specifications, others in meeting notes, emails, chat messages, or earlier versions of drawings. 

When information comes from too many sources, two problems often arise. 

First, it becomes difficult to determine which version is current. Second, requirements from different sources may conflict with one another. 

Critical assumptions are not documented 

When input information is incomplete, engineers often make reasonable assumptions based on experience so that the project can continue. 

However, if these assumptions are not documented and confirmed, other team members may treat them as established facts. 

If the actual conditions later turn out to be different, significant rework may follow. 

Requirements change without sufficient impact assessment 

Changes are common during product development. 

Customers may revise performance targets, suppliers may change components, or test results may trigger design modifications. 

The issue is not that requirements change. The real question is whether those changes are communicated to everyone involved and whether their impact on structure, interfaces, cost, schedule, and technical documentation is properly assessed. 

Turn Vague Requirements into Verifiable Conditions 

Reducing rework does not mean that every detail must be known from the beginning. 

A more practical approach is to identify as early as possible which information is confirmed and which still requires clarification. 

Vague design requirements can be converted into actionable and verifiable conditions through targeted questions. 

For example: 

If “the equipment must operate in a high-temperature environment,” the team should clarify the maximum ambient temperature, duration of exposure, and cooling conditions. 

If “the structure must withstand transportation loads,” the team should clarify the transportation method, fixing arrangement, vibration conditions, and impact requirements. 

If “the product should be easy to install,” the team should clarify the available installation space, required tools, number of operators, and acceptable installation time. 

Once requirements become more specific, engineering decisions can be made on a clearer basis, while testing and acceptance criteria also become easier to define. 

Define Design Boundaries and Engineering Interfaces 

Many cases of rework are not caused by an incorrectly designed individual component. Instead, they occur at the interfaces between different systems and teams. 

Typical examples include: 

• Installation space between mechanical structures and electrical components 
• Connection dimensions between equipment and the customer’s site 
• Routing relationships between structures, piping, and cables 
• Interfaces between components supplied by different vendors 
• Functional boundaries between mechanical, electrical, and control systems 
• Consistency between drawings, models, and bill-of-material information 

When interface responsibilities are unclear, each team may assume that someone else is responsible for resolving the issue. 

Before design work begins, it is therefore important to clarify what belongs within the current team’s scope, what remains the responsibility of the customer or supplier, what information must be exchanged between the parties, and who is responsible for confirming interface changes. 

The clearer the boundaries are, the lower the risk of responsibility gaps and information breakdowns later in the project. 

Separate Facts, Assumptions, and Open Issues 

Engineering work does not necessarily need to stop completely when all design inputs have not yet been finalized. 

A more practical approach is to divide available information into three categories: 

Confirmed facts 
Information that has been formally confirmed by the customer or project team and can be used as a valid design basis. 

Current assumptions 
Temporary assumptions used to keep the work moving forward, together with their basis and potential impact. 

Open issues 
Missing, conflicting, or unresolved information that requires an assigned owner and a target completion date. 

This classification helps the team understand how stable the design basis really is. 

If an assumption changes, the team can quickly identify which design elements need to be reviewed instead of discovering late in the project that the entire solution was built on an incorrect premise. 

Establish a Unified Design Input Baseline 

Design inputs need a clear and traceable version. 

Before the project enters formal design, key inputs can be consolidated into a unified baseline that includes: 

• Functional and performance requirements 
• Key technical parameters 
• Operating environment and critical operating conditions 
• Regulations, standards, and customer specifications 
• Mechanical, electrical, and system interfaces 
• Material and manufacturing constraints 
• Deliverables and file formats 
• Design scope and responsibility boundaries 
• Acceptance criteria 
• Outstanding issues 

A baseline does not mean that requirements can never change. 

Its purpose is to make it clear which version of the requirements the current design is based on, what has changed since then, and which design elements are affected by those changes. 

Without a baseline, different people may unknowingly work from different versions. With a baseline in place, changes can be identified and managed more effectively. 

Involve Relevant Disciplines Early 

Design inputs should not be reviewed only by the project manager or by a single engineering discipline. 

Mechanical, electrical, software, testing, procurement, manufacturing, and technical documentation teams all look at the same information from different perspectives and may identify different gaps. 

Mechanical engineers may focus on loads, dimensions, and materials. Electrical engineers may focus on power, interfaces, and available space. Test engineers may focus on acceptance criteria. Manufacturing teams may identify process and supply-related limitations. 

If these issues are raised only after detailed design has been completed, the cost of making changes is usually much higher. 

By involving relevant disciplines early in the review of design inputs, teams can identify conflicting requirements sooner and reduce the risk that a local optimization in one discipline creates new problems elsewhere. 

This does not mean every function needs to be deeply involved from day one. It means that the right experts should have the opportunity to raise concerns before key decisions become fixed. 

Reconfirm Inputs at Key Project Milestones 

Design inputs should not be reviewed only once at project kickoff. 

As the project progresses, new information becomes available and earlier assumptions may be confirmed or disproved. 

At key milestones—such as concept approval, start of detailed design, drawing release, prototype manufacturing, and testing—the team should revisit several questions: 

• Have any requirements changed? 
• Have all open issues been closed? 
• Is the current design still based on the latest information? 
• Are interface conditions still consistent? 
• Have design changes been synchronized across the relevant files? 
• Are the acceptance criteria still clear? 

These milestone checks help prevent small input changes from accumulating throughout the project and eventually turning into major rework. 

Design Input Management Should Not Become a Process Burden 

Some teams worry that additional requirement checks, issue lists, and stage reviews will slow the project down. 

In practice, however, what often causes the greatest delays is not spending extra time clarifying requirements early, but repeatedly modifying completed design work later. 

Good design input management does not require a complicated approval system. 

It can begin with a few simple and practical practices: 

• Use a standardized input checklist 
• Record key meeting decisions 
• Assign owners to unresolved issues 
• Confirm important assumptions in writing 
• Clearly identify document versions and effective dates 
• Check for input changes before design release 
• Perform a basic impact assessment for significant changes 

The purpose of the process is not to create more documentation. It is to make sure that the entire team is working from the same set of information. 

Rework Cannot Be Eliminated Completely, but It Can Be Controlled Earlier 

Industrial product development will always involve change and uncertainty. 

Not every instance of rework can be avoided. Some changes result from new findings during testing, while others are driven by legitimate changes in the market, supply chain, or customer requirements. 

What should be reduced is unnecessary rework caused by missing information, inconsistent understanding, version confusion, and unclear interfaces. 

When engineering teams begin managing projects from the design input stage, they can identify uncertainty earlier, understand the basis of the design more clearly, and resolve issues while the cost of change is still relatively low. 

This not only reduces repeated design work but also improves control over project schedule, cost, and quality. 

As a technology service company providing engineering services, Etteplan supports customers through engineering design, project collaboration, and multidisciplinary expertise, helping clarify engineering requirements, define design boundaries, and move design work forward on the basis of clear and traceable inputs. 

Reducing rework is not only about helping engineers design faster. It is about making sure the entire team is solving the same problem from the very beginning. 

中文版 

从设计输入开始：如何减少工业产品开发中的返工 

在工业产品开发中，返工并不一定发生在设计出错之后。 

很多返工，其实在设计工作正式开始之前就已经埋下了伏笔。 

客户需求描述不完整、不同文件中的参数不一致、使用工况没有明确、接口边界尚未确认，或者项目团队对同一句话有不同理解，都可能让工程师在错误或不完整的信息基础上推进设计。 

问题往往不会立即暴露。 

直到设计评审、样机制造、测试验证甚至现场安装阶段，团队才发现原来的理解与实际需求存在偏差。此时，修改可能已经不再局限于一张图纸，而会进一步影响零部件、采购、制造、测试、技术文档和项目交付。 

因此，减少返工的第一步，不只是提高设计速度，而是提高设计输入的质量。 

什么是设计输入？ 

设计输入是工程团队开展设计工作的基础。 

它不仅包括客户提供的图纸、模型和技术参数，还包括产品需要实现的功能、使用环境、法规标准、接口条件、制造约束和验收要求。 

一套相对完整的设计输入，通常需要回答几个基本问题： 

• 产品需要解决什么问题？ 
• 产品将在什么环境下使用？ 
• 必须满足哪些性能和安全要求？ 
• 需要与哪些设备、系统或零部件连接？ 
• 哪些尺寸、材料和技术路线已经确定？ 
• 哪些内容仍可以由工程团队优化？ 
• 最终需要交付哪些图纸、模型和技术文件？ 
• 客户将依据什么标准判断设计是否合格？ 

只有当这些问题形成较清晰的共同理解，设计团队才能在正确的方向上开展工作。 

设计输入为什么容易出现问题？ 

工业产品开发通常涉及客户、项目经理、设计工程师、采购、制造、测试和供应商等多个角色。 

信息在不同人员和系统之间传递时，很容易出现遗漏、偏差和版本不一致。 

需求表达过于笼统 

例如，“结构需要足够稳定”“设备应方便维护”“尽量降低重量”等要求，方向上没有问题，但无法直接用于设计和验证。 

工程团队还需要进一步明确： 

• “稳定”对应哪些载荷和工况？ 
• “方便维护”需要满足什么操作条件？ 
• “降低重量”是否有明确的目标值？ 
• 哪些要求是必须满足，哪些属于优化方向？ 
• 如果这些内容没有被量化或转化为可验证的条件，不同人员就可能产生不同理解。 

信息分散在不同文件中 

一部分需求可能记录在技术规范中，一部分来自会议纪要，还有一些存在于邮件、聊天记录或旧版图纸中。 

当信息来源过多，团队容易遇到两个问题： 

一是无法判断哪一份是最新版本；二是不同文件中的要求可能相互矛盾。 

关键假设没有被明确记录 

当输入信息不完整时，工程师通常会根据经验作出合理假设，以保证项目可以继续推进。 

但如果假设没有被记录并确认，其他团队成员可能会把它当作已经确定的事实。 

一旦后续真实条件与假设不同，就容易产生较大范围的返工。 

需求发生变化，却没有充分评估影响 

项目推进过程中，需求变化很常见。 

客户可能调整性能目标，供应商可能更换零部件，测试结果也可能推动设计修改。 

问题不在于需求发生变化，而在于变化是否及时传递给所有相关人员，以及团队是否评估了它对结构、接口、成本、进度和技术文件的影响。 

把模糊需求转化为可验证条件 

减少返工的关键，不是追求一开始就掌握所有信息，而是尽早识别哪些信息已经明确，哪些信息仍需要确认。 

对于模糊的设计要求，工程团队可以通过进一步提问，将其转化为能够设计和验证的条件。 

例如： 

“设备需要适应高温环境”，需要进一步明确最高环境温度、持续时间和散热条件。 

“结构需要承受运输载荷”，需要明确运输方式、固定方式、振动条件和冲击要求。 

“产品需要便于安装”，需要明确安装空间、工具条件、人员数量以及允许的安装时间。 

当需求变得具体，设计决策就更有依据，后续测试和验收也会更加清晰。 

明确设计边界与工程接口 

很多返工并不是由单个零部件设计错误造成的，而是发生在不同系统和团队之间的接口位置。 

例如： 

• 机械结构与电气元件之间的安装空间 
• 设备与客户现场之间的连接尺寸 
• 结构件与管路、线缆之间的布置关系 
• 不同供应商零部件之间的接口 
• 机械、电气和控制系统之间的功能边界 
• 图纸、模型和物料信息之间的一致性 

如果接口责任不明确，每个团队都可能认为相关问题应由其他人员处理。 

因此，在设计开始前，需要明确哪些内容属于当前团队的设计范围，哪些由客户或供应商负责，双方需要交换哪些数据，以及接口变化由谁确认。 

边界越清晰，后期出现责任空白和信息断层的可能性就越低。 

区分事实、假设和待确认事项 

在设计输入尚未完全确定时，工程工作不一定必须全部暂停。 

更实际的做法，是把现有信息分成三类： 

已确认的事实 
已经获得客户或项目正式确认，可以作为设计依据。 

当前使用的假设 
为了推动工作暂时采用，但需要说明依据和潜在影响。 

待确认事项 
缺少信息或存在冲突，需要指定负责人和完成时间。 

这种分类能够帮助团队清楚地看到设计基础是否稳定。 

当假设发生变化时，团队也可以快速判断哪些设计内容需要重新检查，而不是等到项目后期才发现整个方案建立在错误前提上。 

建立统一的设计输入基线 

设计输入需要有一个明确、可追溯的版本。 

在项目进入正式设计阶段前，团队可以将关键输入整理成统一的基线，包括： 

• 功能和性能要求 
• 主要技术参数 
• 使用环境和关键工况 
• 法规、标准和客户规范 
• 机械、电气和系统接口 
• 材料与制造限制 
• 交付物和文件格式 
• 设计范围与责任边界 
• 验收标准 
• 尚未关闭的问题 

基线并不意味着后续不能变化。 

它的作用是让团队明确：当前设计基于哪一版要求，后续发生了哪些变化，以及这些变化影响了哪些设计内容。 

没有基线，项目中的每个人可能都在依据不同版本工作；有了基线，变化才能被识别和管理。 

让相关专业尽早参与 

设计输入不能只由项目经理或单一专业进行判断。 

机械、电气、软件、测试、采购、制造和技术文档团队关注的问题不同，也能从不同角度发现输入中的缺口。 

机械工程师可能关注载荷、尺寸和材料，电气工程师关注功率、接口和空间，测试人员关注验收条件，制造团队则会发现工艺和供应方面的限制。 

如果这些问题在详细设计完成后才提出，修改成本通常会更高。 

让相关人员在项目早期共同评审设计输入，可以提前发现相互冲突的要求，也能避免某个专业的局部优化给其他环节带来新的问题。 

这并不要求所有团队从项目第一天起持续投入大量时间，而是在关键决策形成前，让相关专业有机会提出问题。 

在关键节点重新确认输入 

设计输入不是项目启动时确认一次就结束了。 

随着项目深入，团队会获得更多信息，早期假设也可能被验证或推翻。 

因此，在概念方案确定、详细设计启动、图纸发布、样机制造和测试开始等关键节点，团队都应重新检查： 

• 需求是否发生变化？ 
• 未确认事项是否已经关闭？ 
• 当前设计是否仍基于最新输入？ 
• 接口条件是否保持一致？ 
• 设计变更是否已同步到相关文件？ 
• 验收标准是否仍然明确？ 

这种阶段性确认能够防止小的输入变化在项目中不断累积，最后演变为大范围返工。 

设计输入管理不是增加流程负担 

有些团队担心，增加需求确认、问题清单和阶段评审会拖慢项目进度。 

但真正影响进度的，往往不是前期多花了一些时间澄清问题，而是在后期反复修改已经完成的设计。 

高质量的设计输入管理并不意味着建立复杂的审批程序。 

它可以从一些简单而实用的做法开始： 

•  使用统一的输入清单 
•  记录关键会议结论 
• 为待确认问题指定负责人 
•  对重要假设进行书面确认 
• 明确文件版本和生效日期 
•  在设计发布前检查输入变化 
•  对变更进行基本的影响评估 

流程的目标不是增加文件数量，而是确保团队在同一套信息基础上工作。 

返工无法完全消除，但可以更早被控制 

工业产品开发始终存在变化和不确定性。 

并不是所有返工都能避免。有些修改来自测试中的新发现，有些来自市场、供应链或客户需求的合理变化。 

真正需要减少的，是由信息遗漏、理解偏差、版本混乱和接口不清造成的无效返工。 

当工程团队从设计输入开始管理项目，就能更早发现不确定性，更清楚地判断设计依据，并在修改成本仍然较低的时候解决问题。 

这不仅有助于减少重复设计，也能提高项目进度、成本和质量的可控性。 

作为一家提供工程服务的技术公司，Etteplan通过工程设计、项目协作和跨专业资源，帮助客户梳理工程需求、明确设计边界，并推动设计工作在清晰、可追溯的输入基础上展开。 

减少返工，不只是让工程师设计得更快，而是让整个团队从一开始就在解决同一个问题。