產(chǎn)品經(jīng)理和設(shè)計(jì)師看一下：

iOS人機(jī)界面指導(dǎo)手冊（iOS Human Interface Guideline ） 在線地址：http://t.cn/hb5g1R （點(diǎn)右側(cè)PDF可直接下載） 

一個(gè)不錯(cuò)的中文翻譯：http://xuexiao.me/2011/03/ios-human-interface-guidelines/

 安卓設(shè)計(jì)指導(dǎo)（Android Design） 在線地址：http://developer.android.com/intl/zh-CN/design/index.html 

一個(gè)不錯(cuò)的中文翻譯：http://www.topfun.us/adchs/index.html

講到移動設(shè)備的轉(zhuǎn)場設(shè)計(jì)，我們先來看看移動設(shè)備。 移動設(shè)備有三個(gè)主要的特點(diǎn)：

1. 屏幕小，相對于普通的PC來看移動設(shè)備的屏幕相對要小很多。

2. 使用環(huán)境多變，由于移動設(shè)備便攜的特點(diǎn)我們會在各種環(huán)境中使用。

3. 由于屏幕小一次展示的內(nèi)容少加上各種不穩(wěn)定操作環(huán)境，軟件上有簡單易學(xué)易于操作的特性

回到正題來看轉(zhuǎn)場 說到“轉(zhuǎn)場”一般都會想到電影和PPT里面的轉(zhuǎn)場，

下面來看轉(zhuǎn)場在這兩個(gè)領(lǐng)域的定位和作用

隨著互聯(lián)網(wǎng)信息爆炸式增長，用戶瀏覽單個(gè)網(wǎng)頁時(shí)，并不像我們想象的如閱讀文章般從左到右、從上倒下逐一查看，為什么？

一、 視覺層級為什么重要

左側(cè)是設(shè)計(jì)師期望用戶的瀏覽方式，右側(cè)為用戶實(shí)際的瀏覽方式—摘自《Don’t make me think》

用戶來到一個(gè)網(wǎng)站有他自己特定的目標(biāo)，如閱讀新聞、購物、查看新消息，然而信息量太大，逐一查看需要大量時(shí)間，這就要求網(wǎng)站能抓住主流用戶特征，將重點(diǎn)推送給他，用戶找到自己的目標(biāo)或感興趣的點(diǎn)，才有可能繼續(xù)瀏覽或產(chǎn)生下一步動作，否則就會離開。

用戶時(shí)間有限加上互聯(lián)網(wǎng)信息量巨大，這兩項(xiàng)原因正是考驗(yàn)視覺設(shè)計(jì)師要建立良好的視覺層級呈現(xiàn)給用戶，幫助用戶快速找到目標(biāo)的功力。

總結(jié)一下，建立有效的視覺層級主要從以下四個(gè)方面著手：

1、簡約： 有選擇的展現(xiàn)信息，讓用戶在有限的信息中發(fā)現(xiàn)重點(diǎn)

2、組織： 預(yù)先對信息進(jìn)行科學(xué)的分類，整理好優(yōu)先級，可以得到更好的傳播效果

3、呈現(xiàn)： 多種表現(xiàn)方法結(jié)合，呈現(xiàn)最好的視覺層級效果，這個(gè)點(diǎn)細(xì)化后有很多可挖，這里總結(jié)了幾個(gè)點(diǎn)，歡迎繼續(xù)哈

4、引導(dǎo)： 遵循用戶習(xí)慣，同時(shí)給予適當(dāng)?shù)囊龑?dǎo)推薦

　怎樣的設(shè)計(jì)能給人留下深刻印象？

　　名人效應(yīng) （借助名人或明星效應(yīng)，產(chǎn)生不言而喻的說服力）

　　每人內(nèi)心都有自己仰慕或效仿的對象，而且有一種想盡可能地向他靠近的心理欲求，從而獲得心理上的滿足。在選擇人物形象時(shí)必須要與產(chǎn)品的品格相吻合、使用戶快速理解產(chǎn)品傳遞的特點(diǎn)和價(jià)值，比如我們以往的設(shè)計(jì)作品中經(jīng)常會使用到馬云的形象，他在互聯(lián)網(wǎng)具有極高的話語權(quán)，選擇用他的形象來推廣產(chǎn)品能產(chǎn)生不可言喻的說服力，當(dāng)然你不能濫用。

　　時(shí)勢結(jié)合 （緊隨潮流，激發(fā)思想和感情上的共鳴）

　　結(jié)合當(dāng)前社會事件如釣魚島、奧運(yùn)會、中秋節(jié)、中國好聲音等等，或當(dāng)下流行的語言詞匯如屌絲、高富帥、白富美等等，緊隨潮流的事物反應(yīng)當(dāng)下的社會形態(tài)，潛移默化的感染到用戶的思想或感情，產(chǎn)生震撼和共鳴。下面的例子就是結(jié)合現(xiàn)在最流行最熱門的節(jié)目“中國好聲音”。

［總結(jié)］：在用戶的視角來看，我們也希望他看到的都是最簡單最愉悅的一面。作為客戶培訓(xùn)師，你不需要知道產(chǎn)品數(shù)據(jù)在我們后臺是存儲在什么服務(wù)器的。用戶搜索產(chǎn)品時(shí)，也更加不需要了解一個(gè)檢索詞是經(jīng)過了多少詞解析判斷計(jì)算，跑了幾臺服務(wù)器，最終把結(jié)果呈現(xiàn)給他的。但是作為工作人員，我們得了解需要怎么做，才能夠把最簡單最愉悅的結(jié)果呈現(xiàn)出來。（Heidi注：如圖5所示）

