模塊化設計思路:好的原型文檔應該注意什么?
本文主要介紹了模塊化設計思路的定義和優勢,以及如何用模塊化設計思路來使文檔更易于閱讀。
很多人對程序員的刻板印象都是邏輯性強、機械、封閉、死板;至于用戶體驗這種事情,好像從來不是程序員擅長的。
但是我想說的是,其實很多產品經理和交互設計師在易讀性、易用性這塊,其基本功不如一個程序員。
如果把我們工作中輸出的文檔當做一個產品的話,那么文檔的讀者就是用戶,很多產品經理或交互設計師使用Axure或其他工具做的原型,可讀性遠不如程序員寫的代碼。
我們來看看下圖,很多產品經理或交互設計師的文檔就像這樣,我之前就有同事會輸出這種文檔。我們現在招聘看到的很多人的作品也是這種類型的文檔。(與文檔內容無關,不需要看清楚內容,所以圖片已做模糊處理)
厲害吧?酷炫吧?我能夠在一張圖上面駕馭這么復雜的邏輯和流程,看看我多么專業。
我只能呵呵一句,互聯網這個處處考慮用戶,連你工作的上下游都是你文檔的用戶的行業,真是不太適合你。
這種毫無模塊化思路的文檔,會造成團隊溝通上的困難,文檔難以維護,工作無法交接,而且會導致在做產品設計時思路混亂,漏洞百出。
如果你招聘時收到了這樣的作品文檔,請慎重。
模塊化的設計思路,如果你是一個邏輯性強且在乎讀者體驗的人,那么你自己工作中完全有可能摸索出來模塊化設計思路。
但是這種思路被運用得最成熟,被強制執行得最透徹的,是程序設計領域。
可惜的是,產品經理和交互設計師往往各種專業背景很雜,在一些基本功方面,沒有像程序設計那樣接受過系統的教育。
學過計算機課程的人應該都知道,模塊化設計思路是程序設計的第二課(第一課可能都是hello world吧 :))
因為程序開發是一個非常強調溝通協作的領域,所以程序代碼的易讀性是非常重要的。為了使程序易于理解,除了加注釋外,最重要的就是模塊化設計。
模塊化設計要求:
- 每段代碼長度不能超過長200行(不同團隊限制有所不同),超過必須重構。
- 盡可能將獨立的一段代碼封裝到獨立的模塊中去,然后再通過一行代碼調用此模塊。
- 模塊的含義要清楚明確,命名易于理解,模塊之間盡量減少關聯,低耦合。
程序設計對“用戶”體驗的要求都如此之高,可能會令很多產品經理和設計師汗顏。當然,模塊化程序設計的作用不僅僅是閱讀者體驗,在此不做討論。
很多程序員剛開始的時候,非常不習慣模塊化,喜歡把東西一股腦鋪出來,而且還認為代碼寫的看起來越復雜越能體現自己的水平,正如上圖中有些人的產品設計文檔一樣。
毫無模塊化的思路和模塊化的思路對比
我們來通過一個偽代碼的例子看看這種模塊化設計思路:
下圖是一個描述買房的流程,沒有模塊化,讓你在一個頁面看到所有的細節,看起來會讓人非常懵。你細細看一下會發現很復雜且很難理解,就像上面那張產品設計圖一樣。
同樣的流程,下圖模塊化之后,更便于閱讀理解,也更便于流程設計者反思:
作為產品設計,我們應該如何用模塊化設計思路來使文檔更易于閱讀
通過我的經驗積累發現:再復雜的交互文檔,都可以通過模塊化來使其清晰易懂。
- 學會拆分模塊;
- 考慮閱讀體驗,不要讓文檔橫向拖動;
- 一個模塊只描述一個主要的流程。
1. 學會拆分模塊
以Axure為例,做了一個簡單的樣例。
如圖所示,我們不要試圖在當前頁面中描述所有的內容。對于一些單獨頁面或流程,可以放到子頁面里。但是需要注意的是,不是任何內容都要放子頁面中,子頁面如果太多了,也會影響閱讀體驗。比如一些彈窗確認,彈窗浮層等等,直接在當前頁面描述就可以了。
2. 考慮閱讀體驗,不要讓文檔橫向拖動
閱讀文檔的時候,如果需要橫向拖動頁面,那么閱讀體驗會非常糟糕。尤其是需要在橫縱兩個維度上閱讀時,思路非常容易被打斷,而且看文檔時還會很容易看漏內容。
無論是手機還是PC機上,你的流程應該是從上到下描述的,而不是從左向右。這樣使你的文檔只要滾動鼠標滾輪就能閱讀。而且右側還可以放注釋說明,注釋說明區域與界面原型不會“打架”。
控制你原型界面的寬度,有些產品設計人員喜歡把原型做的非常寬,導致注釋在屏幕之外,閱讀文檔很難受。其實你完全可以把原型等比例縮小,不一定要完全按照實際像素。
3. 一個模塊只描述一個主要的流程
比如說,在拍攝視頻的子頁面中,只從上到下描述這個流程(UI flow),如果流程中有界面或子流程在當前頁面無法描述的,可以繼續建子頁面。
如下圖,簡化的流程示意(原流程實際上有十幾個步驟):
圖中選擇關聯好友實際上是一個相對獨立的流程,且流程比較麻煩,需要有篩選,查找好友等功能。該字段的描述不應該打擾你整個流程的描述,應該將其獨立為一個子模塊。這樣,你的流程描述就會非常清晰明,主次分明。
用這種思路,就能讓你的文檔閱讀者有更好的體驗。有些人可能擔心有些復雜的流程無法做到這種方式描述,但是實踐證明,所有的都可以,不用懷疑。就像再復雜的軟件程序代碼一樣,都可以拆解為易于理解的模塊。
總結
模塊化的思維,本質上是邏輯思維的一種;不僅僅只是程序員,產品經理和交互設計師也應該具有這種思維。這種思維無論是你解決問題,還是工作溝通協作,都是非常有用的。
如果你作為一個關注用戶體驗的產品或設計人員,自己輸入的文檔卻都不能關注閱讀者的體驗的話,那你如何能讓別人覺得你是有水平的呢?
本文由 @楓葉 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
其實 “一個新的模塊”和“一個新的功能” 這兩句話一樣嗎 我一個ui經常聽產品和我們說模塊和新功能都要搞混了0.0
是的,有時候項目太小了,我都直接按照描述頁面元素的思路來寫文檔,比較大的項目才能撐起模塊化
上次我去面試一個B端的產品經理,那個技術經理就說我的思維太過于線性思維,缺少模塊化思維。在此拜讀文章,謝謝分享
1、其實每個模塊,可以分為流程和功能點兩部分
流程為一個頁面,用于講解主流程,便于大家對整體邏輯的理解和評估工作
功能點其實就是文章中講到的,講復雜的功能拆分展示和描述
2、主要是為了讓合作更方便,作為產品也應該用產品思維對待這個事情,不同情況的解決辦法也不是一定的
第一點加的正確,有些頁面流程也很復雜,最好還是有頁面的流程表示一下,讀者易懂,單單泳道圖大體流程清楚了對應不了頁面~
不過對于展示同一個頁面的不同狀態(非點擊跳轉的流程)的情況,是不是橫向展示更容易觀看
核心目標是在于如何讓用戶更清晰的get到信息
對的
贊,學習了。
嗯哼
咋了~
面向模塊工作,贊
我一開始也是像你這樣分父子頁面做的,但開發和我反應他們不想點來點去…希望我們不要拆解而將流程都設計在一張圖上,也方便他們直接看圖評估工作量。
我覺得解決問題的更好方案還是提前做好組件的模塊化,方便開發的隨時調用,只關注業務流程邏輯即可。
我遇見的開發都非常喜歡模塊化文檔,這點我和開發明確溝通過。
你的情況有可能的原因:
1. 具體業務的不同,如果你們具體的業務的交互設計中,流程描述較少,而動態交互效果要求較高,那么確實沒有必要硬拆。
2. 可能是因為你模塊拆分不太合理,導致閱讀者頻繁切換。
3. 有可能參與的項目并不大,暫時還沒有模塊化的需要。對于一些大型一點的項目,模塊化更為重要。