感謝您的回覆，蠻想多聽聽您討論「具體化了成果，導致思考的部分被低估」這個觀點。

我再補充說明一下每個工作階段有具體的產出是很重要的原因。

主要就是，UX的工作歷程其實很像是在學習建造一個新的事物，但在客戶的認知中，他並不是花錢買你的時間讓你學會什麼東西，而是要購買設計師所提供的服務。

這個服務不能只有內化的觀點與知識，而必須是轉換成一個可以被傳承、記錄、運用的成果，例如商業模式分析圖可以拿來說服開發團隊或者長官取得共識，角色Persona 可以用來墊高溝通成本以延緩從未參與過專案的高層突然空降的想法（例如禮貌的告訴高層，我們可以增加您提出的這個調整，但這是還未被評估過的情景，可以多告訴我們一些訊息，讓我們確認這個情景要實現的優先順序有多高可以嗎？）

UX在每一階段產出的具體文件，不只是用於記錄想法，而是要應用於團隊內部溝通用的工具，用來證明每一階段提出的規劃是有所本的。

因為UX投入了時間與設計方法取得了有憑有據的規劃方向，這可以阻擋所有只憑喜好挑戰你規劃的人任意踐踏設計專業。

關於您的第二個討論「怎麼跟客戶解釋這些業內的常識」

我的作法如同上述，我是去告訴客戶專案推動的過程會遇到哪些阻力以及風險，為了讓專案可以成功推動，這些UX的設計工具，可以讓想法變得更可靠有客觀的說服力。

但最終我依然會看客戶的狀況適當調整工作流程，畢竟不是每個客戶都想要「真正的UX設計服務」，不想要「很麻煩的用戶需求訪談」，他們內在動機可能是想讓介面變得更好看些，讓上面的老闆有面子，而不是真正相信透過UX的改善可以讓產品提昇（或者他們公司不靠這個賺錢）。

遇到這種狀況，我們最低限度會溝通的是：如果流程合理，介面自然會好看囉……