推薦：UI設計范式之三：實時預覽
問題綜述用戶總是希望第一時間就能知道自己填寫的表單遞交以后會是什么樣的結果。舉例適用范圍當你原意為用戶提供其填寫內容的實時預覽功能的時候當你覺得

　　WEB開發技術發展到現在已經有了越來越細化的分工，從90年代末，一個懂html代碼的人就能寫一個站，到現在，內容、架構、UI、前端、程序、UE、分析監測、SEO、推廣 都有了獨立而成熟的角色分工。隨著網站規模的增大、開發技術和標準的發展、運營過程中各類門檻性、專業性問題的解決需求增加，有一些新工種衍生出來，它們包括：內容設計師、架構設計師、前端技術工程師、網站分析師。這些基本是前端和內容部分的，技術部分的我就不敢說了。

　　內容設計師（網站策劃）和UE：

　　把內容設計和UE放在一起說是因為我認為UE應該做為是一種觀念來對待，是應該貫徹到包括內容設計、流程設計、用戶界面設計和前端技術等開發環節中的一種意識。

　　除了電子商務或者專門的應用服務類網站（比如SNS），大部分網站項目并不需要單獨的UE設計師，建議聘請可用性顧問來做培訓，指導參與用戶調研設計、可用性測試及分析交互模型設計等，并在開發過程中中分階段跟進，對設計產品做UE評測。

　　這點上，我同意一葉千鳥說的：“把職責分散給內容與UI設計師和PM，而不建議由專職UE團隊來把控產品質量，第一責任太大，第二職權失衡，第三增加治理成本，第四降低工作效率。”每個人都貫徹UCD來共同完成UE的工作，比把事情都交給用戶體驗工程師去做要有效得多。

　　內容設計是UI、 UE工作的上一環節，清楚明確的結構內容規劃直接影響網站所有前端層面的開發方向與規范。以前這塊工作多是由內容編輯人員或頁面設計師來做，在近兩年內，網站策劃這一工種慢慢獨立，多數是從這編輯、設計、營銷人員或者互聯網行業分析師中轉型出來。

　　很多項目中，PM在做著其中的一部分內容設計的工作，比如負責溝通，采集需求，確定網站的內容結構、風格、欄目、功能，制定網站策劃書。但是一但到達中型規模的網站項目，必定需要大量具體的描述型和圖形化文檔來需要規范相關環節的工作。幫助開發成員將需求分析結果更加明確化，實現文本備忘。

　　內容設計師應做的：

　　1. 明確的用戶需求，進行用戶需求調研，設計調查問卷或組織討論。撰寫《用戶需求分析報告》。
　　2. 進行市場調研，清楚的分析相似網站的性能和運行情況。撰寫相關《市場調研文檔》或《同類競爭對手分析文檔》。
　　3. 協調PM，組織相關開發人員與用戶一起進行需求分析，根據討論結果撰寫《網站功能描述文檔》，描述文檔中的相關部分可組織核心設計和程序共同編寫。
　　4. 根據項目需求和功能描述，生成高度結構化的文檔，并形成線框圖（頁面結構圖）。
　　5. 根據網站功能需求，配合UE顧問/工程師設計用戶交互模型，生成用戶任務的流程圖。
　　6. 結合項目需求，制定可用性改善目標，制定可用性基準。配合UE顧問/工程師，在用戶界面草圖階段，組織用戶做一次可用性評估。同UE顧問共同撰寫并分析評估報告。制定改善方案。

　　寫完一大溜內容設計師應該做的，就會發現這個工作主要做的是協調和文檔性工作，并不一定要求設計師去多懂設計、懂技術模塊、懂交互、懂可用性。但是一個合格的內容設計師，必須對這些相關的配合工種有所了解，并具備協同工作的能力。

　　許多網站中這部分工作都是由PM來做，或者由PM將工作拆散交給相關人員去做。PM應該做的工作是擔負與產品項目相關的項目治理職責，負責分工、聯絡、協調和驅動。控制進度、梳理各類分歧、監控項目質量。從策略高度對產品的長期發展戰略提出建設性意見，

　　PM是公司決策層與項目團隊之間的橋梁，而不應該埋頭于各類文檔，將橋梁延伸到更具體的內容設計中。

　　一個人參與到整個產品的支持是不合理的，讓專業的人做專業的事。

　　內容設計師相當于PM、設計、前端、架構、開發、和UE之間的匯聚點。在需求制定和內容決策期，組織各個部門留下清楚規范的指導性和備案性文檔。在聘請外部顧問的時候，尤其充當了做對定制化部分做需求描述與補充的重要角色，也就是自身需求與外部專業指導之間的橋梁。

　　各類文檔中，有很多部分需要相關技術人員去共同撰寫，內容設計師落實不了，沒有細化的文檔很快會被束之高閣。千萬不要把文檔都丟給一個人，大家腳翹在桌子上張張嘴開開會就算了。

　　很快又有人會說到內容設計師的控制權問題。爭論誰擁有對設計或內容的控制權是一個非常無聊的話題。假如你有足夠的說服力。決定交給對項目/產品負責的人去做。

　　原文：http://blog.hc1983.com/2007/07/15/28

分享：如何面對改版？
關于改版，在上一篇文章中我談到了三方面的內容：為什么要改版？期望達到的目標？如何改版？下面就這三方面（我考慮了下，增加了改版后的測試），結合聚會上