推薦：UI設(shè)計(jì)范式之三：實(shí)時(shí)預(yù)覽
問題綜述用戶總是希望第一時(shí)間就能知道自己填寫的表單遞交以后會(huì)是什么樣的結(jié)果。舉例適用范圍當(dāng)你原意為用戶提供其填寫內(nèi)容的實(shí)時(shí)預(yù)覽功能的時(shí)候當(dāng)你覺得

　　WEB開發(fā)技術(shù)發(fā)展到現(xiàn)在已經(jīng)有了越來越細(xì)化的分工，從90年代末，一個(gè)懂html代碼的人就能寫一個(gè)站，到現(xiàn)在，內(nèi)容、架構(gòu)、UI、前端、程序、UE、分析監(jiān)測(cè)、SEO、推廣 都有了獨(dú)立而成熟的角色分工。隨著網(wǎng)站規(guī)模的增大、開發(fā)技術(shù)和標(biāo)準(zhǔn)的發(fā)展、運(yùn)營過程中各類門檻性、專業(yè)性問題的解決需求增加，有一些新工種衍生出來，它們包括：內(nèi)容設(shè)計(jì)師、架構(gòu)設(shè)計(jì)師、前端技術(shù)工程師、網(wǎng)站分析師。這些基本是前端和內(nèi)容部分的，技術(shù)部分的我就不敢說了。

　　內(nèi)容設(shè)計(jì)師（網(wǎng)站策劃）和UE：

　　把內(nèi)容設(shè)計(jì)和UE放在一起說是因?yàn)槲艺J(rèn)為UE應(yīng)該做為是一種觀念來對(duì)待，是應(yīng)該貫徹到包括內(nèi)容設(shè)計(jì)、流程設(shè)計(jì)、用戶界面設(shè)計(jì)和前端技術(shù)等開發(fā)環(huán)節(jié)中的一種意識(shí)。

　　除了電子商務(wù)或者專門的應(yīng)用服務(wù)類網(wǎng)站（比如SNS），大部分網(wǎng)站項(xiàng)目并不需要單獨(dú)的UE設(shè)計(jì)師，建議聘請(qǐng)可用性顧問來做培訓(xùn)，指導(dǎo)參與用戶調(diào)研設(shè)計(jì)、可用性測(cè)試及分析交互模型設(shè)計(jì)等，并在開發(fā)過程中中分階段跟進(jìn)，對(duì)設(shè)計(jì)產(chǎn)品做UE評(píng)測(cè)。

　　這點(diǎn)上，我同意一葉千鳥說的：“把職責(zé)分散給內(nèi)容與UI設(shè)計(jì)師和PM，而不建議由專職UE團(tuán)隊(duì)來把控產(chǎn)品質(zhì)量，第一責(zé)任太大，第二職權(quán)失衡，第三增加治理成本，第四降低工作效率�！泵總�(gè)人都貫徹UCD來共同完成UE的工作，比把事情都交給用戶體驗(yàn)工程師去做要有效得多。

　　內(nèi)容設(shè)計(jì)是UI、 UE工作的上一環(huán)節(jié)，清楚明確的結(jié)構(gòu)內(nèi)容規(guī)劃直接影響網(wǎng)站所有前端層面的開發(fā)方向與規(guī)范。以前這塊工作多是由內(nèi)容編輯人員或頁面設(shè)計(jì)師來做，在近兩年內(nèi)，網(wǎng)站策劃這一工種慢慢獨(dú)立，多數(shù)是從這編輯、設(shè)計(jì)、營銷人員或者互聯(lián)網(wǎng)行業(yè)分析師中轉(zhuǎn)型出來。

　　很多項(xiàng)目中，PM在做著其中的一部分內(nèi)容設(shè)計(jì)的工作，比如負(fù)責(zé)溝通，采集需求，確定網(wǎng)站的內(nèi)容結(jié)構(gòu)、風(fēng)格、欄目、功能，制定網(wǎng)站策劃書。但是一但到達(dá)中型規(guī)模的網(wǎng)站項(xiàng)目，必定需要大量具體的描述型和圖形化文檔來需要規(guī)范相關(guān)環(huán)節(jié)的工作。幫助開發(fā)成員將需求分析結(jié)果更加明確化，實(shí)現(xiàn)文本備忘。

　　內(nèi)容設(shè)計(jì)師應(yīng)做的：

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

　　寫完一大溜內(nèi)容設(shè)計(jì)師應(yīng)該做的，就會(huì)發(fā)現(xiàn)這個(gè)工作主要做的是協(xié)調(diào)和文檔性工作，并不一定要求設(shè)計(jì)師去多懂設(shè)計(jì)、懂技術(shù)模塊、懂交互、懂可用性。但是一個(gè)合格的內(nèi)容設(shè)計(jì)師，必須對(duì)這些相關(guān)的配合工種有所了解，并具備協(xié)同工作的能力。

　　許多網(wǎng)站中這部分工作都是由PM來做，或者由PM將工作拆散交給相關(guān)人員去做。PM應(yīng)該做的工作是擔(dān)負(fù)與產(chǎn)品項(xiàng)目相關(guān)的項(xiàng)目治理職責(zé)，負(fù)責(zé)分工、聯(lián)絡(luò)、協(xié)調(diào)和驅(qū)動(dòng)�？刂七M(jìn)度、梳理各類分歧、監(jiān)控項(xiàng)目質(zhì)量。從策略高度對(duì)產(chǎn)品的長(zhǎng)期發(fā)展戰(zhàn)略提出建設(shè)性意見，

　　PM是公司決策層與項(xiàng)目團(tuán)隊(duì)之間的橋梁，而不應(yīng)該埋頭于各類文檔，將橋梁延伸到更具體的內(nèi)容設(shè)計(jì)中。

　　一個(gè)人參與到整個(gè)產(chǎn)品的支持是不合理的，讓專業(yè)的人做專業(yè)的事。

　　內(nèi)容設(shè)計(jì)師相當(dāng)于PM、設(shè)計(jì)、前端、架構(gòu)、開發(fā)、和UE之間的匯聚點(diǎn)。在需求制定和內(nèi)容決策期，組織各個(gè)部門留下清楚規(guī)范的指導(dǎo)性和備案性文檔。在聘請(qǐng)外部顧問的時(shí)候，尤其充當(dāng)了做對(duì)定制化部分做需求描述與補(bǔ)充的重要角色，也就是自身需求與外部專業(yè)指導(dǎo)之間的橋梁。

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

　　很快又有人會(huì)說到內(nèi)容設(shè)計(jì)師的控制權(quán)問題。爭(zhēng)論誰擁有對(duì)設(shè)計(jì)或內(nèi)容的控制權(quán)是一個(gè)非常無聊的話題。假如你有足夠的說服力。決定交給對(duì)項(xiàng)目/產(chǎn)品負(fù)責(zé)的人去做。

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

分享：如何面對(duì)改版？
關(guān)于改版，在上一篇文章中我談到了三方面的內(nèi)容：為什么要改版？期望達(dá)到的目標(biāo)？如何改版？下面就這三方面（我考慮了下，增加了改版后的測(cè)試），結(jié)合聚會(huì)上