A Design Engagement System: The Missing Piece to Better Product Development

Realizing a Design Engagement System might be the key to unlocking your leaky design feedback pipe and defining a Design Engagement System are two very different tasks.

Let’s tackle the latter.

But first, it’s worth revisiting the gaps in your current process that a DES solves. 

Right now, without a DES, your design reviews are:

1. Rife with friction. You’re scheduling meetings 3-6 weeks out to align calendars. Those meetings center around screen sharing CAD while engineers point out issues. Not everyone speaks up and the follow-up is poor at best. Then, these screenshots are shared via email making version control nearly impossible. 
2. Lacking essential context. With CAD screenshots, you lack product context. With CAD viewers, you lack the context of other people’s feedback. With drawings, your manufacturing partners lack context until much later in the PD process. In these scenarios, reviewers lack the full picture and so can’t perform an accurate and complete design review.
3. Stifled by rigid workflows. Many PLMs provide workflows to do design review. But the architecture of a PLM forces design review into rigid, sequential steps. However, the purpose of design review is to start and resolve many design conversations with many stakeholders in parallel. So, the waterfall process of a PLM design review workflow doesn’t match the intended purpose of design review. And so teams don’t use them the right way or don’t use PLM workflows at all.
4. Virtually untrackable. Teams record design review issues in spreadsheets, online documents, emails, PowerPoint slides - or worse, nowhere trackable. And these systems have no way of speaking to each other. This makes rolling issues into a single place or prioritizing bottlenecks across PD projects nearly impossible. So, your most critical design decisions slip through the cracks leading to pilot build failures, quality errors and missed timelines.

Engineering teams know all this. And more and more companies realize these issues are major bottlenecks to company growth and profitability.

So, a DES must address these issues, helping engineering teams perform higher quality design reviews, launch higher quality products faster and tangibly contribute to the company’s bottom line.

Essentially four key qualities make a DES a DES:

1. A DES is frictionless
2. A DES is contextual
3. A DES replaces sequential workflows with engaging reviews
4. A DES is self-documenting

‍

The first quality of a DES is that it's frictionless. But, what do we mean by frictionless? 

Put simply: it's easy to get data in and out of the platform, and it's easy to access the system. A good litmus test for measuring friction is how easy and worthwhile the system is for infrequent users. For example, if you invited a supplier into a DES to provide an RFQ, they should be able to: 

• Easily access the system in less than a couple clicks;
• Access data in seconds-to-minutes, and; 
• Provide the RFQ with minimal input from your team

Now, when it comes to connecting your digital thread, a DES is also meant to be frictionless in its interaction with your CAD and PLM systems. 

It should be easy for anyone to view and interact with a 3D model regardless of their CAD license. They should be able to drill down to specific parts of an assembly, measure, cut planes or explode the model. Essentially, any design review participant should be able to engage with a 3D model. 

Similarly, it should be easy to pull data from your PLM into a DES, while maintaining inherent PLM data controls. Team members with proper permissions should be able to create a design review file package, send that package to a DES for review and maintain version control within the PLM.

Finally, with access to both PLM files and CAD data, you’re able to participate in a design review without having to download any software. This is a critical aspect of a frictionless system.

Because – as we’ve explored earlier – what teams do now is rife with friction.

• You need to download and send files via email
• You need to have access to a specific kind of software just to access files
• You need to screenshot CAD views and do markup inside a PowerPoint deck
• You have to schedule meetings just to push the review cycle along

These seem insignificant, but their consequences compound. As we’ve reviewed earlier, these small frictions add up to missed product launches and lower quality products. 

To solve these problems, a DES should be frictionless. It should be easy to get people and data into a design review and get the work done, either real-time together or asynchronously. 

When we talk about what a DES does, engineering teams often object with, “Our PLM does design review workflows. How is this different?”

Because a DES replaces this sequential workflow. Every review participant can review and mark up the same file at the same time or can leave feedback asynchronously. Meaning the only constraints on the design review are when it starts and when it ends. 

