<address id="ttjl9"></address>

      <noframes id="ttjl9"><address id="ttjl9"><nobr id="ttjl9"></nobr></address>
      <form id="ttjl9"></form>
        <em id="ttjl9"><span id="ttjl9"></span></em>
        <address id="ttjl9"></address>

          <noframes id="ttjl9"><form id="ttjl9"></form>

          首頁

          量化設計價值(三) 如何創建體系化的監控系統

          seo達人



          隨著用戶體驗設計的發展,我們已經過了僅依賴需求和直覺就可以完成產品設計決策的階段了。數據對用戶體驗設計師的價值可以總結為兩點:1. 數據可以在「產品設計決策階段」提供了更多元的參考意見;2. 數據可以在「產品設計復盤階段」提供更客觀的評價標準。

           

          數據使用的場景

          無論所處哪一種設計階段,總的來說設計師的數據需求主要可以分為兩大類:

          圖片

           

          1.探索事物間關系的“內因/外因”:

          是什么東西影響了用戶的購買決策 ?我的新版網站首頁的改版是否為產品提升了注冊的轉化率 ?這類需求的本質是探究一種事物間的歡喜和因果性,常用「推論性統計」、「相關&非參數校驗」進行分析。對于這類需求,往往會有專業的數據分析師,用戶研究設計師,數據產品經理承接。

           

          2.發現數據中的“模式/異?!保?/strong>

          在一天之中隨著時間的變化,用戶的訪問量有什么規律 ?這類需求的本質是在對已經發生的事物規律做一種總結 ,使用的統計方法更多的是「描述性統計」。對于絕大多數設計師而言,能夠做到發現數據中的 “模式/異?!?基本可以覆蓋絕大多數日常工作的需求。

          本文主要關注解決設計師的第二類使用場景——發現數據中的“模式/異?!?。目前各大互聯網企業內部都會提供自研或者第三方的BI工具,因此筆者建議設計師可以通過建立一個包含關鍵的體驗指標的數據看板系統,對自己負責的業務進行系統的總結和復盤。

          以我曾經的工作內容為例,我們的產品是服務商家進行“前后端對接生產”的訂單審核系統。【效率】是制造業至關重要的關注面,在一個企業用戶的付費決策中也起到了相當重要的分量,客戶使用我們的工具進行訂單審核和流轉的效率是整個用戶體驗模型中的重要部分。

          因此我們需要構建一系列合理的指標來判斷訂單系統的處理效率。除【效率】外,【用戶行為】【用戶特征】等都是設計師關系的信息。以【效率】為起點,最終我們構建了一個籠統的包含設計師所有要監測的信息看板系統

          圖片

           

          關鍵概念

          本質上互聯網產品中的看板(kanban)與自然科學領域研究人員的用 R 或者 Seaborn繪制的精美圖表沒有本質上的區別,差異點可能在于看板更加關注時效性,同時更加具備可交互性。

          隨著儀表盤工具和各種BI軟件產品在人群中的普及,人們對儀表盤,指標(Metric)和關鍵績效指標(KPI)的組成有不同的理解。為了確保我們都說相同的語言,我將定義一組術語,這些術語將構成我們討論的基礎:

          • 度量(Measure):度量是一段數字上可量化的數據。銷售額、利潤、留存率,都是具體衡量的例子。
          • 維度(Dimension):維度表示給定指標的不同方面屬性。例如,時間通常被用作分析不同度量的維度。其他一些常見的維度包括地區、產品、部門、細分市場等。
          • 層次結構(Hierarchy):維度可以進一步分解為層次結構。例如,時間維度還可以形成層次結構,例如 年>季度>月>日。
          • 粒度(Grain):層次結構中的每個級別都稱為維度的粒度。例如,年 > 季度 > 月 > 日 ,中的“年”是一個特定的粒度。
          • 指標(Metric):指標是我們經常在儀表板中顯示的數據類型,它表示一個度量Measure)的數據段與一個或多個特定維度(Dimension)和相關粒度(Grain)的關系。

          圖片

          上圖是在Tableau中一個標準的指標示例-“每周銷售總額” 的構建方式。在這個指標中,我們需要量化的“”是美元——即總銷售額,用來觀察量化數據的“維度”— 即時間,而時間維度可以被進一步分解為“年>季度>周”的層級結構,“每周銷售總額”需要關聯的維度中的特定“粒度 ——即周。

          • 看板(Cards or KanBan): 觀察一個或多個指標(Metric)運行情況的圖表
          • 儀表板(Dashboard): 儀表板是多個圖形,圖表,量表或其他直觀表示的集合。多個看板可組成一個儀表板
          • 報告(Report): 報告可以是對應圖表和其他可視化的表示,也可以是可能直接相關或不直接相關的大量圖表和可視化。多個儀表盤可組成一個報告。

          圖片

          “實時、受眾群體、流量獲取、行為……” 上圖為Google Analytics 中提供的多種類型的數據分析報告,報告可以非常廣泛地涵蓋廣泛的相關信息。每一種特定報告內包含了若干個回答特定問題的dashboard,一個dashboard內可以包含多個相互關聯的指標的看板。

          一個可分析、可追蹤的數據系統中,最原子的構成單位理解成一個“看板”。如何從0-1構建一個客觀有效的數據看板系統?我們可以類比【一個人學習做菜】的過程,做菜的過程可以總結為三個階段:

          1. 學習菜譜&列一個采購清單
          2. 采購食材&烹飪食材
          3. 擺盤料理&品嘗美食

          對應到數據看板系統的創建,我們亦可以總結為三個階段:

          1. 了解數據的特性、明確自己需要哪些數據
          2. 通過技術手段獲取數據、將粗數據加工成意義明確的指標
          3. 將指標數據可視化,觀察數據并嘗試分析現象

          圖片

           

          度量Measure & 維度Dimension

          “ Data is more than numbers, and to visualize it, you must know what it represents. ”

          數據不僅僅是數字,數字、數組、表格、都可以被稱之為數據。要將數據形象化,你必須知道它代表什么。為了構建有效的效率指標,第一步是:明確為了解決當前的問題,要觀察的【度量】是哪些,以及這些度量又需要從哪些【維度】進行觀察。

           

          了解數據類型

          一個線上的項目每天都在收集成百上千種數據,怎樣確定自己需要什么數據作為 度量(Measure)呢?首先值得注意的是,不是所有類型的數據都適合作為度量Measure)被加工成指標。
          不同學科,不同課程,不同領域,對于數據類型的定義基本一樣,但稱呼并不完全一樣。統計學中,數據類型分為四種:定類,定序,定距,和定比。這四種類型是從低到高的遞進關系,高級的類型可以用低級類型的分析方法來分析,而反過來卻不行。

          圖片

          定性數據與定量數據

           

          從宏觀角度分析,數據類型分為 定性 和 定量 兩種。一個通俗的例子,以自身為例:例如衣服的顏色,頭發的類型和鼻子的形狀這些標識標識的是定性數據;例如身高,體重,年齡和鞋子的尺碼,這些可測量的是定量數據。

          1.定量數據

          定量數據是統計數據,通常具有自然結構性意味著它更加嚴格和明確,可再細分為連續/離散兩種。此類數據使用數字和值進行測量,這使其更適合進行數據分析??梢酝ㄟ^以下方式獲取定量數據:

          • 測量
          • 實驗
          • 調查
          • 市場報告
          • ……

          2.定性數據

          定性數據是非統計數據,本質上通常是非結構化或半結構化的。定性數據可以用來問“為什么”的問題。它是調查性的,在進行進一步研究之前通常是開放性的。從定性研究中生成的數據用于理論化,解釋,發展假設和初步理解??梢酝ㄟ^以下方法獲取定性數據:

          • 文字和文件
          • 音頻和視頻記錄
          • 圖片和符號
          • 訪談筆錄和焦點小組
          • ……

          想要了解訂單流轉的效率是怎樣,最簡單的方法是通過和我們的客戶進行面聊一下使用情況并記錄一下反饋,但這樣的產物并不方便進行統計分析和展示。盡管有一些對定性數據“結構化”的方法,比如對定類數據進行的非參數校驗,但實施起來成本較高。定量數據因為本身結構化的特點更適合分析,因此在這里建議設計師在構建自己的dashboard系統時,需要跟蹤分析的數據盡量選擇定量數據。

           

          確定需要觀察的度量&維度

          明確需要觀察的度量有哪些,首先需要從要解決的問題出發。但是沒有一個整體的分析模型,往往會導致我們的分析遺漏很多信息和細節,導致數據分析師無法理解彼此的需求,最終導致最后產出的看板難產或答非所問:

          使用的問題分析工具—— KPI wheel

          在這里介紹一種名為KPI Wheel的簡單工具,可用于收集將用于定義和可視化指標的前期必備信息。您可以將 KPI wheel 的圖片打印在紙上,然后開始嘗試依次思考這四個方面:

          1. “ 要解決的問題是什么”
          2. “誰在關心這個問題?”
          3. “我需要去哪里獲取這些數據?”
          4. “為什么這個數據很重要?”

          在解答的上述的幾個問題的過程中隨手記錄:

          (1)可能引發什么進一步的疑問

          (2)使用此信息可以采取什么行動或決定。

          不斷的提出問題并進行進一步分析,這么做的目的是讓用戶不斷分解問題,直到他們有足夠的信息來采取行動或做出決定。經過幾輪完整的分析后,用戶就可以大致確定指標的「度量」和 所需要的「維度」。

          圖片

          以我曾經的工作內容為例:我們的產品是服務商家進行“前后端對接生產”的訂單審核系統,我們需要構建一系列合理的指標來判斷訂單系統的處理效率。以下是與產品經理討論過程中的具體流程:

           

          第一輪 KPI Wheel ——

          1.Answer KPI Wheel:“ WHAT?WHO? WHERE? WHY? 

          • what:我們需要一種途徑了解用戶進行訂單審核的效率如何

          針對這個問題我們聯想到:

          1.想要了解訂單處理效率,首先需要定義什么叫訂單的效率;在行業中有一種叫做「訂單生命周期」的專有名詞來表示訂單從創建到結束的時長,是一個可借鑒的概念

          2.針對我們的業務,一個工單的生命周期經歷了從創建-流轉&審核-通過,一個工單從創建到通過所經歷的時間是我們需要記錄的【度量】

           

          • who:產品/運營/設計 三個業務方都關注訂單的效率

          針對這個問題我們聯想到:

          1.對于不同的角色,在檢測數據的時候都關注哪些維度?

          2.訂單類型分審核單&生產單這兩種,兩種類型的訂單,訂單類型是一個必要維度

          3.時間是上述三個相關方都需要關注的維度,一個訂單在通過審核時的時間,是一種重要的分析維度;而“時間”維度,我們可以繼續拆分為: 年-月-周-日 的層次結構

          4.對于運營,了解不同行業的商家的訂單效率對進行深入運營是必要的。而”行業”維度根據分類方式的不同,又可以歸類為一級行業(軟裝設計/板式家具/…),二級行業(整木定制/辦公家具定制/暖通/地板/瓷磚……)

          4.對于產品,為了更好的維護客情,對于特定的大客戶的數據需要重點關注。因此商家賬號的ID,也是重要的分析維度。

           

          • where:我們需要的數據要在哪里獲???

          針對這個問題我們聯想到:

          1.與一般的用戶行為數據不同,訂單的數據都儲存在后臺的操作日志中

          2.需要的”行業”維度,可以復用其它團隊已經制定好的標簽

           

          • why:效率是企業的生命,制造業中存在各種效率指標,如“人效”/“屏效”等。糟糕的使用效率會造成我們的產品在根本上是不可接受的,因此效率指標非常重要

          針對這個問題我們聯想到:

          1.通過【訂單生命周期】統計的時間,可以在整體上評估訂單系統的流轉效率。但是僅僅依靠一個這樣的指標,缺少一些更細致的視角。可以增加對方案(訂單的載體)的停留時長的統計,來計算審核在整個生命周期中所耗時間的占比。

          2.The Rising Questions & Action:“ 根據問題1的答案,這還會引發什么其他問題,或者您將采取什么行動?”

           

          在回答上面的4W的過程中,會引發其它衍生問題,例如 “訂單審核周期的時間的最小單位是什么?”  等等。針對上述的其中衍生問題,可以再進行一輪kpi wheel的自問自答。比較簡單的衍生問題,不需要4個方面都進行問題分析。

           

          最終 

          在多次重復上述的兩個過程后,最終我們確定了要在產品中量化哪些 度量(Measure),以及這些度量需要哪些分析維度,并將所有需要的度量和相關的維度都用表格的形式記錄下來。

          例如,‘訂單從創建到最終通過的時長(h)’,是一個需要被量化的度量。它需要關聯的維度(Dimension)有時間、商家ID、一級行業、二級行業。

          圖片

           

          指標Metric

          研究完成菜譜,記錄采購清單后,接下來的帶班過程就是準備食材并進行烹飪。當你已經明確了要觀察的 度量(Measure)、和需要關聯的維度(Dimension),下一步就是通過數據建設獲取這些度量,然后將度量加工成指標。

           

          建設埋點

          獲取度量的過程就是取數’的過程。想要創建看板,數據分析師需要通過各種方式獲取一張包含所有你需要的信息的寬表。如何獲得這張包含一切關鍵信息的表格?我們需要借助埋點獲取數據。

          所謂埋點就是在應用中特定的流程收集一些信息,用來跟蹤應用使用的狀況。您可以把用戶在與您的網站或應用互動時觸發交互行為理解為一個 “ 事件 ”,一個時間存在一個觸發的條件,當達到這個觸發條件后就會上傳請求,請求中會攜帶需要的 “ 參數 ”。

          例如“用戶點擊按鈕將商品加購到購物車”這個行為,每次用戶觸發這個行為后都會發送一個請求,而這個請求中會記錄:1.加購商品的金額/2.加購商品的類型/3.加購商品的商品ID…等信息。這些結構化的信息構成了我們需要的度量(Measure)與 維度(Dimension)。

          在完成了最基礎的埋點后,我們就獲得了最基礎的數據。

          圖片

           

          如何建立有效指標建議

          “指標”是量化衡量標準,未經加工的數據不具備可觀察的價值。通過埋點,我們單純只是得到了若干張包含所有用戶信息的巨型表格,我們是分析不出什么有用信息的。為了更有效的去觀察和分析作為度量Measure)的數據,就需要對埋點數據進行一定的加工,變得更加易于理解和表達。

          當一個度量Measure)的數據段與一個或多個特定維度(Dimension)之間互相聯系了起來,度量就成為了指標。例如,同樣的一份關于【訪問用戶人數】這一度量,可以根據關聯的時間維度的不同,創建 DUV 和 MUV 等多個不同的指標。

          如何創建一個有效的指標,結合筆者的工作經驗,下面給出三點建議:

           

          (1)為一個指標設想一個高級概念:

          • 首先指標的名稱需要客觀,要讓人乍一聽就能大概會意,例如:「加購商品操作每日點擊次數」。而如果您定義的是類似:“軟件上手度”,這種概念比較晦澀、在業內又沒有約定俗成的定義的指標,可能需要重新考慮概念是否恰當。
          • 每周訪問站點的用戶總數/ 每日訪問站點的用戶數/ 每日訪問站點的新手用戶數…,這些指標即相互獨立,但反應的又是同一件事的客觀熟悉的時候,我們可以把這些詳細的指標統一用一個高級的指標概念來做一個歸納,例如“站點訪問用戶數”

          圖片

           

          (2)檢查并確定定義指標的細節:

          • 確定了指標的基礎概念后,需要檢查一遍指標的細節。
          • 例如,“訂單生命周期”這個指標的定義中,生命周期是指一個訂單從創建到最后通過審核耗時,而與其關聯的維度有時間,訂單類型等。需要強調的是,一個訂單可能會存在:創建時間、通過時間,這兩種不同的時間戳。而在“訂單生命周期”這個指標我們需要關聯的時間維度是【通過時間】。如果關聯是【創建時間】,則會得到另外一種完全不同的生命周期計算方式。

          圖片

           

          (3)將測量到的度量數據,通過計算總結為一個指標:

          • 通過埋點收集到的是大量的數據,是一個巨大的整體,而指標則是描述總體特性的參數。而把原始數據組織并總結成更易處理的形式的技術叫做描述性統計,一種最常見的方法是通過計算平均數的方法總結一組數據。
          • 這些描述總體特性的參數中又存在不同的用途,有的用來描述頻數分布,有的用來描述集中趨勢:平均數,眾數、中位數,有的用來描述變異性:四分衛距、方差。我們需要根據自己的用途選擇合適的統計方式來構建指標。

          圖片

           

          根據統計方法的不同,常見的指標類型有以下幾種,他們擁有不同的分布類型和方差的計算公式

          • 【 計數 Count 】
          • 【 概率 Probability 
          • 【 平均數 Average 】
          • 【 中位數(或其它位數)Percentile
          • 【 比率 Rate 】
          • 【 一般比例 Ratio 】

          圖片

           

          可視化 Visualize

          烹飪好食材之后,接下來的工作就是擺盤與上菜。優秀的擺盤可以讓料理更加精致和高級,優秀的數據可視化可以幫助我們更好的觀察與分析數據,反之糟糕的數據可視化可能會讓我們丟失很多重要信息。

           

          Why visual ?

          為什么一定要使用看板(圖表)來觀察和分析數據?僅關注幾個關鍵指標的數據是否就已經足夠?

          使用看板對指標進行觀察和分析的意義在于:相比單純的數字,圖表可以攜帶更多的展示維度(大小、長度、顏色、面積…),能幫助我們多維度的觀察數據、避免疏漏。

          例如,安斯庫姆四重奏(Anscombe’s quartet)是四組基本的統計特性一致的數據,但由它們繪制出的圖表則截然不同。如果僅依靠基本的統計特性來觀察數據,我們很容易忽略一些重要信息。

          圖片

           

          選擇合適的圖表類型

          BI工具中支持多種圖表類型,比如展示瀏覽路徑的“?;鶊D”、展示轉化率的“漏斗圖”,甘特圖、散點圖等。如何選擇合適的圖表來展示并分析你的數據可以參考下圖:

          圖片

          圖表種類繁多,但只要掌握其中的一小部分就能滿足絕大多數需求。對于大部分設計師,以下3種最基礎的圖表類型是最常用的:

          1. 條形圖:是最常用的圖表類型。條形圖易于閱讀,我們用眼睛比較條形圖的末端,很容易快速得出結論:哪一類最大、哪一類最小以及類別之間的增減區別。
          2. 線圖:最常用于繪制連續的數據。因為線連接了點,這就暗示了點與點之 間存在著離散數據(一系列數據分隔成不同的類別)間沒有的聯系。通常,連續性數據都以時間為單位:天、月、季度和年度。
          3. 餅圖:在總量間各部分的占比時比較高效

          最后,當我們創建了許多看板后如何進行歸納?我們可以將關注相同的問題的看板歸納在一起,就形成了一個關注同一類問題的Dashboard;對不同的 Dashboard 提取共性,將同一個業務的不同Dashboard組織起來,就形成了一個Report。一個Report內可以籠統的包含當前業務需要關注的所有信息。

          圖片

          例如:【訂單生命周期】關注的是企業的訂單效率問題,但并不是唯一關注效率的指標。另外還有諸如:“審單員平均審核時長”這樣的人效指標的看板,這些看板同樣反饋的是訂單的效率。我們將關注相同的問題的看板歸納在一起,就形成了一個Dashboard,Dashboard內的看板與指標都有關注同樣的問題—效率。

          除了效率,身為設計師的我們還需要關注很多其他的問題:比如使用的用戶的特征、流量的來源、用戶發起的行為等等,這些問題都可以擁有自己獨立的Dashboard。最后這些Dashboard組織在一起,就成為了一個支持系統的觀察分析當前業務的體驗指標的完整報告。

           

          觀察與分析數據

          “ 我們需要的不是數據 , 而是數據告訴我們的實事 ”。通過建立一個系統的監測體系的目的主要是為了從數據中探索:模式/ 異常。不管圖表的形式是什么,我們都需要留心觀察這兩者。

           

          1.何為「模式」:

          模式即數據中的某項規律。比如機場每月的旅客人數,雖然隨著時間推移變化不定,但是通過幾年的數據對比,我們可能發現旅客人數存在著季節性或周期性的變化,某些月份的旅客數量一致偏低/某些月份則一直偏高。

          圖片

          根據數據畫像我們可得知某個產品的成熟期用戶占絕對多數的現狀,

          了解了這個「模式」就可以更好的制定符合絕大多數用戶心智的設計策略

           

          2.何為「異?!梗?/strong>

          異常即問題數據。異常數據并非是錯誤數據,也有可能是設備記錄或人工錄入數據時,出現的問題。我們通過異常異常分析,一方面可以分析異常原因;一方面可以發現現有系統的漏洞。

          圖片

          蘋果公司通過監控異常值、發現了位于深圳的AppleCare灰色產業,

          進而改善了AppleCare的產品策略,避免了巨大的損失

          最后在觀察分析數據的過程中,有三個需要特別關注的數據的特性不要忘記:

          • (1) 數據具有可變性(VARIABILITY)

          數據的可變性這一重要的特性讓我們可以從數據中獲取規律和關系。如果您構建的指標本身并不具備可變性了,那您很可能需要嘗試其他指標進行跟蹤和分析。

          • (2)數據具有不確定性(UNCERTAINTY )

          很多數據都是只能提供一個估計而不是絕對準確的數量。例如:分析人員通常會通過樣本的數據,進而對整體的數據分布進行進行猜測。

          • (3)數據需要聯系上下文( CONTEXT )

          數據分析離不開情境。我們知道,數據的產生必然是有其情境的,不過統計數據時,我們通常都要剝離情境;而當我們進一步分析數據時,又必須回到具體的情境中去。

          例如:某個羽絨服經銷商發現某一年冬季的銷售額產生了明顯的下降,這本應該是一個異常的信號,但我們不能簡單粗暴的定義這是一個糟糕的數據。因為實際上,銷售額下滑的哪一年是一個暖冬,且和同類的競品相比自己的產品銷售額下滑趨勢的更低。結合情景分析數據,往往能得到意想不到的結論。

           

          本文參考文獻:

          文章:Dashboard Design: Key Performance Indicators and Metrics —— Thomas Gonzalez文章:【統計學】區分定類、定序、定距、定比變量——YYIverson書籍:Tableau:數據可視化之極速BI —— 沈浩書籍:Which chart or graph is right for you?——Tableau圖表白皮書

          書籍:Data Points:Visualization That Means Something  —— Nathan Yau

          書籍:Storytelling With Data —— Cole Nussbaumer Knaflic

           

          原文鏈接:酷家樂用戶體驗設計(公眾號)

          作者:曉虎

          轉載請注明:學UI網》量化設計價值(三) 如何創建體系化的監控系統

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務

          詳解|組件庫可以替代 B 端設計師么?

          seo達人


          有很多同學跟我說,自從 Ant Design 的組件變得越來越完善,自己也越來越不知道 B 端設計師的工作意義和價值是什么了。其實除了 Ant Design,還有很多常見的、優秀的組件庫,都為 B 端設計和開發的工作提供了便利。那么使用組件庫真的可以替代 B 端設計師么?當然不能。B 端設計師有其存在的獨特價值,本文就跟你聊聊組件和設計師之間的關系。

           

          圖片

           

          1 . 組件是「效率」工具

          組件是工具,用來為設計師和開發提升工作效率。上文中所提到的 Ant Design 的初衷也并不是要做一款替代設計師的組件庫,其根本目的之一也是提高整個團隊的工作效率。使用組件可以從兩個方面提效:

          (1)工作內容上:可以將不必要的、重復性勞動的時間節省出來

          (2)工作流程上:便于設計師與前端開發做交接和協作,節省溝通成本

           

          2 . 組件是「質量」保障

          使用組件,可以在一定程度上保證設計工作的質量。組件規范了前端和設計師的工作方法,建立相對底層的系統,設定了設計和開發的質量底線。

          圖片

          基于組件規范,設計和開發的產品更容易具備:

          (1)一致性:具備相對一致的表現樣式,設計風格和交互體驗上均可保持統一

          (2)可用性:對于用戶操作,可以保證最基本的可理解性和可操作性

          (3)審美性:符合基本審美標準,雖不會很亮眼,但也不會很難看

           

          3 . 設計師要「沉淀」業務組件

          B 端設計師可以嘗試沉淀有針對性的業務組件。很多業務領域有其獨特性,比如金融類組件和政務類的產品頁面列表內容就有很大區別。單一的元素組件在應用的過程中是可以被再次組合和沉淀的。

          舉個例子,我在做業務需求設計時,相比于 Ant Design,其實更常用的是 TechUI —— 它是建立在 Ant Design 基礎上的、由我們螞蟻的設計師通過對業務需求的提煉、組合和封裝,做成的一套于螞蟻自己的【業務組件】。

          二者的區別是:

          • Ant Design:是所有人的,是通用的,是單一的原子級別的(比如一個輸入框)組件。
          • TechUI:是螞蟻自己的,是私有的,是組合的區塊級別的(比如一整個表單)組件,更具備螞蟻集團自己的業務屬性。

          圖片

          針對你公司不同業務類型,沉淀出不同種類的區塊級別的組件,這類組件使用起來也會更加得心應手、加倍提效。這也是 B 端設計師可以去學習和精進的一點。

           

          4 . 設計師要「洞察」業務訴求

          使用組件,可以讓設計師把節約出來的時間和精力放到更多有價值的工作上去。作為 Ant Design 的設計師之一,坦白的說,即使你的設計稿全部使用了 Ant Design 的組件搭建,最終的頁面效果也仍不完善,在用戶體驗上始終可以更進一步。

          B 端設計師應該更多去關注對用戶需求和業務邏輯的深入挖掘,不僅僅是在界面細節的表現手法上下功夫,還要學會站在全局,用系統性思維看待每一個項目,為整個產品的系統流程做優化,做更全面的產品體驗升級。

           

          5 . 設計師要「放眼」B 端未來

          隨著技術的發展和迭代,B 端產品的發展也呈現出多元化趨勢。我列舉以下幾個方面,用于思考和拓展設計師的邊界:

          (1)承載媒介:多端化設計需求增多

          B 端產品的應用領域日漸廣泛,各類終端設備普及,設計師需要更多的探索設備的應用場景。如點餐系統、收銀系統、AR、VR 應用等等,最近鴻蒙系統中演示的多端聯動,也可能是未來的趨勢之一。

          圖片

           

          (2)工作流程:中臺策略 / 組件化設計

          它是一種提效的工作方法。中臺策略適用于公司層面,我們上文提到的組件化設計更適用于團隊。

          圖片

           

          (3)用戶體驗:重視用戶個性化和體驗

          B 端設計越來越重視用戶體驗,提供個性化的配置方式,并考慮無障礙設計領域。很多 B 端的應用和業務也在逐步開放給 C 端。 例如企業微信在 2019 年打通了個人微信和企業微信的壁壘,釘釘從 2020 年也開始在 C 端發力。

          圖片

           

          (4)視覺表現:數據可視化設計

          需求多來源于政府、企業的定制化需求,更偏向于對數據呈現效果的打磨和優化,能夠展示和分析數據中的關鍵內容,形式與內容需要高度一致,才會達到良好的展示效果。

          圖片

           

          原文鏈接:長弓小子(公眾號)

          作者:元堯

          轉載請注明:學UI網》組件庫可以替代 B 端設計師么?

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務



          庫存領域的業務——庫存模塊

          資深UI設計者

          導語:近期公司需要把一個事業部的發貨及庫存相關業務實現線上化,在我們部門內部進行業務調研及充分討論后,庫存中心的產品規劃方案基本確定,本文把我們實戰過程中的方案分享給大家,期望能夠為讀者在設計庫存模塊時提供些許思路。


          01 場景說明

          XX事業部主要業務以化工貿易為主,在市場上對部分產品處于核心地位。XX事業部自己不進行產品生產,主要提供營銷服務,倉庫、物流均以整合社會資源為客戶提供服務為主。整體的業務流程如下:

          1. 客戶自己在平臺下單,或業務員代客戶下單,提交訂單時需要判斷發貨倉是否有足夠的貨物發出。
          2. 內勤確認訂單無誤后,進行發貨操作,業務要求后期需要進行自動發若客戶有特殊需求則需要指定具體批次貨物進行發貨。
          3. 根據發貨單,由倉庫人員處理出庫,并進行實際的庫存扣減。
          4. 物流人員根據發貨單中的收發貨信息安排承運商進行配送,并回收配送相關狀態。
          5. 在客戶需求變更或配送的貨物發生異常情況時能夠進行售后申請,把貨物進行相應處理。
          6. 對于庫存管理人員要求能夠定時進行庫存盤點,能夠及時發現庫存貨物由于一些管理上的異常情況而導致貨物數量異常的情況。
          7. 貨物需要定期進行存貨核算以及倉儲費用結算。

          在整體的業務模式中主要可分為以下三種貨物供應模式:

          1. 計劃性的向供應商采購貨物后進行備貨,再銷售給客戶。
          2. 在客戶下單時若除常規備貨的商品外還有其它貨物需求,可由銷售反饋給采購后進行零采。
          3. 向兄弟公司調貨銷售給客戶(具體可分為對方公司直接發貨給客戶和由銷售公司發貨給客戶兩種方式)。

          在庫存管理的業務中,事業部相關人員要求需要及時知道有多少貨能夠進行銷售,其中有多少是已經在倉庫可以隨時發貨,有多少可能是已經采購但貨還在配送過程中,還有一些可能是產品管理人員能夠預測未來會到貨的貨物數量。

          02 業務分析

          通過對上述場景進行分析后,我們能夠把和庫存配送相關的業務進行如下分類:發貨業務、出庫業務、到貨計劃、入庫業務、庫存管理業務、調撥業務、售后處理、其它出入庫業務。

          整體的業務架構圖如下:

          產品設計:庫存模塊

          在整體的業務架構中,各個部分具體的使用角色以及所需要負責的業務具體如下:

          發貨:一般由銷售助理/內勤人員完成,其主要任務是執行銷售訂單,在客戶沒有特定要求下,可以設置為系統自動生成,按先進先出的規則進行批次匹配,在客戶對批次有特殊要求下需要人工干預,選擇對應批次的貨物發給客戶。

          注:在化工行業不同批次貨物其性質會有所差異,故客戶會有一些特殊要求。而發貨單也是事業部對接倉庫、承運商的單據,倉庫根據發貨單進行貨物分揀并以發貨單與提貨司機進行匹配,防止貨物錯發,同時物流調度人員也會把發貨單分配給具體的承運商,承運商下的司機根據發貨單到對應的倉庫進行提貨,并配送到對應的收貨地址。

          出庫:公司以出庫單為依據影響庫存,同時也根據出庫單生成實際發生的應收。主要分為銷售出庫、退貨出庫、調撥出庫、其它出庫。銷售出庫主要為根據發貨的實際情況進行庫存扣減,是記錄貨物從真實的從對應的倉庫中已經發出的憑證;退貨出庫主要為記錄售后需要進行退貨處理的記錄憑證,把退貨業務放在出庫單中進行記錄有一個好處就是能夠直接通過負數的單據關聯原有單據進行沖銷,而根據出庫單生成應收后也能直接進行應收沖銷,由此不會改變財務核算的邏輯;調撥出主要記錄跨組織調撥、轉庫調撥等情況,能夠記錄清楚該出庫時由哪家公司發起調撥而產生的,最終能夠反映在內部結算上;其它出則包含了盤虧出、報損出等不同的情況。

          退貨質檢:主要記錄在客戶把貨物發回到指定地點后到貨物再次入庫之間的業務信息。能夠在該單據上記錄貨物異常的情況以及責任所屬。

          到貨計劃:主要用于記錄計劃性采購訂單貨物接收計劃,能對在途可售庫存進行管理。到貨計劃需要記錄貨物是否可售,到貨具體的時間、數量、位置等信息。

          入庫:入庫單能夠直接影響庫存,同時能夠根據入庫單生成實際發生的應付;主要分為采購入庫、退貨入庫、調撥入庫和其它入庫,具體邏輯和出庫類似。

          庫存邏輯:主要分為庫存設置、明細、庫存量和庫存報表。庫存量的定義和具體邏輯是該部分最為復雜的業務,在討論庫存量前我們需要明確幾個定義:

          • 現存量:指倉庫(可以是虛擬倉)中實際存放的貨物數量,理論上能夠進行實際出庫的貨物數量,有些文檔中也稱之為物理庫存、賬面庫存。
          • 在途可售:指貨物未在倉庫,當時也能夠銷售的庫存,支持外部采購在途、內部調撥在途。
          • 待發貨量:指已經下單需要進行發貨的貨物數量,支持銷售待發、調撥待發。

          以上三個庫存量均有實際單據進行對應,由于我們需要管控到批次基本,所以我們需要同時在SKU和批次兩個維度進行庫存量的記錄,在途可售不需要在批次維度進行記錄。

          基于此我們通過計算得出我們能夠用于銷售的可售量,再通過一些庫存分配策略我們就能實現很好的庫存管理,例如:可設置預留量20%,各個渠道設置不同的數量,各個渠道可售數量之和可以大于總庫存,但每個渠道的庫存則不能大于最大可售量。我們也能夠設置相應的庫存預警機制,在庫存低于一定比例是能夠進行預警或者是限售。

          03 功能設計

          通過對具體的業務進行分析后,我們即可對產品功能進行詳細設計,根據業務的實際情況,整體的功能結構如下圖:

          產品設計:庫存模塊

          從業務分析中我們可發現主要涉及兩個領域的業務:物流配送領域和庫存領域,物流配送領域我們暫且不做具體的功能設計說明,對庫存中心整體分為四個大的模塊:出庫管理、入庫管理、庫存管理、其它管理。

          出庫管理主要滿足庫存扣減相關的業務場景,例如:銷售出庫、調撥出庫或其他出庫,但有一種特殊情況就是售后退貨也是放在出庫模塊,主要是出于財務核算邏輯考慮,如果公司財務核算是應收和收款核銷,應付和付款核銷,沒有應收和應付核銷的模式,那么售后退貨就應該用出庫模塊解決,如果公司由應收和應付核銷的模式則也可以把售后退貨放在入庫模塊;但第二種模式會增加財務核算的難度,同時在進行庫存統計是也會造成入庫數據虛高,實際出庫不足,主要還是看具體業務的模式。

          由于我們服務的事業部暫沒有做應收和應付核銷的模式所以我們就采用了第一種方式,而對于出庫單之前是否一定需要有發貨單也是要根據具體業務進行規劃,如果倉庫管理、物流配送都是自己公司內部完成,也可以使用出庫單+配送單的模式進行處理。

          由于我們的業務是物流配送和倉庫管理都是外包給第三方所以對外是以發貨單為標準單據進行管理,所以出庫單只是發貨單的具體執行情況的記錄。

          入庫管理主要滿足庫存增加的相關業務場景,例如:采購入庫、調撥入庫和其它入庫,同出庫一樣在采購發生退貨時也是以入庫單的形式進行處理,如此設計的理由和銷售側是一樣的。

          對于庫存管理,則屬于庫存中心最為核心的業務模塊,根據業務分析中的相關概念,我們把單據對庫存的影響整理一張圖:

          產品設計:庫存模塊

          上圖中有一個核心公式:可用量=現存量+在途可售-待發貨量,由于化工行業的產品有分批次的特性故需要考慮SKU級的庫存結構設計和SKU+批次級的庫存結構,批次級的現存量合計一定要等于SKU級的現存量,而待發貨量則不一定相等;在提交訂單時(提交或支付)以SKU級的庫存(不考慮庫存分配規則)進行校驗即可,在進行發貨時則需要同時滿足訂單上的可發貨量和SKU+批次及的可用量以防止超發或者超賣。

          在SKU級的可用量的基礎上我們可以根據具體的業務設計庫存分配策略,庫存策略以可分為預留和可售,預留則表示不對外進行銷售,可售又可按渠道、活動級其它邏輯進行分配,各個方式之間的總和可超總可售量,但每種方式不可超總可售量,通過如此設計我們可以最大限度利用庫存,而避免出現超賣現象。

          庫存的核心計算邏輯主要在圖示藍色部分,基本上把各種單據對庫存的影響都羅列進去了,但以上的整體邏輯還是基于有貨(或在途)的情況下開展的,但還有一種特殊情況是該邏輯不能覆蓋的即預售/期貨模式,預售/期貨模式是以銷定采的模式,是在確定了銷量的情況下再去進行集中采購;所以對于預售/期貨模式 我們需要單獨設計一個虛擬庫存的模塊,而該模塊根據實際經營可以輕量級的方式在商品中心進行實現,最終在進行貨物交付的時候在通過出庫單進行管理即可。

          在庫存中心還有庫存預警、盤點、期初處理等功能,在此不一一展開說明,大家可根據自己的實際情況進行產品功能設計。

          04 總結

          庫存領域的業務是一個相對比較專業和復雜的領域,市場上也有十分之多的傳統軟件或SaaS,在很多企業認為通過采購的方式去部署一套軟件性價比會比自建庫存中心要高。

          但筆者認為在數字化轉型的浪潮之下,通過數字化的工具提升供應鏈的效率、降低供應鏈管理的成本一定是一個十分之重要的目的之一,營銷測的數字化轉型大多數企業已經通過消費互聯網認識到了其價值,我想供應鏈測的數字化轉型在接下來的這幾年也一定會逐漸顯現其寶貴的價值。

          傳統的庫存管理軟件不管其架構還是對業務的實現都有其弊端,很難實現和營銷側的互聯網架構的系統進行完美對接;所以自建基于互聯網架構的庫存中心,并培養懂庫存業務知識的互聯網人員是大多數要做數字化轉型或產業互聯網的企業必須要完成的任務之一。


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          文章來源:人人都是產品經理   作者:不可分類者

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務






          CentOS7 升級PHP到7.2

          前端達人

          寫在前面

          CentOS7下安裝PHP默認是5.4的,但是有些框架要求PHP的版本得在5.4以上,這就需要我們把PHP升級一下了。

          yum provides php 
          
          • 1

          開始升級PHP:

          rpm -Uvh https://mirror.webtatic.com/yum/el7/epel-release.rpm #更新源
          rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
          yum remove php-common -y  #移除系統自帶的php-common
          yum install -y php72w php72w-opcache php72w-xml php72w-mcrypt php72w-gd php72w-devel php72w-mysql php72w-intl php72w-mbstring  #安裝依賴包 
          
          • 1
          • 2
          • 3
          • 4

          查看版本

          php -v 
          
          • 1

          PHP 7.2.8 (cli) (built: Jul 20 2018 15:20:01) ( NTS )
          Copyright (c) 1997-2018 The PHP Group
          Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
              with Zend OPcache v7.2.8, Copyright (c) 1999-2018, by Zend Technologies
          

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          轉自:csdn 作者:Peithon

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          centos7重啟php環境

          前端達人

          apache
          啟動
          systemctl start httpd
          停止
          systemctl stop httpd
          重啟
          systemctl restart httpd
          或者

          service httpd stop

          service httpd start

          service httpd restart


          mysql
          啟動
          systemctl start mysqld
          停止
          systemctl stop mysqld
          重啟
          systemctl restart mysqld

          或者

          service mysqld stop

          service mysqld start

          service mysqld restart



          php-fpm
          啟動
          systemctl start php-fpm
          停止
          systemctl stop php-fpm
          重啟
          systemctl restart php-fpm


          nginx
          啟動
          systemctl start nginx
          停止
          systemctl stop nginx
          重啟
          systemctl restart nginx

          或者

          service nginx stop
          service nginx start
          service nginx restart

          開機自啟

          chkconfig httpd on

          chkconfig mysqld on
           

           

          一、MySQL啟動方式

          1

          2

          3

          4

          5

          1、使用 service 啟動:service mysqld start

           

          2、使用 mysqld 腳本啟動:/etc/init.d/mysqld start

           

          3、使用 safe_mysqld 啟動:safe_mysqld&

          二、MySQL停止

          1

          2

          3

          4

          5

          1、使用 service 啟動:   service mysqld stop

           

          2、使用 mysqld 腳本啟動:/etc/init.d/mysqld stop

           

          3、mysqladmin shutdown

          三、MySQL重啟

          1

          2

          3

          1、使用 service 啟動:service mysqld restart

           

          2、使用 mysqld 腳本啟動:/etc/init.d/mysqld restart

          四、強制關閉

          以上方法都無效的時候,可以通過強行命令:“killall mysql”來關閉MySQL,但是不建議用這樣的方式,因為這種野蠻的方法會強行終止MySQL數據庫服務,有可能導致表損壞……所以自己掂量著用。

          Windows下重啟MySQL服務,對于沒裝mysql圖形管理端的用戶來說啟動和停止mysql服務:
          …\…\bin>net stop mysql
          …\…\bin>net start mysql

           

           

          卸載PHP

          yum remove php
          yum remove php*
          yum remove php-*
          yum remove php7
          yum remove php70
          yum remove php7.0
          yum remove php-common
          這才是苦大仇深卸載個干干凈凈= w

           

           

          Centos下Yum安裝PHP5.5,5.6,7.0

          默認的版本太低了,手動安裝有一些麻煩,想采用Yum安裝的可以使用下面的方案:

          1.檢查當前安裝的PHP包

          yum list installed | grep php

          如果有安裝的PHP包,先刪除他們

           yum remove php.x86_64 php-cli.x86_64 php-common.x86_64 php-gd.x86_64 php-ldap.x86_64 php-mbstring.x86_64 php-mcrypt.x86_64 php-mysql.x86_64 php-pdo.x86_64

          2.Centos 5.X

            rpm -Uvh http://mirror.webtatic.com/yum/el5/latest.rpm
            CentOs 6.x
            rpm -Uvh http://mirror.webtatic.com/yum/el6/latest.rpm
            CentOs 7.X
          rpm -Uvh https://mirror.webtatic.com/yum/el7/epel-release.rpm
          rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

          如果想刪除上面安裝的包,重新安裝
          rpm -qa | grep webstatic
          rpm -e  上面搜索到的包即可

          3.運行yum install

            yum install php55w.x86_64 php55w-cli.x86_64 php55w-common.x86_64 php55w-gd.x86_64 php55w-ldap.x86_64 php55w-mbstring.x86_64 php55w-mcrypt.x86_64 php55w-mysql.x86_64 php55w-pdo.x86_64
           

          yum install php56w.x86_64 php56w-cli.x86_64 php56w-common.x86_64 php56w-gd.x86_64 php56w-ldap.x86_64 php56w-mbstring.x86_64 php56w-mcrypt.x86_64 php56w-mysql.x86_64 php56w-pdo.x86_64


          注:如果想升級到5.6把上面的55w換成56w就可以了。

          yum install php70w.x86_64 php70w-cli.x86_64 php70w-common.x86_64 php70w-gd.x86_64 php70w-ldap.x86_64 php70w-mbstring.x86_64 php70w-mcrypt.x86_64 php70w-mysql.x86_64 php70w-pdo.x86_64
          4.安裝PHP FPM

          yum install php55w-fpm 
          yum install php56w-fpm 
          yum install php70w-fpm
          注:如果想升級到5.6把上面的55w換成56w就可以了。

          nginx重啟不了



          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          轉自:csdn 作者:鍋巴胸

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務


          HarmonyOS Sans - 華為把鴻蒙系統自帶的字體開放給全社會免費商用了

          資深UI設計者

          最近華為發布了鴻蒙系統并且開源了代碼,成為了科技圈的熱聞。不過我注意到了,系統內置的字體也是開放免費商用的。



          關于 HarmonyOS Sans

          華為鴻蒙字體 (HarmonyOS Sans) 是華為和漢儀字庫合作定制,專門為鴻蒙操作系統設計打造,設計上聚焦于功能性、普適性,字形和之前介紹過的谷歌思源黑體、阿里巴巴普惠體以及 OPPO 手機公司的 OPPO SANS 等免費商用字體有點類似,是一款適合閱讀的多字重中性字體。

          HarmonyOS 字體特性

          • 5種字重粗細調節。HarmonyOS Sans 支持可變特性,讓用戶選擇他們喜歡的字體粗細來進行文本的顯示。

          • 支持等寬與變寬兩種樣式。變寬數字在閱讀文本段落中能讓閱讀體驗更加連貫。而等寬數字在強調數值以及數據需要經常變化的表格、時鐘數字的 UI 界面使用時,效果會更好。

          • 支持多國語言。HarmonyOS Sans 支持簡體中文、繁體中文、拉丁、西里爾、希臘、阿拉伯等5大書寫系統,105種語言全球化覆蓋。

          • 通用性極佳,中英文混排效果優秀。鴻蒙系統是一款面向全場景的分布式操作系統,無論在手持設備、電視大屏幕還是手表的小屏上, HarmonyOS Sans 鴻蒙字體都具備極強的通用性和協調性。無論是粗體還是細體均需擁有出色的一致性。

          undefined
          harmonyos-sans 5種字重

          字形特點

          在保障字體體驗的功能性前提下,HarmonyOS Sans 在人文和現代中找到新的平衡。在短筆畫時保持橫平豎直,簡約無裝飾,撇捺彎鉤長筆畫中融入書法的筆勢美學,帶來全新的視覺感受。

          undefined
          harmony-sans 字形特點
          undefined
          harmonyos-sans 筆畫特點

          在排版設計中常見的“字體不協調”問題之一就是中英文混合的排版,鴻蒙字體對此做出了針對性的優化,把西文字體設計得更顯大更顯寬,與中文對齊的匹配度更高,細看起來更加和諧。

          undefined
          harmony-sans 英文字形

          一張圖對比其他同類字體字形:

          undefined
          和其他類似字體比較

          字體應用效果

          undefined
          harmonyos-sans 應用例子
          undefined
          harmonyos-sans 應用例子

          使用場景和用途

          HarmonyOS Sans 易讀性強,字型簡約富有科技感,在各種不同尺寸的屏幕上都能獲得清晰的顯示效果,既適合用于設計制作、平面印刷,也可用于閱讀,顯示大量文字也依然干凈清爽。擁有5種字重,用在正文閱讀通透流暢,粗細結合的標題也更醒目。

          而對于移動 UI 界面設計來說,HarmonyOS Sans 本身優化了顯示效果和協調性,特別是對數字的優化(比如時鐘顯示的冒號,往往需要手動調整),使得對 UI 作品整體氣質有所提升,因此也可以用在效果圖或作品集中。

          當然了,你也可以設置為日常的辦公文檔字體,也可以下載用來替換自己手機設備的默認字體,即使沒有華為設備,也能體驗一下鴻蒙系統的文字顯示效果。鴻蒙字體的格式為 .ttf,可以在 Android、WindowsmacOS、Linux 等系統上使用。

          免費商用說明

          華為鴻蒙字體 (HarmonyOS Sans) 是隨鴻蒙系統發布的中西文字體,有華為聯合漢儀字庫專為鴻蒙系統設計,現在華為將其公開發布,任何個人和公司都可以免費下載使用,包括商用。

          需要注意的是,windows 系統內置的微軟雅黑字體以及 macOS 內置的平方字體都是不能商用的,用在設計或者印刷上會面臨侵權風險。喜歡這一類中性字體的,除了思源黑體、阿里巴巴普惠體,現在又多了一款鴻蒙系統字體可以選擇了。




          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          文章來源:站酷   作者:weyman_me

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務





          太強了!這些Dribbble頂尖插畫大神的作品,是我學習的源泉

          seo達人

          今天彩云跟大家分享的是Dribbble上,我非常喜歡的插畫設計大佬們。優秀的太多,這里僅放10位我覺得最值得看的,可謂是精選中的精選,所以我建議你一定要收藏學習。(彩云花了3個多小時艱難選擇出的10位,太難取舍了,最后入選的標準是一些更具風格特點插畫大佬們)

           

          1、Mikael Gustafsson

          https://dribbble.com/MikaelGustafsson

          首先推薦的這位大佬是我超喜歡的插畫師,他在dribbble上發的作品不算多,但不發則已,一發驚人。每一張作品中,不論是畫面構圖、場景、配色都非常優秀而且還把插畫做成了動態(其實是在Unreal引擎中落地的游戲場景動畫),細節做到了極致。尤其喜歡他作品中的配色,我經常參考他的作品找配色的感覺,推薦你一定要去看看。

          圖片

          圖片

           

          2、Beresnev

          https://dribbble.com/Beresnev

          這位大佬也是我在Dribbble上關注比較早的插畫師,他的作品大多數都是動態的,其實發現他的動態也是做到了極致。插畫的風格偏簡潔矢量,很有自己的個人風格??梢詮乃淖髌分袑W到很多動畫動態細節,畫面的動態速度、動作曲線、轉場,極簡的配色等等。他發布的作品量也不算大,但每一個都值得學習。

          圖片

          圖片

          圖片

           

          3、Jenny Yu

          https://dribbble.com/jennyyu

          這位小姐姐很擅長在畫面中運用光影關系打造意境,效果超喜歡,而且每一張圖都能讓看的人感受到一個故事,富有情感。畫風比較輕盈,喜歡在畫面中添加一些彩色的噪點,像是水彩撒上去的感覺,值得學習。

          圖片

          圖片
          圖片
          圖片

          圖片

           

          4、Andrey Prokopenko

          https://dribbble.com/Pro_Art

          這位插畫大佬擅長在結合圖形本身構成的不規則暗色框里作畫,從幾年前就開始流行這種風格的畫法。大概在5年前,彩云也畫了不少類似這種風格的插畫,當時跟這位大佬還經?;?,每次他發作品我會點贊,我發作品他也會給我點贊。只是他現在還在堅持更新這種風格圖,我已經好久沒畫了,慚愧??傊?,學習他的構圖,細節,配色都是非常不錯的,值得關注。

          圖片

          圖片
          圖片

          圖片

           

          5、MBE

          https://dribbble.com/Madebyelvis

          Mbe插畫風格應該很多人都已經熟知了,而他就是引流這股趨勢的創始人。這種風格技法上較為簡單,應用范圍較廣,曾經有段時間,各大廠的應用在空狀態頁,啟動頁面等等都進行了跟進。從這位大佬的作品中可以學習他的構圖,配色細節,尤其是可以學習他對于可愛風格的表達。

          圖片

          圖片
          圖片

          圖片

           

          6、Burnt Toast ®

          https://dribbble.com/BurntToast

          這位大佬在Google,Facebook,Samsung,Microsoft都工作過,跳遍國外大廠啊。他的插畫具有很明顯的個人風格:明亮的色彩,簡單平滑的曲線描邊,清新有趣可愛。我很早就關注了他,非常喜歡他的風格,給了我很多的靈感。他發布的作品量挺多的,很多都比較適合用到UI領域,推薦關注學習。

          圖片

          圖片
          圖片

          圖片

           

          7、Brian Edward Miller

          https://dribbble.com/bemocs

          他是美國科羅拉多州的一位獨立插畫師,作品風格偏古典,擅長使用噪點筆觸給畫面增加細節。畫面細節較為厚重,在一些風景,場景的表達上,比較適合參考。相比較于前面的一些插畫風格,這位大佬的作品算是比較特別的,推薦給大家。

          圖片

          圖片
          圖片

          圖片

           

          8、Canopy

          https://dribbble.com/canopy

          這是一家在紐約的插畫工作室,他們的作品以矢量插畫為主。我很喜歡他們畫的這種圖形規則的矢量風格,對于不擅長畫插畫的同學比較友好,很適合來臨摹學習,也能用到一些UI項目中。他們對于顏色的不同明暗過渡運用的非常好,值得學習。

          圖片

          圖片

          圖片

           

          9、Matt Carlson

          https://dribbble.com/matt-carlson

          這位大佬的插畫作品,風格較為多變,擅長畫一些風景畫,尤其是對于樹的表達有自己的特點。也是我關注的比較早的一位插畫師,功底很好,值得關注。

          圖片

          圖片
          圖片

          圖片

           

          10、Ana Miminoshvili

          https://dribbble.com/Anano

          最后推薦的是一位自由插畫師,她的作品喜歡加一些噪點,并結合一些特別的圖形外框,用出界的構圖方式營造立體感,增強了視覺表現力。她的小插畫,也很適合用到UI和運營里。在她的作品中從圖形上,構圖上,能看出是一位功底深厚的插畫師,值得學習。

          圖片

          圖片
          圖片
          圖片
          圖片

          總結

          文章中列出來的這些是我從關注列表中再三篩選出來的比較有代表性的頂尖插畫大神,在我的工作學習過程中,他們給了我很多的靈感。當然,這份推薦名單只是我自己的個人喜好,無關粉絲數量,排名也不分先后。

          這篇分享,一定是值得收藏的,不論是找靈感,還是臨摹學習,不用到處找,這10位大佬的作品就足夠你研究了。當然,插畫能力的提升離不開大量的練習,可以把這篇文章中分享的作品收藏起來(彩云挑選出的比較有代表性的作品),慢慢臨摹學習都是極好的。

           

          原文地址:彩云譯設計(公眾號)

          作者:彩云Sky


          轉載請注明:學UI網 ? 太強了!這些Dribbble頂尖插畫大神的作品,是我學習的源泉


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務



          如何建立完善的設計驗收機制

          seo達人



          在日常工作中,設計師經常會有這樣的煩惱:上線的產品和原先設計的不一樣,不是這個交互提示沒有顯示,就是那個圖標大小顯示錯了。更有甚者,產品功能的交互邏輯就有問題。用戶在使用過程中體驗大打折扣。導致這個問題的原因很可能是在產品開發鏈路中,設計師完成對設計稿的交付后就認為這個任務告一段落,開始著手下一個任務。而后續環節中的隊友對設計意圖、設計細節理解不足或產生誤解,將關注度僅集中在主要功能的提供上。解決這個問題,設計師們需要設立設計驗收環節,進行設計輸出和產品實現的比對和檢測。

          而在傳統的瀑布式開發流程中,由于產品實現周期較久,產品上線前設計師可以安排充足的時間進行驗收;但是在敏捷開發過程中,每個迭代的任務多、時間緊,設計驗收往往草草收場,以至于問題不斷累積,影響產品整體用戶體驗。本文將會結合酷家樂工具型產品-酷大師在敏捷開發過程中的實踐經驗說明如何搭建設計驗收體系,在設計師與隊友們的高效溝通的前提下,保障產品高品質在線。

           

          搭建設計驗收框架

          很多設計師反饋:產品上線前驗收過,有些小問題沒法立即解決;上線后會發現一些新問題;隨著產品功能的增加,問題越來越多,通常呈現分散式、零星式的特點,有些防不勝防的感覺。

          實際上,這是因為大多數設計師認為設計驗收就是上線前的事情,結束了就完成了,沒有建立系統驗收框架,缺少全生命周期去跟進設計實現的概念。

          由于酷大師項目是我從0到1一直跟進的項目,在啟動初期就做好了搭建設計驗收框架的準備,按照單一功能驗收、部分模塊功能驗收、全局功能驗收、階段性整體復查這樣的順序,網格狀、系統性、地毯式進行驗收。驗收階段貫穿上線前、上線后,形成點、線、面、體相結合的布局。

          圖片

          單一功能驗收階段——模塊驗收階段——全局驗收階段——周期性復查階段

           

          一.單一功能驗收階段

          大多數項目進行敏捷開發時,一個sprint結束后會上線該sprint研發的功能,此時可以進行該sprint中開發的功能的驗收。在酷大師敏捷開發過程中,一個sprint往往會完成1個復雜功能或多個獨立的簡單功能,我通常會給每個功能建立設計驗收文檔,逐個進行驗收。這個階段的驗收往往比較細致,會關注每個功能的設計輸出中涉及的所有細節點。

          這樣一輪精細化驗收結束后,往往能夠發現產品實現中90%以上的問題。我稱這個階段為點狀驗收。

           

          二.模塊驗收階段

          有些功能比較復雜,會拆解為多個子功能,花費多個sprint進行研發。比如說酷大師中的渲染功能,先實現構圖外景等能力,再實現陽光調節能力。

          所以會先進行構圖場景和陽光調節的單一功能驗收,當這些能力研發完成,渲染功能比較完整時,再進行整個模塊功能驗收。此時的驗收既是對單一功能的復查,也是對模塊功能的檢測。我稱這個階段為線狀驗收。

           

          三.全局驗收階段

          通常我會在一個相對具體的時間節點,比如半年、一年或者大版本更新迭代時,去查看整個產品功能迭代情況。這樣的時間節點就很適合進行一場全局性的功能驗收。

          平日的驗收結束后陸續會進行優化,但是由于優化時間點不一定是即時的,也有很多情況下是問題優先級較低,很久才修復。全局功能驗收就能從全局角度了解半年或一年進展情況,查漏補缺。

          由于酷家樂體系下,半年會對產品做一次回顧,所以我會在1個季度結束后進行一輪全局驗收,檢查出的問題可以下一個季度進行優化,保證每半年回顧時整體狀態可控。我稱這個階段為面狀驗收。

           

          四.周期性復查階段

          前面三個環節結束后其實會沉淀下數量客觀的驗收問題,一部分在上線前會解決掉,一部分上線前不容易解決的會在上線后短期內解決,還有一部分問題可能涉及資源、產品方向等短期難以解決的問題,會留檔,等待合適的時機進行解決。

          為了防止短期內沒有解決的問題被時間所遺忘,我會安排周期性復查,比如在半年的節點上,復查這半年的驗收文檔,對問題進行跟蹤整理,適合近期進行優化的推進優化解決,短期內還是沒法解決的再進行備注說明。

          這樣體系化的全生命周期的驗收,就可以保證產品穩定的質量呈現。

           

          明確基礎驗收流程

          圖片

          建立驗收文檔——驗收問題錄入——同步&溝通驗收問題【確定問題優先級&跟進機制】——過程中跟進調整情況———上線前復查

           

          一.建立驗收文檔

          有些團隊內部協作習慣于直接口頭溝通,面對簡單且量少的問題時比較快速,但是也存在信息遺漏、溝通誤差等問題。所以建議每次設計驗收時先建立驗收文檔。

          如果團隊共同使用線上協同工具,那么驗收記錄留檔和信息同步都能及時有效進行;如果沒有團隊協作工具,可以自己使用在線或本地文檔工具,比如石墨、語雀、Pages等。建立文檔時也需要按照一定規則,方便后續查找,比如命名按照功能、模塊、時間順序等。

          隨著文檔的增加,為了方便進行管理,可以建立一張驗收文檔管理表,記錄單個文檔的基礎情況。有些團隊分工較細,交互設計師和視覺設計師會分別建立驗收文檔,在我們的團隊協作中發現共同維護一份文檔比較高效,只需要在問題類型中進行交互、視覺的分類即可。

           

          二.驗收問題錄入

          設計師在對最初的設計輸出和設計實現進行比對時,往往會發現與最初設計意圖有出入的地方,建議將差異點都作為驗收問題進行錄入,在后續溝通跟進弄清緣由的情況下,再去判斷是否列入驗收問題。

          驗收問題錄入的過程,實際也是對功能的二次思考,在這過程中真切驗證原先規劃的操作路徑是否真的易用。有時也會在錄入過程中,發現需要增加延展的能力,那么也是可以錄入并備注,為未來的體驗優化積累突破點。

          驗收文檔的撰寫標準將在后文具體說明。

           

          三.同步&溝通驗收問題

          驗收問題常常會涉及多個崗位團隊成員,比如前端、后端、運營等,如果是團隊使用在線協作工具,在問題錄入的同時設計師可以先做好原因預判,立即@相關隊友,在正式進行溝通之前,能夠給相關隊友預留一些排查原因的時間。

          在一次設計驗收完成后,可以依據整個驗收文檔,與相關隊友共同溝通驗收問題??梢哉偌嚓P幾位隊友直接溝通,或者召開會議。在溝通的過程中,通常需要復現問題,判斷原因,以及確定跟進優化的負責人。

          同時會根據問題的影響程度、調整難易程度、資源配比程度,綜合判斷各個問題的優先級,再根據優先級進行排期調整。設計師在排定優先級時需要遵循體驗原則,盡量保證新功能上線時以較好的效果呈現。這樣用戶初次接觸功能時,在首因效應影響下,會對該功能體驗抱有好感,對產品整體體驗也會給到好評。

           

          四.調整跟進

          驗收問題調整的過程中,對于復雜問題往往需要進行頻繁的溝通,工程師需要在過程中與設計師確認方向正確性,防止偏差導致的再次誤差。

          此時設計師應給予充足的支持,比如詳細解釋設計意圖,比如幫助工程師尋找類似場景的實現效果,比如相關組件資源等。既是團隊協作共同解決難題,同時也在解決問題的過程中了解底層原因,為預防后續遇到類似問題積累經驗。

           

          五.上線前復查

          體驗問題調整結束,依據體驗文檔,再次驗證修復情況。在這個時期,如果還遇到其他問題,也是可以進行問題錄入和優化。

           

          制訂驗收文檔標準

          圖片

          標明序號——定位問題范圍——定位問題分類——問題清晰說明——差異截圖對比——原因與解決方案——定位負責人——記錄優先級———跟進記錄

           

          一.標明序號

          驗收文檔支持以多種形式呈現,比如word、excel、ppt等,嘗試過多種形式后,選擇使用excel表格。對問題屬性、范圍、負責人等進行說明時可以單獨呈現,很容易最終進行分類整理。

          比如復查時,可以拉取一段時間的驗收文檔,整理后可以知道視覺問題占比10%,那么視覺還原程度還是不錯的。比如渲染模塊問題占比20%,那么說明這個模塊下還需要集中進行優化調整。

          確定呈現形式后,可以在文檔中標明序號,方便后期整理。

           

          二.定位問題范圍

          驗收問題影響范圍往往并不相同,比如影響當前功能、多個功能、當前模塊,也有些問題涉及產品全局,甚至還有些問題會涉及公司其他產品線,此時需要說明清楚。

          工程師在修改問題時就可以針對該范圍進行問題解決,防止解決問題覆蓋面太小,產生遺漏。而涉及到公司跨業務線的問題時,可以@對應負責人,進行溝通解決。

           

          三.定位問題分類

          在酷大師驗收過程中,通常遇到的問題分類為:交互類問題、視覺類問題、運營類問題、技術類問題、產品方向類問題等。相關人員通常會直接關注對應問題,幫助高效處理。

           

          四.問題清晰說明

          清晰描述問題,盡量具體,避免類似于“不符合”、“不好看”、“與設計稿不一致”等主觀籠統的概括;提出問題的同時盡量說明解決方案,當然有些方案設計師能夠直接給予,而有些涉及其他崗位時就可以@隊友進行解決方案的描述。

           

          五.差異截圖對比

          將設計稿與開發界面進行截圖對比,標注出差異問題點,幫助相關隊友快速直觀理解問題。有些情況下截圖不能說明清楚操作過程中的問題,也可以采取錄制gif的方式,演示操作行為。

           

          六.原因與解決方案

          通常問題涉及的相關人員會在這個區域進行跟進說明,比如造成當前問題的原因、解決方案、排期等。

           

          七.定位負責人

          記錄當前跟進的跟進入。

           

          八.記錄優先級

          優先級的評定可以有多種維度。通常可以直接做判斷的維度有兩個,易于調整的問題優先級較高,對完成功能影響大的問題優先級高。其他維度可以根據具體產品,與團隊共同進行分析,總結其中的規律。

           

          九.跟進狀態記錄

          主要集中于對問題解決情況的跟進,通常分為已解決、跟進中。

           

          其他思考

          為了實現產品高品質在線,除了在研發實現后落地系統的驗收機制以外,設計師可以在很多環節發揮作用:

          1.設計稿本身的高標準輸出,考慮清楚開發成本和可實現性;

          2.交互評審環節盡量解釋詳盡,與相關工程師達到理解上的一致;

          3.開發過程中參與溝通,幫助工程師先做一波問題的排除;

          4.出現問題幫助促成解決,包括跨團隊資源的收集、組件支持之類;

          5.明確產品設計還原度對于用戶體驗的重要性;

          6.以多種方式邀請合作伙伴參與到驗收環節中,比如bugbush、專家走查、可用性測試。

           

          原文鏈接:酷家樂用戶體驗設計(公眾號)

          作者:懷瑾

          轉載請注明:學UI網》如何建立完善的設計驗收機制


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務

           


          復雜系統如何設計 | 論B端產品的體系化構建(上)

          ui設計分享達人

          導讀


          為什么B端產品總是容易“失控”?B端產品設計與C端有何差異?如何在不斷復雜的系統中,權衡效率、成本、體驗之間的關系? 


          本文將帶你從B端產品的本質出發,了解產品發展過程中容易出現的問題,并從復雜系統的角度去探討設計體系的構建方式。



          目錄


          一、「 困局 」容易“失控”的B端產品

          A .「 關注重點的差異性 」

          B .「 微小差異的不斷疊加 」

          C .「 產品發展進入惡性循環 」

          D .「 進入效率拐點,產品失控 」


          二、「 啟發 」從復雜科學的角度思考設計

          A.「 自然算法 」

          B.「 物質的構成原理 」


          三、「 探究 」什么是產品設計體系?

          A.「 定義 」

          B .「 組成部分 」

          C .「團隊能力要求 」

          D .「 構建方向 」


          四、「 剖析 」B端產品的生命周期

          「 產品生命周期概述 」

          A .「 初創期 」解決核心問題,產生價值

          B .「 成長期 」能力完善,產品擴張

          C .「 成熟期 」效率提升,快速增長

          D .「 暮年期 」商業價值降低,發展逐漸停滯


          NEXT、「 下期預告 」設計體系的構建法則




          前言


          隨著產業互聯網時代的到來,市場對B端產品的重視程度逐漸提升。然而,談及B端產品,特別是SaaS產品,大多數設計師對此并不是特別感興趣。一來,SaaS更注重功能層面,似乎本身對設計的要求并不高;二來,SaaS產品的最終實現效果總是不盡人意,就算設計得再好看,實現出來也難以出彩。


          確實,若設計師僅僅只是關注視覺層面本身,那么B端產品確實不像C端那么吸引人。但是,若你能以整個產品構建的角度去思考B端產品設計,那么設計師能夠在其中發揮的空間是巨大的。


          假如把C端產品比作精致的小房子,那B端產品就是一幢巨大的高層建筑。建造小房子,你可以盡情地發揮創意,追逐潮流,大不了推倒重來。而建造大房子,則需要設計師考慮更多的維度,因為這是一個長期而復雜的工程。


          建筑的外觀不僅需要好看,更需要足夠耐看、穩定;為了適應更多人的需求,你不僅要考慮房子的軟裝,還要考慮戶型的合理性、通用性;而為了降低成本,你還需要考慮家具、硬裝的標準化、房間的兼容性等等…


          “你是否有信心建造一個宏偉的高樓大廈?” 


          這是我在B端設計中,反復強調體系化思維的原因之一。想要建造一個大型建筑,沒有體系化思維、沒有更完善的多職能協作流程,那么這座高樓一定會在建設過程中埋下隱患。而當問題一旦出現,涉及到的沉沒成本也將會非常巨大。


          當然,對于C端產品來說,體系化也愈發重要了。隨著互聯網時代的持續發展,一些C端產品的復雜性也堪比B端。我在之前的文章中提到過一個觀點:“C端B化,B端C化”。在未來的數字產品設計中,B端產品將會逐漸開始重視產品的外觀與體驗,因為觸達的人群更年輕化、對體驗要求更高了。而C端產品也會更注重體系化建設,因為產品體量越來越大,需要尋求效率與成本之間的平衡點。


          產品設計體系,本質上是一套更科學的復雜性數字產品的設計方法與工作流程。因此,不管是B端產品還是C端產品,設計體系能夠在提升設計品質的同時,讓產品更“可控”,提升效能,降低成本。


          這套設計方法論,是我在工作中不斷實踐與完善的一些經驗與方法。希望能借此分享一些自己淺薄的經驗,也探討一下數字產品設計未來的形態。




          ?

          一、「 困局 」容易“失控”的B端產品

          -


          作為較為復雜的數字產品,B端產品在快速發展的過程中,總是容易出現一些問題。特別是當產品體量到達一定階段后,問題就會逐漸暴露出來,比如:


          1. 產品丑、設計質量低;

          2. 組件樣式繁多,操作習慣不一致;

          3. 新老系統差異大,不同模塊體驗差異大;

          4. 頁面結構混亂。


          等等…


          很多問題大家都能明顯地意識到,但往往因為“不影響售賣”、“價值不高”、“新功能優先”等理由被擱置。


          隨著問題逐漸積累,產品的優化成本也變得越來越高,最終使整個產品已經積重難返。若只是多部分頁面/組件進行優化,小修小補,雖然成本低,但成效甚微;若是進行大修大補,那么優化成本將遠大于研發新功能的成本。


          這種普遍的B端產品現象,被稱為“產品失控”,即——團隊已經對整個產品的形態失去控制力。


          那么,為什么B端產品特別容易出現這種問題呢?



          A .「 關注重點的差異性 


          首先,產品的本質決定了其關注重點的差異性。


          與C端產品不同的是,B端產品往往更看重“能力”(為企業用戶解決問題),而產品的銷售方式與付費模式,也決定了產品體驗并非首要關注的對象。由于B端產品通常針對企業用戶,需要更長的研發過程,產品的體量和復雜性也相對較高。因此,除了產品解決問題的“能力”之外,產品還需要關注研發的效率及成本。


          因此,在產品的發展初期,企業通常對效率最為關注,其次是成本,最后才是體驗(能用就行)。絕大多數B端企業,只有在產品跑通商業邏輯,并具備一定用戶與盈利預期之后,才會對產品的體驗逐漸重視起來。



          B .「 微小差異的不斷疊加 


          任何微小的差異,在無數次的疊加之后,都會被快速放大。特別是當團隊的人員逐漸增多后,放大速度將會呈指數級上升。


          為了配合產品的快速發展,產品往往會采用“堆量”的研發模式。增加研發效率,最簡單直接的方法便是投入更多的資源。隨著產品不斷增加模塊、功能、頁面,團隊人員也在不斷地擴充。


          但是,人類不是機器,并非簡單的1+1=2。團隊數量的上升雖然會帶來效率的短期提升,但同樣也會增加團隊的管理成本。不同的產品經理、設計師、研發人員,對于產品的認知是不同的。隨著團隊人員的不斷增加,“個體差異性”將會被不斷地疊加與放大。


          就像“傳話筒”的游戲一樣,同一個事物,不同的人理解總是不同的,經過多次的“傳話”以后,往往與原本的意思已經大相徑庭了。


          這種情況表現在產品設計中,則會出現:當相同的組件由不同的人做時,總是會在基本樣式、實現原理、交互細節等不同的維度出現差異。比如上圖中的導航菜單組件,不同的模塊在開發時總是會存在差異,最后差異越來越大,形成了五花八門的導航菜單形式。



          C .「 產品發展進入惡性循環 


          令人遺憾的是,雖然問題很明顯。但是在不斷的“成本考量”中,產品團隊往往優先關注新功能的開發,而忽略底層問題的優化。


          隨著產品的快速發展,產品的優化/迭代成本將會逐漸大于研發新功能的成本。要么背負巨大的成本進行整體重構;要么降低標準,繼續以這種模式不斷疊加新功能。


          在這種情況下,大部分B端產品往往會選擇后者。于是,產品的發展將會進入一個“惡性循環”


          • 產品快速發展,功能不斷疊加;

          • 各模塊由不同的產品、不同的開發研發,導致各模塊之間差異增加;

          • 產品丑、體驗不統一,但老系統優化成本過高。綜合衡量,優先進行新功能研發;

          • 所有模塊標準不統一,產品迭代效率持續降低,維護成本持續增加。



          D .「 進入效率拐點,產品失控 


          產品的發展猶如一輛快速奔馳的巨型列車,一旦加速便難以停止。


          隨著問題的反復出現,以及在一次次的“利益權衡”中選擇性的忽略,產品的惡性循環不斷重復,而問題也逐漸疊加、沉積下來。


          當這個問題已經大到我們無法回避時,我們才發現:產品的單位迭代/優化成本,已經遠遠大于新功能的研發成本。而新功能帶來的增量,已經無法抵消現有模塊的迭代成本——產品迎來了效率拐點。


          就像一個龐大而復雜的機器,雖然依舊可以運行,但整體效率已經很低了,而與之對應的維修成本則非常巨大。小修小補根本無法解決問題,而大修大補則很有可能會帶來更大的虧損。


          最終,產品逐漸在“失控”中難以自拔,競爭力逐漸降低,但整個團隊對此卻無能為力,嚴重影響了企業的發展。


          那么,在產品發展中,我們應該如何避免這種情況呢?換而言之,一個高度復雜的數字產品,我們應該如何設計,才能避免其逐步走向混亂? 




          ?

          二、「 啟發 」從復雜科學的角度思考設計

          -


          如果我們將B端產品看作是一個復雜系統,那么產品“失控”的本質即——在不斷復雜化的形態中,缺乏有效的控制機制,最終導致整個系統失去控制。 


          但是,在大自然面前,B端產品這種復雜程度顯然不值得一提。


          像大自然這樣的復雜系統,是如何構成的?所有的物體都由原子所構成,為什么簡單的一百多種原子,能夠構成如此復雜的世界?生命又是如何在無機物的世界中誕生,并逐步進化成如此復雜的個體的?



          A.「 自然算法 


          道生一、一生二、二生三、三生萬物...無論是老子的《道德經》,還是《深奧的簡潔》、《萬物皆數》、《復雜》這些現代的書籍中都闡述了這樣一個觀點:


          任何看似復雜而又可控的系統,一定存在著精簡的“算法”,通過不斷的疊加從而形成復雜系統。


          就像愛因斯坦說的:“宇宙最不可理解之處,就是它居然是可以被理解。”


          在大自然中,有很多的花紋與圖案的形狀都存在相同的規律。比如上圖中的羊齒草分形圖案,這種圖案在森林當中到處可見,我們看到很多樹的形狀跟葉子的形狀是一致的,這就是一種分形圖案。而這種分形的圖案本質上是一個公式,通過不斷地自我引用進行迭代,這便是分形。


          科赫曲線(Koch curve)就是一種分形。其形態似雪花,又稱科赫雪花(Koch snowflake)、科赫星(Koch star)、科赫島(Koch island)或雪花曲線(Snowflake curve)。


          它最早出現在瑞典數學家海里格·馮·科赫的論文中。我們將一根直線分成四段,然后向中間擠壓形成等邊的倒V形狀;接著再將每個倒V的邊進行相同的操作,不斷地重復之后,我們發現:第一步是倒V型、第二步變成了大衛星,第三部變成了楓葉,第四步… 經過無數步以后,最終成了越來越復雜的“雪花”形態。


          科赫曲線便是“自然算法”的一種。海岸線雖然很復雜,但是卻有一個重要的特性——自相似性。從不同比例尺的地形圖上,我們可以看出海岸線的形狀大體相同,其曲折、復雜程度也很相似,換句話說,任意一段海岸線就像是整個海岸線按比例縮小的結果。而海岸線的構成原理就是這種科赫曲線,它是通過天然的演化,不斷折疊最終形成了這種形狀。


          可以發現,他們都是由 基礎物質 x 簡單算法 x 隨機變量,經過無數次疊加后,最終形成了一個復雜而多變的整體。



          B.「 物質的構成原理 


          宇宙中還有其他各種驚人的“巧合”。愛因斯坦的相對論揭示了宏觀世界的規律性,普朗克和海森堡的量子力學揭示了微觀物質世界的規律。當我們從微觀世界到天文學會發現——原子核的構成方式居然與天體的構成非常相似。粒子圍繞原子核的運動方式,就好像行星圍繞太陽運動一樣。


          不管是整個宇宙,還是生命體,將其置于復雜科學的研究框架中,那些基本定律最終也會變得極其簡單。


          在宇宙中所知最為復雜的形態,便是如同我們自身的生物。這些復雜體由已知存在于銀河系中最普通的物質所構成。但是,通過氨基酸的形態,這些基本原料竟能自然地將自己組合成一個自組織系統。


          混沌中隱藏的算法,使宇宙成為極有秩序的地方。而在秩序中隱藏的隨機數,又使得宇宙成為極為豐富的世界。


          也正是因為算法的精簡,一切物質的創造才能具備復制性、延續性、進化性。


          那么,我們反過來思考——想要使復雜的系統簡單可控,是否就需要一套簡潔、有效的“算法”?通過“算法”,將基礎的“物質”不斷地“有序疊加”,形成一個可控的復雜體系。


          因此,對于復雜的SaaS系統設計,我開始引入“設計體系”這一概念,希望能夠找到未來SaaS產品設計的發展方向。只有設計體系的建立,才能保證產品可控性,才能在不斷復雜系統中,保證效率、成本、體驗之間的平衡。




          ?

          三、「 探究 」什么是產品設計體系?

          -


          產品設計體系,在國內仍舊是較為陌生的詞匯。什么是設計體系?


          A.「 定義 


          一個成熟的數字產品,需要有一個穩定、且持續迭代的形態。創造這個形態的過程,我們稱之為廣義上的產品設計(這里指產品的整個策劃和設計過程,包含策劃、交互、視覺及部分前端開發)。而負責控制和維護這個形態的這套系統,便是產品設計體系。


          我們接觸到的更多是設計系統(Design System),比如平臺級的設計體系,Apple、Google、Microsoft等系統級的設計系統,及其設計開發套件、應用生態。公司級的設計系統,如Airbnb設計系統、IBM的Carbon設計系統、螞蟻金服的Alipay Design等。


          但是,在一個企業內部,想要Design System能夠系統性地運轉,還需要基于這套標準建立的團隊協作機制。只有設計標準與團隊協作標準完美融合,才能建立真正的設計體系。



          B .「 組成部分 


          如果將數字產品比作復雜的“生命體”,產品的發展比作競爭中“自我進化”,那么設計體系便是產品的DNA。它既是產品形態的控制源,又是不斷自我迭代的進化源,它的作用是:


          • 控制產品外觀——感知性模型(視覺風格/規范)

          • 制造基礎構件——功能性模型(基礎/復合組件)

          • 模塊的構建規則——模式語言(產品框架規范)

          • 產品標準定義、生產方式制定——協作模型(高度協同的工作流程)


          它不僅能控制產品的“生產結果”,提升產品質量;還能規范產品的“生產過程”,形成一套完整的多職能協作流程,提升產品的生產、迭代和維護效率。 


          從宏觀來看,設計體系像是一個“規范的復合體”,它是各職能之間規范的有效整合,產品框架、交互規范、視覺規范、前端規則,同時也是基于整合規范所創造的一套創新的工作模式。



          C .「團隊能力要求 


          設計體系的建立,需要整個產品團隊擁有一致的目標,并為之通力協作才能完成。這就需要整個團隊擁有較高的平均素質與契合度


          同時,體系化的建立和推動,也需要團隊中有人牽頭去推動。設計師作為“產品-開發”的中間環節,是非常有條件成為推動者的角色的。


          當然,這就要求設計師擁有更豐富的橫向能力。


          一方面,設計師需要將自身的能力邊界進行拓展,與上下游的職能保持密切的溝通,并解他們的訴求。只有當設計體系滿足各方利益時,體系化才有推動的空間。


          另一方面,對于產品側與開發側人員,設計團隊也可以通過培訓來提升他們的能力邊界。比如針對產品的交互培訓、針對開發人員的基礎審美培訓等。這樣才能提升產品的下限與上限,增強產品的綜合競爭力。



          D .「 構建方向 


          設計體系并非超脫于產品之上,而是根植于產品的成長過程中。


          想要推動體系化的建立,必須充分了解產品發展的基本規律。產品處于不同的生命周期,所要解決的問題是不同的。在正確的時間做正確的事情,并對未來的形態進行規劃,才能逐步讓設計體系根植于產品、融合于產品。


          因此,在下一章,我們首先來了解一下B端產品的生命周期。




          ?

          四、「 剖析 」B端產品的生命周期

          -


          對于設計師來說,首先要更宏觀地了解產品所處的生命階段,才能知道設計需要解決的問題是什么,并以此有針對性制定不同的設計策略,最終幫助產品構建完善設計體系。


          本章更多的是對B端產品的發展階段做一個剖析,而不同階段具體的實施策略,會在后面講解。



          「 產品生命周期概述  


          類似于人的成長歷程,一個新的B端產品從誕生到逐步擴大,通常都會經歷幾個不同的生命階段。


          B端產品研發是一個漫長而系統化的過程。這個過程通常伴隨著商業業務發展與商業戰略模式的不斷調整。


          B端產品從立項到下線,產品會處于幾個典型的不同狀態中,這就是產品的生命周期。通常來看,大多數產品都會經歷以下幾個生命周期。初創期-成長期-成熟期,直至最終進入暮年期。


          而產品的商業價值,也會伴隨著產品的發展而變化。在通常情況下,伴隨著產品的逐漸成長,其商業價值也會隨之增長,并在成熟期進入黃金的商業價值期。而當商業價值出現大幅、持續性的降低時,則基本算是進入了暮年期。


          那么,不同的生命周期中,產品將會遇到哪些問題?而為了保證產品的持續發展,產品團隊又需要做哪些事情呢?



          A .「 初創期 」解決核心問題,產生價值


          初創期,即產品已經從構思到研發,并成為了初步的產品。這個時期,產品雖然還不能覆蓋完整業務,但已經能夠順利運行。


          從構思到創意,再到實踐落地。B端產品的誕生,通常源于在行業內深耕多年的資深玩家。在不斷地實踐中,通過創意與實踐,找到了一條能夠幫助行業解決問題、提升效率的路徑。


          在這個時期,產品需要解決以下幾個問題: 


          1)用戶是誰?


          B端業務的本質,就是“向組織銷售服務來獲得盈利”。哪些企業最需要你的產品?哪一類用戶的問題最需要通過這種方式得到解決的?這些都是需要在早期非常明確的。


          站在普羅大眾的角度去規劃產品固然是好的,但成功的產品都始于一小部分早期用戶;B端產品的用戶通常來自某一垂直領域,首先讓他們喜歡上你的產品,然后慢慢向外拓展至更大的人群當中。


          想想看,最初一千名喜歡你產品的種子用戶可能是哪些人?


          2)產品能夠解決什么問題?


          我們要為用戶解決什么問題?“用戶的問題”可能是一個需求、一個困擾或是一個機遇。他們的需求是否真的是痛點?


          這個時期,團隊需要拜訪大量的目標用戶,通過交流獲取痛點。我們必須驗證這個需求的真實性,以及我們的解決方案是否具備一定的可實施性。


          我們可以通過更具象的UI或流程,初步展示想法,不斷優化。最終形成一個可驗證的初步產品Demo,并通過Demo進一步與潛在用戶進行溝通。


          3)這個問題是否普遍?是否具備標準化的可能?


          不同企業的需求是有差異的,如何將個性化的需求抽象成共性的解決方案?如何權衡范圍與成本之間的關系?我們要將不同企業的需求進行抽象,形成標準化的解決路徑。


          這個階段,我們需要為種子用戶創建方向聚焦的MVP。MVP必須是名副其實的最小化可行產品,要為種子用戶帶來端到端的精準體驗。如果他們不理解產品功能,不知道如何或為什么使用,或是發現其性能低劣、bug 太多,無法達到“可行”的程度,那么你的假設就難以得到有效驗證。


          4)是否能夠形成完整的商業閉環?


          用戶是否真的會為這個產品買單?換句話說,產品是否能賺錢并且養活整個團隊?


          B端產品在初創期,最重要的是快速驗證產品與業務的親密性,能否完成既定的商業戰略。產品團隊需要通過磨合業務,快速調整業務解決方案和產品架構。


          不僅是產品的打磨,整個團隊也要形成完整的閉環。工作流程、產品的商業運轉機制也要初步跑起來。產品的售前、解決方案、產品研發、實施、客戶成功,我們需要真實地完成這一套閉環的操作,并基于此做團隊毛利模型的測算。 


          解決問題,帶來價值,并且能夠將價值轉化為收益,這才是產品可持續發展的關鍵。只有跑通完整的商業模式,擁有長期的盈利預期,產品才能順利進入下一個階段。



          B .「 成長期 」能力完善,產品擴張


          成長期,即產品形態初具完善,并具備完整商業閉環之后,處于快速成長的時期。這個時期,產品將進行快速的迭代,覆蓋的業務一天比一天完整,能滿足的業務需求越來越多,而產品為業務帶來的價值越來越大。


          與新生期的區別在于,新生期時的迭代方向還未完全明確,迭代更多的是嘗試,磨合業務與產品。而在成長期時,產品的迭代方向已經是非常清晰了的


          1)更多用戶,更多真實需求


          產品在真正投入運營之后,所遇到的情況一定與MVP時期有所區別。隨著產品的不斷售賣,我們將會接觸到越來越多的真實用戶,以及更多的真實需求。而這些用戶與他們的訴求,將會成為產品發展的指引。


          2)解決更多問題,業務范圍擴張


          經過長期的打磨,產品的形態和可用性已經初步成熟了,商業模式也已經初步跑通。隨著更多的真實需求,產品將會選擇有價值的方向擴張業務范圍,從“解決一個問題”逐漸走向“解決一系列問題”。


          3)功能完善,產品體量快速增加


          伴隨產品的快速迭代,產品的基礎功能會逐漸完善,同時也會基于核心功能去搭建更為豐富的功能矩陣。更多的能力、產品模塊、頁面,最終逐漸疊加為一個完整的大型產品。


          4)組織逐漸完善,人員專業化


          隨著業務擴張,組織架構逐漸完善。為了提高專業性與效率,團隊人員從“多面手”逐漸轉化為專業化方向。與之對應的是,團隊成員的數量也會在這個時期快速增加。售前、解決方案、產品研發、實施、客戶成功,這一套完整的團隊模型在各模塊中不斷地復制。



          C .「 成熟期 」效率提升,快速增長


          成熟期,即產品的形態已經穩定,并能夠創造持續的商業價值。處于成熟期的產品,肯定是已經進行商業化運行的。反之,沒有達到預期的商業價值的產品,不能算成熟期。


          進入這個階段時,產品已經實現了產品-市場匹配。但是,我們需要對整個產品、以及團隊進行一系列的調和與優化,才能讓整個產品的形態與運作方式更加合理,以便將產品推向更廣闊的市場


          1)產品效率、組織效能提升


          經過一系列的快速發展,產品體量通常都會比較大,而團隊成員也快速擴張。隨著一致性成本、溝通成本增加,勢必會造成研發效率、組織效能會下降。因此,如何降低產品的單位研發成本?如何讓整個團隊的組織效能達到最佳狀態?是需要解決的問題。特別是當產品具備一定的客戶數量以后,單位研發成本的降低將會極大提升產品整體的利潤率。


          2)產品設計-研發標準化,構建完整鏈路


          通過產品設計-研發標準化、數據架構標準化,打通不同模塊的壁壘,提升模塊化與靈活性。將單點之間的競爭力相互配合,形成“場域”競爭力。


          產品的單點也許不能保證都有最佳的競爭力,但如果我們能夠提供一系列的、高質量、無縫銜接的配套服務形成閉環,將會形成強大的整體競爭優勢。同時,產品設計-研發標準化,能夠增加產品售賣的靈活性,通過靈活的組合方式吸引不同的用戶,提升銷售靈活性與成單率


          3)提供高質量的用戶體驗


          產品最終是給人用的,用戶體驗也會在將來逐漸成為B端產品的核心競爭力。隨著競爭的加劇,以及用戶群體的逐漸年輕化,用戶體驗將成為企業在選擇產品時的重要考量因素,也是口碑傳播的重要途徑。


          由于在“產品-市場匹配”階段需要盡快地推出產品,所以在設計開發過程中可能遺留諸多問題,需要進一步打磨優化。產品設計需要與開發具備高度的一致性,視覺交互是否合理,前端代碼是否準確合理,操作反饋是否高效等問題,都需要這個階段來進行調和。


          4)教育市場,賣給更多的人


          當產品逐漸成熟并具備一定體量之后,單靠銷售跑單是遠遠達不到發展要求。這個階段,需要市場部人員對市場進行教育,聚焦不同的行業領域,從“點式營銷”轉變為“面式營銷”,并配合銷售人員進行產品的售賣。因此,在這個階段,產品的品牌力、核心能力的傳播將至關重要。



          D .「 暮年期 」商業價值降低,發展逐漸停滯


          暮年期,即產品發展停滯甚至倒退,逐漸失去商業價值的產品。


          B端產品進入暮年期的原因,主要有兩個。一是,伴隨著業務的發展,產品已經很難滿足業務需求。且翻新產品的投入產出比較低。二是,伴隨產品的使用時長,產品將變得臃腫和遲鈍,逐漸難以敏捷地滿足業務需求。


          很多時候,商業環境的快速發展、技術的更新迭代都有可能成為產品進入暮年期的原因。對于暮年期的產品,根據商業戰略,產品經理既有可能要延長產品的壽命,也有可能持續保障產品完成順利換代。當然,更多暮年期的B端產品,由于業務的調整,最終迎來生命的終結。


          需要注意的是,很多產品因為在成長期、發展期無法建立有效的產品控制機制,導致產品過早的進入臃腫階段。也就是前文中所講的“產品失控”,非常有可能加速產品暮年期的到來。


          因此,是否能在前三個階段建立健康、完善的設計體系,是產品能夠獲得更長生命力、更多價值的關鍵。




          ?

          NEXT

          「 下期預告 」設計體系的構建法則  

          -


          你的B端產品處于什么生命周期?在這個階段產品要解決的問題是什么?而在這些過程中設計體系又應該如何構建?


          設計體系的建設并非一蹴而就,通常是伴隨著產品的而發展逐步建立的。在下一篇文章中,我們將基于B端產品的發展階段,帶你詳細了解設計體系的正確構建方式。


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          文章來源:站酷   作者:Jady13_劍杰

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          如何設計友好易用的表單

          ui設計分享達人

          表單對于用戶和產品同樣重要。當我們需要收集數據時,表單是我們最常采取的方式(也許是由于在互聯網普及之前,表單就已經長期應用于我們日常生活中 )。因此,將表單設計得友好易用是提高用戶信息填寫完成率的關鍵。


          表單拆解

          表單的樣式會根據業務目標、內容的不同而發生變化,但是有一些基礎的組成部分能幫助用戶快速順利地完成表單的填寫。


          1.類別標題:類別標題能夠幫助用戶瀏覽表單并同時解釋整個表單的大致內容是什么。當你需要把被收集的信息分類為多個部分時,比如個人信息、職業信息和財務狀況,這時類別標題就可以派上用場。


          2.文本標簽: 文本標簽能夠提示用戶在每個輸入框中應該填寫什么樣的信息。


          3.提示文字:文本標簽的附加說明。


          4.錯誤信息提示:向用戶反饋為什么輸入框中輸入的信息有誤。


          5.重要行為召喚按鈕:表單末尾的按鈕,用來提交表單上輸入的內容。



          表單狀態


          在用戶使用表單時,有三種最基本的狀態能夠幫助用戶完成操作。


          1.默認狀態:默認狀態是用戶未進行任何操作時的狀態。


          2.激活狀態:當用戶點擊輸入框后,輸入框就變成激活狀態并通過樣式的變化強調顯示。如果用戶視線離開了屏幕一小會兒,這個狀態可以幫助用戶快速瀏覽定位。


          3.反饋狀態:此狀態一般在完成一個信息的填寫,并進行下一個字段輸入的時候出現,讓用戶了解輸入的信息是否正確。對于一些無法立即驗證的信息可以在用戶提交表單的時候進行反饋。



          設計原則


          1.保持簡單:將表單設計得短且簡單。只收集必要的信息,避免讓用戶分開填寫姓氏和名字(分開填寫姓氏和名字一般只存在于外國網站)。允許用戶查看已輸入的密碼,而不要讓用戶填寫兩次密碼去確認。


          2.使用內嵌提示:當用戶輸入信息有誤時要給出錯誤提示,同時要將錯誤原因注明在相應的輸入框旁。


          3.組合相關項:將有相關性的填寫項組合在一起,然后將它們以合理的順序整理,這可以幫助用戶不必花費太多認知成本去填寫必要的內容, 這個過程不僅輕松而且只需要用戶很短的專注時間。


          4.使用左對齊的文本標簽:始終在輸入字段上方放置文本標簽。不要用文本標簽替換提示文字,不然用戶在提交表單之前很難檢查他們輸入的信息,會浪費較多的時間。請把標簽放在輸入字段上方并且左對齊。


          5.根據輸入信息的格式設計輸入框:簡單來說,確保輸入框的格式與輸入信息的格式協調。比如說,地址的輸入框應該比手機號碼的輸入框更長。


          6.CTA按鈕(行為召喚按鈕)

          一般表單的后面會有一個或多個按鈕,比如“提交”、“下一步”之類的。在按鈕有多個的情況下,最重要、或者是最想要用戶點擊的按鈕應該要突出,而其他按鈕弱化處理。

          當使用模態視圖狀態下的表單時,有時會有一個關閉按鈕用于關閉模態視圖。另一種設計方式是使用叉號圖標并將其放置在頂部的右側邊緣,它可以代替關閉按鈕,如圖所示。


          7.搜索字段:當網站內容比較多的時候,把搜索字段做的明顯些,方便用戶對網站內容進行篩選。同樣的,在用戶使用了搜索功能獲取到結果后,不要清除搜索框內的搜索關鍵字,因為用戶可能會查看最初他們搜索了什么。


          8.清晰:向用戶清晰地表達信息,不要出現含糊不清的詞。用戶可能不愿意填寫表單,所以盡可能清晰簡單。如下圖的綠色按鈕文字使用“提現”而不要使用“確定”。


          原文:https://blog.prototypr.io/creating-user-friendly-forms-46e3f7f4eef2

          作者:Momoh Silm

          譯者:Ballen貝林、春風似蛋撻

          本文翻譯已獲得作者的正式授權

          授權截圖

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          文章來源:站酷   作者:Ballen成明

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          日歷

          鏈接

          個人資料

          藍藍設計的小編 http://www.syprn.cn

          存檔

          亚洲va欧美va天堂v国产综合