隨著原型應用的普及，越來越多的產品會採用原型設計來表述、完善整體需求，這樣做自然有其原因，但為何要進行原型設計呢？在回答這個問題前，首先要說一下溝通這個普遍存在的問題。
人們在溝通過程中，乙個人通常只能說出心中所想的80%，但對方聽到的最多只能是60%，聽懂的卻只有40%，結果執行時，只有20%了。心中的想法也許很完美，但執行起來卻差之千里，這是由「溝通的漏斗」造成的，因此必須採取適當的方法，去克服這一「漏斗」現象，也即所謂的溝通的成本，如何使溝通的成本降低，是很多產品人員一直追求的。
溝通的成本通常包含兩部分，一是溝通的時間成本，一是溝通的有效性，這裡不去說該如何去進行溝通前的準備，或者溝通過程的控制，單純從如何降低溝通成本的角度，結合原型的應用來分析。時間成本一般都為人所知了，這裡就如何提供溝通有效性上進行分析，即如何降低溝通的漏斗效果。
首先需要達成的乙個共識就是，借助輔助介質的溝通會比單純的對話來的更有效果，在這基礎上，來說明輔助介質的重要性。產品在設計過程當中，需要經常和使用者，開發，測試就產品的各種問題進行溝通，這些溝通的過程中，有輔助介質的溝通會有效的多，比如需要向使用者說明設計方案的時候，單純的口頭溝通，肯定沒有有實質交付物的溝通來的順暢，這裡的實質交付物可以是文件、草圖、原型，而原型則比前兩者要好，首先文件是要靠文字描述出來的，文字描述會有歧義，且長篇累牘的文件會降低使用者認真閱讀的積極性，文件還有乙個缺陷就是會夾雜文件編寫人員的個人因素在裡面，無法完全細緻的把每個功能點都提到或者都描述清楚；草圖顧名思義只是一種很簡單的效果，最多只能描述出乙個主題的框架，具體到每個功能點的時候是無法表述出來的；原型因為效果接近模型，甚至可以做到和demo差不多，可以給使用者乙個非常直觀的感受，細到每個功能點，每個互動，都可以在原型上表現出來，這樣在溝通的過程中就能大大減少溝通的時間，且能借助原型的展示，降低溝通與實際的差異。
原型的製作成本和演示成本都比較低，除非比較複雜或者保真度要求比較高的原型，在描述乙個功能的時候，可能花了很多時間仍不能完全描述清楚，且使用者理解能力上的差異，必然效果不會好，有原型的演示的話，一目了然，使用者可以根據自身的判斷，再結合演示者的描述，理解起來就不那麼費勁了。原型還有乙個好處就是能吸引到演示物件的注意力，一般的溝通會如果沒有依託任何介質的講話，效果往往不好，下面的人各幹各的，但如果有ppt或者原型在上面演示，必然能引起大家的注意力，我想這點是大家感同身受的。
原型的好處我在介紹axurerp的文章裡面其實也有提到過，這裡是純粹的從溝通的角度去考慮，其實如果大家用過原型去做演示的話，就會知道其確實是可以提高溝通的效果的。影響溝通的因素有很多，如果各個方面都能做到最好，那是自然能降低溝通成本的。原型作為溝通的輔助介質，能讓使用者更好的表達自己的想法，讓聽眾接受更多的資訊，理解更多的資訊，發揮了很好的作用。
Julia 為什麼要設計nothing
julia中的nothing是什麼玩藝？簡單地說，就是不返回值。為什麼要這個呢？你看一下。情況一 f 裡面，事實上，有沒有nothing，沒有什麼差別 function f a for i in eachindex 1 10 a 1 1 end nothing for 循還外，預設不返回值。end情...
為什麼要設計JAVA異常
從業這麼多年，每當談起異常，都是懵懵懂懂，只是依稀記得它是處理錯誤的，當程式出錯，日誌裡會有異常日誌，可以檢視異常定位錯誤。但是最近突然發現乙個問題，那就是處理錯誤不一定非的要用異常啊，比如說引數合法性檢查等等，判斷是否為空後直接返回校驗資訊等，通過程式的各種手段都可以處理，那麼為什麼要用異常呢？它...
為什麼要學習設計模式
廢話不想多說，就說關鍵讓你信服。前情一 上班後，很多時候首先就需要熟悉公司專案的 工程，裡面一大批分支，一大堆 檔案，看著都頭疼，這對於程式設計新手初級程式設計師來說想要短時間弄透它的結構是多麼難的一件事啊。如果你熟練設計模式，那問題就不大了，首先大框架如果是mvc模式那簡直是乙個通透啊，資料管理檔...