圖5：簡明網(wǎng)站產(chǎn)品建設(shè)流程圖

這個(gè)圖呈現(xiàn)的流程，依賴于多個(gè)部門的通力合作。從戰(zhàn)略層高瞻遠(yuǎn)矚的判斷、從產(chǎn)品經(jīng)理對于市場的分析以及功能、內(nèi)容的規(guī)劃、描述，到用戶體驗(yàn)團(tuán)隊(duì)，開發(fā)和測試團(tuán)隊(duì)的全力配合，而網(wǎng)站產(chǎn)生后，還要依賴于SEO、市場營銷、銷售和客服的工作。

成功的網(wǎng)站，一定是多個(gè)部門一起圍繞相同目標(biāo)運(yùn)作的結(jié)果，但是其中一個(gè)環(huán)節(jié)失敗，則可能會造成全盤皆輸。

本文雖然篇幅已經(jīng)很長，但是涉及到具體的流程、方法，都只能簡單帶過，希望大家要記住這是對話的場景，不要以偏概全哦。
你對他提出的問題，想如何回答呢？如果你有問題，質(zhì)疑，鼓勵(lì)……歡迎交流。

離開交互圈已經(jīng)有段時(shí)間了。但由于博客還在，還是能夠偶爾收到一些郵件，上周有位同學(xué)問我：我在求職，我看到很多招聘說明上需要交互設(shè)計(jì)師編寫界面交互設(shè)計(jì)文檔 ，請問界面交互設(shè)計(jì)文檔是什么文檔？怎么編寫呢

 

所謂DRD即是用來承載交互說明，并交付給前端、測試以及開發(fā)工程師參考的文檔。

 

在項(xiàng)目中，交互設(shè)計(jì)師的主要產(chǎn)出物可能依次是：site map，page flow，wireframes。有的大型項(xiàng)目前期，交互設(shè)計(jì)師有可能還會產(chǎn)出用戶需求分析文檔（與PD產(chǎn)出的市場需求文檔不一樣的是，URD更多側(cè)重于對目標(biāo)用戶的需求分析）。

 

DRD則很少有人專門撰寫。如果需要對交互設(shè)計(jì)進(jìn)行說明，聰明的交互設(shè)計(jì)師往往會直接標(biāo)注在線框圖里，或者在項(xiàng)目中不斷和前端工程師和開發(fā)工程師口口相傳，反復(fù)驗(yàn)收，不斷迭代修改來確保所有的交互設(shè)計(jì)意圖最終得以呈現(xiàn)。

二. 為什么要寫？

 

DRD非項(xiàng)目必需環(huán)節(jié)，一般情況下也不會為交互設(shè)計(jì)師專門留出相應(yīng)的時(shí)間預(yù)估。沒有這份文檔，項(xiàng)目也會繼續(xù)，但是可能項(xiàng)目會為此承擔(dān)不必要的溝通成本和時(shí)間成本。嚴(yán)重的話，項(xiàng)目的質(zhì)量也會受到影響。所以寫與不寫，交互設(shè)計(jì)師需要做把握，時(shí)間被統(tǒng)一包含在“線框圖”環(huán)節(jié)內(nèi)——如果你要寫，請?jiān)谠u估時(shí)預(yù)留1-2天的時(shí)間。

 

那么，結(jié)合我過去的經(jīng)歷，談一下此文檔的必要性。

 

下圖是一個(gè)產(chǎn)品開發(fā)項(xiàng)目基本的流程。

 

敏捷開發(fā)意味著很多不同角色的流程需要并行操作。如果等到產(chǎn)品經(jīng)理的FRD已經(jīng)全部敲定，交互設(shè)計(jì)師再開始去畫線框圖，固然會減少溝通成本和返工風(fēng)險(xiǎn)，但是同時(shí)意味著交互設(shè)計(jì)師的很多想法不被采納。如果產(chǎn)品經(jīng)理再強(qiáng)一些，他甚至?xí)贔RD里連原始的DEMO也一并繪制出來了，功能性的需求和界面交互的需求有時(shí)無法區(qū)分太清楚——比如他會在FRD里直接要求每頁條目40條，超過40條即分頁。而交互設(shè)計(jì)師可能會認(rèn)為像蘑菇街那樣不斷裝載出足夠長的頁面會更親和……所以，我們希望是和產(chǎn)品經(jīng)理同時(shí)開始工作，在術(shù)業(yè)有專攻的時(shí)候相互補(bǔ)充。

 

同樣，開發(fā)工程師也希望及早介入需求，在FRD并未確認(rèn)的時(shí)候就了解需求，進(jìn)而將商業(yè)需求和功能需求轉(zhuǎn)化為開發(fā)工程師看得明白的開發(fā)需求清單（這個(gè)清單，大部分叫做UC，即USE CASE）,當(dāng)這份清單由工程師需求分析師——在過去，這個(gè)角色被叫簡稱為RA，但是目前已經(jīng)取消此專門的職位，而是由開發(fā)工程師代表擔(dān)綱此環(huán)節(jié)工作，為了便于描述，在此文里，我仍然將做這件事情的人稱為RA——交付給具體的執(zhí)行工程師后，執(zhí)行工程師基本上可以當(dāng)作一條條的checklist開始工作，而不必再思考商業(yè)邏輯和需求。同樣，測試工程師也需要編寫具體的文檔去指導(dǎo)很多測試人員在開發(fā)后測試，這也是基于UC和FRD去撰寫的。