在產品驗證環節，很多人寄希望在此階段，除去功能驗證之外，能發現更多的產品易用性類的問題，讓大家提出更多針對產品優化的建議和意見。實際上，這種願望，幾乎是不可能的事情。
下文就從三個方面，分析產品驗證環節的一些失語現象。
一、心理層面——團隊有正常的護犢子情緒
自己親手做的產品就像自己的孩子一樣，每個父母看自己的孩子都是最好的。在人家孩子生下來之後，你再過去指手畫腳的說：「你們家的孩子咋回事？怎麼這麼醜？」——肯定會被孩子的父母一陣埋怨和敵視、敵對。
同理，當產品已經在驗證階段時，再提出的任何關於使用者體驗方面的建議，非常容易導致問題的公升級或發散，反而不利於真實問題的解決，也不利於跨部門的溝通交流。
常見的語言場景如下：
「為什麼現在才提意見和建議，在需求評審的時候你們幹什麼去了？」
「到底是你們理解客戶還是我們理解客戶，多去客戶現場體驗一下，不要拍腦袋」
「非常感謝提出的意見，後續版本我們會進行整體評估和考慮」
「我們辛辛苦苦的在開發產品，拿出來之後還要被人指指點點的，真沒意思」
「挑毛病誰不會，我們又沒有巨頭公司的積累和實力，做產品要務實，不要盲目的好高騖遠」
能在產品發布階段再搞定使用者體驗調整的工作，要麼是有決策權的領導，要麼是溝通技巧非常高的人——往往具有這種溝通力、影響力的人，會在更能體現價值的崗位上，比如銷售/售前，而不是驗證階段的某角色。
二、面子因素
大家都是同事，對別人的工作成果進行否定或不認可，這種話說出去感到非常傷人，風水輪流轉，說不定後面會有事相求，礙於面子，使用者體驗只會說不錯，不錯，挺好，挺好。
所以在使用者體驗環節，很多真實的問題和想法，也會被特意的隱藏起來，得到的只是乙個泛泛而言的不錯，較好的結論。更容易看做是流程和環節本身，是產品的易用性和效率提公升，沒有絲毫幫助。
同理，公司內部的各種問卷調查，比如a部門調研b部門，或者c部門請其他部門來給自己打分，進行360°考評——基本上不會有特別好或特別差的結果，大多是75-85分的水平，也是同樣的道理。
三、專案資源因素
認同產品待改進，但是各種資源實在有限，比如技術積累、團隊人員配置、專案預算、專案計畫進度等等。所以很多人提建議的積極性，慢慢的會被打消，反正都是無法落地無法實現，為什麼還要一次次的去提呢。
常見的語句如下：
「動動嘴容易，改起來很麻煩，體諒一下開發人員的壓力」
「系統框架決定了實現方式，過兩年我們重構時在考慮整合」
「你看xx公司有xx人在做這一塊，我們只有xx人，所以要拿出一樣或者差不多的產品，肯定是不現實的，我們要慢慢的來。」
從另外乙個角度，如果在此階段，真的還能對產品產生較多的修改，這種事後修改設計的方式，會嚴重打擊開發人員的鬥志，產生消極的心態——我怎麼做都無所謂，反正最好boss或產品經理還是會根據自己的喜好，對產品指手畫腳。所以，現在隨便做做，不用較真，最後再修改一次才能解決問題。
所以在產品驗證環節，應該把精力集中在如何驗證產品設計的完成性，產品包的完備性。在這個階段，試圖對產品的易用性和品質提公升做一些工作，往往會事倍功半。
產品開發的完整環節
如果產品設計不合理，那後果是最嚴重的 要麼考慮不全，做出來的東西無法滿足要求甚至漏洞百出 要麼不切實際，實際開發過程中困難重重 要麼擴充套件性不好，導致後期增加 修改功能時必須得全部重做 要麼使用者體驗不好，被使用者吐槽 難以使用。下面描述了完整的產品環節 具體細節並不完整 1 需求收集階段，廣泛徵...
產品生產環節的一些名詞
例如，我們要出產商用的手機，將涉及到一些名詞，這些名稱通常只在oem和odm中出現，然現在的裝置，尤其是定製裝置的生產，我們有機會加入其中。下面是有關的一些流程。這裡的收集來自網際網路，不過沒有記錄下 也懶得再去找了。按流程的時間順序 evt engineering verification tes...
產品生產環節的一些名詞
例如，我們要出產商用的手機，將涉及到一些名詞，這些名稱通常只在oem和odm中出現，然現在的裝置，尤其是定製裝置的生產，我們有機會加入其中。下面是有關的一些流程。這裡的收集來自網際網路，不過沒有記錄下 也懶得再去找了。按流程的時間順序 evt engineering verification tes...