交互設計師工作中的產出物

以下內容來自知乎,作者@MoonMonster,百度無線使用者體驗部交互設計師,上海MUX負責人。雷鋒網已取得作者授權,而對原回答做出適當編輯排版。

2012年的最後一天,年終總結應該成為過去式了。在業內每個領域、每個崗位都有自己的工作模式,包括「交互」這個人人都唉談及的工作,而我們可以從交互設計的平常工作中,瞭解交互工作的流程以及其所給出的交付產出物。

UE Team 內部工作流程

指導性的流程,實際操作中會有偏差,如任務緊急有些環節及review就會被跳過,大體是這樣一個流程。

UE團隊

UE Team 外部工作流程

簡陋版(複雜版估計看不懂了),表達出大體的意思,各方之間的職責及工作範圍。需求方要提供詳細的需求文檔(request doc),需求有變更需要被記錄(change request doc)、接受需求後進入內部流程並交付產出物給開發團隊(一堆doc,視覺都需要文檔化)。

開發團隊依據設計文檔交付版本,QA部依據設計文檔進行測試並回饋bug,UE繼續跟進,然後無限迴圈……. -_-’



UE團隊外部工作流程

產品Workflow文檔

這玩意除了我和開發其它人都不敢看,傷神!當初畫得這麼複雜也是有點報復心理 -_-’ 。交互人員請多畫畫workflow能幫你理清邏輯,但別像下圖這樣。

產品wordflow文檔

產品spec文檔

用來殺腦細胞的,為這頭髮白了不少!下圖是老的製作方法,完全手寫,後期就與原型一併產出了。詳細到介面上每個元素的具體定義及行為描述,Diagram圖的編號需要與上面的Workflow內的編號一致,方便開發人員查找!

有些同行說沒用、沒人看,但我的體會是寫個一年半載,整體設計能力將提升一個level,workflow文檔和spec文檔也可以考驗一個人的細膩程度,現在的基本功也是那時候練下來的。

產品spec文檔

Spec文檔細分

上面這個是大spec文檔,還包含一些其它部分的文檔。像之前我們的產品進行設計時是一個通用性的產品,當需要針對不同的客戶進行訂制化時,又將產生相應的Site Modification文檔 。

Spec文檔細分

產品原型

早些年做原型時基本以PPT進行產出,review時方便進行展示,後來也用Axure(算是國內較早一批使用Axure的使用者吧),由於前期流程比較扎實,review環節也比較多,我們製作原型時往往會產出高保真原型。另外,我們使用Axure製作原型除了看重它的交互性之外更重要的是它能方便匯出spec文檔。ps.現在已經較少用到了。

<a rel="attachment wp-att-204901" href="HTTP://www.alibuybuy.com/?attachment_id=204901">產品原型

工作資料目錄

做完一堆工作,產出N份文檔,需要有一個邏輯清晰的目錄管理,方便以後工作。下圖僅列出產品目錄,三個層級:產品名稱 》 文檔分類 》 具體目錄。 簡單、明瞭、命名清楚(相關人員只要看到文檔名就知道是哪個產品的哪份文檔以及版本情況,下面介紹)

工作資料目錄

文檔命名規範

這個是有大用處的東西!交付物從不同的設計人員手中產出,以文檔的形式進行存放,並且需要給不同部門、不同人員進行閱覽, 命名統一後管理方便、溝通一致。

文檔命名規範

羅列到這吧,除了上述這些,還有許多雜七雜八的文檔。

目前,市面上使用者體驗人員越來越多,設計師也越來越多,但… 對於流程、規範、交付物、都沒有太多介紹,不知道上面羅列的對各位有木有説明,各個公司都有各個公司的玩法,算是一個補充吧。

UX / UE / UCD / UED / PED … 我都浮雲了! 設計而已嘛,繼續加班 ……

ps. 轉載請注明作者,不然黑你家產品 (-」-)

作者博客:MoonMonster

 

特別注意:本站所有轉載文章言論不代表本站觀點,本站所提供的攝影照片,插畫,設計作品,如需使用,請與原作者聯繫,文章轉自alibuybuy

Comments are closed.