降低項目溝通成本和風險:寫好互動設計說明文檔

來源:互聯網
上載者:User

文章描述:如何寫一份互動說明文檔.

離開互動圈已經有段時間了。但由於部落格還在,還是能夠偶爾收到一些郵件,上周有位同學問我:我在求職,我看到很多招聘說明上需要互動設計師編寫介面互動設計文檔,請問介面互動設計文檔是什麼文檔?怎麼編寫呢?

這讓我想起來2009年自己在項目裡也大力推行過互動說明文檔(在下文中,簡稱為DRD),格式倒沒什麼限制,互動設計師自己寫到介面上也行,單獨文檔成文也行,總之就是讓互動設計師能夠將介面承載不了的資訊通過文檔沉澱下來,降低項目裡的溝通成本和風險。今天整理電腦,翻出以前的PPT,分享之。

這將涉及到幾個問題:

一、什麼是互動說明文檔(DRD)?

所謂DRD即是用來承載互動說明,並交付給前端、測試以及開發工程師參考的文檔。

在項目中,互動設計師的主要產出物可能依次是:site map,page flow,wireframes。有的大型項目前期,互動設計師有可能還會產出使用者需求分析文檔(與PD產出的市場需求文檔不一樣的是,URD更多側重於對目標使用者的需求分析)。

DRD則很少有人專門撰寫。如果需要對互動設計進行說明,聰明的互動設計師往往會直接標註線上框圖裡,或者在項目中不斷和前端工程師和開發工程師口口相傳,反覆驗收,不斷迭代修改來確保所有的互動設計意圖最終得以呈現。

二、 為什麼要寫?

DRD非項目必需環節,一般情況下也不會為互動設計師專門留出相應的時間預估。沒有這份文檔,項目也會繼續,但是可能項目會為此承擔不必要的溝通成本和時間成本。嚴重的話,項目的品質也會受到影響。所以寫與不寫,互動設計師需要做把握,時間被統一包含在“線框圖”環節內——如果你要寫,請在評估時預留1-2天的時間。

那麼,結合我過去的經曆,談一下此文檔的必要性。

下圖是一個產品開發項目基本的流程。

敏捷開發意味著很多不同角色的流程需要並行操作。如果等到產品經理的FRD已經全部敲定,互動設計師再開始去畫線框圖,固然會減少溝通成本和返工風險,但是同時意味著互動設計師的很多想法不被採納。如果產品經理再強一些,他甚至會在FRD裡連原始的DEMO也一併繪製出來了,功能性的需求和介面互動的需求有時無法區分太清楚——比如他會在FRD裡直接要求每頁條目40條,超過40條即分頁。而互動設計師可能會認為像蘑菇街那樣不斷裝載出足夠長的頁面會更親和……所以,我們希望是和產品經理同時開始工作,在術業有專攻的時候相互補充。

同樣,開發工程師也希望及早介入需求,在FRD並未確認的時候就瞭解需求,進而將商業需求和功能需求轉化為開發工程師看得明白的開發需求清單(這個清單,大部分叫做UC,即USE CASE),當這份清單由工程師需求分析師——在過去,這個角色被叫簡稱為RA,但是目前已經取消此專門的職位,而是由開發工程師代表擔綱此環節工作,為了便於描述,在此文裡,我仍然將做這件事情的人稱為RA——交付給具體的執行工程師後,執行工程師基本上可以當作一條條的checklist開始生產力,而不必再思考商業邏輯和需求。同樣,測試工程師也需要編寫具體的文檔去指導很多測試人員在開發後高效測試,這也是基於UC和FRD去撰寫的。

所以,開發需求分析是個很重要的環節。那RA是如何來完成需求分析工作的呢?

1、前期介入,對PD進行開發需求評估支援;

2、參與每次的FRD評審會;

3、詳細審閱FRD文檔並不斷與PD確認。

對於做這件事情的人來說,足夠詳盡的FRD是非常重要的。所以一份FRD雖然是PD產出,但是很多實施細節則是由開發工程師不斷溝通評估並確認下來的。而設計需求的傳遞,卻存在很多問題。除了線框圖,沒有“詳盡的說明性的文檔”告訴他們。比如:

一方面,互動設計師對產品經理說:這塊由我們來考慮,你的文檔不必包含設計上的說明,這隨時會調整的。

另一方面,線框圖的評審有時會讓RA參與,有時卻沒有叫他們。即使叫上了他們,他們也會發現互動設計的需求變化要比FRD變化快。另外,他們會認為UC不必寫太多關於互動設計的需求。

在某個大型項目結束後,作為互動設計師,我進行了一些調研,聽聽這相關人員是怎麼表述問題的:

開發部門的需求分析師:

1、每次變動都很痛苦,設計變了之後,我就要跟著改UC,改截圖,有時候UED改了還忘了通知我們,導致UC有問題……

2、頁面互動的需求容易漏掉,因為UC裡面不可能寫太多互動方面的東西。

3、希望UED能夠在提交HTML DEMO給RA時,能同時給出一份頁面元素描述文檔,需要介紹html demo中的文案、連結以及相關的圖片尺寸或顯示字元個數。現在RA在這方面花費的時間比較多,經常要和UED去確認這些內容。

產品經理:

前期RA和PD溝通過程中,有很多互動點點不能夠明確,比如“預設顯示多少屬性值”,“標題顯示多少字元”等。在以往的需求和項目中,對待這些問題我們都是想到一點補一點的到FRD文檔或者郵件中去。既增加了溝通成本又會存在遺漏細節的風險。PD為了可控性的需求,往往會“越俎代庖”,直接在FRD註明這種需求(對於互動設計師來講,卻又導致沒有發揮餘地)

走訪了一些互動設計師後,他們也存在如何清晰無遺漏將互動設計需求傳遞下去的困惑:

互動認為很平常的設計需求,如果不表達出來,還是容易被前端和開發忽略掉。我經曆的一個項目,前端從頭到尾更換了三個人,每次我都要重複去講解下設計需求,講得口乾舌燥。而且做好後,還需要去驗收。

DRD做為參考手冊,一定程度上避免不吻合的問題發生。

即使有問題發生,也可以作為介面驗收時的Checklist。將“我對A說,我對B說,A對B說”,轉變為“A和B共同參考同一份文檔”,減少溝通成本及資訊不對稱。

全程影響使用者體驗(一直到測試,都需要參照設計文檔)。

可是以下問題都可以通過一份DRD來解決嗎?

[1] [2] [3]  下一頁



相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

11.11 Big Sale for Cloud

Get Unbeatable Offers with up to 90% Off,Oct.24-Nov.13 (UTC+8)

Get It Now >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。