一款產品從0到1的設計流程,在進入開發前的所有工作。這篇文章以去年做的一個小項目為例。
1.了解客戶需求,根據競品產生需求
工具:Axure、Mindmanager、Visio、OmniGraffle、PPT
1.1產品初期模型
1.1.1 競品收集(應用市場、專業網站、行業調查報告、搜索引擎、)
在應用市場、專業網站、行業調查報告、搜索引擎中尋找競品
輸出:
在產品的潛在目標用戶尋找競品
對產品的潛在用戶進行挖掘,分析核心功能的其他實現方法,將功能延展擴大可獲得不同層面的競品。
輸出:
將過程、操作的碎片化處理來尋找競品
將產品的結構、使用過程、操作等一步一步的拆開,根據每一個碎片信息來尋找競品。
輸出:
1.2競品選擇
競品選擇中最關鍵的一步,就是對競品進行分類。
1. 功能完全相同的競品:找出當下產品的核心價值,評估與我們設計目的與市場上成型產品的一致性;更快更好地借鑒對方取得成功的地方;有針對性地尋找差異化競品的方向。
2. 核心功能相似的競品:通過以點帶面地挖掘價值點或者創新點,將我們自己的產品做到。功能完全相同是一個點進行縱向思考,然后尋找競品;核心功能相似則是多個點,排列組合式地進行縱向思考,找到的競品更加全面,我們能夠借鑒到的價值點更多。
3. 功能本質相同的競品:加深對待設計產品的需求本質的理解,通過本質相同挖掘需求的核心所在,借此來找到相對應的參照物。該類競品,往往需要我們進行橫向思考,試圖從別的方面,方向入手,其思維廣度大大增加,有可能從其他領域中得到解決問題的啟示。這類競品是最容易發現亮點和突破的。
輸出:1.功能完全相同的競品
壁紙制作:可以將喜歡的圖片制作成精美的壁紙,定制專屬于你的高清壁紙。
2.核心功能相似的競品
座右銘壁紙:可選擇背景、輸入文字形成自己的鎖屏壁紙。
3.功能本質相同的競品
livefun:將視頻轉換為壁紙,將多張照片合稱為一個live photo。
1.3 競品拆解
競品拆解就是用碎片化方法對競品功能進行拆解,并最終形成競品的功能列表的過程。
形成功能列表后,對功能進行備注,尋找到競品使用過程中的不足,從而超越競品。
輸出:
接下來還需要和所有必要的相關人員就產品以及項目的開展方式進行多次頭腦風暴。
頭腦風暴(Brainstorming)是由美國奧斯提出的,一種激發集體智慧產生和提出創新設想的思維方法。頭腦風暴(Brainstorming)指一群人(或小組)圍繞一個特定的興趣或領域,進行創新或改善,產生新點子,提出新辦法。
頭腦風暴可能帶來一套啟動計劃、一個精簡的框架和一系列比較早期的概念圖以及模型。
頭腦風暴如下圖所示:
2.確定需求
2.1產品定位及如何正確描述需求
前面我們已經講述了怎樣搭建初步產品模型,通過梳理產品模型,可以清楚地了解應該如何定位一個產品。產品定位是需求收集的方向。
用戶需求主要包含三個要素:目標用戶、使用場景、用戶目標。
經過對產品定位的梳理,就明確了產品的目標用戶群體,接下來就可以進行需求的收集、分析活動了,總體流程包括需求收集、需求分析和篩選,需求優先級排序幾部分。
輸出:
產品定位:以用戶產出內容為主的可個性化推送壁紙應用。
用戶場景描述:
陶娟平時喜歡根據心情更換不同風格的壁紙,但是每次找壁紙都讓她十分頭疼,很難找到有個性又好看的壁紙(都是用戶制作上傳的壁紙作品)。
陶娟打開8樓壁紙app,登陸后填寫了她的個性偏好,系統根據她的喜好個性化推送壁紙。陶娟選了一款壁紙,還可以看到同時和她使用同一款壁紙的網友。
2.2需求收集的途徑
1.用戶場景畫像:根據之前的產品定位和使用場景用戶畫像文檔分析產出需求
2.競品分析:找到同類競爭產品,深入體驗競品功能
3.頭腦風暴:可以集結產品經理、設計師、運營、市場、開發、進行頭腦風暴,圍繞一個特定的話題進行討論
4.用戶反饋
5.數據分析
輸出:
2.3需求分析和篩選
在需求收集過后,已經有很多的被選需求了。
如何分析和篩選需求呢?
1.篩掉明顯不合理的需求
哪些是明顯不合理的需求?比如當下技術不可能實現的或明顯意義不大的,投入產出比低的、無匹配的產品使用場景、明顯不合理的需求等
2.做需求分析
把明顯不合理的需求排除后,就需要一個一個對剩下的需求進行分析。首先要了解需求的三個分類:用戶描述的需求、用戶實際想要的需求、用戶的潛在需求,這是三件不同的事情,卻有著千絲萬縷的聯系。我們需要通過用戶描述的需求,找到用戶實際的需求,再挖掘用戶潛在的需求。
3.需求做減法
有時候決定不做什么比決定做什么要更重要,產品的需求是無上限的,大量的堆積需求,會使產品非常臃腫,毫無特色,還會導致工期過長,拖慢了產品推出市場的進度,對產品百害而無一益。因此,應該傾向于做“輕產品”,學會做需求的減法。
這就涉及接下來需要討論的問題,如何判斷需求的優先級。
輸出:篩選后的需求列表
2.4需求的優先級
需要對所有的需求定義一下優先級,優先級高的需求優先開發,優先級低的需求延遲開發。
輸出:
2.5 輸出產品功能圖和功能需求列表
用戶需求列表確定之后,先以產品功能的形式展現出來,產品功能圖可以直觀的看出產品的初步功能架構。
輸出:產品功能圖
功能需求列表的價值,一是在于幫助產品經理理清思路,二是在于幫助項目團隊的其他成員了解產品功能需求,讓他們提前做好相關準備。
輸出:功能需求列表
3.產品架構
3.1 產品功能架構
結合之前的市場調研及產品路徑規劃,梳理了一下產品架構的大模塊
輸出:產品功能架構
3.2 流程圖的規范
流程圖有時也稱作輸入-輸出圖,某種程度上來說,流程圖是一種溝通性質的圖形化語言。一般會使用一些標準符號代表某些類型的動作,如判斷用菱形框表示,具體的操作行為、活動用方框表示,開始和結束用圓角矩形框表示。
3.3 確定核心功能流程圖
首先我們要設計的是產品的核心功能流程,例如登陸的流程就需要前期設計好,綁定手機號登陸還是直接微信登陸。登陸的流程會對后期的功能產生影響。
輸出:功能流程圖
做好了核心功能的流程圖后,我們需要對app主干做一個流程圖。保證每一個功能都可以形成閉環。
3.4 評審與確認
評審主要是讓業務部門和開發部門參與,好的流程圖具備清晰易懂、簡單明了、完整準確的特點
4. 原型設計
4.1 什么是產品原型
產品原型是設計方案的表達,是產品經理、交互設計師的重要產出物之一,也是項目團隊的其它成員(尤其是設計師、開發人員)的重要參考和評估的依據。
4.2 低保真產品原型
首先我們要根據產品架構畫出初步的頁面,也就是低保真產品原型。
這樣的原型圖有幾個好處:
可以快速產出:有時候一個需求的開發周期很短,低保真原型可以快速滿足同事的時間要求。
修改成本低:一個產品策劃很可能會被修改很多次,低保真的原型修改起來很方便。
輸出:低保真原型圖
4.3 高保真產品交互原型
工具:axure、ai、ps
高保真產品原型,則是高功能性、高互動性的原型設計,是忠實展示產品功能、界面元素、功能流程的一種表現手段。
高保真的好處:
便于梳理產品細節:制作高保真原型的過程中可以讓產品經理提前發現產品潛藏的各種問題,提前處理風險。
更容易讓其他成員了解產品設計:有時候簡單的線框圖無法讓別人想象出你要做的事情,也不清楚你要放的是哪幾個字段,而高保真原型就可以。
相對而言,劣勢就是制作周期比較漫長,涉及到產品流程的修改,那基本原型就得回爐重造一遍。所以高保真原型可以做一些核心頁面,不重要的頁面可以后期慢慢完善。
輸出:動態交互稿
5. 視覺設計
工具:Sketch、Ai
在產品0到1時候視覺評審,會花大量時間去討論產品的設計風格和主配色,在確定視覺稿沒有交互問題后,然后就是討論視覺設計稿的細節。在產品功能迭代的時候,評審的都是整體視覺風格的繼承性和視覺稿的細節。例如對交互設計的理解是否到位,邏輯是否正確,視覺層次是否正確等。
5.1 設計組件規范
5.1.1 為什么做組件規范
1.保證產品風格統一
每個設計師都有自己的審美和風格,產品迭代可能是不同的設計師來負責項目,但是產品的風格必須保證是統一的,所以就需要一個規范性的文件來作為設計標準。
2.提升團隊效率
在sketch里,有一個好的組件庫,設計師就不用重復去改每一個頁面上的圖標。只需要改動一個就能同步頁面上所有的圖標。
3.打磨細節體驗
在產品長期迭代的過程中,對每一個元素都需要對其場景、狀態考慮清楚。所以在整理過程中,經常會發現以前沒有注意到的問題并優化。
5.1.2 組件規范內容和分類
不同的項目的規范內容都是不同的,我們需要明確規范內容的分類有哪些??梢韵却_定大體的規范內容,在頁面完善的過程中也不斷的完善規范。
iOS的設計尺寸建議使用一倍圖375*667的尺寸進行設計。因為這和安卓的常用尺寸360*640的誤差很小。安卓和iOS可以共用字體、圖標和間距??梢愿臃奖憷镒龊媒y一的設計規范。
輸出:
文章來源:站酷
本篇文章將分享 Web 端系統布局,從基本布局初識、網格、布局模塊到柵格進行完整鏈路內容整合,以簡單易懂的案例與大家進行探討。
在以往的學習過程中,我發現市面上大部分文章對于 Web 端系統布局內容講的比較籠統,一般提及較多的是網頁柵格相關的內容,但是一些關聯性和原子結構等相關內容較少。比如,了解布局時應該需要了解哪些方法論?什么是網格?網格與柵格之間是什么關系?柵格與布局之間是什么關系等。我會從這些缺失出發,結合工作經驗與實際案例為大家進行分享。
用戶在操作系統時所看到的頁面框架其實就是系統布局,它是一個產品最外層的框架結構,一般包含了頂部導航、側邊導航欄、面包屑、圖文、卡片、內容等元素。
對于設計師而言,想要了解一個中臺,首先要了解它的系統布局,系統布局是頁面設計的基礎,它與頁面的關系,就如同建筑與地基的關系。日常完成需求時,UI 界面反復的調試頁面寬度與卡片比例會占用我們大量的時間。為了提高工作效率,并且把更多的時間放在業務、視覺創新等方面,我們就應該需要一套完整的布局規范。
對整個公司產品體系而言,內部員工與普通用戶使用的操作系統達到幾十甚至上百個,單一的頁面布局滿足不了各個子項目的使用場景。所以我們從前期的布局框架設計調研到產品業務的特性,定義了中臺界面的幾大類型,并且在我們的設計規范中定義了幾大類型系統布局方式,根據其布局方式定制好柵格,方便日后在各個業務場景中使用,從而能夠保持一致性、并且可擴展,方便快速迭代和維護。
視覺層次
對于中臺的 UI 設計師們而言,良好的理性思維相對比感性的視覺思維更加重要,因為在 UI 設計師設計頁面時需要把很多互不相關的元素有秩序的組織在一起,正確引導用戶操作與使用。亨利·亞當斯(Henry Adams)曾經說過:「混沌是自然法則,秩序是人類的夢想」。人們總是喜歡秩序,因為秩序可以讓事情變得更容易理解。這同樣適用于數字產品的用戶界面,當 UI 元素被有序組合和結構化時,人們可以輕松的使用應用程序和網站,并對產品感到滿意,所以設計頁面時需要結合視覺層次理論。視覺層次理論是設計過程的核心方法之一。最初是建立在格式塔原理的基礎上,它觀察到了用戶對相互關聯元素的視覺感知,并展示了人們如何將視覺元素歸為一類。那么什么是視覺層次呢?官方概括:視覺層次結構致力于一種用戶能夠理解的方式呈現產品的內容,以便用戶可以理解每個元素的重要性級別。它可以組織頁面內容,以便大腦可以根據物理差異例如:大小,顏色,對比度,樣式等區分對象。
蘋果的設計一直以來都是引領著設計趨勢,其設計被國內外用戶所認可,所以就以蘋果官網作為案例。其中,字重對比:蘋果官網在字重上給人眼前一亮的感覺,它采用 Medium+Bold 的字重使得標題與詳情內容產生強烈的大小對比,用戶進入官網的第一眼便能了解核心內容。顏色對比:在顏色上使用黑色背景承托產品和內容,強烈的黑白對比增強了信息傳播中的識別度和對比度。圖文排版:在圖片與文字排版中使用了文字層和圖片層互相疊加的視覺效果,使得頁面層次感更加的豐富。如下圖:
格式塔理論
往往用戶打開頁面進行閱讀或者操作界面時視覺的第一感受是產品的整體效果,而并不會感知到一些較細節的元素。往宏觀來講當人們感知到一個物體由許多元素組成的復雜對象時,人們會采用有意識或無意識的方法將這些部分安排到整個組織的系統中,而不只是簡單的元素級。它適用于不同級別的感知,但是視覺部分似乎是設計師設計界面時最能體現價值的部分,這其實就是格式塔理論,格式塔(Gestalt)這個術語來自德語單詞 Gestalt,中文翻譯為「形狀,形式」。
格式塔心理學家庫爾特·科夫卡(Kurt Koffka)的一句話可以捕捉到這一運動背后的基本思想:「整體不是元素基因的總和」。官網概括:「在心理現象中,人們對客觀對象的感受源于整體關系而非具體元素,也就是說知覺不是感覺元素的總和,而是一個統一的整體,部分之和不等于整體,因此整體不能分割」。格式塔理論中元素之知見的原則分別為臨近,相似,連續,封閉和連接。
在我們的現實生活中有很多自然規律都遵守了格式塔原則,比如說每到秋天,北方的嚴寒氣候不再適合大雁生存,這時候大雁便會飛往較暖和的南方,當人們看到天空正在南飛的大雁隊伍,它們組織鏈接得十分嚴密,并且群體在往同一個方向移動,所以隊伍的形狀在我們的大腦中將它們視為一個群組的一部分,產生人字形或一字形的圖形。
信息框架
剛剛我們也介紹了視覺層級結構和格式塔理論,接下來簡單介紹一下信息框架,它也是在系統布局中需要考慮的內容。信息框架是將信息內容進行組織分層,一個產品的信息框架取決于其特有的業務,他與業務強相關并且需要了解用戶群體目標。根據業務和用戶目標將內容組織搭建信息框架,形成系統布局的骨架,方便用戶在瀏覽或操作頁面時能夠快速找到重點內容,提升用戶使用效率。我們用今日頭條 Web 端和飛書 Web 端兩個線上產品作為案例分析吧,今日頭條和飛書屬于兩種完全不同類型的產品,那么其信息架構也完全不同。
今日頭條屬于門戶類新聞客戶端,主要是生產內容展現給用戶,首先進入到產品映入眼簾的是無窮式的信息流,它不需要用戶登錄/注冊作為身份門檻,而是直觀的把內容展示給用戶,推送用戶感興趣的內容,也不需要用戶決策任何選擇,用戶只需沉浸式的閱讀體驗即可,目的是方便第一時間抓取用戶、吸引用戶達到留住用戶的目的。當用戶產生興趣以后想要進入下一步操作如:點贊、評論時才會彈出登錄/注冊,一方面是獲取用戶的身份等信息,另一方面是間接性的把用戶留下來。從產品業務屬性來看,今日頭條的布局把重要的內容放入中間,并且占有整個布局的一半大小,其次放在內容兩側;
飛書屬于工具協作類產品,用戶第一次打開產品需要注冊才能使用。與新聞閱讀類產品不同的是工具類型產品用戶目的比較明確,所以首頁做成一個功能介紹頁面,作用是引導用戶了解產品核心功能從而轉化成產品的用戶。當然功能介紹頁也是一個網站的門面,首頁想要出彩,不僅需要在布局上做的合理還需要考慮網站的色彩、插圖等元素的統一性。在設計網站時,首頁的功能介紹頁一定要充分突出自身產品特色,強調出自身產品的優勢和亮點,如飛書首頁主要是想突出其產品能夠提高工作效率,所以直接把「在飛書,享」slogan 這句話放在了首頁的第一屏,輔助文案詳細的介紹了產品的核心功能,直接抓住用戶的痛點。用戶完成注冊以后,進入到功能頁面,如右下圖可以看出,其系統布局的模塊分成三份,占面積最大的模塊屬于產品最核心的部分也就是聊天窗口,較重要部分是聯系人部分,最小區域是功能 Tab 部分。
小結
所以對于設計師而言,在設計頁面時必須熟練掌握一些基本設計基礎知識,并且將這些知識靈活運用到實際的工作當中。比如設計師在搭建系統布局時需要熟知頁面視覺層次、格式塔理論、信息框架等知識才可創建合理的布局基礎。當然布局框架只是整個產品的基礎骨架,在骨架確定之后,設計師才可進行下一步的設計,如統一的視覺表達元素,清晰的功能操作,流暢的交互表達。
系統布局規范,需要通過統一的設計元素和間距規范去引導使用者們(使用規范的設計師)跨平臺使用并且能夠適配不同屏幕尺寸,目的是達到一致性,可適配、可控性原則。
一致性:對于界面來講,界面中的元素和結構需要保持一致性,如:在使用布局時應當使用一致的網格,基準線和填充,在使用設計元素時配色、圖標、文本等需保持一致。
可適配:布局是可自適應的,根據用戶在不同的設計環境下能夠通過交互動效、界面樣式有效作出適配反應。用戶操作后需給出即時反應。
可控性:當用戶看到界面時應直觀有效傳遞內容,如界面中模塊區域明確、內容組織明確、表意明確都能使得用戶快速理解。界面需要簡單直白,讓用戶快速識別,減少用戶記憶負擔。
在設計過程中,為了減少設計師們的日常溝通和理解成本,在設計內部我們統一了一套設計畫板尺寸為 1280。經過我們官方調研得出在中臺系統中用戶使用的電腦屏幕主流分辨率分別為:1440*900、1366*768、1920*1080、1280*800,而1280 是主流分辨率中最小且最為保險的的一個尺寸,在設計頁面時設計師如果能夠在 1280 尺寸下,縮小寬度或拉升頁面寬度都能保證沒有遮擋或擠壓問題,那么設計是合理的。在我們的規范中頁面再小于 1280 時需要吊起系統的橫向滾動條。在中臺系統中考慮到用戶效率問題很少做響應式,所以常規情況下設計師會限定界面的一個最小值。如果設計師把畫板設置為 1440 或者 1366 時可能會存在其在畫板中頁面大小正好合適,但是頁面上線以后縮小瀏覽器可能會發生遮擋或擠壓的情況。所以我們建議設計師們使用 1280 寬度畫板畫圖。
首先先分析一下界面框架,我們將頁面的用戶操作行為進行層級區分。我們至下而上將元素進行層級分層,目的是把用戶界面模塊化。界面可分成背景區域、內容層、全局控制層、內容彈層,每一層都具備獨特性,將界面中所有的信息層級提取分類并且按結構屬性分層,目的是能夠使得頁面視覺和交互邏輯符合用戶的習慣認知。之前我們有提到過視覺層次、格式塔理論和信息框架,設計師在創建這一步的時候可以用來指導搭建一套合理的頁面信息層級,一個內容模塊都屬于一個容器,容器可以承載各種內容元素。
背景層
背景層樣式固定,在界面中永遠置于界面底部,并且一般會給予背景層中性色,作用是方便突出內容層和全局控制層。
內容層
視圖結構中最核心和復雜的一層,他與業務強相關,內容層的容器承載了業務場景的用戶需要獲取的核心信息以及輔助核心任務的操作。容器承載了內容,從 Material Design 中的 Elevation(海拔)概念中可以了解到,它屬于第二層級內容,基本布局結構有平行結構或者父子結構。如下圖卡片屬于容器,卡片中承載了數據圖表等內容,整個卡片+內容就屬于內容層。
全局控制層
全局控制層我們定義他在內容層之上,屬于頁面第三層級內容,一般在業務場景中對整個網站的控制以及導航功能如:Header menu、Sidebar menu 組件,如下圖中 Header menu 浮在內容層之上。
內容彈層
當前任務或者內容相關的臨時出現層,優先級高于內容層,一般承載當前需要臨時處理的任務或者需要進行內容補充說明等功能。如:Modal(Dialog 各個平臺叫法不一致)、Tooltip、Popover、Notification 等組件 。其中 Modal 是以滑出或者彈出的形式展現給用戶。Modal 它包括兩種類型,一種是模態內容層不可操控,被蒙版遮罩禁用,比如在業務中需要較為聚焦的分支流程操作時使用。另一種是非模態,吊起彈出層后不印象內容層操作。當然,Tooltip、Popover、Notification 都屬于非模態,反饋較輕,不干擾用戶使用界面。如下圖的頁面中的內容彈層使用了 Popover,在次頁面它的功能就是加以補充說明。
隨著科技高速發展,屏幕分辨率也越來越多樣化對于 UI/UX 設計師來講必須熟練的基本知識方便日常工作所需。首先我們先了解一下屏幕中的一些單位。
在高密度屏幕下每英寸具有比低密度屏幕更多的像素,可能導致開發實現稿的視覺不符合設計師心理預期,比如:相同像素尺寸的 UI 元素在低密度屏幕上顯得較模糊,而在高密度屏幕上則比較清楚。同一物理尺寸(肉眼所見尺寸)下,低密度顯示器的像素個數明顯小于高密度顯示器的像素個數。
其實像素是與密度沒有關聯,我們簡稱密度為 DP (讀作 DIP,英文全稱 Density-independent pixel ),它是可縮放的靈活單位,可在任何屏幕下現實相同的尺寸,如圖顯示,紅色網格為像素密度,被放大內容為 UI 元素物理尺寸。
所以我們可以得出,DP 可以自適應屏幕的密度,不管屏幕密度怎么變化,實際顯示的物理尺寸相同,DP 可以保證物理尺寸的一致性,所以 DP 是目前比較適合 UI 設計的單位。當屏幕的密度為 160 的一個物理像素時,1PD=1PX。要計算屏幕密度,可以使用以下公式得出:DP=(PX*160)/PPI。
關于網格
網格線(Grid Line),網格線又稱布局分割線,它是構成網格結構的分界線。一般在布局中它們是由行網格線和列網格線組成。如下圖是模擬網格做了一個示意,其中橘黃色兩根線分別是行網格線和列網格線。
網格軌道(Grid Track),兩個相鄰網格線之間的空間。你可以把它們想像成網格的行或列。如下圖橘黃色的行網格線和列網格線之間的空間既是網格軌道。
網格單元格(Grid Cell),兩個相鄰的行網格線和兩個相鄰的列網格線之間的空間屬于網格單元格。這是網格系統的一個「單元」。如下圖橘黃色的行網格線和列網格線交叉處即是網格單元格。
網格區域(Grid Area),由單個或多個網格單元格組成,它是可以用來擺放頁面元素。如下圖所示,橘黃色的行網格線和列網格線交叉處即是網格區域。
網格設置
在設計界面時可以通過網格定制能夠使界面更加有序、整齊、規范,網格的主要用途之一是保持設計元素對齊和排序。通過建立一個網格系統,設計師可以為自己創建一個結構來適配不同的屏幕寬度。
在我制定的規范中一般會把網格的基數設置為 4,它不僅符合偶數的思路同時也能夠匹配多數主流的顯示設備,如中臺系統的用戶主流分辨率用 1440*900、1366*768、1280*800。我們可以通過設置網格規范幫助設計師快速搭建頁面,使用有律可循的布局空間的設計給到開發減少溝通成本。下圖所示設計布局網格由三個元素組成:列寬,間距,邊距。
在 Sketch 中設置網格,在菜單欄中找「視圖」-「畫布」-「網格設置」-彈出浮層可設置網格大小,網格設置的基數設置成4,之后在設計界面時可按照網格基礎的倍數作為組件的大小和頁面元素間距分割,如下圖:
我們放大頁面局部大家可以看到,把網格基數設置成 4,每個網格單元格為 4*4 大小。同理,如果把網格基數設置成 8 以后,每個網格單元格大小為 8*8 大小。
界面框架內系統布局是頁面所有模塊的組合方式,我們定義一個頁面框架中基礎模塊和內容模塊的數量最好不超過 3 個。經過調研和歸納總結出 3 大布局類型,分別是上下布局、左右布局、T 字型布局。
上下布局布局是 Web 端運用最廣泛的布局方式之一,頁面內容區以 feed 流形式展現,一般用在 Web 端官網首頁。設計師普遍做法是對兩邊留白區域為內容區并進行最小值的定義,一般定義值為 1200 較多(具體寬度要設計師如何設置柵格,后面會講到如何設置柵格),當留白區域到達極小超過極限值之后需要對中間的內容區域進行動態縮放或遮擋,此邏輯需設計師根據業務所需而定。也有少部分設計師會設計成全屏布局,內容隨瀏覽器寬度自適應。
其優點是頁面結構清晰簡單,強突出內容區,但缺點是布局的規矩呆板,變化少。設計師如果不注意合理的視覺元素和色彩細節變化,用戶很容易感覺到乏味,此布局適用于層級較為簡單頁面。
巨量引擎(Ocean Engine)是字節跳動旗下的營銷服務品牌,整合了今日頭條、抖音短視頻、火山小視頻、西瓜視頻、懂車帝、Faceu 激萌、輕顏、穿山甲等產品的營銷能力,為全球廣告主提供綜合的數字營銷解決方案。我在設計此官網時正是采用了上下布局作為頁面布局,頂部導航整合了所有子頁面的內容,導航下方為主要內容區并且內容定寬,當時采用此布局原因第一是因為次官網層級較簡單只有三個層級內容,第二是官網更需要的是突出內容區,所有頁面使用次布局更為合適。
設計師在設計重內容,輕導航類型網站是常用左右布局作為基礎框架進行頁面設計。此布局把系統頁面分為兩大模塊,其中設計師常見的做法是將左側設置成導航欄模塊并且固定,常常用來控制全局內容。而右側區域設置成工作區域或內容區,內容區可進行動態縮放。
下圖為飛書溝通窗口截圖,由于關系到內部信息保密性我把內容進行了模糊,從外觀結構上看還是能大致了解飛書結構是采用了左右布局,整個布局結構清晰有理也是符合左右布局特點。從交互體驗分析左側屬于導航區,它承載了不同功能并且固定。飛書屬于即時溝通產品設計師考慮到瀏覽器窗口有限所以對導航設計成較小模塊,而右邊為聊天窗口對于業務屬性分析它更為重要,所以模塊較大。其導航欄固定,內容區可進行動態縮放。
T 字型布局常用在 Web 端的中臺系統中,因為中臺系統業務結構復雜、層級多,而 T 字型布局能夠解決復雜結構的問題。使用此結構能夠把頁面結構清晰化,主次更加分明。設計師常常的做法是將頂部作為一級導航欄方便控制全局,二左邊設計成是二級導航并且固定導航欄固定,右邊的內區域可進行動態縮放(一般會把其設計成柵格動態區域),內容隨瀏覽器寬度自適應。
下圖是 Material Design 設計文檔,首先簡單介紹一下 Material Design,它是由谷歌的設計團隊創建的一種語言,宗旨是幫助設計師們創建易用性和實用性較強的網站和應用程序,其設計理念是將現實中的物理學帶入進設計中。Material Design 設計文檔中的結構使用了 T 字型布局作為基礎布局。頁面分為了三個模塊,其中頂部導航作為頁面一級內容進行全局控制,接下來左邊為側邊導航作為二級內容控制頁面,右邊是內容區滿足用戶使用瀏覽。從放眼望去整個頁面架構清晰明了。
以上為 Web 最常見的三大布局,但是需要大家在實際的工作中靈活運用。設計師在日常工作中可能會遇到更為特殊的業務場景,設計師可以通過整理基礎模塊然后分析其業務的信息框架,將模塊進行相互組合、嵌套歸納可以總結出更多的 Web端布局框架并落地到業務中。
剛剛在定義布局模塊中已經分析過了三大布局類型,接下要分享的是 UI 設計師更為關注內容「網頁柵格」。網頁柵格也是設計師口中常常提及的柵格系統。其實網頁柵格系統是從平面柵格系統中發展而來,它延續了平面設計的方法與風格,在網頁中使用柵格能夠使得網頁信息展現更加清晰明了、美觀易讀。
首先網頁柵格系統基本由是柵格總寬度/頁面總寬度(W)、一個柵格的寬度(a)、柵格與柵格之間的間隙(i)、一個單元的寬度(A)、外邊距(M)組成。
1. 列寬
一個柵格的寬度(a),我們稱之為列寬,一個列寬包涵了N個網格單元格(Grid Cell)我們也可以把它看成一個網格區域(Grid Area),在上面我們已經講到過網格的內容,主要目的正是為柵格做鋪墊。其中我把一個網格單元格設置為4(原因在網格中也解釋過,如果忘記的同學可以爬樓看下)。由此可見列寬非固定值,這樣可以使內容自由適配任何屏幕尺寸。在柵格中列寬由屏幕尺寸決定。
2. 水槽
柵格與柵格之間的間隙(i),我們稱之為水槽,一個水槽寬度大于等于1個網格單元(Grid Cell)。在柵格中水槽為一個定值,寬度可以是N個網格單元,如網格單元格設置成4,那么水槽可以是4、8、12、16…N*4。
3. 柵格單元
1個列寬+1個水槽寬度即一個單元的寬度,一個柵格總寬是由N個柵格單元組成,次寬度不固定,由屏幕尺寸決定。
4. 柵格總寬
列寬+水槽再成以N即是一個柵格的總寬,公式為:W=(A*n)-i。
5. 柵格設置
經過調研我們得出常見的柵格分為 12 列柵格系統和 24 列柵格系統。其中 12 列柵格系統在流行的前端開發開源工具庫Bootstrap 與 Foundation 中廣泛使用,適用于業務信息分組較少、業務結構較簡,單個盒子內信息體積較大的中后臺頁面設計。24 等分的柵格系統適用于業務信息量大、信息分組較多、單個盒子內信息體積較小的中后臺頁面設計;相對 12 柵格系統,24 柵格系統變化更加靈活,更適合內容比較多樣復雜的場景。如下圖分別是 12 柵格系統(左)和 24 柵格系統(右)。
6. 小結
在柵格系統結合布局結構和網格做了我做了一些知識結合,其實前面所講的網格版塊和布局版塊都是為柵格做一個鋪墊,利于同學們更加深入的了解網格、布局、柵格三者的關系。
系統布局只是網頁中的基礎部分,但也是核心內容,一個產品布局需要根據其業務屬性決定。布局搭的好相當地基打得好,但是同時在對美感的追求之上,還應當結合可用性來看待設計。在實際的工作中肯定還會遇到各種形形色色較奇葩的需求,所以希望這篇文章能夠做的不是限制而是啟發,大家可根據此次分享內容能夠進行舉一反三利用到實際的工作當中。
文章來源:優設
本文整理了人工智能行業中設計師需要理解的一些名詞和內容。
一方面供自己學習思考,另一方面也希望能幫助到準備投入到人工智能行業的設計師。之前聽有的朋友講到,覺得自己沒有計算機背景,有點害怕進入到這樣一個領域來。
沒有計算機背景沒有關系,只要對這個行業充滿好奇,一個個的問題解決掉,在你眼前的迷霧都會散去的。
先簡單舉幾個人工智能在生活中有在應用的例子:
像現在有的超市寄存物件,開箱時采用的人臉識別;像家里購置的智能音響,時不時還能跟它聊上幾句;像接聽到的銀行電話(是的,對方可能是機器人噢);像在淘寶上咨詢的客服小蜜;像你手機里的虛擬助手….等等這些都是人工智能在生活中的應用。
人工智能在設計領域的應用也相當廣泛,具體可以看這篇文章:
這幾個例子是在生活中比較普遍能接觸到的,實際人工智能應用的領域還在不斷的擴大,我們甚至都無法想象到,未來的生活會是怎樣的狀態和場景。
在這家公司之前,我做過語音交互類的產品交互設計。當時在定義人與設備進行語音交互時,會是怎樣的一個交互場景。從說喚醒詞到發出指令,從收到反饋到繼續對話。喚醒后等待的時間、結束的規則等等這些。
而現在,我大部分時間是在設計工具,如何讓使用者能快速的創建出一個智能機器人。如何讓機器人的創建者方便快捷的添加機器人的相關數據和創建出對話場景。
所以在進行這些工具的設計之前,有些名詞概念,會需要設計師來了解一下,能讓我們更好的理解人工智能的一些原理以及能夠讓設計師具象化到實際的設計中,甚至能基于此技術/原理來進行相關的創新或研究。
整理內容如下:(內容基于工作及自身理解,如有概念理解錯誤,歡迎指正)
下面嘗試用較易理解方式來解釋這些名詞:
與機器人進行對話,首先就需要讓機器人懂我們說的話,這其中,就需要來關注到自然語言處理,通過自然語言處理技術,能夠實現我們與機器之間「無障礙」對話。
我把這三者關系畫了張圖示,我是以這樣的方式理解的
從圖中可進一步看出,NLU 和 NLG 是 NLP 的子集,而 NLP 是人與機器溝通中很重要的存在。
涉及到語音就會經常聽到 ASR 和 TTS
語音識別(ASR):將語音內容轉為文字
如微信里面,當別人發的語音信息不方便外放收聽時,可以轉為文字查看
語音合成(TTS):將文字內容轉為語音
如現在很多的閱讀軟件,支持播放,有的就是利用 TTS,直接將文本內容轉為語音播放出來。
我試著將上面提到的 NLP 和 ASR、TTS 組合起來,關系可以如下圖所示
當我們說一句話的時候,機器知道我們表達的是什么嗎?
意圖(Intent):一個人希望達到的目的,或者解釋為想要做什么,他的動機是什么。
如:
槽位(Slot):可以理解為系統要向用戶收集的關鍵信息。
如:
「買張明天從上海到北京的機票」
上面這句話中,獲取到意圖(買機票);提取關鍵信息 時間(明天)、地點(出發地:上海;到達地:北京)
這些關鍵的信息就是槽位,當系統獲知到這些信息后,就能去執行下一步動作。
還可以這樣理解,當我們去銀行營業廳辦理卡的時候,會填寫一張表,表每個要填寫的選項,就是一個個的槽位。槽位就是為你服務的人員要從你那收集的關鍵信息。
實體(Entity):用戶在語句中提到的具體信息
實體這詞放在生活中,我們很容易理解,就是實實在在的物體,像桌子、電腦、熊貓等等這些都是實體。
但是在人機對話中,機器理解人的語句內容,會識別出語句中的實體信息(如:地點、人名、歌曲名等),然后進行標記。
那槽位和實體是不是講的是一回事?只是不同的說法?
我之前有一度陷入這樣的困惑中,但其實這兩者還是有所區別的。比如,一個實體是數字,但是在語句中,數字將代表不同的含義。
如:
人:有沒有10元的鮮花? 機器人:玫瑰花10元一支 。
這句話中,實體number「10」,但這個 10 在句子中表達的是價格,所以收集到的槽位信息是價格:「10元」
這樣說可能還是不太能理解,那我們可以先了解下,在一句表達中,需要進行槽位信息收集,但機器如何知道「買張明天從上海到北京的機票」中,「上海」是城市,并且「上?!故浅霭l地呢?
「上海」這個詞會被建立在一個城市實體詞庫中,這是「上?!鼓鼙蛔R別到是「城市」的原因。
其次,通過將解析槽位加入語料中,加以訓練讓機器學習相關表述結構,來獲知該句式中,收集到的第一個城市是出發地,于是把第一個城市填到對應的槽位中。
使用什么工具來讓機器知道,這個信息是要提取的信息?
解析器(Parser):抽取/解析用戶語句中的關鍵信息
上一個講到實體,這里講到的解析器則是這么個工具,用來抽取這些信息。比如會有些通用的解析器如時間解析器、城市解析器、歌手解析器等等。
解析器的類型也比較多,如通用解析器、詞典解析器、正則解析器、組合解析器等等,這里就不再擴展開講具體解析器,實在過于復雜了。
命名實體識別(NER):用來識別具有特定意義的實體。主要會包括像機構、地名、組織等。
是不是發現,解析器和 NER 在做差不多的事情?我是這樣理解的,解析器的話是一個更大的存在,其中包括了 NER。解析器下會有不同類型和不同功能的工具來實現關鍵信息的識別/抽取。
在我們與機器人對話時,一般會涉及到四個不同類型的對話,開放域的聊天、任務驅動的對話、問答(FAQ)和推薦。
上面是在有次分享中提到的,這四個不同類型的對話,在機器人平臺中,會需要借助不同的功能模塊來實現。
任務對話(Task Dialogue ):有上下文聯系,就像我們要去訂票、訂餐之類的一段任務型的對話。
我們公司產品中,任務引擎模塊就是做這個任務對話的創建,比如,要訂機票的場景。用戶在這個訂機票的場景中,會涉及到的對話內容、流程的設計。
知識圖譜(Knowledge Graph):這個可以理解為可視化關聯信息。
比如:查詢一個明星的身高、年齡,他的學校、他的女友,他的相關作品,這些基于這個人而構建的信息庫,都可以通過知識圖譜在做整理。并且在構建時能夠做到可視化的了解。
要讓機器人知道,它腦子里有貨了!
訓練(Train):這個概念可以這樣理解,比如你創建了個機器人,但是它什么都還不懂,于是你塞了堆知識給他,這時,它就需要自己訓練學習了。訓練好了,就能回答你塞的那堆知識里的問題了。
講到這就忍不住想用這個學習的例子,來簡單講下一般機器人的創建流程。像我們在學校,會經歷上課學習新知識-復習溫習-考試-整理錯題集,以此循環進行。
這個創建機器人的流程也是一樣通過知識的導入/創建-訓練-測試-優化-上線-優化,以此循環,不斷強化機器人,讓它越來越智能。
其他:
數據標注:將對話日志中的有價值數據做標注(標記/匹配/關聯之類)。
因為人的表達萬千,多種表達方式都代表的同一個意思。有時用戶說了句話,是語料庫中并不包含,于是機器人可能就答非所問了。
Ai 訓練師們就可以將這些數據信息標注到對應的問題中去,這樣當用戶再用同樣方式表述時,機器人就能如預期回答了。
講到標注想到之前在朋友圈很火的你畫我猜,谷歌推出的這個小游戲席卷朋友圈。他們用了個如此聰明的做法,其實我們參與其中的做法就是在做數據標注,而且還是主動提供數據的那種。
這也反映了,數據對于機器人的重要性,通過不斷的進行數據維護和補充數據,機器人就會越來越理解人,表達也會越來越智能。就跟我們學習一樣,不斷學習才能夠理解其他的含義,甚至當認知能力提升了,看待問題的角度才能不一樣。
文章來源:優設
B 端工作看起來總是沒有 C 端工作那么有趣,面臨的限制比較多,面對客戶(金主爸爸),很多時候總是左右為難。在實際工作中,面對這些情況該怎么辦?筆者根據自己的 B 端工作經驗,總結了一些交互設計的要點。
從事 B 端 SaaS 行業已經兩年有余,從最開始面對需求的茫然無措,到現在已經有了自己的一些基本方法論,這期間經歷了從有人帶到自己摸索的一個階段。
每天看看文章、看看書,大家講的都是 C 端的產品,C 端的交互和體驗;每天看同行們分析的不是如何提高用戶活躍量,就是 APP 的設計風格。這在我一個 B 端交互看來,無比羨慕啊。
C 端項目的設計師感覺每天和一線用戶打交道,忙得不亦樂乎,可以與用戶直接對接,可以添加有趣生動的文案。
而對于一個做 SaaS 的 B 端來說,Boss 常說的話就是:
你這個顏色太鮮艷了。
我們是 B 端,你這種頁面布局不合適吧。
這個文案太幼稚了,不適合我們產品的調性。
中規中矩就好,不要太跳。
整理了一堆的字段,畫了無數的線框和流程圖,卻拿不出 C 端設計師才有的豐富多彩的作品集,
盡管如此,設計的原則是通用的,無論是尼爾森十大可用性原則,還是格式塔原理,在設計方案的落實上,都有著相同的方法論。
無意在此討論 B 端和 C 端之間的差異,僅以此文章來總結下我自己的一些工作經驗,如有錯誤,敬請指出。
從業務需求的對接,到界面交互的細節,從功能的設計要點,再到產品的發展導向,我總結出了以下幾個方面,逐步展開:
C 端設計師最開心的可能就是收到用戶的反饋需求了吧,這樣表示自己的產品還有人在用,然后建個群讓用戶開開心心吐槽,完了就從里面提煉適合產品的一些需求和建議。
而對于 B 端設計師來說,如何處理需求是其成長的第一關,尤其是 SaaS 行業,不會處理需求,產品的功能更新將會遇到極大的問題。
B 端的用戶不像 C 端,雖然可以用用戶畫像來進行歸類和分析。但是由于 B 端的直接用戶是付費用戶,付了錢的就是大爺,因此大爺提的需求你敢不應?
用戶提的需求亂七八糟,有些是體驗問題,有些是功能問題,有些就是屬于比較極端的需求。那種傳說中甲方要你做一個可以根據手機屏顯示顏色而改變手機殼顏色的需求,在 B 端行業也是存在的。
那么問題來了,我們該如何處理紛繁雜亂的需求呢,我從收集需求-評估需求-需求落地挨個講起:
如果你也打算像 C 端產品體驗群那樣建立一個群,完了將自己的用戶聚集在那里,靜靜等待需求的話,我勸你三思而后行。你可以這么做,但是應該明確群的目標,可以收集需求,可以是 bug 反饋群,也可以是更新通知群;但是不要將其變成一個純粹的用戶反饋群,因為這會導致用戶的吐槽聲音過大,而讓潛在的用戶流失。
B 端的客戶一旦使用你們的系統,就要付出相應的金錢和時間代價,不是說想換一家就能換。因此他對于已經使用中的用戶反饋是極其看重的,B 端的產品很大程度是靠著同行間的口碑傳播從而取得了良好的效益。如果一個新用戶想進群了解,結果一進去就發現大家都在吐槽這個系統的不足之處,那么可想而知他的選擇是什么。
因此,最好的需求收集方式是通過運營、市場以及客服的同事們的反饋,因為他們是離客戶最近的人,他們每天都跟客戶打交道,了解這個行業從業者的一些基本情況。很多時候,客戶回訪和運營對接的時候用戶會提出一些功能的建議。
通常的一種情況是,在 SaaS 行業,你的一個客戶的流失意味著你的競爭對手多一個客戶。因此一般市場都會有競爭對手的信息,他們會知曉客戶從我們平臺流失到其他平臺的一些原因。最重要的是,他們也為你提供了絕佳的競品資料,進而可以進一步明確需求。
收集好的需求,該怎么處理呢?
工具之前我用的是 trello,很好用,你可以將需求按照類型分為不同的看板,規劃產品的進度。
之后由于團隊的原因,改用 teambition,功能要豐富點,可以寫測試案例等,對于國內用戶比較友好;可以按照 KANO 模型將需求劃分為不同的類型,用以安排產品。
KANO模型
基本(必備)型需求——Must-beQuality/ Basic Quality
一個產品應該具有的基本功能,能滿足用戶的基本需求,比如,微信的基本功能是即時通訊。
用戶不會因為該功能的出現而覺得滿意,因為這是基本的、必備的一項功能。如果連這個都沒法滿足,用戶滿意度會大幅下降。
期望(意愿)型需求——One-dimensional Quality/ Performance Quality
用戶迫切希望產品能提供的功能,當提供該需求時,用戶滿意度會大幅上升,當不提供該需求時,用戶滿意度會下降。
比如百度網盤一直為人詬病的下載限速,無法對單次下載而付費。而需要開通會員,用戶的抱怨恰好說明了其痛點;當提供單次下載付費的服務時,用戶滿意度明顯提升。
興奮(魅力)型需求—Attractive Quality/ Excitement Quality
用戶對該類型的需求并無明顯的期望,但是若產品能夠提供該類需求,用戶滿意度會極大提升,也會培養用戶的忠誠度。
比如,很多產品都有實驗室功能,即對那些不是必備需求的功能設計一個開關,用戶打開后可以進行使用。對于有的用戶來講,這些功能很大程度上會帶來驚喜。當然,每個人期望不一樣,實驗室方案也可以視為另類的灰度測試,用以驗證用戶對于功能的需求。
無差異型需求——Indifferent Quality/Neutral Quality
產品無論是否滿足該類需求,用戶的滿意度是不會變化的,正如用戶不會因為收到「瑪莎拉蒂5元代金券」而感到開心。因此在 B 端行業,開發時間有限的情況下,無需為該類需求投入資源。
比如優化一個用戶訪問量很少的網頁,也無需因為領導或者客戶的個人喜好而改變后臺頁面的顏色。無論使其鮮艷活潑還是穩重大氣,后臺滿足基本的視覺要求和規范即可。當然,這并不意味著你可以把后臺設計的簡陋和雜亂。
反向(逆向)型需求——Reverse Quality
當提供方向性需求的功能時,會招致大部分用戶滿意度的大幅下降。比如常見的在搜索中摻加廣告、強制用戶授權過多個人信息以及推送大量無用的消息等,會導致用戶的反感。
通常需求的收集不是你一個人在進行,產品經理、老板以及其他同事也會幫助你收集,匯總到你這里的需求會開會進行討論,下一步要做什么。
做之前首先要對需求進行評估,評估的原則基本是按照 KANO 模型來,但是也會有比較特殊的情況。
交互設計師需要注意的是,你除了需要關注用戶體驗的問題以外,還要與開發一起評估該需求的實現;你不懂技術沒關系,開發會告訴你該需求的落地會出現什么問題,在實現上會有什么難度。這些在評估需求的階段都要提出來,并且在交互層面解決掉,否則你畫出了原型以后,開發告訴你這個頁面必須要修改,否則開發成本過大,無法在排期內完成,這個時候你再去改交互稿將會費時費力。
評估完需求,定好下期開發的需求后就結束了么?
其實并沒有,因為需求收集不可能是一個固定的階段,它是漸進的、不確定的。因此收集需求和評估需求會不斷在實際工作中疊加和重復,比如你制定好了需求優先級,已經著手開發了;這時候老板或者領導突然又增加了一個優先級很高的需求,所以你得重新安排這些需求。如何在敏捷開發中保質保量的完成工作任務,這是一場斗智斗勇的 battle。
前面講到需求評估的時候,需要與開發人員一起評估技術難度。其實在你將需求落地為交互原型的時候,也需要持續溝通,這完全是為了避免因為技術問題而產生修改設計稿或溝通不順暢的問題。
如果你是在做的過程中,持續與開發人員保持溝通,能了解到他們是如何實現這個功能的。當然,有些基本的設計原則所不允許的事完全不用屈服于他們的「淫威」,畢竟他們得按照你的方案來。如果開發懶惰而想通過最簡單的辦法來實現,用戶體驗又是極其不友好,那么請直接對其說「NO」。
比如常見的刪除的二次確認等彈窗,一般最好的體驗是在按鈕旁邊彈出;但有些開發懶得寫彈窗,直接調用瀏覽器的彈窗,即瀏覽器頂部經常出現的那種確認彈窗,這個時候你要堅決告訴開發,這樣搞是堅決不行的。
需求的落地伴隨著競品分析,判斷一個需求是否靠譜、落地方案是否成熟的一個重要途徑就是競品分析,可以通過調查研究相關競品是如何進行設計的。這對于我們有著非常大的幫助,可以避免很多的彎路,甚至能避免犯錯,提高交互方案的可靠性。競品分析又是個比較繁雜的事項,如果是有特殊要求可以做成報告的形式,如果僅是去參考對照的話只需要去體驗競品即可。
B 端的業務比較重要,尤其是涉及到數據的增刪改查和金額的計算,一旦出錯,將會導致無法挽回的后果。因此在出錯前和出錯后,應該有相應的挽回機制。
1. 出錯前
內容編輯類的功能應該提供自動保存草稿功能,防止沒有及時保存而丟失內容;刪除、禁止等較重操作應該有二次確認,防止用戶誤刪。
對于操作流程應該建立明確的引導機制,長表單可以分開按步驟填寫。
提示信息應該明確而及時。比如一個表單需要登錄才能填寫,在未登錄的狀態下,應該先提示其登錄再填寫否則用戶在填寫大量信息后,因為一個錯誤而前功盡棄。
系統內的禁止信息、警告信息、提示信息建立一套相應的規則。
2. 出錯后
用戶的時間就是金錢,這對于 B 端商家角色中尤為重要,大量訂單的處理、表格化的導入和導出、批量管理和網站運營等方面,對于效率有著極高的要求,商家通過可視化界面來完成某項任務。
在這其中,影響最大的莫過于交互方式了,相信各位一定用過各大銀行的網站,頁面的導航關聯性弱、結構不合理、提示不明確、交互流程過長,甚至有的網站光是登錄,就得大費周章。
如何提率,我認為主要從以下幾個方面著手:
1. 提高易用性
如果你的產品,讓人看一眼就能上手,那么說明是非常友好的設計。易用性不一定意味著簡單和低智,依據復雜守恒定理(泰勒斯定理),每個應用程序都有自己內在的、無法簡化的復雜度。
所以,提高易用性意味著要設計合理的交互,易用性分為對新手(小白用戶)友好和對老用戶(專家用戶)友好,包括數量最大的中間用戶。
如果你的界面是僅僅對于新手友好,那么可能完成的任務都是簡單而輕松的。但是對于老用戶,他需要更復雜的功能來處理大量龐雜的任務;因此在設計的時候,既要提供傻瓜式的操作方式,也要對專家用戶提供提率的工具。
2. 智能化
此處的智能化既包括通過大數據或者人工智能自動將操作步驟變得簡潔,也包括諸如一些字段輸入、自動定位、圖片識別、OCR 等方式來使用戶的效率得以提升的功能。
以前的用戶要摳圖可能會在 ps 中操作好幾個步驟才能完成,但是隨著機器學習技術的發展,ps 已經可以更加智能的摳圖。當然,還包括其他功能的智能化。
在 B 端 SaaS 領域,智能化也是一個重要的趨勢,針對不同的商家所面臨的不同的行業領域,我們或許可以提供更加全面且友好的服務。
3. 場景化思維
如果你深入了解你的用戶,去觀察他們整個行業的運作模式,以及他們對于業務的處理方式,你就會明白你的產品的走向。
你需要深入每一個場景,比如,在戶外旅游領域,發布旅游產品線路的可能是在辦公室中的編輯人員,帶隊出行的是在戶外場景中的導游,現場簽到的可能是集合點的管理人員,而處理訂單的又是另一個坐在辦公室里的小伙伴。
他們需要協同工作,才能使各項工作順利展開,發布活動-用戶報名-訂單管理-報名人統計-活動成行-集合點簽到-帶隊出發-旅游結束-活動評價-領隊評價-交易成功,這一系列流程中,面臨的角色是復雜的,而意外也是常有的事。比如報名人無法參加活動而導致的退款、活動因為天氣原因而無法成行、戶外活動發生意外等。
你需要做的就是:
場景化的思維會讓你設身處地為一線操作用戶的體驗而努力。因此,交互稿完成以后,徹底回退到小白用戶的身份,假裝自己是在某個場景下要做某件事,通過你的交互方案,能否順利完成自己的目標。
此處的通用性是指,在 SaaS 軟件領域,不同客戶所面臨的行業有一定的差別,可能這個功能對于 A 用戶極其重要,但對于 B 用戶,該功能并不重要。比如有的客戶想要在前臺展示某活動的報名人的姓名以增加真實性,用以吸引用戶參加;但是有的客戶就明確反對該功能,認為這個功能侵犯了用戶的隱私。
諸如此類的需求相離、甚至相反的情況太普遍了。合適的解決方式是建立兩套開關,一套是由 SaaS 服務提供商的統一后臺來配置,用以區分比較大的行業差別,比如電商領域中,可以配置店鋪類型為:美妝、服飾、食品、電子產品等;另一套開關在客戶的站點后臺,用以控制不同的站之間的差別,比如前臺界面樣式、交易流程、相關字段或菜單的前臺顯示等。
另外比較重要的一點,也是最基本的一點,軟件設計中存在一個原則就是高內聚低耦合,模塊化設計,用以提高系統內部組件的復用。
交互設計也是同樣的道理,可以將你的商品視為一個模塊,那么這個模塊無論是添加到網站,還是小程序,我只需要創建一個商品即可,可以同步更新到不同的平臺。
另外,訂單的管理只需要添加相關的標記即可(比如來自小程序的訂單標記為小程序,淘寶訂單標記為淘寶等),一個平臺發布,多個平臺同步,有效提高了運營人員的效率。
同樣的,如果你的 pc 端產品和移動端產品沒有實質性的運營差異(即當成兩種模式來運營),那么很多數據(如文案、圖片、banner等)的獲取可以采用同一個數據源 。
最后,提高系統內的一致性,減少用戶認知成本。在同一平臺內的頁面,樣式和交互上要盡量保持一致性,不要有的地方是總金額,有的地方是總價格,這會讓用戶犯迷糊。提高通用性,也意味著你需要關注并熟悉系統內不同功能之間的關聯性,盡量做到統一處理。
在進行商業化運作和產品功能的優化時,對于正向的用戶需要激勵,對于負向的用戶需要限制。
這是我在讀完有贊的白鴉寫的關于有贊產品設計原則的文章后,影響最深的一個原則,他寫到:
我們的使命是幫助每一位重視產品和服務的商家成功?!该恳晃弧购汀干碳页晒Α故俏覀冏钪匾年P鍵詞,我們要服務的是每一位商家,然后幫助每一位商家成功,但是為了整個生態的健康,那些不重視產品和服務的商家,我們是(可以)不服務的。所以我們在產品設計原則上,在產品做一些功能的選擇上,如果這個功能做完了會導致商家不重視產品和服務,我們是不會/能做的。
舉個例子:消費者購買之后(可以)有一個評價,我們的購物評價是要么開啟要么不開啟這個功能。我們不接受商家去刪購物評價,因為商家一旦可以刪了消費者的差評,他就(很可能)不會那么重視產品和服務了。所以有贊永遠不會提供刪除商品評價的功能,商家要么就不開啟。可以不用,如果要用就要接受有人說你不好,商家可以去跟消費者溝通,溝通完了消費者自己改,但是我們不提供讓商家刪壞評價的功能。所以,這就是最基本的有贊產品設計原則,我們只服務重視產品和服務的商家,我們所有的產品設計原則都是需要這樣。
——《白鴉內部培訓:企業服務類產品的底層邏輯和有贊產品設計原則》
更多內容請看:
曾任支付寶首席產品設計師,現任有贊創始人的白鴉是很多人心里的產品大神,這份由他在內部分享的《產品設計原則》值得設計師、產品、運營等閱讀學習。
閱讀文章 >>我將其概括為一個產品的中正原則,即中立且保持正向原則。
一方面,對于企業未來的發展而言,正向的用戶能帶給平臺無盡的潛力,平臺可以和商家一起成長,而負向的用戶,則會給平臺帶來隱患。比如,淘寶既限制商家的違規運營和欺詐客戶,也限制 C 端用戶的惡意薅羊毛,在商家和用戶之間做一個中立者和調節者的角色。
我在做需求的時候,也遇到過很多的負向需求,這在商家看來是一個必須的功能,作為平臺應該提供。但是若是提供給商家,則會對消費者的利益造成損害,刪除差評就是一個很好的例子。
看了白鴉對于有贊產品原則的闡釋,我覺得每一個平臺類的產品,都應該保持自己的中正原則:
在 B 端行業,口碑傳播是非常重要的一種被動營銷方式,很多 B 端公司都是低調的潛行者,堅持中正原則,并不會損害自己的利益,反而會獲得商家的尊重和消費者的信賴。
啰啰嗦嗦說了這么多,比較細碎,不乏邏輯凌亂的片段,但也算是對自己兩年以來對于 B 端交互的一些心得吧。
其實交互的原則基本都是通用的,無非就是根據平臺屬性做一定的調整,不同的是產品所處的行業,每一個產品都無法脫離其所處的行業而存在,這也是使用產品的具體場景。
因此做一個產品前,一定要了解行業,去熟悉行業的通用做法,了解行業的專業術語和規范,研究行業的所屬群體等,這樣你就會做出真正適合市場且能讓大多數用戶滿意的產品。
文章來源:優設
在網頁和移動端界面中,內容和信息是否能夠經過系統性、有效的整理和組織,對于內容的可用性和實用性,都是意義巨大的。而在呈現信息的時候,視覺間隔是組織信息的關鍵因素。它說起來并不難理解,但是在實際的運用當中,卻是千變萬化,今天我們來梳理一下流行的視覺間隔的方法。
視覺間隔是一種布局元素,它有助于將內容分隔成為清晰的分組、選項和部分。它可以讓設計師更好地組織內容的視覺體驗,處理信息的層級,也有助于用戶理解內容,明白內容之間的關系。
視覺間隔和頁面上的其他內容在一起,構成視覺層級,這是它最重要的作用。在視覺間隔的幫助之下,用戶可以輕松地感知內容之間的關系,明白各個信息片段之間的關系是相似,并列,承襲,從屬,還是其他。
視覺間隔的可用性也同樣重要:在很多時候,有的視覺間隔元素看起來是可點擊,可交互的,這在移動端界面上,是非常重要的。
談到視覺間隔,我們可以從兩方面來進行拆解分析:視覺間隔的外觀和功能。按照視覺特征,視覺間隔有5種基本的類型:
下面我們分別針對這5種類型進行說明。
很長時間以來,在排版印刷領域,線條就一直是一種用來分隔內容的方法。線條的分隔功能是認可度最高的一種間隔方式,用戶幾乎不用思考,就能夠理解和感知它,并且發揮作用。
另一方面,這種間隔方式也很容易顯得過于簡單,并且和應有的形態相去甚遠。這也是為什么設計師在想盡辦法去尋求別的視覺間隔形態。太多的線條間隔會讓屏幕上的視覺干擾太多,并且帶來不必要的視覺噪音。
所以,能夠將線條間隔用得微妙、恰到好處、出神入化,是設計師功力的一個重要體現。
在這個網站產品頁面中,使用深色的線條間隔來分割產品信息,用來組織和間隔信息內容。
在這個頁面當中,線條分隔了不同的內容區塊,讓頁面的結構更易于被掃讀。
這個電商網站將不同級別的視覺內容進行了分離,借助簡單的水平線將價格、CTA按鈕以及承載相關信息的表單分隔到不同的區域。
負空間,也就是留白,也是最為常見的一種視覺分隔元素。留白絕不是對空間的浪費,和屏幕上其他的元素一樣,它同樣發揮著重要的作用,拱衛支撐著整個用戶體驗。負空間是最為流行的視覺分隔之一,尤其是在極簡主義風格為主導的設計當中。負空間本身遵循著格式塔原理,尤其是其中「接近原理」和「相似原理」是負空間在設計中,發揮分隔作用的核心所在。合理地運用負空間,還能強化頁面的呼吸感。
上面這款旅行規劃 APP當中,使用留白將不同的條目分開,沒有使用額外的具體視覺元素,僅僅只靠留白。
Health Blog 的列表的排版層次是基于負空間來實現的,看起來清晰又充滿呼吸感。
高對比度的色彩,同樣能夠帶來清晰的視覺間隔效果。在 UI 界面中高對比度的色彩有著極為明顯視覺表現潛質,它們能夠增強網站的信息和內容的表現力,分割區塊,營造氛圍。對比度是影響頁面和屏幕可讀性的關鍵因素之一。在具體的應用當中,不同的色彩會有效地分離不同的選項、條目和區域,這意味著它作為視覺分隔的作用非常強。這也是近年來分屏式設計如此流行的原因所在。
這是一套移動端菜單的概念設計,強烈的色彩對比讓信息清晰可見。
即使是在這樣的柔和的設計當中,色彩的對比度也發揮了相當的作用:一方面,強烈的色彩對比讓CTA按鈕和輸入框之間有了明顯的區分,另一方面,右側的主視覺元素的背景也同樣借由不同色彩的對比,做到了突出的效果。
在 GNO Blankets 這個網站當中,強烈的明暗對比將網站元素分隔成為精美而清晰的區塊。
陰影和體積也是一種非常常見的視覺間隔方式,通過營造在「高度」或者說高程上的視覺差異,從而達到分層的效果,而這種設計也是符合人類一直以來的認知習慣。這種方法有利于保持整個設計的平衡和易讀性,另一方面,它又能保持足夠的微妙和自然,不會那么引人矚目從而讓人覺得出戲或者受到干擾。
這個APP的目錄頁面所有元素都采用了白色的背景,而陰影讓布局呈現出了縱深層次,讓內容足以展現又不顯突兀。
這款提供定制化花束服務的APP也采用了類似的陰影元素,讓整體看起來清晰又通透。
圖片在 UI 界面當中,同樣也是一種非常有效的視覺間隔,尤其是在包含大量文本內容的界面中。無論是博客、在線媒體網站還是其他類型的網站當中,圖片的間隔作用都非常明顯。無論是照片、插畫、3D圖形,它們作為圖片都可以很好的平衡文本內容,提高內容的識別度和可讀性,有效地劃分層級,并且提高情感吸引力。
這個比特幣網站的著陸頁就使用了帶有3D效果「了解更多」動態圖片,圖片和文本在內容和功能上都清晰地分隔開來。
在這個餐廳 APP 當中,圖片作為劃分內容的關鍵元素而存在。
如果從功能的角度上來劃分視覺間隔,可以根據它所處的層次來進行劃分。
使用線條作為全出血間隔是最為常見的,它會很跨整個屏幕布局來作為信息層級的劃分。
這個畫廊圖庫 APP 的藝術家目錄當中,使用線條作為全出血間隔,來區分藝術家。
這個名為完美食譜的APP也使用了全出血間隔線來區分內容。
在這個財務APP當中,也使用了全出血間隔線來區分條目。
在這個電影APP的結帳頁面當中,也使用了線條來作為全出血間隔。
嵌入式間隔的功能是將相關性較高的內容分割開,并且它通常會和標題或者其他的特定元素保持對齊或者對應,它們通常是進行某個大區塊內不同組件的分隔,或者將多個同類的元素分隔開。
這個網站當中,使用橫向的短分隔線來區分表單中的參數條目。
這種分割線通常會置于布局的中間某處,同樣是分隔相關的內容,但是通常它們在屬性上不一定是一致的,但是層級近似。
在這個出售草藥的電商網站的右側,使用中間分隔線將文本和可交互的區域清晰地分隔開。
上面對于不同類型的視覺分隔方式都有描述,在此之外,還有兩個問題需要注意:
文章來源:站酷
日常工作中,經常聽到交互和視覺同學有著如下對話:
可以看到,無論交互還是視覺同學的提問,其實都是圍繞「信息」表達的邏輯。視覺同學設計過程中,應該如何理解交互稿件,并進一步體現交互的層級邏輯?是否可以對交互稿的布局進行調整發揮?我們通過案例來一起看看。
目前,頁面類設計一般分為運營型和平臺型。
關注重點:「活動利益點」「模塊內容順序」「視覺發揮空間大」
活動頁設計中,信息的層級表達相對簡單,一般分為主氛圍圖-體現活動主題、內容展示區-直接轉化、尾部兜底區-相關擴展。這類型需求,重點在理解交互稿中主題的表達、內容區的分類及重點元素體現。視覺設計師在該類型的設計中,發揮度是很大的。
關注重點:「層級結構」「瀏覽順序」「視覺在信息邏輯之上發揮」
平臺類設計項目,交互設計師通過頁面框架、模塊設計來表達產品/運營的策劃思路,涉及內容及模塊更多,且包含著復雜的邏輯關系。一個優秀的平臺視覺設計師,應當是通過好的視覺表達,按照交互信息層級關系,將信息內容傳遞給用戶。這里視覺同學要避免兩個誤區:完全按照交互框架和排布,只是純粹填色;從「好看」的角度重新布局,忽略交互層級關系。
下圖是美妝頻道的一次改版,通過觀察交互稿和視覺稿可以看到,這位視覺設計師在交互稿的基礎上,采用了更靈活的視覺引導方式。這些改變是否有效傳遞了交互邏輯?視覺階段的這些調整是否都合適呢?看完本文,你就能有一個清晰的答案了。
瀏覽順序 元素表意
這是一個新品速遞模塊的設計方案。交互稿表達的信息是:這個區塊是用來介紹新品的,首先希望用戶知道模塊屬性是什么,然后讓用戶快速了解推薦商品是什么,及為什么值得買。視覺稿較好的傳遞了交互層級及信息表達,首先突出了欄目名稱讓用戶能一眼看到,其次是商品及商品特性展示;而稿件中的欄目名稱位置和樣式則在視覺上做了自由的發揮。
小結:模塊中各元素的瀏覽引導(眼睛瀏覽路徑)需要嚴格按照交互邏輯,元素的表達和位置可以根據邏輯發揮。
下面這組案例,在信息層級上,視覺稿是否完整傳遞了交互邏輯?先自己思考一下吧~
模塊比重 內容布局
交互層級來看,整個區域有2個模塊「正在進行」和「品牌精選」,每個模塊有4個等大的展示單元格。而視覺稿中,「正在進行」模塊的單元格變成了兩大兩小。嚴格來說,這個調整是不符合交互邏輯的。
但是,視覺稿的輸出效果明顯更靈活,瀏覽層次更佳!那,能不能這么改呢?
這需要回到,為什么交互輸出時,畫成了等大樣式。在交互環節,運營側提出四個專題希望是相同層級,無優先級的差異。
這種情況下,視覺同學如果仍然堅持有層級差異的視覺感官更好,可以先和交互同學一起商量,從用戶體驗的角度來看,這個改變是否有嚴重影響,如果團隊內部也都認為改動后的效果更佳,可以一起找到對應的運營同學,說明原因,建議他們進行調整;同時去了解這樣的調整對業務方的業務表達是否有影響。
小結:視覺表達要關注信息模塊的比重,視覺側好的想法也要直接提出和交互及業務方討論
上面這個案例也是關于模塊比重的,最大的差異在于欄目名稱及入口的調整。從不強調樓層名稱變成樓層名稱成為模塊的視覺焦點,因涉及到模塊比重,類似的改動也建議和交互設計師進行討論。同樣,該案例的改動,豐富了樓層樣式,并通過標題模塊強調了樓層的調性氛圍,同時并未對用戶閱讀體驗造成不好的影響,因此是個視覺提升交互表達的優秀案例。
對于同層級關系的單元格,我們也可以采用不同的操作方式,比如上面案例中,視覺環節使用了疊起的展示樣式。相對于交互,優點在于增加了一種互動形式,而缺點則在于會對部分信息進行遮蓋,不能直觀呈現全部內容。這個案例的處理方式是,我們將兩種方案的優劣告知運營方,運營方認為可以犧牲部分信息的呈現,而選擇互動方式的不同呈現。
我們以TAB來舉例,TAB形式體現的是并列關系的多個模塊呈現,視覺設計師可以根據不同場景用不同視覺方案來呈現。
常規的視覺展示
場景化表達-日歷
下面案例中,交互傳達的是一周七天的食物推薦,在視覺階段可以把TAB樣式設計得更貼近日歷,更貼合模塊的主題表達。
場景化表達-餐桌
這個案例視覺側在模塊面積上進行擴大,影響到原首屏內展示內容的信息量。這種情況則需要與業務同學進行溝通,信息后置是否會影響他們在首屏信息的展示需求。一般活動類頁面,首屏內容和頁面長度的要求,相對寬松;如果是工具類/綜合性展示頁面,信息是否能在首屏出現,對頁面點擊和使用效率會有很大影響。
TAB的引導位置
下面案例中,因為TAB的位置發生了調整,用戶的閱讀順序發生了變化。交互稿中,我們希望用戶先看到TAB分類以了解推薦手機的不同緯度;而視覺稿中,優先讓用戶看到推薦商品,如果首輪推薦無興趣,再通過TAB切換查看其它維度內容。
元素的不同呈現順序會體現不同的交互邏輯。
下圖中的推薦區模塊,交互上的順序是圖→人物→具體商品描述,首先強調的是商品,其次是用戶的評價;而視覺稿上的順序是人物→圖→具體商品描述,首先調的是評價的人,再說商品是什么。兩種邏輯其實都符合「食鮮者說」的邏輯,但從屬關系是不同的。這里的邏輯決策是,如果評價用戶是知名度較高的,可以通過人物為食物加分,則我們選擇視覺稿邏輯;而如果我們是靠商品圖本身致勝,評論者只是輔助決策元素,則選擇交互稿邏輯。
模塊間的層級關系,可以通過去色來快速判斷,是否符合交互瀏覽要求。去除顏色和元素對界面視覺優先級的影響,更聚焦邏輯本身。
對比下面案例,去色后可以更容易看到,優化后方案更加整體,視覺引導也更加順暢。
交互稿中體現的邏輯,涉及到樣式/位置調整的,我們應遵循原則:「在保證信息順序、層級關系、信息占比邏輯正確的前提下,視覺可以進行專業的各種發揮」。
文章來源:優設
無論是2B產品,還是2C產品,用戶系統都是基礎。對于非互聯網產品從業者,2C用戶系統的場景和功能通過日常各類APP的使用,大家都非常熟悉。因此,筆者通過和2C產品的對比,談談2B SaaS產品的用戶系統設計。
2C產品面向的用戶是個人,用戶系統的核心是獲客,因此大多2C產品的用戶系統設計重點在于方便用戶注冊、登錄,能夠建立精準的用戶畫像,從而達到流量變現的目標。
2B產品面向的用戶是企業,用戶系統的核心是組織、員工精細化管理,提升人效,從而實現節約成本的目標。
2C產品的注冊主要用于個人用戶注冊場景,重點在于提供多種渠道的注冊方式,如賬號、手機、第三方社交應用(微信、微博等),其核心目標是既能方便用戶注冊,又能多渠道多平臺賬號打通。
2B產品的注冊分為兩部分:企業管理員代表企業注冊和企業員工注冊。
2B平臺型SaaS產品,和2C最大的區別在于產品需要用戶付費。因此,平臺方為企業(平臺租戶)提供了注冊入口,一方面需要方便租戶能夠通過其他渠道快速注冊試用產品,一方面需要驗證企業相關信息,識別該用戶確實為潛在用戶。
1)企業注冊:
當企業管理員代表企業注冊時,需要提供的注冊信息:管理員昵稱、手機號、郵箱、企業工商信息(名稱、組織機構代碼、地址、法人信息等)。
其中工商信息的完整度,不同的產品要求不一樣,需要根據具體產品而定。如果方便注冊拉新,盡量減少工商信息填寫要求,如果產品安全性要求較高,可以盡量要求工商信息填寫完整。
2)企業工商信息認證:
這部分并非強需求場景,取決于產品的安全性要求。一般安全性要求較高的平臺產品,會在企業注冊后,進入到企業工商信息認證環節。此環節要么是平臺管理員人工審核,要么通過第三方認證驗證企業工商信息是否合規。企業完成認證后,即可試用產品。
如非安全性要求較高的產品,可以直接跳過該環節,租戶通過注冊頁信息填寫完整后既注冊成功。
3)企業員工注冊:
登錄場景比較容易理解,目前B端產品相較C端產品仍然比較傳統,多采用郵箱/手機進行登錄。
未來也希望可以實現,B端產品能夠和更多C端產品平臺打通,可通過通用的第三方賬號進行登錄,實現業務與社交的連接。
用戶畫像是2C產品至關重要的內容,只有精準的用戶畫像,才能更精準的服務好用戶。無論是電商,還是資訊平臺,基于用戶畫像的精準營銷投放才是產品的核心。
2B的產品很少有講用戶畫像相關的內容,事實上對于2B產品而言,用戶畫像也至關重要。
筆者目前從事CRM產品相關工作,CRM核心要解決的問題就是幫助你的客戶獲客,那么如何去建立客戶的企業標簽,去按照企業標簽屬性,借助大數據分析,幫你的客戶找到他的客戶群,是筆者近期在研究的課題。
2C的產品從本質上來講不存在組織結構,個人用戶即為產品主體,但會存在群組/社群的概念。
2B產品的應用主體是企業,而組織結構是企業運營管理的必要手段和方式。因此組織結構管理是用戶系統的重要組成部分。
1)建立組織結構
組織的單元是部門,因此管理員需要能夠按照企業組織結構建立、調整(編輯、合并)、刪除部門。
2)部門樹結構
部門作為組織結構的單元,只是組織結構的分子,而要形成組織,就要按照企業的業務形態要求形成一定的層級體系。因此部門不僅僅只是簡單的信息描述,還需要有層級描述,這就需要我們在建立部門時按照層級結構建立部門,定義清楚所建立的部門是上級部門、下級部門。
3)通訊錄展示
管理員通過后臺創建完組織結構后,企業員工可通過前臺查詢按照部門結構展示的通訊錄。
角色管理是B端產品的特有功能,企業員工按其所負責的業務模塊劃分不同的崗位職責。
由于企業數據具有較高的安全性和私密性要求,按照崗位職責的不同,不同崗位的員工對于業務數據的操作/查看權限不同。
因此,我們設計了角色管理,該角色并非嚴格意義上的崗位職能角色,而為了區分不同的員工不同的系統權限所設計的系統角色,這就是RBAC設計。
1)建立角色
建立角色的主要目標即為建立一個用戶權限組,該權限組內的用戶具有相同的權限。
2)分配角色權限
基于角色分配系統權限,以實現不同的角色下的用戶擁有不同的權限。
員工管理是B端產品的特有功能,員工是企業組織的重要組成部分,員工也是產品真正的終端用戶。
B端產品從本質上是要能夠幫助企業員工提升工作效率,提高企業人效,以實現企業管理者降低運營成本的目標。
1)新建員工
前面提到的用戶注冊即為新建員工的過程。包括被動邀請和主動注冊兩種形態,主要目標是將員工信息注冊至系統,并建立員工和企業的關聯關系。
2)建立員工匯報關系結構
為了實現精細化管理,企業內部一般按照組織結構設定員工的匯報關系,因此從CEO到基層員工會形成組織關系樹,該結構可以和組織結構完全一一對應,即該部門下的所有員工均匯報給部門負責人,但也有部門內部分不同的小組,不同的人匯報給不同的小組負責人。
因此匯報關系和組織結構關系有一定關聯,但并不是完全一一對應,所以我們需要設計員工匯報關系功能。
3)員工離職設定
為了保證企業數據的安全,員工離職后,需凍結員工賬號,離職員工將不能以該企業員工的身份登錄系統,以確保企業數據的安全性。
至此,2B用戶系統的功能基本設計完整,其重難點在于組織結構、權限控制,需要重點關注。
文章來源:人人都是產品經理
當我們在談 SaaS 的時候,在談什么?
● 什么是 SaaS
● SaaS 產品的優缺點
● SaaS 產品的銷售模式
● SaaS 產品指標
● SaaS 業務指標
● SaaS 收入計算
一、什么是 SaaS
這個模式讓軟件變得和水電氣很相似,只需要每月繳納固定的費用即可享受服務。
——馬克·貝尼奧夫(salesforce 創始人)
訂閱模式
SaaS(software as a service),軟件即服務,是一種軟件交付和銷售方式——訂閱許可模式。
它基于云, 運行在遠程服務器上,集中托管。因此不需要獨立部署甚至物理分發來完成交付和使用,這意味著用戶通過網絡即可使用。
例如,過去你使用 office,需要買一張光盤或者在線下載,輸入序列號(一次性付費),進行本地使用。如果要更新你需要重新購買和下載版本。而 SaaS 只需在線登錄即可使用服務,無需安裝和手動升級,并根據使用時間付費(按月/年)。
規模化和復利
SaaS 采取訂閱付費(按月/年)模式,良好留存的情況下,當月/年的收入就是下個月/年的基礎,不斷累加下去(復合累積收益),形成良好的現金流。
也因此,SaaS 產品的收入具有了經常性、可預測性的特點。這使得,企業可以根據現金流進行規劃,甚至通過融資,提前獲取未來的收入,來進行產品的增長和擴張。
同時,對于訂閱者而言,無需購買硬件和中間件(前期成本),以及實施、維護、更新、運維和管理成本(后期持續投入成本),只需要連接網絡即可使用,致使決策和投入成本得到了大幅降低。同時,后期可根據業務的發展,升級套餐或增加數量,這些優勢致使 SaaS 軟件更容易擁有大量客戶,形成規模。
從復利性角度,SaaS 產品的估值是經常性收入的若干倍。因此,SaaS 產品的改進,不僅僅是提高下個月的或者長期的收入,而是整個企業的市值,可謂“一本萬利”。
開放和靈活
SaaS 會針對不同組織的訴求,提供多種套餐方案,通常在付錢前,用戶可以進行免費試用,從而更好的判斷是否滿足自身需求。
同時,SaaS 會開放自己的接口(API),方便與其他軟件集成,從而更好的滿足客戶業務。SaaS 廠商也會對接市場上跟產品業務相關的主流軟件,從而提供更加完善的解決方案。
例如,你使用 53KF 云客服進行在線服務,同時打通 CRM 和訂單系統,以及百度、騰訊、頭條、360 等流量渠道,從而提供更好的客戶支持和流量轉化。
先進生產力
SaaS 產品的發展,是不斷驗證市場需求(PMF)、優勝劣汰的過程,其成功就代表著某種先進生產力(工具、流程或方法)。
從更大價值角度考慮,SaaS 賣的不僅僅只是工具,而是解決方案,融入到生產制造中去,協助客戶獲取成功。同時,對于廠商而言,也是更有價值、更有競爭力、更長久存在的經營方式。
從市場而言,SaaS 是一種眾包模式,廠商覺得市場有大量的同類需求且長期存在,開發成產品進行運作。也真正有效的節省了同類訴求其社會資源的多次投入。
由于 SaaS 產品的有利可圖,促使市場的激烈競爭,也鍛造了廠商在其領域的專業化,提供更加有效的解決方案。
二、SaaS 產品的優缺點
優點/優勢
● 易于訪問。SaaS 通過網絡提供服務,用戶可隨時訪問,且數據儲存在云端,實時同步。
● 免費試用??梢栽诟犊钋?,進行免費試用,進行多家對比,選擇最合適的。
● 費用便宜。使用訂閱模式,價格取決于用戶數量,訂閱者無需一次性支付大量費用,降低前期購置成本。
● 支付靈活。按月/年進行支付,此外,訂閱者可根據業務發展,增加或升級套餐,減少或降低套餐,甚至隨時停止使用。
● 良好支持。服務的好壞決定了客戶的訂閱,所以 SaaS 廠商會提供更加友好、高質量的客戶服務。
● 開放集成。開放的接口(API)可以與其他產品進行數據打通。
● 立即使用。無需安裝和部署,有網絡的地方即可使用。
● 無需維護。SaaS 統一運行在廠商的服務器上,由廠商統一維護、更新。
缺點/風險
● 數據安全。所有數據儲存在云端和軟件廠商的服務器上,可能會引發泄露等安全問題。SaaS 軟件廠商,通常非常注重數據的安全性,因為數據泄露對于 SaaS 廠商的企業經營而言是致命打擊。有些 SaaS 廠商也提供混合云服務,將敏感性數據儲存在客戶自己的服務器上。
● 網絡連接。沒有網絡,將無法使用 SaaS 產品。同時,網速深刻影響 SaaS 產品的運行速度。
● 服務中斷。軟件廠商的硬件故障、網絡攻擊等造成的服務中斷,會致使產品無法使用。
三、SaaS 產品的銷售模式
通常來說,SaaS 的銷售模式分為三種:
1、非接觸(no-touch):自助服務
1、低接觸(low-touch):交易型銷售
2、高接觸(high-touch):顧問式銷售
非接觸(no-touch):自助服務
理想的 SaaS 銷售模式是客戶自助完成整個服務,沒有銷售人員的介入。
這需要產品簡單、價值明顯、支付容易甚至售價便宜。同時,產品本身提供良好的支持(操作引導、使用說明、幫助中心以及反饋入口),從而允許客戶自助完成服務。
非接觸的 SaaS 產品,通過省去銷售團隊和支持性投入,采用低價,獲取大量客戶。同時,也因為價格便宜,無法支持銷售和支持性團隊的組建。
例如,某 SaaS 產品,10 月/月,一個銷售人員的底薪 4000 元/月 + 五險一金和辦公等費用,那么至少需要銷售 600 個客戶才能抵消成本,這是很難完成的。
低接觸(low-touch):交易型銷售
低接觸的 SaaS 產品,通常采用免費試用的方式,進行獲客。然后,銷售人員通過在線咨詢服務(53KF 云客服)或者電話進行銷售轉化。
同時,產品在 onboarding 上需要投入大量的資源,從而降低用戶使用摩擦,使得用戶能夠成功的上手并獲取價值。
低接觸的 SaaS 產品通常采用按月訂閱的模式,其滿意度決定了持續收入。因此,低接觸的 SaaS 產品的銷售,需要同時兼任“客戶成功”的職能,提供良好的客戶支持,從而保證客戶持續的獲取產品價值而不斷續費。
高接觸(high-touch):顧問式銷售
高接觸的 SaaS,通常需要大量的人力投入,招標、拜訪、出解決方案、商務談判等等。
高接觸的 SaaS 更多采用年度收費的模式。強銷售決定了年收入的上限。因此,高接觸的 SaaS 產品幾乎是圍繞銷售團隊的,市場營銷的主要工作是為銷售團隊獲得足夠多且合格的銷售線索;產品、開發更多的配合銷售團隊滿足客戶需求;客戶成功團隊接收后期服務、產品支持、關系維護以保證客戶續費。
從我個人接觸到的,低接觸、高接觸對于產品設計而言,在于主導權方面。
低接觸會考慮更多的價值面(通用的最大化價值),從而會拒接沒有未來(可能性和想象力)的單體訴求。
而高接觸,更多來自客戶傳導給銷售,銷售傳導給公司,公司傳導給產品的業績壓力。所以,高接觸一定是高單價,低單價的高接觸在一定層面掙得是辛苦錢,無競爭力的勞動輸出,而不是方案輸出。
四、SaaS 產品指標(SaaS Product Metrics)
PMF(Product-market fit) 產品市場匹配
SaaS 產品的早期,更多的是驗證產品與市場的匹配(Product-market fit,PMF),直白的說就是生產的產品是否具有市場價值,是否有人愿意花錢購買。
所以 PMF 是不斷確認這三點的過程:
1、目標客戶是誰
2、目標客戶的需求(痛點、爽點、癢點)
3、提供的解決方案是否能掙到錢
PMF 通過早期付費客戶來確定有利可圖的細分市場。和他們不斷交談,收集反饋來迭代產品。
并根據付費客戶特征,尋找客戶共性,從而更緊密的圍繞最佳客戶打造產品、從而更明確的找到目標客戶接觸途徑、從而更有效的設計市場營銷宣傳策略。
NPS(net promoter score) 凈推薦值
通過 NPS 進行客戶滿意度調查,衡量客戶體驗,預測未來業務增長以及預防客戶流失風險。
NPS 采用 10 分制,讓客戶進行打分。
打分者分類:
● 推薦者(dpromoter):9-10 分,對服務非常滿意,愿意持續使用并向他人推薦,從而推動產品增長
● 中立者(passive):7-8 分,對服務滿意,但忠誠度低不會主動對產品宣傳,容易受競爭對手影響
● 貶低者(detractor):0-6 分,對服務不滿意,會對產品進行負面評價和傳播,從而阻礙產品增長
NPS=(推薦者數/總樣本數)×100%-(貶損者數/總樣本數)×100%
例如,有 100 客戶打了分,結果如下:
● 10 分:15 人
● 9 分:20 人
● 8 分:20 人
● 7 分:20 人
● 6 分:10 人
● 5 分: 10 人
● 4 分:5 人
忽略打 7-8 分的人數,9-10 分人數 35,6 分及以下 25 人,NPS=35%-25%=+10%
如果 NPS 是負值,那么業務收入可能將會減少,因為客戶在不斷流失。正值的 NPS,表明客戶滿意度高,未來具有可持續增長的潛力。
五、SaaS 業務指標(SaaS Sales Metrics)
單位經濟收益:CAC:LTV
SaaS 產品的成功與 PMF 高度匹配之外,還需要一個切實可行的商業模式,即客戶價值(LTV)大于獲取成本(CAC),健康的增長意味有效平衡兩者,從而確定這是一個有利可圖的市場。
CAC(Customer Acquisition Cost)
獲得客戶的平均成本。
CAC= 銷售和營銷費用之和 ÷ 新增客戶數量
LTV(Customer Lifetime Value)
客戶生命周期內(從注冊到流失)平均總價值。
LTV=(ARPA*毛利率%)÷ 客戶流失率
ROI(Return on investment)
客戶獲取的投資回報率。
ROI=LTV:CAC
Months to recover CAC
CAC 通過 MRR 收回的平均月份。
Months to recover CAC=CAC÷(ARPA*毛利率%)
ARPA:每個帳戶的平均收入,你的 MRR 除以客戶數量,即所有客戶的平均 MRR
毛利率=[(營收-成本)÷ 營收]×100%
David 在《SaaS Metrics 2.0–衡量和改進重要內容的指南》一文中指出,LTV:CAC ≥3,Months to recover CAC ≤12 月,通常被認為是良好的 SaaS 項目。同時也指出,很多健康 SaaS 在初期可能并不符合,但會在一段時間內通過改善業務逐漸接近這兩條準則。
經常性收入:MRR 和 ARR
經常性收入(Recurring Revenue)是未來持續可獲得的收入,就 SaaS 而言,經常性收入來自客戶的訂閱,具有穩定、可預測、高度確定的特點。
在 SaaS 業務中通常采用按月或按年合同:
● 主要按月合同及少量的年度合同,采用 MRR(Month Recurring Revenue 月度經常性收入)。MRR 用于衡量每月訂閱收入,如果有一些年度訂閱,除以 12,再分攤到每月來計算 MRR
● 按年合同及少量的多年合同 ,采用 ARR(Annual Recurring Revenue 年度經常性收入)。多年合同除以合同年限,再分攤到每年來計算 ARR
在 MRR/ARR 統計中,并不會計算一次性的收入。例如,定制功能費用。
經常性收入會不斷推動這 SaaS 廠商的發展,也是驗證產品是否具有可持續增長的指標。
流失(Churn)
SaaS 是訂閱模式,在高留存率下,隨著時間的推移,意味著更多的客戶、更多的訂閱,持續收入不斷復合累積。所以,流失率對 SaaS 廠商是非常重要的指標。
在 SaaS 中有兩種計算流失的角度:
● 客戶流失(Customer Churn),取消訂閱的客戶數量
● 收入流失(MRR/ARR Churn),取消訂閱的收入損失
那為什么會有兩種計算方式?
例如,53KF 云客服的業務,是按照坐席收費,50 元/月。假如我們有 200 個客戶,100 個大客戶(每個大客戶擁有 100 個坐席),100 個小客戶(每個小客戶擁有 10 個坐席)。
當月,我們流失了 10 個客戶,那么月客戶流失率為 5%。
如果,流失的客戶中,有 8 個是大客戶,2 個是小客戶,那么 MRR 流失 45000 元,MRR 流失率為 7.45%。
如果,流失的客戶中,有 2 個是大客戶,8 個是小客戶,那么 MRR 流失 14000 元,MRR 流失率為 2.55%。
所以,通過不同的計算方式,使得我們更加全面、準確的了解到業務中所發生的事情。
Customer Churn Rate
客戶流失率,客戶取消訂閱的比率。
Customer Churn Rate= 期間流失客戶數 ÷ 期初客戶數
MRR Churn Rate
月度經常性收入流失率,通過降級、取消而損失的 MRR 比率
MRR Churn Rate= 期間流失 MRR ÷ 期初 MRR
Net MRR/ARR Churn
凈 MRR/ARR 流失。
Net MRR/ARR=期間新增 MRR/ARR 之和 - 期間流失和收縮 MRR/ARR 之和
Net MRR/ARR Churn Rate
凈 MRR/ARR 流失率。
Net MRR/ARR Churn Rate=(期間流失和收縮 MRR/ARR 之和-期間新增 MRR/ARR 之和)÷ 期初 MRR/ARR
當收入增長超過流失的損失,在這種情況下,凈 MRR/ARR 流失則為負值,稱之為負流失(Negative Churn),表現在財務表上的就是收入的不斷增長。
記住,在計算流失時,總是在特定的時間范圍內,例如上月客戶流失率是 5%。
六、SaaS 收入計算
確認收入(revenue recognition)
對于 SaaS 而言,確認收入是非常重要的財務知識,確認收入與合同金額、收款金額有很大的區別。
例如,按年收費的 SaaS 產品,年費 1200 元,那么:
● 合同金額是 1200 元
● 客戶一次性支付年費,收款金額是 1200 元
● 在合同期間的每個月的確認收入則為 100 元。剩下的 1100 元則為遞延收益
● 從企業資產負債表而言,剩下的 1100 元均為負債。因為服務還未完成,還需要投入 11 個月資源履行服務義務,甚至合同可能發生中止等情況,所以還不是確定的收入,需要通過后期的確認收入(損益表中的利潤)來減少資產負債表上的負債
* 遞延收益:指尚待確認的收入或收益。凡在期間內完成的服務所產生的收入,則為確認收入;反之,即使款項提前預收,但未在期間內完成服務,則不作為確認收入。
* 資產負債表:反映企業經營在一定時期內(月份、年度)財務狀況(兩個方面,一方資產、另一方負債和權益)的報表。
* 損益表:反映企業經營在一定時期內(月份、年度)利潤(收入)或虧損(支出)的報表
總結
通過梳理總結,談了談 SaaS,這是在我當前知識體系范圍內的總結,SaaS 是的龐大的體系,關乎個個層面:產品、營銷、銷售、客戶成功、增長、定價、渠道等等。
藍藍設計的小編 http://www.syprn.cn