“We already have someone doing the HF work.” 

It sounds like a sign of progress, but to experienced teams, it’s often the first clue that functional silos may be forming. That statement usually points to a situation where the human factors (HF) work is happening without clear integration into the larger development and risk management strategy. 

At Suttons Creek, we frequently encounter this situation. A client has a third-party HF vendor developing a Use-Related Risk Analysis (URRA) separately from the team managing the Use Failure Modes and Effects Analysis (UFMEA). Over time, we’ve seen this approach lead to misalignment, inconsistent risk characterization, and major inefficiencies that could have been avoided with better integration. 

When Risk Tools Tell Two Stories 

URRAs and UFMEAs may serve different purposes, but their content overlaps significantly. The UFMEA is typically used during design and development to assess risks associated with user interaction and to inform mitigations. The URRA is often formatted for regulatory submission, demonstrating how critical tasks and associated risks have been addressed. Both are important tools, but problems arise when they are developed independently. 

Without coordination, teams often end up with two risk assessments that appear aligned at a high level but diverge in detail. These differences may not become obvious until a regulatory reviewer points out discrepancies in critical task classification, mitigation strategy, or severity ratings. In other cases, inconsistencies only emerge after launch when the post-market surveillance team attempts to trace complaints back to the original risk assessments, only to find that the documented risks do not match how the product is actually used. 

In one program we supported, our client faced a rise in user complaints related to a specific interaction with their product. Upon investigation, we found that the HF vendor had excluded this interaction from their summative testing. The use scenario had been discussed in early engineering design sessions, but that information never made it to the HF team. The resulting URRA was technically complete, but it missed a foreseeable use error that would have been flagged in a well-maintained UFMEA. 

Siloed Human Factors Is a Systems Problem 

This kind of issue is not about execution. It’s a system-level gap. When human factors work happens in isolation, it’s often due to a lack of systems engineering oversight. 

Combination product development requires coordinated contributions across risk management, design, human factors, and regulatory. Each function relies on the others to produce a coherent and complete picture of safety and performance. Without shared ownership, synchronized tools, and structured communication, documentation becomes fragmented, and risk management becomes disjointed. 

We have seen clients invest heavily in HF studies and URRA documentation, only to find out late in development that the deliverables don’t support their submission or sustainment needs. This results in delays, rework, and a rush to rebuild risk documentation that should have been aligned from the beginning. 

Tips for Managing UFMEA and URRA as Separate Tools 

While our team typically recommends using the UFMEA as the primary tool and generating the URRA as a submission-ready subset, we recognize that some teams operate with both documents maintained separately. If that is your approach, it is essential to put structure in place to keep the tools aligned. Here are a few ways to do that: 

• Define document ownership clearly. Assign responsibility for each risk document and ensure those teams remain active in communication throughout development. 

• Maintain a shared use error and mitigation library. This helps ensure that the risks captured in the URRA reflect the same understanding developed through engineering analysis. 

• Use harmonized terminology and risk ranking systems. Align severity definitions, critical task classification, and mitigation language between documents to reduce confusion and review comments. 

• Reconcile documents regularly. Set trigger points such as after HF formative testing, summative study completion, or design reviews to check both tools for consistency. 

• Build URRAs as filtered views of the UFMEA. Even if you maintain them as distinct documents, using a template or structure that mirrors the UFMEA can reduce errors and improve traceability. 

This last point reflects a best practice that has worked well across many of our client programs. The UFMEA serves as the living document throughout development and post-market support. When needed for submission, the URRA can be generated as an appendix or filtered output that excludes occurrence ratings and non-essential columns. This keeps the documentation lightweight while preserving alignment. 

Managing Human Factors Vendors with a Systems Engineering Mindset 

When an HF vendor is contracted independently, without active engagement from the engineering, regulatory, or quality functions, they often lack the context needed to build a robust URRA. This is not a reflection of their competence, but rather a breakdown in how their role is managed within the program. 

HF vendors must be integrated into the broader development process. This includes: 

• Sharing the latest UFMEA and risk management plan 

• Aligning on terminology and task analysis before HF studies begin 

• Ensuring that design changes and mitigation decisions are communicated in real time 

• Reviewing URRA drafts with input from systems engineers and risk owners before submission 

Managing HF vendors in this way is not micromanagement. It is systems engineering. Without it, the URRA becomes a static deliverable rather than a meaningful part of your risk management ecosystem. 

The Bottom Line 

Fragmented URRA and UFMEA development creates costly inefficiencies and real risk exposure. These tools must tell the same story. Whether you choose to manage them as separate documents or as variations of a single tool, the key is alignment. 

At Suttons Creek, we’ve worked with clients at every stage of the product lifecycle. In many cases, the path to resolution started with reconnecting disconnected teams and restoring a unified approach to user-related risk. 

If your program includes external HF vendors or parallel risk documents, now is the time to evaluate how well those activities are integrated. Early investment in coordination always pays off with fewer surprises and smoother regulatory pathways. 

For more insights, or to learn how we help teams embed HF within systems engineering, contact us at discuss@suttonscreek.com or complete our contact form.