簡短回答： 把外部專家的建議、內部團隊掌握的情境和最後採納權分開，先檢視建議所依據的假設，再共同設計有限試驗。專業意見值得認真考慮，也需要與現場條件接合。
邀請專家前先說明要解決的問題
外部專家可能熟悉某種方法，內部同事則知道使用者、歷史限制及日常例外。合作開始時，說清楚希望得到分析、選項、操作設計還是正式審核，並列明誰有權採納。若工作涉及法規或安全專業要求，仍須依正式資格與審批程序辦理，不能用一般討論替代。
英國政府的探索階段指引提醒團隊先理解問題及限制。本文將這原則用於專家合作，並不宣稱任何專家的建議都能靠一個小試驗驗證；有些判斷需要更完整資料或專門評估。
用假設清單對話，避免各說各話
假設情境：顧問建議所有查詢都改用網上表格，前線指出部分使用者需要電話協助。可以把爭論改寫成：「建議假設使用者都能自行輸入，我們目前有哪些資料支持或不支持？」請專家說明適用條件，請前線展示去識別化的實際任務，不把經驗少的一方直接排除。
可分成必須保留、值得測試及現階段未知三欄。內部的「以前一直如此」也應接受檢視；外部的成功案例則要核對與本地資源是否相似。若要求已互相矛盾，透過跨部門取捨整理確認批准人，而非讓執行同事自行選邊。
記錄如何採納，也記錄沒有採納的理由
共同試驗可選一類低風險查詢，保留合適替代入口，觀察能否完成、在哪裏求助及增加了誰的工作。試驗前先說好甚麼結果會支持繼續、調整或停止，避免看到任何結果都宣稱原建議正確。未經批准，不要把真實個人資料交給外部人員。
最後由有權負責的人作採納決定，記下證據、限制和後續責任；可沿用清晰會議決定的方法。不同意部分建議不等於否定專業，接受建議也不代表內部團隊失去判斷。保留雙方角色，才較容易在發現新情況時坦白修正，而不是爭取誰的說法永遠勝出。
試驗結果亦應回到提出建議的人，由其說明是否需要調整原假設；內部團隊則交代新增限制。這可以避免把一份最初簡報當成永遠不能修訂的答案，也讓最後採納者知道建議目前適用的範圍。
