JunChen在最近的一篇《為何XHTML原型會失敗》中說出了一個實質(zhì)問題，即在快速變化的互聯(lián)網(wǎng)公司中，非XHTML原型只是“看上去很美”而已。

　　究其原因。除了JunChen提到的“難以維護”以外，對設(shè)計和開發(fā)人員精力的消耗也是一個重要方面。

　　讓我們來看一個典型的流程：

　　用戶研究員進行用戶研究，根據(jù)結(jié)果編寫了研究報告（比如角色模型和使用場景）；
　　交互設(shè)計師按照用戶研究報告，設(shè)計了線框圖；
　　視覺設(shè)計師拿到線框圖，和交互設(shè)計師討論并溝通后，進行視覺設(shè)計并輸出高保真視覺原型；
　　前端開發(fā)工程師拿到視覺原型，在和交互設(shè)計師及視覺設(shè)計師溝通后，進行編碼工作，輸出HTML文件；
　　用戶研究員開始可用性測試，并將問題反饋給交互設(shè)計師；
　　回到第一步，直至用戶研究員（或其他的什么人）認為質(zhì)量合格。
　　這一看似合理的流水線作業(yè)存在什么問題呢？讓我們來仔細分析一下：

　　1、困惑的交互設(shè)計師
　　用戶研究是一個漸進式接近真相的過程，其結(jié)果不可能一步到位。尤其在研究初期，哪些因素會對產(chǎn)品設(shè)計有較大影響，哪些因素實際無足輕重，這是沒有辦法事先準確預(yù)估的。這就造成當交互設(shè)計師在依照研究結(jié)果設(shè)計時，發(fā)現(xiàn)研究結(jié)果不能給自己的設(shè)計以有力的支撐。

　　比如，當兩種交互方式都可以達到同樣目的、而從已有的數(shù)據(jù)中又無法判斷用戶會喜歡哪種時，交互設(shè)計師就會猶豫不決。從資源的角度來考慮，請研究員再一次制訂計劃、招募用戶并實施研究，是不太可能的；更不用說設(shè)計兩種原型并分別測試了。因此此時交互設(shè)計師只能依據(jù)自己的經(jīng)驗，或者進行押寶。

　　此外，交互設(shè)計師還面臨一個頗為尷尬的問題：由于處于流程中的中間環(huán)節(jié)，缺少堅實的硬性產(chǎn)出，他很難、甚至沒辦法證明自己的工作價值。一方面，交互設(shè)計是一種偏“軟”的技能，它目前沒有、將來也很難產(chǎn)生一個標準化的量尺來考量其自身的質(zhì)量。可用性測試可以做到部分量化，比如完成時間、出錯次數(shù)等，但十幾個人（一般甚至更少）的數(shù)據(jù)在統(tǒng)計學(xué)上是沒有任何意義的。而且，有多少用戶能理解那種低保真的原型呢？另一方面，就算用Axure等軟件制作可操作的原型然后拿去做測試，各個業(yè)務(wù)部門會相信測試結(jié)果么？沒錯，你可以強硬一些，比如采取“如果業(yè)務(wù)部門不參與觀察測試，就算自動放棄決策時的發(fā)言權(quán)”這樣的辦法，可這只能說你有工作方法，這實在無益于專業(yè)技能的提升。而且有多少設(shè)計師可以強勢到讓所有的業(yè)務(wù)部門閉嘴的？

　　實施社會分工的目的之一，就是實施標準化的作業(yè)。而當流水線中某一環(huán)節(jié)的產(chǎn)出物質(zhì)量，是隨著其作者的經(jīng)驗而變化時，也就是說質(zhì)量并不能定量控制時，分工的意義就不復(fù)存在，這一生產(chǎn)方式也就不可能按簡單復(fù)制的方式擴張規(guī)模。

　　2、交互、視覺和前端間的溝通成本，和可能的不愉快
　　在交互設(shè)計師和視覺設(shè)計師交接工作時，溝通不可避免。視覺設(shè)計師要充分領(lǐng)會交互設(shè)計師的意圖，這需要溝通；反過來視覺設(shè)計師給交互設(shè)計師的線框圖提意見，這也需要溝通。尤其在整個部門缺乏UI規(guī)范時，溝通成本可能會高得嚇人。比如交互設(shè)計師認為某處需要用3級標題（比如h3），到了視覺這里直接用了一行紅字。所以常常覺得“有那時間費力溝通，還不如直接改了算了”。結(jié)果改完了交互設(shè)計師心里會想“你怎么也不和我打聲招呼就改了”，不愉快就這么來了。

