B端交互|全局框架制定·終篇
組件固然重要,但在交互設(shè)計(jì)中,頁(yè)面的布局和樣式統(tǒng)一更為重要,因此需要制定一個(gè)全局的框架,它是提升效率的一大法寶,但需要一定的經(jīng)驗(yàn)和想法才能夠更加熟練地完成。作者結(jié)合自己的經(jīng)驗(yàn),分享了全局框架制定的步驟,希望對(duì)你有所啟發(fā)。
一、項(xiàng)目的頁(yè)面類(lèi)型設(shè)定
組件雖然是非常重要的內(nèi)容,但全局要素中并不是僅僅關(guān)注它就夠了,還需要關(guān)注關(guān)注項(xiàng)目中應(yīng)用的頁(yè)面類(lèi)型。
不管有什么樣的需求還是功能,它們都是由具體的一些頁(yè)面類(lèi)型組合而成。比如一個(gè)大型項(xiàng)目中包含了數(shù)十上百個(gè)表格頁(yè)面,必然會(huì)有一部分頁(yè)面包含比較特別的操作還是交互。
如果沒(méi)有制定過(guò)比較統(tǒng)一的布局或交互形式,往往越做到后面越割裂,無(wú)法形成統(tǒng)一的體驗(yàn)。
所以,最理想的情況,就是設(shè)計(jì)師在交互制定過(guò)程中梳理會(huì)使用的頁(yè)面類(lèi)型,以及統(tǒng)一它們的交互、布局框架,盡可能保證不同頁(yè)面交互的一致性。
下面,我們就分別介紹一些常見(jiàn)的頁(yè)面類(lèi)型,和它們基本的交互特征。
1. 表盤(pán)頁(yè)面 Dashboard Page
表盤(pán)頁(yè)面主要是用來(lái)容納數(shù)據(jù)圖表和一些快捷功能的綜合頁(yè)面,它的主要特點(diǎn)就是 “碎”。因?yàn)楣δ芰闼榈奶匦?,?dǎo)致頁(yè)面要置入很多組件模塊。
所以在表盤(pán)類(lèi)頁(yè)面的搭建中,就是要應(yīng)對(duì)各種不確定的模塊組合。而應(yīng)對(duì)方式,就是提前確定出表盤(pán)頁(yè)面的布局模式,和一些固定的內(nèi)容模塊規(guī)格,讓它們可以根據(jù)需要有效拼裝。
首先是布局模式,多數(shù)情況下表盤(pán)頁(yè)面為了空間利用率會(huì)采用多列的模式進(jìn)行布局,但因?yàn)橐暰€的聚焦區(qū)域在中央,所以往往將權(quán)重高的模塊放左側(cè),權(quán)重低的模塊放右側(cè)(和更左邊的導(dǎo)航呼應(yīng))。這就導(dǎo)致左右兩側(cè)的比例是不對(duì)等的。
再加上,在前期規(guī)劃框架的階段,我們是不可能具體確定模塊高度的(要根據(jù)具體內(nèi)容決定),所以我們只能優(yōu)先確定模塊包含哪幾種柵格列數(shù)的規(guī)格。
也就是說(shuō),我們?cè)谶@個(gè)階段中制定了這樣的模塊寬度,后面就只用它們進(jìn)行不同表盤(pán)頁(yè)面的布局即可。
2. 表格頁(yè)面 Table Page
表格頁(yè)面,主要是用來(lái)放置表格的頁(yè)面類(lèi)型,它是多數(shù) B 端項(xiàng)目中最重要的頁(yè)面類(lèi)型。
雖然表格本身可以理解成是一個(gè)高級(jí)組件,但頁(yè)面中并不會(huì)只包含表格一個(gè)模塊而已,以及表格的部分元素對(duì)頁(yè)面的結(jié)構(gòu)會(huì)起到非常大的影響,也可以提前拆分出來(lái)做規(guī)劃。
比如添加操作按鈕、篩選模塊、表格切換標(biāo)簽、選中操作欄、頁(yè)碼等,都是可以提前在需求中預(yù)判的框架元素,我們就可以提前進(jìn)行處理。
當(dāng)然,前期的框架不可能完整滿足后續(xù)所有情況,所以基礎(chǔ)的框架結(jié)構(gòu)要有良好的 —— 擴(kuò)展性,以滿足更多復(fù)雜的需求。
3. 表單頁(yè)面 Form Page
表單頁(yè)面,是用來(lái)容納輸入、選項(xiàng)的頁(yè)面類(lèi)型,一般用在編輯、創(chuàng)建等場(chǎng)景中。表單頁(yè)面一般包含整頁(yè)、步驟、浮層三種模式。
表單頁(yè)面的框架設(shè)置內(nèi)容相對(duì)較少,主要是提前確認(rèn)產(chǎn)品中要應(yīng)用哪幾種表單類(lèi)型,以及適用的范圍。防止后續(xù)設(shè)計(jì)過(guò)程中,做到一個(gè)表單頁(yè)面就換種表現(xiàn)形式。
例如在有的整頁(yè)模式下,只有一兩個(gè)選項(xiàng),而一些選項(xiàng)特別多的場(chǎng)景卻用了彈窗的模式,有的情況又啟用抽屜,操作體驗(yàn)非常的不統(tǒng)一。
4. 內(nèi)容頁(yè)面 Contant Page
內(nèi)容頁(yè)面,主要是用來(lái)查看詳情信息的頁(yè)面類(lèi)型,和表單頁(yè)面類(lèi)似,它也會(huì)包含多種顯示模式。
通常一個(gè)項(xiàng)目?jī)?nèi)只建議使用兩種展示模式即可,如整頁(yè)和抽屜模式。同時(shí),內(nèi)容頁(yè)面往往因?yàn)樾枰胖玫膬?nèi)容太多,是需要進(jìn)行模塊拆分的,所以我們可以提前確定頁(yè)面的分區(qū)方式。
當(dāng)然,如果還有其它的可以提前確認(rèn)的上級(jí)操作模塊,也可以在這個(gè)階段確認(rèn),如分頁(yè)控件、操作欄等。
5. 列表頁(yè)面 List Page
列表頁(yè)面,和表格頁(yè)面類(lèi)似,也是用來(lái)展示數(shù)據(jù)條目的頁(yè)面,只是數(shù)據(jù)量通常不會(huì)太大。比如展示員工列表、資訊列表等等,會(huì)比應(yīng)用純粹的表格瀏覽效率更高。
列表頁(yè)面通常包含了兩種形式,一種是普通上下排列的模式,另一種是多列的卡片模式。
上下排列的通常適用于資訊類(lèi)型的列表,例如站內(nèi)消息、平臺(tái)新聞、服務(wù)列表等,需要有比較大的空間展示內(nèi)容文本信息。而這類(lèi)形式中又因?yàn)檎故緝?nèi)容的權(quán)重不同,對(duì)每條數(shù)據(jù)的展示要求也不一樣。
多列卡片則適用于需要較高屏幕利用率的列表,并且每個(gè)卡片內(nèi)包含的字段相對(duì)零碎,更依賴(lài)數(shù)據(jù)封面圖的情況。如內(nèi)部員工、產(chǎn)品列表、知識(shí)庫(kù)列表等等。
所以,我們可以根據(jù)可能出現(xiàn)的列表形式進(jìn)行判斷,設(shè)置好基礎(chǔ)的幾種不同的列表框架。
6. 其它頁(yè)面 Other Page
以上是 B 端項(xiàng)目中最常見(jiàn)的五種頁(yè)面類(lèi)型,會(huì)在一個(gè)項(xiàng)目中多次復(fù)用,但并不是說(shuō)項(xiàng)目中僅有這 5 種頁(yè)面類(lèi)型而已。
例如 OA 模塊中常用的任務(wù)看板頁(yè)面、日歷頁(yè)面、甘特頁(yè)面,Devop 模塊中的日志信息、代碼編輯、架構(gòu)頁(yè)面,CCTV 模塊(監(jiān)控)中的監(jiān)控視圖、設(shè)備編輯、線路管理等等,都是在對(duì)應(yīng)業(yè)務(wù)中才會(huì)用到的頁(yè)面類(lèi)型,雖然它不像前面 5 類(lèi)具有普遍性,但在相關(guān)業(yè)務(wù)環(huán)境下卻意義非凡。
所以,設(shè)計(jì)師要在前期的準(zhǔn)備中,去確定會(huì)出現(xiàn)哪些頁(yè)面的類(lèi)型。把這些類(lèi)型整理出來(lái)以后,再去做進(jìn)一步的思考,每個(gè)頁(yè)面類(lèi)型要應(yīng)對(duì)哪些場(chǎng)景,應(yīng)該提供幾種框架模式。
然后,才是動(dòng)手把這些頁(yè)面的基本交互原型全部制作出來(lái),并輸出相關(guān)文檔。
前期準(zhǔn)備得越充分,后面完成頁(yè)面設(shè)計(jì)的過(guò)程也就越順利,項(xiàng)目交互的統(tǒng)一性也就越高,用戶(hù)操作效率與體驗(yàn)自然也會(huì)更好。
二、框架的設(shè)計(jì)實(shí)例
了解完以上的內(nèi)容,我們就通過(guò)實(shí)例來(lái)解釋框架交互內(nèi)容的如何進(jìn)行輸出的。因?yàn)闀r(shí)間關(guān)系,我只按最低標(biāo)準(zhǔn)來(lái)做輸出,后面合訂版本會(huì)做進(jìn)一步完善。
首先,確定頁(yè)面的整體的基本架構(gòu),導(dǎo)航和頂部欄等核心欄目的分布與交互方法。
然后,再制定頁(yè)面的基本柵格應(yīng)用和響應(yīng)邏輯。
接下來(lái),將前面提到的不同類(lèi)型頁(yè)面的框架和使用場(chǎng)景進(jìn)行羅列和介紹。
最后,再對(duì)沒(méi)有應(yīng)用在常見(jiàn)頁(yè)面出現(xiàn)的全局組件進(jìn)行羅列與解釋即可。
全部?jī)?nèi)容都整理好后,就可以在軟件畫(huà)布中把所有相關(guān)頁(yè)面信息進(jìn)行排版,方便自己和其他同事查看,我們的任務(wù)就完成了!
作為初版肯定會(huì)存在很多問(wèn)題,所以盡量在推進(jìn)具體交互原型之前進(jìn)行一次框架交互評(píng)審,和產(chǎn)品經(jīng)理、前端開(kāi)發(fā)共同討論框架元素的合理性,完成最終的優(yōu)化。
三、結(jié)尾
最后,分享一點(diǎn),全局框架的制定需要成為提升設(shè)計(jì)效率和操作效率的工具,而不是限制設(shè)計(jì)發(fā)揮的牢籠。這種工作類(lèi)似開(kāi)發(fā)中的架構(gòu)師,需要對(duì)未來(lái)的需求做出大量的分析,以及結(jié)合自己的經(jīng)驗(yàn)去預(yù)判產(chǎn)品經(jīng)理的預(yù)判……
所以剛開(kāi)始嘗試使用這種做法很容易碰壁,因?yàn)樽龀鰜?lái)的方案很難符合項(xiàng)目實(shí)際需求,缺乏充分的靈活性,這都是正常的現(xiàn)象。
只要堅(jiān)持嘗試和總結(jié),就可以在幾個(gè)項(xiàng)目之后完全掌握它們的訣竅,并從容應(yīng)用。
作者:酸梅干超人;公眾號(hào):超人的電話亭(ID:Superman_Call)
本文由 @超人的電話亭 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來(lái)自Unsplash ,基于 CC0 協(xié)議。
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
正是我現(xiàn)在頭疼的問(wèn)題
真棒