前我主要深耕于B端設計中,深知B端表格設計與C端有很大的不同,無論是表格的展示形式以及承載內容上都有非常大的差異。而現在網上有不少關于表格如何設計的文章,但要真正落到實處的少之又少,因此今天我們就來聊聊表格,探討一下B端表格究竟應該如何設計。
由于表格組件類型復雜,因此分為上下兩篇,上篇主要講基礎知識點,下篇主要針對交流群中的20個問題進行解答,歡迎持續關注~
在我們B端表格頁中,由導航、篩選、表格幾大模塊構成,因為表格面積占比最大,頁面呈現最為重要,會直接影響用戶的使用體驗。
在我們對表格的設計思考過程中,需要注意兩項原則:易讀與易用
前者是提升使用者在表格瀏覽時的體驗,主要是從信息密度、色彩分隔、以及視覺節奏三個方面去理解;后者是使用表格時的操作感受,比如快捷操作、多數據編輯等方面去理解。無論是B端的任何頁面,表格都是必不可少的部分。
想要把這三種形式講透,需要將數據的形式結合起來說,我會從展示形式、數據結構、前端標簽 三個方面去解釋三者的區別。
表單擁有一對一的數據結構,能夠讓用戶明白數據間的對應關系。同時使用表單的門檻最低,擁有更合理的錄入形式,比如在常見的問卷調查、登陸注冊都是采取表單的形式。
在前端展示方面,表單采用的標簽一般會包含:text、password、radio、checkbox、button、submit、reset、image、file等屬性,我們也要針對不同的屬性進行相應的設計區分。
列表能夠將數據在一列中井然有序的展示,保持數據的有序與整潔。列表擁有一對多的數據結構,能夠讓用戶理清一條數據下的多個對應關系,并且多個對應關系是相互并列。比如在常見地待辦事項、走查清單中里,就是使用單維度數據進行排列。
在前端展示上,列表中的標簽分為有序與無序。
? 有序列表:即有順序的列表,其各個列表項按照一定的規則排列定義,前端標簽上采取<ol><li>的結構。
通常有序列表一般為數字序號(1、2、3、4...)或者字母序號(a、b、c、d)
? 無序列表:無序列表的各個列表項之間沒有順序級別之分,為并列關系。前端標簽上采取<ul><li>的結構。
在多維度的數據分析中,你是永遠的逃離不了表格,使用多維度數據進行統一的結構化展示,讓用戶清晰的看到在同一主題下的多條數據的對比,使數據能夠進行多維度的展示,保證數據的完整性。
在前端的方面,表格中都是采取 <table> 標簽進行展示,同時表格中的行與列分別用 <tr> 與 <td> 標簽,我們通常說的表頭,則為 <th> 標簽。但要注意,在前端眼中表格永遠沒有列的概念,列都是每行拼接而成。
正式開始之前,我們先定義一下表格~
表格是一種常見的信息展現形式,它是所有B端組件中信息展示密度最高,同時涵蓋了B端的所有場景,因此是B端設計中的一個重要的組件。
在我們常見的B端產品改版中,除了對頁面流程調整以外,更多就是圍繞表格而展開的一系列優化。因此表格的設計,做為B端設計師的基礎能力之一,也是檢驗一個B端設計師是否合格的關鍵因素。
表格屬于形式十分單一的組件,對于沒有經驗的設計師來說,會認為能夠調整的地方實在太少,往往在思考層面就會有所不足。對于一個B端表格來說,它需要具備數據瀏覽、數據新增、數據操作、數據統計,因此功能多而全,很難思考解決問題思路。
通常設計師設計單個組件,都會有較好的全量意識。而到了多組件的聯動時,就會出現問題。
比如在表格中,除了表格本身,還會有搜索、篩選、視圖、分頁等操作,如果不對多組件的交叉使用進行思考,也會缺少對于這些場景的設計。
在表格中,會承載多種多樣的字段類型,而每一個字段類型都會有相應的差異。形式的不同落到表格上就會有不同的呈現形式,在關鍵數值的處理上,也會差強人意。因此看上去簡單的一個表格,其實會有很多需要設計的點。
而深入到表格的內部中,你會發現能做的遠遠不止于此,如果剛開始沒有對表格進行梳理,那么你在設計的過程中,對于反復出現的表格將束手無策,為了讓大家能夠對表格有更深的理解,我將表格進行系統的拆解,結合實際案例,能夠讓表格更淺顯易懂。
首先問大家一個問題,你覺得表格一共有幾個部分組成,分別是什么?給大家五秒鐘時間思考~
5
4
3
2
1
~
在我看來,表格一共分為五部分:
概括整個表格的內容信息,讓用戶一眼就知道該表格的用途是否符合自己心中的預期。
在實際場景中,除了通過標題文字去的形式之外,你還可以為每一個表格去設計不同類型的圖標,這樣能夠讓用戶看到圖標就能聯想到內容,這也是現在無代碼開發平臺常見的處理方式。
但在工具欄的排列方式會有非常多的講究,在市面上的操作區域一般可分為單行與雙行的狀態,可根據自身產品要求的特點進行隨意的變化,會在文章后半部分具體講到工具欄的設計思路,這里就不再過多贅述。
概括每列的主要信息,在用戶使用表格中,起到數據解釋作用,讓數據能與之進行匹配,使用戶能夠看懂數據。同時在表頭處會擁有一些操作,比如凍結、篩選、排序都會放置于此,因此需要進行留意。
承載用戶的每一條數據,也是整個表格的核心。單元格的大小行高都會直接影響用戶使用表格的體驗,單元格的設計上也會有很多設計思路,在后半部分也給他家提供了我自己的看法,與大家進行探討,在這個就先按下不表。
嚴格意義上講,分頁是不屬于表格當中,但當數據超過用戶所設定的閾值時,就需要使用分頁拆解數據,所以分頁和表格是經常聯系在一起的。分頁一共有:基礎型、迷你型、完整型三種類型。
而如何進行跨頁的操作,一直都是分頁在B端中的難點,需要有好的思路與邏輯,在分頁模塊中與大家聊聊。
你知道表格類型的多少決定你了設計表格的下限。
雖然在大多數業務場景中都是使用基礎表格,但在B端產品中業務的多樣性使得很多特殊的表格有它獨特發揮的空間。
我發現在我的B端交流群都有著類似的問題,他們不知道表格還存在這么多的類型,這時候你與別人之間的認知的差距就是你設計優勢所在。
基礎表格是根基,是由行與列的單元格組成。在使用層面上能滿足用戶多維度查看數據的需求。因為大家都很熟知,在這一章節并不是主角,我們就不做過多贅述。
當表格中的數據為包含與被包含的結構時,可采取樹形表格。
通過逐級大綱的形式來展現數據間的層級關系,讓整個信息結構變得一目了然。這一表格形式常出現于項目管理工具中,比如 Teambition、Tapd、飛蛾都有這樣的設計。
作為騰訊最重要的項目管理工具,在產品設計之初,就考慮到類似情況,你能夠在Tpad單列數據編輯點擊入口,創建子數據,這樣在項目管理的場景下,有著較為友好的交互體驗。
前段時間,Teambition正式成為阿里旗下的辦公套件,而釘釘的云釘一體化,或許證明這樣龐大的市場仍然還要等待時間的挖掘。期待資本對于B端行業的更多動作
我們回到設計上,Teambition在9月份經歷的改版,變化很多,有機會可以總結一個改版分析分享給大家,作為一個項目管理軟件,Teambition也擁有樹形表格的這樣一共功能,它的添加入口出現在每個數據詳情頁的最下方,同時在視圖層面,也可以篩選展示為:所有任務、僅父任務、僅子任務四種場景,更能滿足用戶的需求~
當一條主數據下有多條數據結構不同的關聯數據進行嵌套時,這時候就可以用子表格進行創建。它能夠對主數據進行更加細致的解釋,詳細的了解主數據中數據的含義。從表象上看,就是在一個表格中還能嵌套另一個表格。
比如在對某集團對旗下子公司的銷售表格中,它能夠通過嵌套子表格的形式,將每一個子公司下的銷售人員的銷售記錄進行記錄,從而能夠更加細的了解到每一個公司、每一個人員的具體情況。
在國外報表中,這類表格很少出現,而在中國的報表中,嵌套子表格算是一種不折不扣的中國式報表。
當然這里我們依舊可以深入理解,比如在兩個表格之間,用戶是通過什么樣的方式建立一個父子的關系?表格中當父數據刪除時,子數據如何處理?設計上對父子之間的關聯有著何種限制,這都是我們需要思考的,因為這里牽涉到業務實在太多,我也無法抽象出一個規律供大家學習,因此只有具體問題具體分析。
當一個表格里面有多條數據在同一個小范圍的維度進行展示時,它就是交叉表格。從表象上看,就是表頭有很多分組進行區分,因此它也叫做表頭分組。
它能夠通過硬拆分將數據進行切割,但是這樣數據的易讀性就是有很大的差距,比如在2010-2020公司年度收支表格中,需要同時展示每一年份的收入、支出與利潤,使用交叉報表能夠讓用戶一眼就是看清數據,而基礎表格卻不行。交叉表格也算是中國式表格中的一種,能夠滿足具體業務上的需求。
當一個表格里面有多種圖表數據進行展示時,他就是圖表表格。
在對一些項目做定制化開發時,這是十分常見的場景。用戶點擊某一數據后,直接跳出數據的統計圖,方便用戶進行對比。同時這一功能也可以通過儀表盤這樣的功能去解決,也就說到國內最愛做的數據可視化。
這是很多人都會忽略的一個點,主要是大家對于表格的理解各不相同,也沒有具體的文章對于表格尺寸有個非常明確的限制,在這里分享一個我常用的數據點,用于判斷表格設計的優劣:表占比。
表占比:表占比是指在1920x1080的屏幕大小下,表格占整個頁面的比例 即:表格面積 / 頁面面積 = 表占比
這里需要指出,這里的表格面積是指,表頭+單元格+分頁(不包含工具欄)
在我對十幾款主流B端軟件的總結分析中,驚奇的發現大多數產品「表占比」都是在65-70%之間,而一些不注重交互設計上的產品則會有所偏差。
那為何65-70%是一個更為合理的數據?
因為只要在頁面中出現表格,就代表這個頁面一定是以表格作為核心。而表占比低于65%,代表頁面中的表格不處于內容的核心,你需要重新審視這個頁面所需要傳達的功能。
如果表占比高于80 %,則代表表格出現面積過大,要考慮用戶是否能夠接受如此大的占比。
因此,設計的合理性來說,占比在65-70%之間能夠保證數據展示的合理性,同時這主要是針對CRM產品,大家可以使用這個占比去衡量自己設計的B端產品~
當然這樣的情況并不是一塵不變的,B端最大的魅力便是業務邏輯,我們來看一個看起來像是反面的例子:在銷幫幫中,表占比為:61.2% ,看似是一個并不合格的成績,而且數據十分異常,讓我想要深挖,為何會如此的低。
通過進一步的分析,發現銷幫幫是一款與釘釘生態深度綁定的產品,其產品只能通過釘釘軟件進行使用,而釘釘本身默認并不是1080px的寬度,用戶打開并且全屏的尺寸偏小。默認尺寸大小的不同,最終讓銷幫幫選擇去滿足業務而犧牲表占比去換取更多的功能。
因為在B端的工具欄的設計中,市面上缺少思路與方法的指導,會出現非常多的問題,因此我展開講講工具欄的設計,就不出單獨系列進行講解~
首先,對于工具欄,不同的產品,會對它有著不同的定義。比如在Apple MacOS 系統當中經常提到的Toolbars和Toolbar Items;又或者是Microsoft 產品中采取的Ribbon設計模式。在設計底層思路上截然不同,平臺級產品思路與定制化產品思路存在很多截然不同的做法,我們今天簡單聊聊大家遇到過多的表格工具欄設計,不做深挖~
在表格工具欄的設計中,信息分區與頁面透氣是非常重要的兩個設計核心。
信息分區:
因為工具欄是由標題、篩選、搜索、視圖、新建等操作組成,而功能間的區分是工具欄設計的一個關鍵。
當一個工具欄中,需要將如此多的元素進行組合排列時,必然會有其排序的規則,這時我們就可以通過親密性原則,對工具欄中的信息進行相應區分
在設計的親密性原則中,我們可以將功能相近的工具放在一起,比如:搜索與篩選都是數據過濾的操作,應該放在同一分區;
同樣,工具欄也會存在一些功能點不太相近操作,我們就應該通過分區將其間隔開,比如在下圖中,每個功能都將其用線條區分。
當然,在信息的去區分上,也有強弱兩種不同的方式,一種是通過線條直接分割;另一種是將工具欄進行空間上的區分。因此可以通過信息區分去檢查你的工具欄設計是否合理。
內容呼吸:
在一個定制化項目中,設計師一定要讓自己的頁面具有呼吸感。在B端業務中,信息量本身就已經足夠龐大,而頁面的中的疏密關系就顯得尤為重要。
通常列表都承載著繁雜、冗余的數據,是一個信息集中的密;工具欄作為與表格關聯的上部分,呼吸感便成為表格的重要因素。通常在表頭處要將空間盡量分散開,這樣才能滿足整體的疏密關系。
經常看到一些十分冗雜的表頭,甚至它喪失了表頭的真正含義。在實際情況下,盡可能明確、簡單的講出表頭的內容,以免造成表格的宣兵奪主。當然也會存在一些專業術語,這時候,給一個Tooltips再合適不過。
在表格中,單元格的行高是一直都是一個難以控制的變量,因為行高會直接控制表格中的信息密度,而信息密度永遠是一個無法量化的元素。而在我們設計過程中,需要采取盒子模型的方式,讓你的設計更加落地。
知識點補充:盒子模型
從前端開發而言,單元格是一個最為基礎的盒子模型。而HTML中的所有元素都可以看作是一個盒子。而我們所設計的頁面也正是由這個樣的原理去還原出來。
Margin(外邊距):清除邊框外的區域,外邊距是透明的。
Border(邊框):圍繞在內邊距和內容外的邊框。
Padding(內邊距):清除內容周圍的區域,內邊距是透明的。
Content(內容):盒子的內容,顯示文本和圖像。
a.單元格內容
內容一般為文字、圖標、頭像等等,而對于數據中你想要格外突出的內容,這里稱為關鍵數據標識別。從盒子模型的角度來看,它就是當中的Connect,但單元格內容中,一般會有一些處理技巧:
關鍵數據標識:
用戶在使用表格時,會經常去留意一些關鍵的數據。比如數據的狀態、變化的多少…
如果在系統中,你能夠很明確知道用戶想要了解的數據時,便可在關鍵數據上進行標識。這樣能夠幫助用戶快速定位到自己想要的信息,減少數據尋找所化的時間。但如果你對關鍵數據標識出現誤判,這條數據便是一條十分干擾的數據,因此在這里的設計,需要慎重考慮。
比如在飛書的成員與部門中,對于賬號狀態就是一個關鍵數據的標識,一方面用戶可以快速了解到已經激活的成員,另一方面對于未激活狀態的進行突出展示,同時給予用戶未激活后的再次發送提醒的操作,是對用戶使用的優化提升。但,如果將不重要的數據進行標識,例如手機號,那么這將會是一個令人痛苦的設計。
人員角色展示
人員角色展示在表格中十分常見,通常會是以用戶名稱+頭像的形式展示。
但在真實場景的表格中,頭像需要給予默認的形式,比如釘釘、飛書就是以用戶“姓”作為頭像的默認值,而在多個人員角色展示時,就需要考慮特殊情況,無論是極值省略展示與獲取全量數據中,都需要我們進行設計上的處理。
進度條
進度條是屬于關鍵數據的一種,它所涉及到的功能與圖表表格類似,能夠更直觀展示數據的占比,方便用戶對于多條數據間的值進行判斷。進度條常見于“容量、使用量”的數據中。
表格空白處理
表格中經常出現空數據的情況,而表格的留白對于用戶而言會造成一些困擾,特別存在與頁面中的大面積留白,感覺像是數據沒有加載出。因此在表格空白數據處理上,可以使用“-”來進行默認展示。
b.單元格行高
單元格行高一般由:文字大小、文字行高、左右上下邊距共同組成。
從盒子模型的角度來看,它就是其中的Padding。因此行高的確定,是由上方四個條件共同組成。
文字大小:一般出現在表格中的文字大小都在12-16px之間,通常13、14px最為常見,建議大家設計也在此范疇內。
文字行高: 行高是一行文本垂直方向的高度,這個高度和字高無關,文字內容水平居中。可設置為字號的1.2-1.8倍,文字與分割線間距離可以設定為字號的1-1.5倍。
邊距(Padding):表格中的邊距分為左上右下四個方向,而左上右下恰好就是對應前端去編寫Padding代碼的順序,在對頁面驗收時,便可采取這樣的形式。
單元格行高可配置:單元格行高直接影響著信息排列的密度,而在實際業務中,真正落地也有著不同的做法。
在對定制化項目的開發中,通常會設計一套設計師認為更加合理的單元格高度,一般為32px-56px區間內,而在很多通用化產品中,存在多個設備屏幕分辨率的差異,為了讓每一個分辨率下的產品都能夠有較好的展示效果,于是乎將選擇權交給用戶,在表格左下角會設置舒適、標準、緊湊三種高度來滿足需求,使得表格更加落地合理。
總結:整個單元格的行高,就是由這三部分組成,它們的嵌套與組合,所形成了單元格的行高
c.表格分割
在表格設計當中,每一條線都有著它存在的意義。
當表格中展示橫線;隱藏縱線。
用戶的橫向閱讀體驗更佳,強調一條數據的完整性,能夠讓用戶進行快速的對應。
當表格中展示縱線;隱藏橫線。
用戶的縱向閱讀體驗更佳,強調數據上下間的對比,能夠讓用戶找到同一緯度數據下的對比。
比如在一個組織架構的成員列表中,我相信大家都設計過類似頁面,同樣的設計方式,我一個采取展示橫線、一個展示縱線,結果明顯,我成員需要閱讀完整條數據,因此橫線會更加合理。
當然,在我們日常的設計中,展示橫線的場景顯然會更多,但我們日常使用時,數據對應的場景還會更多這是需要有更強的設計形式:
d.行、列凍結
當表格的行與列的數量過多時,會導致一屏展示不下,而表格中的關鍵信息與操作是需要在任何時候都展示,這是采取行、列凍結,能讓用戶快速觸達。
表頭凍結:通常出現在垂直滾動時,通過固定表頭的信息,能夠讓用戶閱讀時對應不同的數據,使用戶更好理解數據。
首尾凍結:通常出現在水平滾動,通過固定首列的主屬性字段以及尾列的數據操作,來滿足用戶對于一列數據的認知,從而使用戶進行快速操作。
在對分頁設計的分析中,我們需要對分頁中的元素進行拆解,才能明白分頁的類型所帶來的不同。
表格信息:會展示表格信息當中的數據總量、更新時間、默認排序方式等...
數據總量主要展示用戶需要瀏覽的內容的總量;常見于管理后臺搜索、篩選符合條件的數據記錄時,搜索結果頁通常會展示這個信息,這讓銷售人員在操作時有心理預期。
更新時間主要是展示用戶當前表格所操作時的日期時間;常見于金融類產品中,他們對于表格中數據的時效性尤為關注,這樣可以方便用戶對表格數據中的有效性進行判斷
默認排序方式主要是展示表格中是按照哪一個字段進行的排序;通常這種做法多出現于表頭直接展示icon,但對于可配置化的產品而言,隨著列數的增多,你越來越找不到你想要的默認排序方式,因此在表格的固定位置展示,就再好不過(記住,只針對特定場景)
頁面展示數量:結構為「X條/頁」
它能控制每個頁面展示多少條數據;當在系統中有很多數據時,你可以直接通過「頁面展示數據 * 分頁總數」 直接算出整個表格的數據總和。
上一頁和下一頁翻頁:分頁中基本組成元素通過用戶點擊上一頁、下一頁的按鈕,實現表格的翻頁功能。翻頁通常會根據場景不同,去省略翻頁中的不同元素,比如在下面馬上那個講到的三種翻頁類型,但是上一頁和下一頁是絕對不可省略的。翻頁也如同你翻書一樣,可以進行對數據的逐頁閱讀,遵從用戶之前的使用習慣。
當前頁碼:當前頁碼說明了頁面中數據當前所處的位置,方便用戶進行翻頁的操作。
相鄰頁碼展示:相鄰頁碼通常展示前后兩頁,比如你在第6頁時,頁面需要展示:4、5、6、7、8;但頁碼在第1頁時,就需要展示:1、2、3、4、5;頁尾同理。
更多分頁:當表格數據過多時,就需要使用分頁,同樣,當分頁過多時,我們需要進行處理,就是省略,采用更多分頁,去展示多余的分頁情況,當用戶需要查看更多的分頁,點擊更多圖標即可。
總頁數:代表大概會有多少頁此類數據,通過使用總頁數才能讓用戶知道
總頁數說明了內容一共有多少頁,就像一本紙質書有總頁數,一本有聲書有總時長;通過這個元素,用戶才能了解內容的多少,對整理內容有個把握。
頁碼跳轉:頁碼跳轉幫助用戶從當前頁面跳轉到其他某個頁面;比如用戶在搜索了某件商品,按銷量排序,這時瀏覽到了第15頁,滿意度越來越低;于是打算從前5頁選一個,這時就能通過頁碼跳轉快速跳轉到第1-5頁了。
簡潔型:
當分頁數量較少時,通常在7頁以內,就只有最基礎的展示:上一頁、分頁數量、下一頁。
迷你型:
當頁面空間不足或者降低分頁的視覺影響時,可以采用迷你型,主要為當前頁/總頁數,可以直接跳轉到某頁面。
完整型:
當表格數據較多,為了滿足更多的用戶需求,可以根據需求選擇分頁類型。比較完整的分頁還包括如下功能:顯示總數、調整每頁顯示條數、直接跳轉到某頁。完整型的雖然滿足各種功能需求,但是所占空間較大,所以我們要根據自己的需求合理拆分使用。
分頁固定:
在表格中使用分頁,除了選擇合理的分頁類型外,我們還需要注意當數據過多的時候,是否要固定分頁。這個需要根據需求來決定,如果用戶翻頁很頻繁,表格數據又特別長,就可以考慮分頁固定在底部,免得每次用戶翻頁都要跑到表格的最底部才能分頁,還可以在表頭也放迷你型分頁。但通常在設計表格的時候就沒有固定,也很少使用表頭分頁,所以根據需求來定。同樣按鈕的設計也會存在類似的情況。
另外就是當數量過少時,只有一頁或者無數據的時候,我們是不需要分頁的,這個時候最好去掉分頁,展示在這里沒有什么意義了。但很多時候我們設計沒有做區分,開發也就不管了。
老讀者都知道,我會反復去強調“場景”這一概念(比如在導航菜單、篩選、彈窗、圖標中經常提到這一詞),因為你只有明白用戶真正的業務場景,才能夠真正的明白用戶的痛點。我們回到表格中,在表格的場景主要分為五類不同場景:數據瀏覽、數據新增、數據操作、數據統計與通用場景。我會通過不同場景的梳理分析我們在不同場景中存在那些優化點,可以進行深入探討。
在數據瀏覽的場景中,本質上是對大量數據進行尋找與確認。用戶需要在此場景下進行高效準確的數據查找。而伴隨著用戶的尋找,就需要使用表格當中的工具進行輔助查找,比如篩選、搜索,這些工具的出現,都能夠幫助用戶進行數據的清洗,使得用戶想要的數據能夠快速的被找到。
比如:我們公司的銷售人員在每天早上,都需要去 check in 今天自己所要跟進、回訪的客戶,銷售人員就會通過表格中的各種工具,去幫助銷售人員找到自己想要的那部分數據。
常見行為及設計點:
數據篩選瀏覽:通過自己對數據的一定了解,結合各種篩選條件,配合得到用戶想要的篩選結果。
數據多選:用戶可以通過多選,為他尋找的數據進行標記,方便之后的操作。
數據新增本質上是將復雜的數據結構,通過系統字段類型的相應規則,錄入保存到系統中。這也就我們常說的增刪改查的“增”
比如:銷售人員在對新增的客戶進行登記時,需要登記公司名稱,聯系人,聯系方式,跟進記錄等等。且需要不斷更新跟進記錄,因此銷售人員在表格上的新增是一個非常高頻操作~
數據操作分為對單個數據的操作、單行數據的操作、多行數據的操作三種情況
單個數據的操作,就是我們常見的快捷編輯,可以點擊快捷編輯按鈕,對單個數據進行錄入,
為何需要快捷編輯,在銷售使用場景中,使用表格去編輯一條信息是一個循序漸進的過程,比如在對客戶進行溝通時,數據的不斷更改,跟進內容也在不停修改,導致用戶需要每次進入用戶詳情點擊編輯之后才能進行操作,而在表格內進行快捷編輯直接滿足實時編輯的需求,在交互層面上這是一個非常OK的需求
但落到開發層面上,就意味著要在用戶進入表格中去判斷權限,才能讓用戶知道是否能夠點,點擊過后需要判斷字段屬性,明確該字段是與哪些字段進行聯動
單條數據主要通常會采取兩種路徑進行操作:進入用戶詳情頁界面,對一整列數據進行編輯,這種情況通常都需要多個數據進行處理,因此進入編輯頁面更容易尋找,同時也是最為正常的一種做法
多行數據操作主要采取多選過后的操作方式:當用戶想要對多條數據進行操作時,就需要對多個數據進行checkbox 的勾選,從而滿足多行操作的需求
數據統計主要針對用戶需要審查分析。目的是在通過大量的數據分析去得出自己的某一些結論,由于關注的數據會有主次之分,數據與數據之間也會有內在聯系,用戶會更加跳躍地掃視頁面,而且會更加反復地審查數據。例如,銷售人員需要查閱本月的銷售情況,進入到商品銷售明細表中,分析本月的經營狀況,若其中某些商品
了解了表格的使用場景過后,針對不同的場景,在設計上它的思路就會有所不同
使用上就會有不同的設計思路。由于篇幅原因,我們主要了解了表格的基本形態,如果對于表格的場景還不太清楚,我會在下篇中與大家通過20個問題,了解B端表格中究竟應該如何設計~
我是CE青年
一個2 B行業的2B設計師
我們下篇文章再見
1、html標簽是用來給文本添加語義的,而不是用來修飾文本的;
2、<meta charset="GBK">指定字符集(GB2312、UTF-8),html保存和指定字符一樣,才不會亂碼;
3、<!DOCTYPE html> DTD文檔申明告訴瀏覽器我用的什么協議來寫的,不是html標簽;
4、webstorm快捷鍵大全:https://www.cnblogs.com/yeminglong/p/5995421.html
1、h、p 和 hr 標簽
2、注釋:<!-- -->
3、圖片:<img src=" ">
4、換行:<br> 用于內容未完的換行
5、跳轉:<a href=" "></a>
6、base 標簽:<base target="_self ">
7、假鏈接:點擊不會跳轉
8、錨點:<a href="#id值"><\a>
1、無序列表(!)
2、有序列表(*)
3、定義列表
?
1、格式
?
2、屬性
(1)寬高
(2)水平和垂直對齊(align 和 valign)
(3)內邊距和外邊距(cellpadding 和 cellspacing)
(4)細線表格
3、表格的其他標簽
(1)caption:表格的標題標簽,必須寫在 table 內而且需緊跟 table
(2)th:th 和 td 同級,th 有加粗的效果
4、表格的結構
(1)組成:caption 標題、thead 表頭、tbody 主體、tfoot 尾部
(2)說明:
5、單元格的合并
(1)水平方向:td 屬性 colspan = "2";
(2)垂直方向:td 屬性 rowspan = "2";
1、格式
?
2、input 標簽
(1)type = text:
(2)password:
(3)radio:互斥要設置 name 相同;默認選中 checked
(4)checkbox:選中 checked
(5)button:
(6)image:
(7)reset:value 修改標題
(8)submit:
(9)hidden:
-----------------------------------------------------------------------------------------------------------------------
*相關標簽:
?
3、非 input 標簽
(1)select
?
(2)textarea
4、練習
(1)表單標簽除了 button 外都可以用 value 來指定提交的值
(2)表單添加邊框可以在 form 中添加 fieldset 來實現
1、video 標簽
(1)格式:<video src=" " autoplay="autoplay"></video>;
(2)屬性:controls(控制條)poster(海報)loop(循環)preload(預加載,與autoplay沖突)muted(靜音)width/height;
(3)另一種 video 格式:解決瀏覽器的兼容
?
(4)讓所有的瀏覽器支持 video 標簽:通過 js 框架來實現
2、audio 標簽
(1)使用基本和 video 一樣,屬性只有寬高和 poster 不能用,也是兩種格式
3、details 和 summary 標簽
(1)格式:
?
4、marquee標簽(跑馬燈效果)
(1)w3c 不推薦,但是瀏覽器的支持好
(2)屬性:direction(方向)scrollamount(滾動的速度)loop(滾動次數,默認-1)behavior(滾動類型 slide)
(3)廢棄的標簽:<br><hr><font><b>加粗<u>下劃線<i>斜體<s>刪除線(無語義)
替代的標簽:<strong><ins><em><del>(加入了語義)
5、字符實體
(1) ;空格 <;>; ©;版權符號
(2)理解:html 占用了的不顯示的特殊字符用另外的代替符號表示,使他們正常在 html 頁面上顯示
文介紹了制定產品設計規范標準的重要性,也包括行業對于高級產品經理的要求,并以幾點詳細介紹,包括了制定標準的共同目標、基礎要素、設計原則、規范制定的流程以及如何推動規范的執行等。適合產品崗位的你閱讀。
每一款產品,都會有它的產品設計規范。例如支付寶小程序,微信小程序,有它的設計風格和交互的審核要求。
而適用于移動應用以及Web設計,可以參考Material Design(Google),強調直觀性、一致性和有意義的動效設計。
如果你是ios產品,那首先就得去了解Human Interface Guidelines(Apple),再基于這個設計規范制定符合平臺的標準,最通用,最基礎的,就當屬Microsoft Design Guidelines,適用于Windows平臺的設計規范,強調平面化、簡潔和直觀的設計風格。
為什么要制定產品的規范標準?
制定產品的規范標準可以提高產品的一致性、可用性和用戶體驗,幫助建立品牌形象、提升用戶滿意度,并為團隊提供明確的指導,提高工作效率和協作效果。
行業對于高級產品經理的要求:
在講這篇內容之前,先容許我把之前的幾篇文章給大家同步一下,感興趣的小伙伴或者遇到瓶頸的小伙伴一定要看,我相信會對你們的提升帶來很大的幫助,內容很長,建議先收藏。
我們先來簡單的對規范標準有個概念,有很多小伙伴都總是會在這兩個詞進行拉扯,但其實這兩個詞加起來就代表了準則。而規范則是基于標準之下,如支付寶小程序,它的設計規范,對于我們來講,就是平臺的設計標準,我們基于這個標準下再去制定屬于自己產品的設計規范。
那我們現在來看看,標準和規范在文學上的區別為:意思不同、出處不同。
① 意思不同
② 出處不同
規范要求和標準的區別:
③ 成因不同
接下來,我們開始今天的主要內容。小編會通過三個篇章,七個章節,給大家提供落地的方法。
倘若你目前剛好處在對于制定產品的規范標準無從下手的階段,以下內容絕對能夠讓你按部就班的完成;假如你已經為多個平臺制定過標準,也可以參考本篇內容,思考下有沒有進步的空間;假如你從來沒接觸也沒有機會制定,那么,這篇文章就是你的敲門磚。
小編總結了十點,先給大家介紹一下,我們為什么要去做這個事情,這個事情給我們帶來什么價值。
作為產品,我們必須要清楚一個原則在于:我們做的任何事情,都得有它的價值,要清楚它的目的再去做,拒絕為了做而做的行為,切勿讓自己變成了傳聲筒。
綜上所述,制定產品的設計規范標準可以帶來許多益處,包括提升用戶體驗、降低開發成本、增強品牌形象和改善團隊協作。
規范的制定和執行有助于打造出一致、優質的產品,提高用戶滿意度和市場競爭力。
產品設計的常識(Common Sense),很多時候都會被忽略,特別一些小型項目。研發人員會在初期嫌麻煩不對一些常識的問題進行處理,最終導致的影響,往往是影響到產品的本身。
產品一定要把控好這個關卡,誰都可以不懂,產品一定要最清楚最基本的就是系統異常處理設計規范能夠有效解決且避免以下七點:
產品設計是否保持一致很容易反映出一個產品經理做事情的嚴謹性。有不少產品經理設計產品很隨意,抱著“能用就行”的態度做設計,結果就會出現整個產品的一致性非常差。
比如,列表的添加按鈕一會在頁面的右上角,一會在頁面的左上角,搞得用戶使用不同的頁面像是在玩“躲貓貓”游戲一般,學習成本非常高。
再比如移動端,有些頁面使用長按刪除,有的使用向左滑動刪除,還有的需要點擊“…”在彈層中點擊刪除……同一個產品,多種交互形式也會讓用戶困惑。
至此,產品的規范標準入門篇已經跟大家介紹完了。大家在做任何一個項目的時候,都應該注意入門篇的兩個章節,究竟有沒有做到位,有沒有制定規范標準同步到設計,研發。
入門篇基本滿足大部門從0-1的項目,或者是初中級的產品經理所需要掌握的技能,建議大家收藏起來。如果遇到這類任務的時候,就可以以這篇文章,作為你們的任務List,一項一項對應的去檢查是否有做到位。那么我相信你們吹來的作品,一定是具備一定的專業度,一致性以及可延展性的。
在入門篇開始之前,先給大家交個底。我們在制定產品入門篇的規范標準時,有一個部門必須拉他們參與進來,那就UI部。UI部門在入門篇的環節,起到了決定性的作用,由他們為主導,我們為輔助的方式,達成一致性的決定。
這一個環節,最重要的目的是讓產品與UI保持同頻,大家都在統一規范標準下進行設計,為產品添磚加瓦。而且通常我們都會把這個環節以一個功能模塊級別的需求去做,也有這個需求的版本,持續優化迭代。
當然,需要優化迭代的時候,那就應該是由產品為主導,在原有的標準下,再去優化規范,最終形成新一版的規范標準。
這個環節也是能夠讓產品在與UI溝通上的成本減少,在同頻基礎下工作也有利于減少兩個部門之間的摩擦。
相信大家應該也聽說過交互設計師這個崗位,大多數在中小型企業很難有資源去匹配這個崗位,一般都是在成熟的互聯網公司會有這個崗位的需求。
通過這么個規律我們也可以發現:需要注重交互設計,往往到了產品已經扎根土地,茁壯成長的階段。
相對比較穩定的時候就會開始考慮這個問題,但并不代表說,交互設計不重要。交互設計對于產品來言,在做需求時,靠的是經驗,靠的是競品分析,靠的是借鑒。
看到這里的小伙伴們,自動自覺對號入座,往往一味的靠經驗,靠競品,靠借鑒,只會讓產品的交互五花八門,沒有一個體系。單個功能抽出來可能是合理的,方便的;但全部湊在一起的時候,倘若需要用戶去適應,那么就適得其反。
因此,我們產品就需要UI同學幫忙一起制定出產品交互設計規范,而產品本身,也應該有一套自己的標準,把控好產品的交互,這樣才有利于產品的發展。
接下來,我會通過收集一些常見的交互問題,給大家用實例去介紹產品交互設計規范如何制定。
1)做一個頁面交互設計的時候要注意什么?
2)如何理解模態框?
何時應該使用模態框?模態框和阻斷框有什么區別?
模態對話框(Modal DialogueBox) ,阻斷(Blocking),可以用兩個比喻給大家解釋:
3)在具體設計一個產品的過程中,把握住哪些關鍵點才能讓整個產品有著一致的交互體驗,或者交互模式?比如iOS端和android端,比如web端和移動端?
一致性,在交互設計中非常重要!保持交互一致性,有兩個武器:原則和規范。
規范又有兩個層面:指南Guidelines和規格
原則
一些指導性的東西,在設計當中要遵從。在整個產品(無論多少端,多少子產品)都要遵守的。
舉例:一個界面完成一個任務;表單超過10項必須分步驟;用戶必須隨時能回到主界面……這些原則可以由不同的形式來實現,但必須遵從這些原則。
規范
文章開頭也有提及到,忘記了請翻上去復習一下。
指南:圈定具體的交互模式、色彩搭配和設計禁忌。
在這個層面,一個[構]可以有多個[形],但某個形只能有一個[構],達到相同位置、相同外觀、相同操作。通過指南能夠讓各個端(IOS和安卓)看起來似曾相識,便于用戶學習和養成習慣。
舉例:在沒有左側導航的詳情界面,必須包含面包屑;面包屑只能出現在PC瀏覽器端,不允許出現在響應式web界面中。
IOS和安卓的官方Guidelines就是這樣的東西,但也可視情況制定私有的指南,也就是各個公司自己的設計指南。
規格:規格非常具體的描述了每一個模式的每一個形態的具體尺寸、色彩、響應,精確到數值。
舉例:一級標題,字號為宋體 18pt;行高30pt;行上下外距為5pt;色值為#CC9300。
3)表單布局有什么規范要注意的?
這個問題是初級產品經理最容易犯的問題,設計太隨意,看到別人的就想復制粘貼過來。這個問題正是可以解決很多初級產品常見錯誤的問題,以及給大家提供一個思路。
這里分享四個常見的表達布局對齊:
首先,我們要清楚,人的視覺是上下,左右的。所以我們會把要填寫的標題,放在左邊,輸入的內容放在右邊。這個原因也在于大部分都是右撇子,所以放在右面方便輸入,而在左邊提到的四點,各有千秋。
關鍵在于考慮的出發點是用戶的視覺,還是表單的體驗,抑或者是信息是否足夠直觀。再者就是是否夠簡潔,都是可供選擇,關鍵在于選定一個就保持一致。
綜上所述我們可以知道,交互設計可以通過交互的顯性和交互的隱性去考慮。
交互顯性
交互顯性指的是用戶在頁面所有的點擊,滑動,跳轉的操作,比如刷新方式有下拉、上滑、按壓點擊等方式。
這就是所謂的交互顯性的操作。要保持產品顯性操作的統一性,同類別的交互不可有不同的操作感受。同時交互顯性要符合大眾的認知習慣,可創新但不可違背潛意識,比如說PC端的交互顯性是以點擊事件作為核心操作的,移動端的交互顯性是以滑動作為核心操作的。
交互隱性
交互隱性指的是用戶信息發生改變時的顯示。比如說訂單狀態的顯示,確認收貨后,綠色的標簽顯示訂單已完成,申請售后則有售后的標簽,一些平臺還會以訂單的顏色區分去給用戶隱喻。
再舉個例子,消息有個小紅點,用戶就會知道去點,上文也有提到隱喻,很多時候,我們就是通過交互隱性的方式,來引導用戶,提示用戶,這樣的方式有利于讓用戶自發性去體驗,感受平臺的功能,帶來舒適感。
歸根結底,產品的交互離不開創新,一致,符合規范。
本章節我們以Web端為例,我們在設計過程中,需要考慮我們基于什么樣的尺寸進行基礎設計。劃分哪些區域需要固定尺寸、哪些需要做適配等。
據統計,使用中系統的用戶的主流分辨率主要為 1920、1440 和 1366。
設計思考,有如下幾點:
web頁面是按照Html的設計規范標準進行布局設計的,由以下三部分構成:
1)Margin(邊距)
為避免頁面元素緊貼邊沿的情況發生,WEB 頁面和其中的表格,應設定邊距,最小邊距值為 “3px”。
一般粗細直角以1px,圓角為2px。
2)Button(按鈕)
按鈕一般有三種樣式:小、中、大。
按鈕是交互設計中必備的元素,它在用戶和系統的交互中承擔著非常重要的作用。
后臺中常見的按鈕類型分為線性按鈕、文字按鈕、圖標按鈕等。
按鈕并列間距為:小間距8px,中間距16px,大間距24px
其中小中大的寬度分別為:58px,74px,96px
3)Table(表單)
常見表單是由多個列表項構成的。而每一個列表項都是由最基本的標簽和輸入框組成,常規的表單包括單選、多選、下拉選、輸入框、時間選擇、開關選擇等控件。
頂部標簽是標簽在控件的上方,標簽可以和控件左對齊,對于橫向空間不足的情況是一種很好的方案。
豎列標簽的使用場景思考:
表格的設計思考:
表格的設計規范的設計思考點如下:
表頭的文案,可遵循信息降噪的原則思考:
4)Progress bar(進度條)
進度條的設計思考:
加載中進度條,存在加載中、成功、失敗三種狀態通過顏色去區分,進度條長度支持自定義。
5)Dialog(彈窗)
彈框主要分為兩個大類模態彈框和非模態彈框,他們最大的區別就是是否強制用戶交互。
常規狀態通常出現在頁面的上方,有普通信息、成功信息、失敗信息、警示信息四種icon。
6)Default(缺省狀態):
缺省頁面是當頁面沒有數據、用戶沒有建立資料或網絡連接不通暢的情況下所展現的頁面。
為了緩解用戶面對這類情況產生焦慮情緒,設計師可以用一些插畫和文字的結合來引導用戶進行下一步的操作。
產品風格設計的形成一般通過以下幾點:顏色,字體,圖標,尺寸決定的。
1)Color(顏色)
色彩內容主要包含基礎色(如品牌色、黑色、白色)和功能色(如鏈接色、提醒色等),圖表配色為單獨的配色體系。
在前期制定顏色規范的時候,精益求精的設定顏色,切忌顏色過多。
顏色的狀態色盡量用原色進行轉換,設置一個合理的變色公式,讓所有顏色的狀態色都根據這個公式進行轉換。
例:
在設計規范中,盡量把顏色的色值和 rgba 值都寫出來(這里是強迫癥患者要標的,因為有時候色值完全一樣,但 rgba 數值略有不同,雖然效果一樣,但是對于強迫癥的你來說,舒服嗎?)。
狀態色有 4 狀態色:Normal、Hover、Click、Disable。
在設定圖表顏色的時候,要考慮不同的使用樣式(柱狀圖、環形圖、餅圖等…),同時也要考慮他的延展性。比如你設定 12 個 chart 色值,在使用的時候按著順序來使用,當超過 12 個后可以為同一個顏色。
2)Font(文字)
設定統一的字體規范,使用非襯線字體在各個操作系統下都有最佳展示效果。
首先,要設置一個字體家族,保證產品界面的最優展示。
例如(僅作為展示,不是建議):font-family: “Chinese Quote”, -apple-system, BlinkMacSystemFont, “Segoe UI”, “PingFang SC”, “Hiragino Sans GB”, “Microsoft YaHei”, “Helvetica Neue”, Helvetica, Arial, sans-serif, “Apple Color Emoji”, “Segoe UI Emoji”, “Segoe UI Symbol”;
字號
現在主流的產品中,主體字為 12px / 14px的居多,可根據自身的產品定位以及用戶的習慣進行設定。
字號不要出現奇數,否則在一些顯示器上會有對不齊像素的狀況發生。
字體顏色
字體顏色數量建議在 3~4 個,不宜過多,但是每個層級之間區分要大一些。
文本應該保持至少 4.5:1 (基于亮度值計算)的對比度以保持文本清晰;最佳對比度為 7:1。
測試對比度的網站:https://contrast-ratio.com
WCAG 2.0 中將顏色對比等級分為 3 種,A級,AA級,AAA級,等級越高意味著顏色的對比度越高,呈現出來的視覺壓力越大。
3)icon(圖標)
設定統一的圖標使用規范,讓視覺效果更和諧。
icon大小
icon 的常用尺寸有很多,需要注意的是 icon 的大小中,相鄰的兩個尺寸至少相差 4px,否則你會在后期用的時候會有選擇困難癥。同時功能 icon 盡量貼邊或盡量貼邊繪制,保證展現的視覺統一性(操作 icon 除外)。
單獨 icon 使用的時候,盡量不要太小,最小值建議為 12px。
icon 熱區
icon 的熱區經常被設計師和開發所忽略,本身 icon 的尺寸一般就很小,再加上如果沒有設置熱區的話,操作體驗極差。
所以一定一定要設置 icon 的熱區,設置的值我建議為 icon 大小的 2倍。例:icon 大小為 14 * 14px,則熱區大小為 28 * 28px。
4)size(尺寸)
頁面內布局間、模塊間、模塊內的各部件距離。
尺寸大部分規范中都用的是 8 的倍數,不用糾結,直接用就行。我這里有個公式:Sn = 8px * n,n為正整數。特殊:最小支持4px。
進入進階篇階段,我們不只是按照行業標準制定規范,也不是按照一些平臺標準以及常識問題,去為自己的產品制定規范標準。而是需要投入更多的精力,站在更高的角度去思考要為產品帶來什么價值。而價值的體現就在于轉化,管理,引導,復用,創新,切忌盲目動手。
在進階篇沒有唯一的標準,都需要各位結合自身產品的業務,產品定位,用戶畫像去制定。
接下來的內容,也只是小編分享一下比較通用的方法,希望能夠幫助有緣人在迷茫的時候有個新思路。
在開始之前,再給大家補充三點,作為進階篇學習之前,所需要結合著來學習的3個方面:
引導分為 5 種:Newbie guide(新手引導)、Steps guide(步驟引導)、Help / Operation guide(幫助/操作引導)、New function guide(新功能引導)、Blank guide(空白頁引導)。
1)Newbie guide(新手引導)
新手引導是針對新用戶的,首次進入產品的時候,我們要著重的把自己產品的亮點以及操作快速的介紹給新用戶,讓他用最短的時間上手我們的產品。
新手引導要言簡意賅,并且如果非必要的話,盡量給用戶一個可以直接關閉的按鈕,讓用戶有選擇權。我就非常討厭有一些產品的新手引導,必須走完全部流程后才能關閉,惡心的不行。
2)Steps guide(步驟引導)
步驟引導一般用在有固定操作步驟的場景下,指引用戶一步一步的完成想要的結果。常規的步驟引導建議在 3~5 步之間為合理。
3)Help/Operation guide(幫助/操作引導)
幫助/操作引導的展現方式是比較豐富多彩的,可以是提示語、輔助性文本、tooltips 等等,他的作用就是輔助用戶去了解并且知道如何操作這個功能。
這個也是在產品中使用頻率最高的,運用好他,可以讓你的產品事半功倍。
4)New function guide(新功能引導)
他就是常用在新功能上線后,用戶第一次登陸相關頁面后做的一些引導,目的是為了告訴用戶我們做了新東西,你快來試試吧。
5)Blank guide(空白頁引導)
空白頁引導一般用在在缺省頁,對用戶進行一些操作指引,讓無信息的頁面變得更有價值。比如百度在一些缺省頁上就放了一些關于失蹤兒童的信息,就因為做了這個引導,幫助了千萬個家庭找到了失散的孩子。
這一章節在很多平臺里面,都會給忽略掉它的一個重要性,一個產品的延展性,通用性,易用性和親密性都離不開一個好的角色設計規范,角色設計的底層邏輯就是產品權限的制定。
目前的主流產品對于權限的制定都有一套規范標準,小編負責的產品也是通過借鑒主流產品權限的制定方式來設計,本章節主要是給大家分享下小編的方法。
我在做權限制定的對象是角色,而不是用戶,所以也點一下題,我們在做的是對產品角色設計的規范,并不是對用戶權限去做控制,接下來我們先來梳理下在做權限制定的時候常見的問題。
1)權限制定的過程中常遇到的問題有。
我們可管理的權限(系統資源)分為功能權限、數據權限:
這些問題主要都是基于用戶作為權限主體的時候會出現的問題。傳統的方式就是A -> B -> C 這類型的用戶權限去對用戶進行管理,對于業務的調整以及對功能模塊的拓展是不友好的。
因此,我對于權限管理的理解為權限是主體對客體遵循特定機制做出的行為,而本章節主要是給各位分享RBAC模型。
2)對RBAC模型中的關系描述 – 基于角色的訪問控制
RBAC(Role-Based Access Control)是一種訪問控制模型,用于管理系統中的用戶訪問權限。RBAC模型基于角色來定義和分配權限,通過將權限與角色關聯,然后將角色分配給用戶,實現對系統資源的訪問控制。
1. 角色與權限之間的關系:
2. 角色與用戶之間的關系:
這些關系形成了RBAC模型的基本結構,通過這些關系的建立和管理,可以實現對用戶訪問權限的控制和管理。
3)對RBAC模型的分析
RBAC模型的優點包括:
然而,RBAC模型也存在一些挑戰,如角色爆炸問題(角色數量過多)、權限維護復雜、權限繼承問題等。在實施RBAC模型時,需要仔細設計角色和權限的結構,平衡權限的粒度和靈活性,以及確保合理的權限繼承和分配策略。
4)分享一個使用RBAC模型的實例
假設有一個在線學習平臺,涉及學生、教師和管理員三個角色,以及對應的權限:
1. 角色與權限之間的關系:
2. 角色與用戶之間的關系:
3. 在該實例中,RBAC模型的使用如下:
通過RBAC模型,該在線學習平臺實現了對不同角色的權限控制,確保每個用戶只能執行其角色所允許的操作,從而提供了安全和可控的訪問控制機制。
5)最后,對本章節進行一個總結
在權限模型里面有兩個核心概念,第一個是靜態指責分離,第二個是動態指責分離
靜態職責分離
互斥角色限制:有些特殊的崗位,同一個用戶在兩個互斥的角色中只能選擇一個。
比如財務和審計,不能既是運動員又做裁判。
基數限制:考慮容量、并發等的問題,一個用戶擁有的角色是有限的,一個角色擁有的權限也是有限的,一個角色下的用戶也是有限的。
比如微信公眾平臺做的限制:一個微信號可綁定并管理5個公眾號。
先決條件限制:用戶想要獲得高級別的角色,必須先獲得低級別的角色。
比如一個PMer需要先從專員做起,再升為產品經理,再到產品總監。
這種條件限制在人員規模比較大的團隊就很常見了,人越多越需要嚴格且清晰的制度,避免個別的take a shortcut影響大局的穩定。
動態職責分離
動態的限制用戶及其擁有的角色。
一個用戶可以擁有多個角色,但是運行時只能激活一個角色。
常見就像招聘網站這種,用戶既可以招人也可以找工作,角色不同看到的信息完全不一樣,所以就只能激活其中一個角色。
最后給大家總結一下今天分享出來的內容,產品設計的規范標準,具體的規范還會根據產品的特點、行業要求和用戶需求而有所不同。
在制定產品設計規范時,需要綜合考慮用戶體驗、技術可行性、業務目標和品牌形象等因素,以確保產品能夠提供優質的用戶體驗并達到預期的目標。
歸納為以下8點:
本文由@樂少有話說 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。