　　到了前端開發(fā)那里，問題就更復(fù)雜了。首先，前端開發(fā)需要實現(xiàn)所有細節(jié)，而出于資源上的考慮，這些細節(jié)未必都會由交互和視覺設(shè)計師的產(chǎn)出物覆蓋到（比如同一頁面上僅有一處文字有微小變化，那么線框圖和視覺稿要分別做兩份嗎？），那么前端開發(fā)就需要經(jīng)常和前面兩者溝通；其次，如果前端開發(fā)發(fā)覺設(shè)計稿的實現(xiàn)難度或成本太高，那么情況就更為棘手，最麻煩的莫過于要重新設(shè)計交互原型。

　　當然，上述問題基本都能靠溝通解決，問題是，你愿意花多少時間去溝通呢？從這個角度來說，敏捷開發(fā)的溝通成本是最低的，因為溝通就是產(chǎn)出。而反過來上述流程的溝通成本很高，因為溝通是用來解釋產(chǎn)出的，是產(chǎn)出成本之外的“額外成本”。

　　3、瀑布模型與生俱來的缺陷
　　上述流程是一個典型的瀑布模型，一旦在可用性測試階段發(fā)現(xiàn)問題，就需要重新再走整個流程，其效率之低可想而知。此外，由于涉及到的環(huán)節(jié)和人員不少，流程走得次數(shù)越多，出問題的機會也越多。最常見的是各個環(huán)節(jié)的產(chǎn)出物版本控制困難，甚至根本沒有版本控制，結(jié)果往往造成項目組中每個人拿到的產(chǎn)出物（如Demo）都不一樣，這是一個非?？膳碌娘L(fēng)險，會給項目過程和質(zhì)量帶來非常嚴重的影響。

　　我對這個問題采取過“文檔管理＋版本控制＋減少分工”的方法，效果很好。這個后文會闡述，這里先不展開。

　　4、無技術(shù)含量可言的重復(fù)勞動
　　在一些頁面調(diào)整不大的日常項目中，交互設(shè)計師用2小時做的原型，到了前端那里可能半個小時就把HTML搞定了，如果用CSSEdit那樣的工具，實現(xiàn)過程甚至更快、更愜意。那么，為什么要把原本一件很小的工作硬生生地拆成兩部分來做呢？

　　舉一個非常常見的例子：業(yè)務(wù)部門提需求說要改某某宣傳文案，如果按照上述流程，交互先做線框，給到視覺確認，然后到前端修改，往最快了說也得半小時吧。而若交互設(shè)計師直接改HTML，十分鐘搞定。

　　有人說找到相應(yīng)的模板還要時間呢，這好辦，做個可搜索的模板庫就好了。我們曾參考DocBlock規(guī)范做過VelocityDoc，效果很好。

　　5、破壞了網(wǎng)頁設(shè)計工作本身的美感
　　網(wǎng)頁設(shè)計是技術(shù)和藝術(shù)的結(jié)合，一個優(yōu)秀的設(shè)計師不僅大量吸收傳統(tǒng)的設(shè)計知識（如平面設(shè)計），更懂得如何利用合適的技術(shù)去帶來藝術(shù)上的創(chuàng)新。這個過程是相輔相成的，硬性拆開只會限制設(shè)計師的創(chuàng)造力。

　　這就好像搞油畫的必須要掌握不同染料和畫布的性質(zhì)，搞雕塑的既要有創(chuàng)意又有能動手（你能想象出一個雕塑家只管創(chuàng)意而從不親自去實現(xiàn)嗎）一樣，使用技術(shù)來展現(xiàn)藝術(shù)，借助藝術(shù)去探究可能的技術(shù)。

　　據(jù)說Apple的工業(yè)設(shè)計師都要清楚地理解各種材料的特點的，如果只讓他們畫圖，Unibody這樣的杰作又如何誕生？

　　說了半天問題，下篇中我們來看怎么解決。

　　原文：http://www.heartstringz.net/blog/posts/view/why-no-division-in-web-design-1