Contrast this with your typical PLM workflow and the process is very different. Inside PLM, you have assigned roles and then assigned steps in the workflow based on that role. These steps must be completed sequentially – meaning the review cannot progress to the next role or step until the previous team member has completed their work. (This is, for the sake of simplicity, a generalization. Specific processes and controls differ from PLM to PLM. To discuss how your PLM instance could benefit from a DES, we recommend speaking to a technical specialist).

For simple reviews or formal changes, this process makes sense and is even preferable for some teams. However, when you’re engaging multiple stakeholders both inside and outside your organization, this rigid process is what causes folks to devolve back to email threads, meetings and CAD screenshot markups. Then, we’re faced with the same problems the workflow was trying to solve.

Now, how does a DES replace this sequential process? By bringing any stakeholder into a review either in real-time or asynchronously. Meaning, meetings are still important. But meetings centered around static CAD images are ineffective. Instead, with a DES, you can manipulate CAD in real-time and even have other meeting participants “follow” your screen on their own devices.
‍

Similarly, if you can’t get everyone into the same room, reviewers can come in on their own time and leave feedback or participate in design conversation threads.

Now, we also used the word “engaging” when describing the type of review you get when you use a DES. This is an important descriptor. Because what we often hear is teams settle for a “looks good” review. When you have to adhere to this slow, sequential process, people get frustrated and mentally fatigued. So, they check out. They say, “Sure, looks good,” and move on. 

Replacing a “looks good” review with an engaging review means reviewers process information in an engaging way and uncover issues that save a lot of trouble in quality checks or rework cycles.

To summarize, a DES must reject the inflexible waterfall process for conducting design review. Instead, a DES should allow for elastic exploration within 3D models, drawings and data packages. Giving participants full control of their view states, how and when they enter a review and how they interact with other reviewers means a DES replaces sequential workflows with engaging reviews.

Engineering teams today attempt all manner of creative – and not so creative – ways to document design review feedback. We’ve seen everything from teams with 200 slide PowerPoint decks with CAD screenshots and intricate markups on every slide to spreadsheets with 100+ columns to pages of manual notes and post-its. Aside from the sheer volume of work, the time and effort required to complete this level of documentation is oppressive.

And then, despite the time, effort and sheer volume, teams still spend hours to days searching through this mass of data to justify a single design decision. 

It’s maddening.

So, for a DES to maintain its status as a purpose-built system that brings people into design conversations and product decision-making, it's critical that the DES removes this administrative burden. 

Because when design review participants spend more time on the backend administrative process of documenting design feedback than they do on the review itself, product decision-making suffers. And when product decision making suffers, so does the quality of the final product itself. 

So, when we say a DES needs to be self-documenting, this goes beyond simply gathering up all design feedback. A true DES captures every design comment as a unique object. Meaning as you’re doing the work, the work itself is tagged, stamped and rolled up into a greater record of design decision-making. 

These design work outputs then roll up into a comprehensive review object. Now, you’re not just seeing: 

• A stack of annotations, but the model visual with all pinned feedback in context. Seeing feedback like this avoids issue duplication – a huge problem for engineering teams today.
• A single bit of feedback in a spreadsheet, but seeing feedback across file revisions: either all at the same time, or revision by revision. You can even view two revisions side by side.
• Feedback and markup as objects themselves, but a history of all design review activity: when an issue was opened, when feedback was created and by whom, when an issue was closed, etc.

Then, the DES automatically populates a global design review list. This list elevates all your feedback, issues and decisions across the entire environment. Now, you’re not just seeing your design feedback or the feedback from your individual review – you’re seeing feedback across 5, 10, 20 PD cycles. You can then filter and analyze this list to:

• Prioritize review bottlenecks
• Check timelines across projects
• Predict design review milestone completions

This kind of record-keeping is also critical when married with your PLM. Instead of cluttering the PLM with thousands of markups on a single assembly, you’re making sure the right data reaches the DES so your team can execute an effective design review. Then, you’re making sure the right data makes it back to your PLM once the review is complete.

This is what it means to create a cohesive digital thread.