作者：陳大魚頭

github： KRISACHAN

<input /> 標簽是我們日常開發中非常常見的替換元素了，但是最近在刷 whattwg 跟 MDN 的時候發現 跟 <input /> 有很多相關的屬性，選擇器都沒怎么用過，所以就開篇文章來整理一下一些比較有趣或者實用的知識點。



本篇文章默認大家已經知道 <input /> 標簽的基本用法，不會做過多的基礎說明~







沒想到，這些選擇器居然跟 input …

到寫文章為止，根據的 drafts 指出，一共有3大類，16種跟 input 相關的選擇。其實都挺有用的，善用它們，會讓我們的用戶體驗更加美好。



下面我們來分享一下這3大類選擇器的作用：







第一類：控制系（Input Control States）

選擇器 作用

:enabled 選擇可使用狀態的 <input /> 元素

:disabled 選擇不可使用狀態的 <input /> 元素

:read-only 選擇不可編輯狀態的元素（不僅僅是 <input /> ）

:read-write 選擇可編輯狀態的元素（不僅僅是 <input /> ）

:placeholder-shown 選擇 placeholder text 顯示時的元素

:default 選擇在 <button>，<input type="checkbox" />， <input type="radio" />, 以及 <option> 上的默認狀態

第二類：輸出系（Input Value States）

選擇器 作用

:checked 選擇處于選中狀態的 <input type="radio" />

:indeterminate 選擇狀態不確定的表單元素與 <progress>

第三類：偵查系（Input Value-checking）

選擇器 作用

:blank 選擇處于空值時的 <input>，暫未被瀏覽器支持

:valid 選擇驗證通過的表單元素

:invalid 選擇驗證不通過的表單元素

:in-range 選擇處于指定范圍內的 <input />

:out-of-range 選擇不處于指定范圍內的 <input />

:required 選擇必填的表單元素

:optional 選擇選填的表單元素

:user-invalid 選擇用戶輸入但值非法時的 <input />，暫未被瀏覽器支持

可怕，除了選擇器，居然還跟這些屬性有關系

<input> 除了有很多相關的選擇器，結合不同的type還有不同的屬性可以供使用。他們的作用如下：



屬性 作用

maxlength 可輸入的最大長度

minlength 可輸入的最小長度

size 輸入框的長度

readonly 輸入框是否只讀

required 輸入框是否必填

multiple 輸入框是否可以多選

pattern 輸入框驗證規則

min 可輸入的最小值

max 可輸入的最大值

step 輸入框每次的增量

list 輸入框綁定的可選值數據

placeholder 輸入框預選文字

實戰

通過上面的三類說明，我們大致了解了 <input /> 標簽的相關信息，但是你們以為我是來列list的嗎？



當然不是，還有實操啊~







純CSS實現表單提交功能

首先我們來看個效果圖







上面的效果就是一個純CSS實現的表單提交功能，這是怎么實現的呢？下面我們直接看源碼，然后一步一步地來分拆（不想看的可以直接CV下面的源碼自己做測試~）



<style>

    :root {

      --error-color: red;

    }

    .form > input {

      margin-bottom: 10px;

    }

    .form > .f-tips {

      color: var(--error-color);

      display: none;

    }

    input[type="text"]:invalid ~ input[type="submit"],

    input[type="password"]:invalid ~ input[type="submit"] {

      display: none;

    }

    input[required]:focus:invalid + span {

      display: inline;

    }

    input[required]:empty + span {

      display: none;

    }

    input[required]:invalid:not(:placeholder-shown) + span {

      display: inline;

    }

</style>

<form class="form" id="form" method="get" action="/api/form">

    賬號：

    <input data-title="賬號" placeholder="請輸入正確的賬號" pattern="\w{6,10}" name="account" type="text" required />

    <span class="f-tips">請輸入正確的賬號</span>

    <br />

    密碼：

    <input data-title="密碼" placeholder="請輸入正確的密碼" pattern="\w{6,10}" name="password" type="password" required />

    <span class="f-tips">請輸入正確的密碼</span>

    <br />

    <input name="button" type="submit" value="提交" />

</form>



第一步：寫好基礎結構

首先我們來把基礎結構給寫好，代碼如下：



<style>

    :root {

      --error-color: red;

    }

    .form > input {

      margin-bottom: 10px;

    }

    .form > .f-tips {

      color: var(--error-color);

      display: none;

    }

</style>

<form class="form" id="form" method="get" action="/api/form">

    賬號：

    <input data-title="賬號" placeholder="請輸入正確的賬號" pattern="\w{6,10}" name="account" type="text" required />

    <span class="f-tips">請輸入正確的賬號</span>

    <br />

    密碼：

    <input data-title="密碼" placeholder="請輸入正確的密碼" pattern="\w{6,10}" name="password" type="password" required />

    <span class="f-tips">請輸入正確的密碼</span>

    <br />

    <input name="button" type="submit" value="提交" />

</form>



掃一眼，嗯，挺簡單的，都是常用的東西。咦，不對，這個 pattern 是什么東西？



在這里我們重點分享下 pattern 這個屬性，這是一個用來驗證 input[value] 是否合法的屬性，里面的內容就是匹配value的，語法便是正則的語法，例子如下：



<label>

    <!--

當前pattern的內容就是驗證input[name="part"]的value的，其規則如同里面的正則一樣，匹配input[name="part"]的value是否是一個數字+3個大寫字母

-->

    <input pattern="[0-9][A-Z]{3}" name="part" />

</label>



當然，不同的 input[type] 也會默認帶有相應的 pattern ，例如 input[type="email"] 就是默認匹配了以下規則：



/^[a-zA-Z0-9.!#$%&'+\/=?^_`{|}~-]+@a-zA-Z0-9?(?:.a-zA-Z0-9?)$/

1

第二步：重點功能

input[type="text"]:invalid ~ input[type="submit"],

input[type="password"]:invalid ~ input[type="submit"] {

    display: none;

}

input[required]:focus:invalid + span {

    display: inline;

}

input[required]:empty + span {

    display: none;

}

input[required]:invalid:not(:placeholder-shown) + span {

    display: inline;

}



上面便是核心交互的實現。



首先第一個class就是保證了在兩個輸入框不通過的時候隱藏，就是當輸入框值為空或者不符合驗證規則，則隱藏提交按鈕。



第二個，第三個class則是控制當用戶在輸入框輸入內容時，如果不符合驗證規則，則顯示錯誤信息，否則則隱藏。



第四個class則是用過 placeholder 是否存在來控制錯誤信息的顯隱，如果 placeholder 不顯示，則證明用戶正在輸入，錯誤信息則根據用戶輸入的值來判斷是否顯隱，否則則隱藏。



狀態切換

上面我們有提到一個選擇器 :indeterminate ，這個是用于選擇狀態不確定的表單元素與 <progress> ，玩過掃雷的人都知道，右擊除了可以選擇紅旗，還可以選擇問號，就是選中，但不確定；又跟 promise 的 pending 狀態類型，介于 resolve 與 reject 之間。



多了 :indeterminate 會給我們帶來很多很有趣的體驗。



首先我們來看看它的使用案例。



基礎使用法

先看效果







代碼如下：



<style>

    body {

        background: #333;

        color: #fff;

        padding: 20px;

        text-align: center;

    }

    input {

        margin-right: .25em;

        width: 30px;

        height: 30px;

    }

    label {

        position: relative;

        top: 1px;

        font-size: 30px;

    }

</style>

<form>

    <input type="checkbox" id="checkbox">

    <label for="option">點擊左邊</label>

</form>

<script>

      'use strict';

      checkbox.addEventListener('click', ev => {

        if (ev.target.readOnly) {

          ev.target.checked = ev.target.readOnly = false;

        } else if (!ev.target.checked) {

          ev.target.readOnly = ev.target.indeterminate = true;

        };

      });

</script>



這里面其實沒有什么復雜的實現，只是做了個中間態的判斷，就非常輕松的實現了radio的三種狀態切換。



秀到頭皮發麻法

先看效果







（此天秀效果來自于 Ben Szabo 的 codepen，有興趣的可以仔細研究下，我何時才能有大佬這么優秀，嚶嚶嚶~）



輸入框綁定的可選值

先看效果







其實代碼很簡單：



<input type="text" list="names" multiple />

<datalist id="names">

    <option value="kris">

    <option value="陳大魚頭">

    <option value="深圳金城武">

</datalist>



<input type="email" list="emails" multiple />

<datalist id="emails">

    <option value="chenjinwen77@foxmail.com" label="kris">

    <option value="chenjinwen77@gmail.com" label="kris">

</datalist>



<input type="date" list="dates" />

<datalist id="dates">

    <option value="2019-09-03">

</datalist>



這里原理就是通過 <input list="dates" /> 來綁定需要下拉顯示的數據列表 <datalist id="dates"> 。



那么當我們要實現輸入聯想的時候，也可以通過修改 <datalist id="dates"> 的子元素來實現，而不是再寫一大堆的操作函數來實現。



總結

JS----預編譯及變量提升詳解

JS屬于解釋型語言，在執行過程中順序執行，但是會分塊先預編譯然后才執行。因此在JS中存在一種變量提升的現象。搞懂預編譯環節，變量提升自然而然也就懂了。本文講圍繞以下幾點進行介紹（變量提升會穿插在其中講解）：



預編譯執行步驟

示例演示



預編譯執行步驟

預編譯發生在函數執行的前一刻，過程如下：



創建AO對象，執行期上下文（后面更新關于執行期上下文詳解）。

尋找函數的形參和變量聲明，將變量和形參名作為AO對象的屬性名，值設定為undefined.

將形參和實參相統一，即更改形參后的undefined為具體的形參值。

尋找函數中的函數聲明，將函數名作為AO屬性名，值為函數體。



至此，預編譯環節結束，函數中咯變量按照最終AO對象中的值開始執行。接下來，結合示例演示就會更加清晰。



作者：北海北方

鏈接：https://juejin.im/post/5aa6693df265da23884cb571

來源：掘金

著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。



示例演示

我們先來看下面這段代碼：

function fn(a){

console.log(a);

var a = 123;

console.log(a);



    function a(){};

    console.log(a);

    

    var b = function(){};

    console.log(b);

    

    function d(){};

 }

 

 //調用函數

 fn(1);



作者：北海北方

鏈接：https://juejin.im/post/5aa6693df265da23884cb571

來源：掘金

著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

接下來我們來按照前面的步驟詳細分析它的預編譯執行過程：



創建AO對象



AO{

    //空對象    

}

復制代碼

找形參和變量聲明



AO{

    a : undefined,

    b : undefined

}

復制代碼

形參和實參相統一



AO{

    a : 1,

    b : undefined

}

復制代碼

找函數聲明



AO{

    a : function a(){},

    b : undefined,

    d : function d(){}

}

復制代碼預編譯環節就此結束，此時的AO對象已經更新為：

AO{

    a : function a(){},

    b : undefined,

    d : function d(){}

}

復制代碼函數開始逐行順序執行：

 function fn(a){

    console.log(a);// 輸出functiona(){}

    var a = 123;//執行到這里重新對a賦，AO對象再一次更新

    console.log(a);// 輸出123

    

    function a(){};//預編譯環節已經進行了變量提升，故執行時不在看這行代碼

    console.log(a);// 輸出123

    

    var b = function(){};//這個是函數表達式不是函數聲明，故不能提升，會對AO中的b重新賦值

    console.log(b);//輸出function(){}

    

    function d(){};

 }

復制代碼至此，函數執行完畢，銷毀AO對象。

我們再來看幾個例子，熟悉函數的預編譯過程。

示例一：

function test (a,b){

    console.log(a);

    c = 0;

    var c;

    a = 3;

    b = 2;

    console.log(b);

    function b(){};

    function d(){};

    console.log(b);

} 

//調用函數

test(1);

復制代碼它的AO創建過程如下(此處省略創建空AO對象的部分，下文同)：

AO1{

    a : undefined,

    b : undefined,

    c : undefined

}



AO2{

    a : 1,

    b : undefined,

    c : undefined

}



AO3{

    a : 1,

    b : function b(){},

    c : undefined,

    d : function d(){}

}

復制代碼至此預編譯環節完成，開始執行：

function test (a,b){

    console.log(a); //輸出1

    c = 0; //給AO對象中的c重新賦值0

    var c;//預編譯環節變量提升，不再讀此行代碼

    a = 3;//給AO對象中的a重新賦值3

    b = 2;//給AO對象中的b重新賦值2

    console.log(b);//輸出2

    function b(){};//預編譯環節變量提升，執行時不再讀這行代碼

    function d(){};//預編譯環節變量提升，執行時不再讀這行代碼

    console.log(b);//輸出2

} 

//調用函數

test(1);



復制代碼示例二：

這個例子中我們引入全局對象GO。GO與AO的過程類似

function test(){

var a = b = 123;

}

test();

復制代碼此函數的執行過程：先把123賦給b,再聲明a，再把b賦給a。此時變量b未經聲明就賦值，為全局變量。預編譯環節如下：

GO1{

b : undefined

}

AO1{

a : undefined

}



GO2{

    b : 123;

}

AO2{

    a : 123;

}

復制代碼示例三 ：

console.log(test);

function test(test){

   console.log(test);

   var test = 234;

   console.log(test);

   function test(){};

}

test(1);

var test = 123;

復制代碼我們來看它的預編譯過程：

//執行前（頁面加載完成時）生成GO對象

GO1{

    test : undefined

}

GO2{

    test : function(){}

}



//輸出 function test(){...}



//執行test()前生成它的AO對象

AO1{

    test : undefined

}

AO2{

    test : 1

}

AO3{

    test : function test(){}

}



//預編譯結束開始執行test(1);

AO4{

    test : 234

}

//輸出234

復制代碼示例四：

function demo(){

    console.log(b);

    if(a){

        var b = 100;

    }

    console.log(b);

    c = 234;

    console.log(c);

}

var a;

demo();

a = 10;

console.log(c);

復制代碼我們來看它的預編譯過程：

//首先是全局對象GO 

GO1{

    a : undefined

}

G02{

    a : undefined,

    demo : function demo(){}

}

//執行demo（）前預編譯,由于demo中的c未聲明就使用故為全局對象



//輸出undefined

GO3{

    a : undefined,

    demo : function demo(){}

    c : undefined

}

//此時a還是undefined，故不執行if()代碼塊

//輸出還是undefined

GO4{

    a : undefined,

    demo : function demo(){}

    c : 234;

}

//輸出234

GO5{

    a : 10,

    demo : function demo(){}

    c : 234;

}

//輸出234

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

在我看來，界面設計的視覺層面主要可以分為三個維度來解析：信息傳遞、視覺美化、創意創新。

在做交互文檔之前，我們先要明白什么是交互文檔、為什么要做以及做了給誰看。

一、什么是交互文檔 

交互文檔，即交互設計說明文檔。英文 Design Requirement Document ，簡稱DRD。主要是用來承載設計思路、設計方案、信息架構、原型線框、交互說明等內容。

二、為什么需要交互文檔          

有些人可能對文檔這種東西比較反感，尤其是從事工作不久的朋友。其實工作得越久，越會發現文檔的重要性，它可以幫助你理清思路，并記錄下來，便于回顧。

通常，一個比較基礎、規范的交互文檔（DRD）由：文檔封面、更新日志、文檔圖例、設計背景/思路、業務流程、頁面交互、全局通用說明、廢紙簍八部分組成。當然，這不是絕對，你可以根據你的實際工作需要進行增減。

比如，如果是C端產品的話，用戶調研的結論、用戶畫像、用戶體驗地圖等等，都可以放進去給看的人一個參考。尤其是在如今這么關注用戶體驗、產品思維的一個大環境下，這些數據支撐很有力量。同時還可以幫助開發人員、界面設計人員培養產品思維、體驗思維，大家一起將產品變得更好。

其次，交互文檔的整潔與美觀也很有必要。相信在過去幾年不少人有遇到過這樣的產品經理（兼交互），他們會輸出一些有時連他們自己都看不太懂或者直接從其它競品截圖來的線框圖。當開發和界面設計的人提出質疑的時候還美其名曰線框不重要，重要的是里面的業務邏輯。。。其實用產品思維想，交互文檔就是交互設計師的產品，而看的人就是用戶，保持良好的可讀性，可謂至關重要。

1、文檔封面

交互文檔的封面如上圖，通常包括產品的名稱、Logo、版本號以及版本發布時間、所屬部門、對接負責人/對接人。

2、更新日志

我們都知道，在產品的迭代的過程中，需求/功能是會不斷調整的。而更新日志，就是為了迭代而生。它一般由修改日期、修改內容、修改人、版本號和備注組成。如果是新增的功能或模塊，建議是要加上鏈接可直接跳轉至新增內容的，如上圖。

版本號也是同理，都應加上對應的版本鏈接，便于查看者回溯之前的內容，與當前的新版本形成對比。這一點對開發人員來說很重要，其次對于新同事深入理解產品也能起到很大的幫助。

修改日期，通常是按時間倒序排列，查看起來會比較方便。

3、文檔圖例

文檔圖例，顧名思義就是關于此文檔的一些輔助說明，目的是為了讓讀者更好地理解文檔。如上圖的：操作/跳轉圖例、標簽圖例、流程圖例以及手勢操作圖例。

4、設計背景/思路

因為我今年對接最久的是一個B端產品的項目，所以整理了一個產品畫像，僅供參考。

5、業務流程

業務流程圖，不是操作流程圖也不是頁面流程圖。它是產品的整體業務流程，直接和業務掛鉤，可以說是產品的核心流程。

例如淘寶APP，買家購物由始至終的流程就是它的業務流程。通常用泳道圖的形式展示，多數情況下是由產品經理繪制。

以上是我所負責產品的核心業務的流程圖。因為是B端產品，涉及角色較多，針對3個代表性角色分別進行了繪制，僅供參考。(涉及到保密協議，所有關鍵詞都去掉了)

6、頁面交互

（1）信息架構

信息架構屬于用戶體驗的結構層，是產品的骨架。一般是由產品經理或者更高層的管理人員給出大框架。除非是大的產品迭代，否則不會大改。

（2）權限說明

如果是C端產品，權限這一塊相對簡單，比較好整理的。B端產品涉及角色眾多，可能要單獨拎出來分析整理。以上僅供參考，大家具體情況具體分析。若是功能很單一的產品，交互文檔中也可省去這個模塊。

（3）操作流程圖

產品操作流程圖就是通過圖形化的表達形式，闡述產品在功能層面的邏輯和信息。它能夠更清晰、直觀地展示用戶在使用某個功能時，會產生的一系列操作和反饋的圖標。

上圖是登錄、注冊和找回密碼的操作流程圖。僅供參考。模板源文件下載，后臺回復“交互”即可。

（4）頁面線框圖

頁面線框圖，是通過圖形化的表達形式，闡述產品在頁面層面的信息。包括： 

【頁面標題】即每一個頁面的對應標題，一般就是導航欄標題

【頁面內容】以黑白為主，保證信息規整易讀

【交互說明】用標簽將其對應起來，包括交互邏輯、操作流程及反饋、元素狀態、字符限制、異常/特殊狀態、相關規則 等等

【主流程線】只需要畫出主流程線即可，千萬不可太多太雜，時刻考慮讀者的感受

以上是注冊/登錄的線框圖和詳細的交互說明。將重點內容用紅色標記，可以讓查看者一目了然更好理解文檔。

7、全局通用說明

（1）常用控件

常用控件類似UIKit，通常將極具復用價值的控制整理在一起，方便及時調用。

（2）復用界面

（3）時間規范

（4）缺省頁匯總

五、總結

文檔、軟件只是工具，最重要的還是要落地、實行起來才能對產品有所幫助。所以在撰寫文檔的每時每刻，都應該站在“讀者”的角度思考，他們看的時候感受會是怎樣的，會覺得很難理解嗎？

轉自-站酷

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

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

圖標是 UI 設計中極為重要的一個環節，我們在做每個界面的設計幾乎都會涉及到圖標的表達，出色的圖標設計可以讓界面表達更加精致、有趣。圖標的設計往往也體現著設計師的基本功，因此除了日常多畫提升對圖標造型的把控力外，我們也更需要了解和學習圖標設計的趨勢類型，從而幫助我們提高在設計中的效率。

基于自我學習的目的，平時在瀏覽一些設計網站時也會做相對應的收集。因此本文主要對于圖標設計的 「類型、風格」 進行了整理，以及自己對于每種圖標類型的思考。

圖標的類型劃分

設計網站上的圖標可以說是多種多樣，不同類型的圖標都有著獨特的魅力。例如，線性圖標簡潔輕量、面性圖標厚重直接，當然同一種類型的圖標也具有很多不同的表現形式。

因此基于本人對圖標的理解，大致劃分為三類：線性、面性、線面結合。結合三種基礎類型的表達方式可以創造出各式各樣的表現形式。

線性圖標

使用輕量的線條勾勒的圖標，整體感受也趨向于精致、細致而具有銳度感。不同的線條表現具有不同的視覺感受，細線輕量、直線硬朗、曲線柔美。

1. 線型圖標基礎分析及想法

粗細對比

粗細不同，圖標的力度和重量感就會有差異。粗線的圖標，視覺關注力來說會更加突出，但較于細線的圖標也會顯得粗壯、厚重。細線的圖標，精致、透氣、秀美。

但在設計時需要依據 「整體的 UI 風格」 來決定線的粗細，而并非單純的考慮圖標的關注度，反而更需要考慮圖標與界面整體的平衡感。

柔度對比

直角與圓角決定了外形的感知和風格的走向，如下圖對比中看出，圓角越大圖形越趨向于可愛柔美（如下右圖），圓角越小則越直接、硬朗和陽剛（如下左圖）。因此剛或柔或中間值完全取決于早期對于整體風格的定調。

繁簡對比

除了輕量化和簡潔之外，圖標的識別性也是極為重要。如下左圖，「過度簡潔」 導致圖標失去該有的識別度而出現歧義，而下右圖的元素疊加使得圖標稍顯復雜。在繁與簡的平衡中，應該保持在不影響圖標識別度的情況下，最大限度的提升圖標的簡潔程度。

特征的識別度

除了簡潔程度，也需要考慮圖標該有的特征。例如下圖 「評論」 圖標的案例，當我把圖標中的「三個點」 去掉時，圖標依舊具有 「對話/評論」 的表意，而當我把下面的 「箭頭」 去掉保留 「三個點」 時，則會出現歧義，它可以被表意為 「更多」 的意思，因此在設計圖標時需要對于表意做精準把握，避免歧義出現。

保持圖標的特征美感

如下面的 「心形」 圖標，下左圖是我們具有普識性的圖標，與圓形組合之后依然保持著原有的形態美感。但我們不時也會看到第三種設計，整體外形雖然保持著愛心，但為了與整體風格「一致」 強行對外輪廓進行切割，與原圖形在美感上則稍微有些出入，這也是我們需要思考的關鍵點。

組合型比例

組合型的比例會影響到圖標的精致程度，準確的 「比例值」 能讓整體的造型趨向平衡，更具有美感。如下圖案例嘗試了兩組不同比例的效果，這里以圖標窄邊作為 「基準值」 進行嘗試。當內形為外形的 1 : 2 時（下圖2），圖標的整體視覺效果較為平衡；當大于 1 : 2 并接近 4 : 3 時，圖標內部結構會顯得過于飽滿。而小于 1 : 2 并接近 4 : 1 時（下圖3）則會產生稀疏不緊湊的效果。（這里的比例只是案例需要，實際設計以最終的視覺感知為準）

2. 線性類型拓展

基礎的理論，結合延展的應用，可以迸發出更多的創意想法。線形圖標也并非只有一種設計形態。通過以下案例，可以看看線型圖標設計類型的多樣性。

極簡風格

整體風格極為簡約，沒有多余的線條，通過線條還原圖形的本質，外形 「簡單」 卻具有很強的識別性，在視覺感知上輕松、干凈。

極簡的風格圖標在于對圖形的把控，多一筆可能顯得復雜，少一筆可能影響識別程度。以上圖為例，圖標的組合元素保持在 2 個左右，整體較為干凈。

實際應用：Instagram、Airbnb、Facebook、Twitte

雙色

相較于 「純色的圖標」 更具表現力，細節上也會更加豐富，形態感知上多了一層變化。結合顏色的疊加、對比、互補提升了圖標的層次感和豐富度。

同色系：同為冷色系、暖色系或同一色系的表達形式。如下圖案例，以暗色為主色，亮色點綴提亮，使得圖標具有一種高光提亮的感覺。

另一組案例是亮色主色結合暗色，整體圖標效果還算可以，但較亮的顏色沒有應用在圖標的關鍵特征上，使得圖標第一眼的感知稍有減弱。

對比互補色：顏色跨度更大，層次更加分明。如下圖案例，紅色與藍色的撞色之后相比單色的圖標更加出彩和具有記憶點。

實際案例：騰訊動漫我的頁面

透明度變化

本質上與上面一種為一個類型的設計，通過透明度的疊加和變化，提升圖標的層次感和空間感，降低圖標的壓迫性。

實際案例：愛奇藝9宮格圖標

漸變層次疊加

漸變帶出了圖標的質感，結合「不同深度」或「不同飽和度」的變化，讓圖標更具有細節和層次。

黑白+品牌色

黑白色作為主色調，結合品牌色作為點綴色。與常規的黑白圖標相比，既產生了變化，同時兼顧了品牌色的透出。

實際案例：大眾點評攻略頁面圖標

線性漸變

結合漸變的顏色，豐富了整個圖標的視覺表達，并提升了圖標的視覺沖擊力和設計感。案例結合黑白背景作為嘗試，白底：粗線比細線的視覺效果相對較好，漸變也能較為清晰地被表達；黑底：細線比粗線的視覺效果顯示得更加精致和具有銳度感。

實際案例：網易考拉、NAVER

一筆成形

此類圖標在視覺表達上具有較高的線性流暢度和設計感，關注點在于整組圖標的 「開口起始點」 設定上需保持一致。例如，「從左到右」或「從右到左」形成一體化的連貫線條，開口起始點不一致會影響整組圖標的一致性，應用在頁面時也會顯得雜亂。

斷點圖標

與上一種較為類似，但沒有連貫度的要求。在線形圖標基礎上面，尋找一個缺口來打破 「全包邊圖標」 的沉悶感，使得圖標具有透氣性和線條的變化。缺口的位置盡量保持統一的方向及大小，另外需要控制開口個數避免過多導致圖標外形過于零碎。

實際案例：騰訊體育、京東

面性圖標

面性圖標比線性圖標更能表達出圖標的力量感和重量感，比線性圖標會更加容易吸引用戶目光。在識別度上，面性圖標更加依賴于外輪廓的清晰度，因此在設計時對于外形的打磨是重中之重，清晰的外輪廓可以幫助提高識別度。

1. 面型圖標基礎分析及想法

輪廓對比

輪廓的差異會體現出不同的氣質，如下圖的左邊和右邊的區別，一個氣質較為直接硬朗，另一個則較為柔美可愛。流暢的外形可以讓面形圖標的整體更加簡潔、規整，如下圖中間的圖標在輪廓的處理上則顯得比較碎，整體外輪廓造型的連貫度有所欠缺。

鏤空對比

適當的鏤空除了補充了圖形的識別度之外，還提升了面性圖標的設計細節。另外需要控制好鏤空部分與整體的外形比例，過小或過大都可能影響圖標的平衡感。如下圖的中間和右邊，鏤空過小對圖標的辨識度并沒有多大作用，沒有鏤空則少了一些透氣感。

形體對比

形態上的差異也會具有不一樣的視覺感知。以「星」和「心」為案例，單獨形體與組合之后的形體相比視覺感知更直觀些，而組合形的圖標相對會精致一些，多了一些層次。在日常設計中的經驗是：越小的圖標形體應該越簡單，因此建議單體出現較好；若圖標的尺寸足夠大時可采用組合型的設計，補充圖標的細節。

繁簡對比

設計面性圖標時，對于多余細節的管理也很重要。隨著細節的增加，塊面切割過多，會使得整體圖標變得過于零碎（如下右圖）。保持簡約的設計提高圖標的識別度，在關鍵的特征細節上做補充（如下中間圖的相機閃光燈）。

2. 面性圖標類型拓展

面性圖標在設計時也可以結合各種不同的表達方式，來提升圖標的質感和創意，而非只是簡單的填充顏色。

單色面+點綴色

整體的外形使用統一的顏色，結合圖標的屬性感知使用不同的顏色進行點綴，通過點綴色提亮了圖標的視覺效果，達到既統一又具有差異化。

多彩雙色

通過對比色、鄰近色的搭配來營造整體的圖標氛圍，提升了圖標的層次和豐富度，雙色的表達也增添了圖形的趣味性。在日常使用的 APP 中極為常見，簡單且容易出效果。

微質感漸變

微弱的漸變提升了圖標的質感。漸變的方向會影響整體圖標的視覺效果，因此可以根據不同設計的需要進行調整。如下圖案例：

實際案例：全民K歌

透明度/灰度變化

透明度/灰度的變化，讓原來單色的圖標變得更加具有層次感和空間感，設計細節更加豐富，降低了單色面性圖標的厚重感。

實際案例：企鵝FM我的頁面

透明度變化+漸變

漸變的設計提升了面性圖標的質感，從顏色上具有一定的豐富度。在漸變的基礎上對組合型做透明度差異化，使得圖標具有了層次感。

透明疊加的圖標+漸變的背景

此類圖標常常被應用在 UI 界面中的列表或者頂部入口的位置。

實際案例：全民K歌點歌頁面

顏色疊加穿透

圖標透明疊加之后產生了交錯的負形，疊加出第三個面。雖然整體設計依然保持著扁平化，但卻多了一份層次感，并且增加了圖標的細節。

實際案例：百度網盤

漸變層次疊加

整體的效果與透明度變化的圖標較為接近，通過漸變的深淺變化，使得形狀的銜接處出現了明暗對比，因此圖標也具有了厚度感和層次感。

實際案例：NAVER、掌上生活

高斯模糊

此類圖標基本沒有在 APP 中看到，與「透明度變化」或「顏色疊加」相比都更具層次感和空間感，同時圖標也具有較強的設計感。

線面結合

結合了線性和面性的優點，既保持了面性的重量感，同時具有線性的精致、細膩。因此在設計時可以根據圖標具體想要表達的感覺對線面比例進行把控，不同比例可以呈現出不同的視覺感知。

1. 線面結合圖標的基礎分析及想法

線面比例

線面比例的差異，圖形呈現出來的張力也會有不同的感受?；谥虚g填充的圖標形態嘗試了三種不同的比例，從下圖中可以看出，當填充與外形窄邊比為 1 : 3 時（左圖）圖標呈現往內收的感覺；填充與外形窄邊比為 1 : 2 時（中間）圖標整體較為平衡；當填充與外形窄邊比為 2 : 3（大于1:2）時（右圖）整體具有外擴趨勢。

組合形式

線面可以通過不同的組合形式進行繪制?；诓煌慕M合形態可以設計出多種多樣的線面圖標，不同的組合形式會體現出不同的設計風格，因此在設計時盡量多發散思考，尋找出適合你的組合方式。

繁簡對比

線面結合本身就由兩種形式組合，因此在設計的時候更需要對整體造型進行把控，單體（線和面）造型必須保持較高的簡潔程度，這樣最終組合形成的圖標才不會過于復雜（左圖），若本身形態過于復雜，則會降低圖標的辨識度和視覺美觀度。

2. 線面結合圖標類型拓展

線面結合的圖標集合了線性和面性的優點，在設計方式上也繼承了兩者的優點。設計方式也是基于以上兩種的結合，因此可以結合出更多設計的可能性。

黑白線+面性品牌色

與「線性+品牌色」的做法較為接近，統一的線性顏色疊加品牌色的透出。

實際案例：好好住、soul

線面雙色

基于線面的基礎上，在線和面的顏色上做差異。具體做法與線性或面性的雙色接近。

線面結合-陰陽

線和面的結合按 50% 的比例進行設計，依據上下、左右、居中等基礎方式的結構化設計，整體圖標的視覺效果較為跳躍，非常規。

線面雙色+錯位

在雙色圖標的基礎上，線和面按照統一的 「百分比」 進行縮放，并進行透視和位移的設計，整體呈現出來的是一種交錯疊加的視覺效果，相比普通的線面雙色更加豐富。

實際案例：閑魚底部tab、臉球底部tab

線面錯位+漸變

基于上一種風格，對面或者線的顏色進行漸變設計，豐富了圖標的質感和顏色更加細膩。

線面透明度變化

與「線面透明度變化」的設計方式大致一樣。如下圖案例，「弱線強面」的第一識別度較弱，而「弱面強線」 的外形識別度較高，也更符合圖標的表達。

實際案例：新浪微博、騰訊新聞

基于三種基礎的類型表達，可以拓展出多種多樣的設計形式。除了以上的案例之外，還收集了一些其他的設計。

線面結合 – 插畫

整體比較偏向插圖的感覺，細節和元素較多，常見于一些 APP 的空白頁設計。

線面結合 – 卡通插畫

整體感覺比較可愛、卡通、二次元，常見于一些二次元或漫畫類的 APP。

面性 – 漸變強質感

整體風格的光影質感會比較強烈，常在一些活動運營或小游戲的界面出現。

面性 – 扁平寫實

整體感覺比較扁平，細節的豐富度與現實感知接近。

線面+漸變插畫

整體風格比較偏向絢麗多彩的顏色風格，質感和細節較為豐富。

寫實風格

3D質感圖標

由于 C4D 的制作成本相對較高，目前較少在常規的 APP 中看到。但 3D 作為一個主流的設計趨勢，在時間和能力允許的情況下需要多做這方面的嘗試。

等距的線面結合

等距的設計，讓原本線面的圖標豐富了層次，并具有立體透視的感覺。

除了以上這些之外，我們在實際場景中也會發現一些較為特別的圖標設計。

Facebook 更多頁面的列表圖標

整體風格偏向插畫風+漸變質感。由于更多的頁面為純列表的設計，因此整個頁面在圖標的設計上做了很大膽的嘗試，與常規的單色圖標相比更具有吸引力。為了區別不同的業務，系統性質的功能圖標做了色調的區分。

APP Store 游戲和新APP界面下的類別列表圖標

整體為具象化扁平風格的設計表達，圖標的顏色還原了最基本的現實感知。

iOS 系統辦公類軟件的起始頁面圖標

整體風格比較偏商務簡約，具象的圖形表達+輕微的漸變質感。

QQ手機版中延展的功能圖標

整體風格偏向輕寫實+微弱漸變。每個圖標都具有豐富的細節表達，色調方面基于業務屬性結合品牌色進行了區分，整體既統一又具有差異化。

大眾點評頂部入口的圖標

整體風格偏向寫實+強漸變+炫光感，每個圖標都具有豐富的細節表達。

旅法師營地

游戲、二次元類的 APP，因此在圖標的設計上也偏向細節較為豐富的插畫風格。

嗶哩嗶哩動漫

圖標風格偏向卡通插畫，選中態與默認態的設計較為巧妙。

總結

本文的重點在于透過這些設計類型或者技法的了解，幫助我們在日常設計中提升輸出效率。圖標雖然作為 UI 設計的基礎，卻有很深的學問，精致的圖標更是可以起到點睛的作用，提升界面的質感和氛圍。

圖標的種類遠遠不止本文所提到的這些內容，但是萬變不離其宗，都是「線性、面性、線面結合」 再結合 「透明度、漸變、顏色疊加、質感、多維空間」等等的表達方式而設計出來的。

我們除了需要掌握這些內容之外，還需要提升圖標設計的造型能力，更需要日積月累的練習和思考，從量到質的變化。

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

nodejs中使用別名映射,兼容webpack的@和best-require 的:xxx 別名映射

項目地址: https://github.com/langyuxiansheng/biu-server-admin



寫在前面

研究了很久,找了很多資料發現都沒有,只好自己去想辦法,查資料.才弄好的,凌晨發布的,轉載請注明出處.

在做nodejs項目開發的時候,你是不是也在為

require('./posts');

require('./controllers/posts');

require('../controllers/posts');

require('../../controllers/posts');

require('../../../apis/controllers/posts');



或者



require(ROOT_PATH + '/application/apis/controllers/posts');

// other require()...

require(ROOT_PATH + '/application/apis/controllers/users');

require(ROOT_PATH + '/application/apis/controllers/products');

require(ROOT_PATH + '/application/apis/services/rest');

require(ROOT_PATH + '/application/apis/config');



這樣的寫法而困擾;



那看完這篇文章,從此之后就可以告別這個煩惱了;



感謝一下 best-require 這個模塊包的作者,不然還需要自己去寫這個

npmjs 鏈接 https://www.npmjs.com/package/best-require

github 鏈接 https://github.com/yuezhihan/best-require



不廢話了,進入正題 往下看:

1. 安裝庫 best-require 進行別名映射
   
   
   
   
   
   npm i best-require --save
   
   
   
2. 映射別名. 實例在本項目中 server/index.js 中
   
   
   
   
   
   const path = require('path');
   
   const ROOT_PATH = process.cwd();
   
   const SRC_PATH = path.join(ROOT_PATH, /server/src);
   
   console.log(ROOT_PATH, SRC_PATH);
   
   //映射目錄別名
   
   require('best-require')(ROOT_PATH, {
   
       root: ROOT_PATH,
   
       src: SRC_PATH,
   
       controllers: path.join(SRC_PATH, '/controllers'),
   
       models: path.join(SRC_PATH, '/models'),
   
       routes: path.join(SRC_PATH, '/routes'),
   
       crawlers: path.join(SRC_PATH, '/crawlers'),
   
       services: path.join(SRC_PATH, '/services'),
   
       middleware: path.join(SRC_PATH, '/middleware'),
   
       lib: path.join(SRC_PATH, '/lib'),
   
       config: path.join(SRC_PATH, '/config'),
   
       logs: path.join(SRC_PATH, '/logs')
   
   });
   
   
   
   //運行服務
   
   require('./src/bin/Server').run();
   
   
   
3. 設置 jsconfig.json
   
   
   
   
   
   {
   
       "compilerOptions": {
   
           "allowSyntheticDefaultImports": true,
   
           "baseUrl": "./",
   
           "paths": {
   
               "@/": ["client/"],
   
               ":root/": [""],
   
               ":config/": ["server/src/config/"],
   
               ":lib/": ["server/src/lib/"],
   
               ":services/": ["server/src/services/"],
   
               ":controllers/":["server/src/controllers/"],
   
               ":models/": ["server/src/models/"],
   
               ":routes/": ["server/src/routes/"],
   
               ":crawlers/": ["server/src/crawlers/"],
   
               ":middleware/": ["server/src/middleware/"],
   
               ":logs/": ["server/src/logs/"]
   
           }
   
       },
   
       "include": ["server/*/","client/*/"],
   
       "exclude": [
   
           "node_modules",
   
           "nuxt-dist",
   
           "server-dist"
   
       ]
   
   }
   
   
   
4. vscode要安裝 path-intellisense 插件 并在設置中配置setting.json
   
   
   
   vscode 中的設置,setting.json
   
   
   
   workspaceRoot 是當前的工作空間,就是當前編輯器打開的目錄.
   
   
   
   配置如下
   
   
   
   
   
   {
   
       "path-intellisense.mappings": {
   
           "@": "${workspaceRoot}/client",
   
           ":root": "${workspaceRoot}",
   
           ":lib": "${workspaceRoot}/server/src/lib",
   
           ":controllers": "${workspaceRoot}/server/src/controllers",
   
           ":models": "${workspaceRoot}/server/src/models",
   
           ":routes": "${workspaceRoot}/server/src/routes",
   
           ":crawlers": "${workspaceRoot}/server/src/crawlers",
   
           ":services": "${workspaceRoot}/server/src/services",
   
           ":middleware": "${workspaceRoot}/server/src/middleware",
   
           ":config": "${workspaceRoot}/server/src/config",
   
           ":logs": "${workspaceRoot}/server/src/logs",
   
       }
   
   }
   
   
   
5. 重啟vscode,試試看吧!
   
   作者的目錄結構
   
   
   
   
   
   
   
   
   
   vue中使用
   
   
   
   
   
   
   
   后續更新
   
   nodejs中使用sequelize的model映射,這樣就解決了沒得提示的煩惱了,讓你的效率提升2個檔次
   
   寫在后面
   
   如果你遇到難題或者有疑問,有好的建議請留言反饋.
   
   這種提示以及Ctrl + 鼠標左鍵的跳轉,只針對 .js 的文件, .vue的沒試過.這個也只是為了解決 js方法映射后沒提示的問題.
   
   
   

vue 生命周期

每個 Vue 實例在被創建時都要經過一系列的初始化過程。設置數據監聽、編譯模板、掛載等等。vue生命周期還是不太容易理解，這里就簡單地說一下它的整個過程。

1創建一個vue實例



new vue({

data () {

return {

}

    }

})



2 初始化事件和生命周期 beforeCreate 創建實例之前執行的鉤子函數

3 初始化·注入和校驗 created 實例創建完成后執行的鉤子



new vue ({

data () {

return {

a: 1

}

},

created: function () {

console.log('created')

}

})



4 渲染頁面 編譯 beforeMount 將編譯完成的html掛載在虛擬dom時執行的鉤子

5 mouted鉤子 掛載完畢對數據進行渲染 會做一些ajax情求初始化數據 mounted整個實例過程中只執行一次



new vue ({

data () {

return {

a: 1

}

},

created: function () {

console.log('created')

},

// 一些鉤子函數

mouted: function () {

console.log('mounted')

}

})



6 修改數據 beforeUpdate 更新之前的鉤子

7 updated 修改完成重新渲染

8 準備解除綁定子組件以及事件監聽器 beforeDestroy

9 銷毀完成 destroyed

css:

*{margin:0;padding:0;}

tu{margin: 50px auto;padding: 10px;width: 500px;

background: rgb(201, 230, 128);text-align: center;}



html:



<body>

    <div id="tu">

        <P id="info"></P>

        <img src="jiao.jpg" alt="冰棒">

        <input type="button" id="yi" value="第一張">

        <input type="button" id="er" value="第二張">

    </div>

</body>



javascript:

window.onload = function(){

var yi = document.getElementById(“yi”);

var er = document.getElementById(“er”);

var img = document.getElementsByTagName(“img”)[0];

var imgArr = [ “jiao.jpg”,“san.jpg”,“bao.jpg”,“hua.jpg”,“pei.jpg”,“tu.jpg”,“xin.jpg”,“niu.jpg”]

var index = 0 ;

var info = document.getElementById(“info”);



    info.innerHTML = "一共" + imgArr.length + "張圖片,當前第"+(index+1)+"張";

    yi.onclick = function(){

        index--;

        if(index < 0){

            index = imgArr.length - 1; 

        }

        img.src = imgArr[index];

        info.innerHTML = "一共" + imgArr.length + "張圖片,當前第"+(index+1)+"張";

    }



    er.onclick = function(){

        index++;

         if(index > imgArr.length - 1){               

            index = 0; 

        }

        img.src = imgArr[index];

        info.innerHTML = "一共" + imgArr.length + "張圖片,當前第"+(index+1)+"張";

    }

}

本文是基于我對《破繭成蝶2》讀后的觀點和反思，自己的項目經歷跟作者相似，也是為了更好的總結這兩年對產品、對設計的心得。

本文篇幅較長，請耐心閱讀。主要是總結一個完善的體系，便于大家理清自己的設計思路和自我定位。

閱讀本文你可以獲得什么？

一、前言——擁抱變化，破熵而行

二、產品設計師的思維轉變

三、對設計師的能力模型

四、設計師該關注的數據

五、產品周期影響設計策略

六、設計師順勢而為，自我定位 

一、前言——擁抱變化，破熵而行

在人口紅利、流量紅利、資本紅利逐漸消退的互聯網下半場，從“買流量、買用戶”為代表的粗放式發展進入了穩扎穩打的精細化時代，需要考慮在有限的資源及能力的基礎上精打細算、量入為出，讓產品可持續地發展下去。

互聯網產品正在從標準化、大眾化轉向個性化。針對垂直領域或細分用戶群體的產品越來越有市場。戰略層也需要抽絲剝繭，拋去形式注重產品的本質。比如一些下沉型電商業務，紅包和會員都只是一種形式，其實本質還是用戶追求“性價比”有利可圖，所以一旦用戶的“便宜需求”難以達到，還是會引發數據的下降，這就需要大量可持續資本投入維持。見利期的變長，傳統電商行業的鋒芒也被新零售掩蓋，投資人也不斷轉移更創新可收的項目。所以真正的留存是可持續發展的，且需要根據企業自己的實際情況，在戰略上和運營上，有一個人無我有的本質上的創新點（核心競爭力），而非形式上的創新。

在日新月異，變化百態的互聯網下半場，創業者和產品設計工作者都需要改變自己的想法，擁抱變化破熵而行，保持自己戰斗力，用更科學客觀的方法來提升產品價值。

二、產品設計師的思維轉變

產品設計師的重要標志是“以產品為中心”的思維及覺悟，即能打破本位主義，站在產品的角度，從整個項目閉環上協同解決問題，提升產品價值。設計師的角度理解，就是打開自身格局，擴展上下游的知識，通過自己的綜合能力助力于業務。在此過程中職能會有跨界，比如我會提出驗證數據的方法，比如ABtest，從業務角度推設計可以通過哪些數據進行提升，然后做出不同方案進行評審，推動項目實施落地。

產品設計者可以由產品經理，UX，UI擔當或轉變，我更傾向是全棧的UX，通過思想認知的轉變，職能界線的打破來扮演這個角色。自己也是這樣努力的在轉型。得益于公司的開放包容，這兩年我還是能承擔起這樣的角色，建立組織，帶領團隊，通過設計來提升產品價值。對于產品設計師，第一個需要改變的就是產品設計思維。

2.1從“問題驅動”到“價值驅動”

2.2 始終貫徹精益思維

互聯網寒冬，連阿里都要把錢花在刀刃上。阿里8月15日發布的財報上，雖然新零售收入水平同步增速高達134%，高于上一季度132%，成阿里本季營收增長引擎，但是阿里本財季對盒馬新零售業務投入仍然十分謹慎。最近兩個季度盒馬開始由原先的大門店業態轉向更多元、成本更低的小業態的轉型期，本財季內凈增門店僅為15家。所以需要我們始終貫穿精益思維去做產品。

精益思想（Lean Thinking）源于20世紀80年代日本豐田發明的精益生產（Lean Production）方式，精益生產方式造成日本汽車的質量與成本優勢，曾經壓得美國汽車抬不起頭。世界汽車工業重心已向日本傾斜。精益思想的核心就是（消除浪費）以越來越少的投入——較少的人力、較少的設備、較短的時間和較小的場地創造出盡可能多的價值；同時也越來越接近用戶，提供他們確實要的東西。

那么要做到產品上的精益思維，一方面要貫徹“以提升產品價值為目標”并用數據驗證；另一方面建議先用較小成本在小渠道驗證，然后在擴大投入。

整個產品團隊，不管是產品負責人、產品經理、設計、運營、開發都需要緊密聯合在一起，為提升產品價值而努力。為什么這么說，其實本質上大家都是為了業務好，但是每個人卻扛著不一樣的KPI，產品經理有業務指標，運營有運營指標，設計師也有自己的設計價值觀。如果大家都只為了自己，產品和運營會唯業務指標做導向，典型的就是引入大量無法留存的流量，耗費資源，最終對整個產品長期發展并沒有太多價值。對設計師來說，我見過很多設計都很有偏向性，要么就是一味追求好看，感覺業務擋了自己發揮才能，要么一味分析競品和交互，卻給不出有效、有價值的解決方案。其實都不是站在產品價值上看問題，更希望是自己能交出一份滿意的答卷。我自己也在一個電商摸索期犯過類似錯誤，無法忍受一個沒有細節的產品，過多追求設計質量，而其實產品初期，負責人只想著能快速迭代，找到活下去的出路。

2.3以始為終打造數據閉環 

數據閉環就是從你的產品價值目標來拆分你的量化目標，通過設計上線等驗證數據，形成閉環，然后循環優化的這個過程。需要從傳統的“問題驅動”轉變成“價值驅動”，因為解決問題是難以被價值量化的，整個業務發展過程中也會出現很多產品問題需要被優化，我們把“提升產品價值”作為目標就形成了“以終為始”的數據閉環。其實現在大部分企業都是以目標驅動業務的，拆分目標，變成顆粒度目標數據再進行逐步達成，這個過程不是說不去“發現問題-解決問題”，而是需要知道工作要務，“重要緊急”的先做，“重要不緊急”的長期計劃實行，至于用戶體驗上的東西也是要有節奏的去優化。

三、對設計師的能力模型

對設計師的能力模型一直在提出不同的更高要求，無論是哪個大咖提出來的理論似乎都是非常的正確和所需要的，導致很多設計師的恐慌，我是不是要被淘汰了。

其實還是要抓住本質，因人而異看待。設計的能力分布模型，大概分為 “I”型 、“一”型、“T”型。

“I”型為單一型，傳統對設計師的定義就是單一的，領域分的比較細。單一型主要看深度，深度達到一定程度可以成為專家，但是如果淺薄又單一很容易被淘汰。

“一”型為廣博型，廣博型最忌諱的就是成為什么都會卻什么都不精的“萬金油”，看似什么都懂，結果做起來什么都廢。

新型模式“T”型，“T”型既有較深的專業知識，又有廣博的知識面，這類是集深與博于一身的人才，也是市面上最有市場的一類。

綜合性人才都是需要一個長期由深度到廣度，再由廣度到深度循環提升的過程，在此過程中也很容易迷失，跟“I”型對比，無法通過有限的時間都提升上去，那么需要掌握一定的方法，認識自我逐步提高。

3.1、強大扎實的專業能力——知行合一 廣而不范

為什么強調專業能力，《破2》里面提到，思維是1，技能是0，話是沒有錯，但是80%以上的設計師還是靠技能在吃飯。有的東西你想得再好無法落地，也是無濟于事。所以一個專業合格的設計師必須有強大扎實的專業能力，當然思維是內驅力，如果你的專業很出色，估計內核也不會差。

首先要有一個專業優勢判斷，然后強化自己的優勢，再根據橫向模型去擴展對自己工作最優幫助的繼續加強，做到廣而不范。比如你是一個ui設計師，你要保證自己的視覺能力，然后去擴展交互能力，其次再去強化動效，體驗等等。再比如你是一個交互設計要保證自己對交互的精通，然后提高用研、數分能力，再去擴展其他能力。還有要做到知行合一，其實大部分我們都在通過不同的學習提升自己的能力，但是要把理論性，縹緲性的知識概念落實到自己的工作中去，努力去實踐，再復盤總結不斷提升自己的實操能力。比如你學了插畫，你的項目上能不能用上；你競品分析了更好的體驗，能不要也變相用到自己的項目里；你新學了一些分析原理，能不能用同樣的思維來分析自己的項目等等。

3.2、保障基礎軟實力 —— 一顆強大正能量的心

心力、腦力、體力，都要保障，尤其是互聯網年輕化后，體力也非常重要，京東就直接把不能加班的員工全開了，多么痛的領悟。那么對于產品設計師其實更關鍵的是心力和腦力，越是高階設計師，思維能力、洞察能力越是重要。無論是ui、ue、還是產品設計師我覺得都需要有強大的自我驅動能力，打破本位主義，不斷擴展自己的專業素質，才能更好的融合于業務。阿里提出：人才是聰明的，的確很多人忽略了先天的差距，事實上同樣的努力，不一樣的天分，總還是有區別的，有的人適合做小兵，有的人適合做將軍，但是你可以保證的是心態，心態里我總結了兩個我覺得非常重要的點，一個就是皮實、一個就是積極，就是有一顆強大而正能量的心！

3.3、先讓自己變得足夠優秀再考慮做管理

對于走技能線還是走管理崗，很多人會想的很多。其實先讓自己變得足夠優秀，不斷提升，一切自然水到渠成。領導者或許需要天分，管理者是每個人都可以成為的，且有一些理論和工具可以支撐的，所以很多團隊會內部提拔，因為培養起來并不難。只要你足夠優秀，還是很有希望做管理，相反過早做管理，自己的基石沒打好，管理起來也會比較艱難。有興趣的人可以去聽一下喜馬拉雅上的《可復制的領導力》。如果你勵志要走向管理層，也可以根據阿里的縱向能力模型對號入座，不斷提升，不過很多時候機遇也很重要。

四、設計師該關心的常規數據

想要驅動產品增長必須要對數據有所了解，來幫助我們產出更貼近用戶行為的設計，同時需要了解數據產生的過程和基礎工具。最基礎的就是產品提出數據，讓開發進行埋點，此過程中設計也可以提出自己想要關心的數據點。公司有后臺可以直接觀測數據，現在也像GrowingIO數據分析產品無需在網站或app中埋點，即可獲取并分析全面、實時的用戶行為數據，需要觀察數據可以直接去后臺關注，也可以讓產品經理或者數據分析師給你拉數據。

頁面瀏覽量（PV）

用戶每1次對網站中的每個網頁訪問（成功訪問/進入）均被記錄1次。用戶對同一頁面的多次訪問，訪問量累計。在一定統計周期內用戶每次刷新網頁1次也被計算1次。理論上PV與來訪者數量成正比，但是它不能精準決定頁面的真實訪問數，比如同一個IP地址通過不斷的刷新頁面，也可以制造出非常高的PV。

獨立訪客人數（UV）

訪問網站的一臺電腦客戶端為一個訪客。00:00~24:00內相同的客戶端只被計算一次。使用獨立用戶作為統計量，可以更加精準的了解一個時間段內，實際上有多少個訪問者來到了相應的頁面。

用戶訪問次數（VV）

當用戶完成瀏覽并退出所有頁面就算完成了一次訪問，再次打開瀏覽時，VV數+1。VV同時也是視頻播放次數（Video View）的簡稱。

跳出率（BR）

表示用戶來到網站后，沒有進行操作就直接離開的比例，代表著陸頁面（訪客進入網站的第一個頁面）是否對用戶有吸引力，常用的計算方式是落地頁面的訪問量除以總訪量。

退出率（GA )

針對網站內某一個特定的頁面而言，退出率是衡量從這個頁面退出網站的比例，通過一個頁面的退出次數除以訪問次數。退出率反映了網站對用戶的吸引力，如果退出百分比很高，說明用戶僅瀏覽了少量的頁面便離開了，因此需要改善網站的內容來吸引用戶，解決用戶的內容訴求。

平均訪問時長（AAT )

指在特定統計時間段內，瀏覽網站的一個頁面或整個網站時，用戶所停留的總時間除以該頁面或整個網站的訪問次數的比例。該數據是分析用戶粘性的重要指標之一，也可以側面反映出網站的用戶體驗。平均訪問時長越短，說明網站對用戶的吸引力越差。

轉化率（CR )

在一個統計周期內，完成轉化行為的次數占推廣信息總點擊次數的比率。常用的是登錄注冊的新流量轉化率和產生實際支付的轉化率。轉化率是產品盈利的重要指標之一，它直接反映了產品的盈利能力。提升轉化是提升產品價值的重要性指標，一般用A/Btest去檢驗更優方案來提升轉化率。

回購率（RR）

指用戶對商品或者服務的重復購買次數（回頭客），是針對有購買功能的產品，回購率越高，用戶粘性越高。

新增用戶

既安裝應用后，首次成功啟動產品的用戶，按照統計跨度不同分為日新增（DNU）、周新增（WNU）、月新增（MNU）。新增用戶量指標主要是衡量營銷推廣渠道效果的最基礎指標。新增用戶占活躍用戶的比例也可以用來用于衡量產品健康程度。如果某產品新用戶占比過高，那說明該產品的活躍是靠推廣得來，這種情況非常有必要關注，尤其是新增用戶的留存率情況，這種情況留存率低對產品來說也非常危險，視為不可持續發展的流量。

活躍用戶

既在特定的統計周期內，成功啟動過產品的用戶。除此之外，我們還可以將活躍用戶定義為某統計周期內操作過產品核心功能的用戶（按照設備去重統計）。

活躍用戶是衡量產品用戶規模的重要指標，和新增用戶相輔相成。

DAU（日活）：某個自然日內成功啟動過應用的用戶，該日內同一個設備多次啟動只記一個活躍用戶；

WAU（周活）：某個自然周內成功啟動過應用的用戶，該周內同一個設備多次啟動只記一個活躍用戶。這個指標是為了查看用戶的類型結構，如輕度用戶、中度用戶、重度用戶等；

MAU（月活）：某個自然月內成功啟動過應用的用戶，該月內同一個設備多次啟動只記一個活躍用戶。這個指標一般用來衡量被服務的用戶粘性以及服務的衰退周期。

留存率

留存率是驗證用戶粘性的關鍵指標，既在某一統計時段內的新增用戶數中再經過一段時間后仍啟動該應用的用戶比例（留存率=留存用戶/新增用戶*100%）。統計留存用戶的顆粒度有：
自然日：包括1天后、2天后、3天后、4天后、5天后、6天后、7天后、14天后和30天后
自然周：包括1周后、2周后、3周后、4周后、5周后、6周后、7周后、8周后、9周后......
自然月：包括1月后、2月后、3月后、4月后、5月后、6月后、7月后、8月后、9月后......
自然日的留存中主要關注（次日留存、7日留存、30日留存并觀察留存率的衰減程度。一般來說，留存率低于20%會是一個比較危險的信號。）

日留存率：快速判斷App粘性
日留存率：可以很快的幫助我們判斷 App 的粘性到底強不強。我們可以通過日留存率的數值來判斷一個 App 的質量，通常這個數字如果達到了 40% 就表示產品非常優秀了。我們可以結合產品的新手引導設計和新用戶轉化路徑來分析用戶的流失原因，通過不斷的修改和調整來降低用戶流失，提升次日留存率。

周留存率：判斷App用戶忠誠度
周留存率：我們可以通過周留存率來判斷一個用戶的忠誠度，在一周的時間段里，用戶通常會經歷一個完整的使用和體驗周期，如果在這個階段用戶能夠留下來，就有可能成為忠誠度較高的用戶。

月留存率：了解App版本迭代效果
月留存率：通常移動 App 的迭代周期為 2 - 4 周一個版本，所以月留存率是能夠反映出一個版本的用戶留存情況，一個版本的更新，總是會或多或少的影響用戶的體驗，所以通過比較月留存率能夠判斷出每個版本更新是否對用戶有影響。

流失率

指那些曾經使用過產品或服務，由于各種原因不再使用產品或服務的用戶。用戶流失率=某段時間內不再啟動應用的用戶/某段時間內總計的用戶量。流失率和留存率有緊密關聯，流失率高既留存率低，但活躍度不一定高，因此需要綜合分析。也是重點關注次日、7日、30日的流失率。對于流失用戶的界定依照產品服務的不同而標準不同。社交類產品用戶幾乎每天登錄查看，可能用戶未登錄超過1個月，我們就可以認為已經流失了。而電商類產品用戶可能3個月未登錄或者半年內沒有任何購買行為可以被認定是流失了，所以不是每個產品都有固定的流失期限，而是根據產品屬性而判斷。

一次性用戶

既新增日后再也沒有啟動過應用的用戶。一次性用戶是關鍵的營銷指標，和判斷無效用戶的標準，從中把目標用戶過濾出來。一般劃定的界限是至少超過7天時間才能夠定義是否是一次性用戶。

使用時長

既統計時間段內，某個設備從啟動應用到結束使用的總計時長。一般按照人均使用時長、次均使用時長、單次使用時長進行分析，衡量用戶產品著陸的粘性，也是衡量活躍度，產品質量的參考依據。

啟動次數

既統計時間段內，用戶打開應用的次數。重點關注人均啟動次數，結合使用時長可進行分析。用戶主動關閉應用或應用進入后臺超過30s，再返回或打開應用時，則統計為兩次啟動，啟動次數主要看待頻數分布情況。

使用間隔

既用戶上次使用應用的時間與再次使用時間的時間差。使用頻數分布，觀察應用對于用戶的粘性，以及運營內容的深度。雖然是使用間隔，但是通過計算同一設備，先后兩次啟動的時間差，來完成使用間隔統計，充分考慮應用周期性和碎片化使用的特征。

常規數據基本就這些，值得思考的是不同類型的產品，定義每個數據的具體量是不同的，而且產品周期中的不同階段關注的主要數據指標也會有不同側重點。

五、產品周期影響設計策略 

產品階段就是產品生命周期，可分為探索期、成長期、成熟期、衰退期，每個階段的設計策略和工作權重都有所不同。雖然每個階段側重點不同，凡是還是需要辯證看待結合實踐，比如大廠的產品初期起點較高，有大流量的引流和背后大數據支撐，所以各種方式都沒有太大的限制，根據業務，資源不同來根據產品用方法。

5.1探索期（產品初創期）

目標：掌控產品方向（活下去）

關注：用戶價值

用戶：假設用戶

策略：最小成本驗證產品方向

方法：假設的用戶畫像、產品故事地圖、設計沖刺法、訪談、用戶研究（定性分析）

關注數據指標：推薦意愿/新增用戶數/滿意度

品牌：不急于建立

5.1.1、通過訪談、調研，初步建立用戶畫像，抽象假象用戶，提煉關鍵點。

用戶畫像是在大數據時代背景下，用戶信息充斥在網絡中，將用戶的每個具體信息抽象成標簽，利用這些標簽將用戶形象具體化，從而為用戶提供有針對性的服務。

產品摸索期我所定義的目標用戶其實并不準確，而是假象用戶，此階段的概念用戶一直隨著產品方向的改變而改變，所以無法確立明確針對性的用戶畫像信息，但是我們應該先確定一個大概的目標用戶定性的去分析，區分用戶角色，挖掘不同角色的痛點，然后找到解決問題的切入點。

5.1.2、利用用戶診斷法建立產品假設，并進行價值評估，明確產品方向。

5.1.3、利用用戶故事地圖篩選核心任務及對應功能

用戶故事地圖可以用小會議的形式展開，就是讓所有參與者一起用便簽，一張一個動作，從左至右按照時間線，描繪用戶在產品使用場景下所發生的所有用戶行為。同一時間發生的，就寫在同一位置的下方；出現同一場景不同可能的動作時，可能會形成不同的分支動作；直到重回主線或者結束支線。最后關鍵還是總結用戶痛點和產品核心的功能點。

5.1.4、貫穿最小成本原則，最小成本試錯——MVP和設計沖刺法

最小可行產品（MVP）是指可以產生預期成果的最小產品發布，對于迭代產品來說，又可以講最小可行方案：最小可行方案是指可以產生預期成果的最小發布方案。

設計沖刺法的本質理念跟MVP還是一致的，只不過所用成本更小。設計沖刺法特點：參與人員較少且有最終決策權；閉關沖刺使用白板隨時記錄；適用于風險高、時間緊、起步難的情況。

MVP是最小可行方案進行發布驗證，而設計沖刺是更短時間產生一個頭腦風暴的真實原型，進行真人測試，這個過程并沒有真正設計一款產品，而是通過設計方式做了一次早起用戶調研，并獲得相對有驗證性的結果，避免真實上線效果不好對用戶造成的負面影響。

其實市面上大部分還是用的MVP，因為實際上用設計沖刺，一個是對設計人員的要求較高，二是驗證的結果由于測試范圍的限制不一定與市場反應一致。與做一個小產品來說，現在更流行保險的辦法可以做一個小程序，或者幾個小程序進行方案對比，大流量下好乘涼，小程序的開發成本，用戶引入成本更低。

5.1.5、定性為主，不斷試錯中掌控產品方向

船小才好調頭，對于產品來說如果本身戰略層出現問題，后續投入越多的資本越難收場，用戶量不上不下，用戶粘性不高，結果資金不夠了，用之雞肋棄之可惜，再轉方向還是比較困難。尤其是用戶對產品建立一定認知后，重新調整大方向，基本等于刷新用戶流。

5.2成長期（產品高速增長期）

目標：鞏固差異化的產品定位（活得好）

關注：產品核心競爭力

用戶：目標用戶

策略：大膽創新鞏固差異化的產品定位

方法：提煉用戶畫像不斷校驗、用戶體驗地圖、設計接力法（定性+定量）

關注數據指標：新增用戶數/留存率/復購率/活躍度

品牌：建立有創意且能落地的品牌，加深用戶認知，占領用戶心智

5.2.1、用戶校驗，確立產品定位

產品成長期用戶大量涌盡，掌握一定數據和掌控產品方向后可以通過數據分析或用戶調研，來看實際用戶特征和之前假設的用戶人群特征是否符合。集中精力服務好最重要的用戶群體，定性挖掘、定量驗證的思路去完成用戶畫像。

可針對目標用戶進行調研和深度訪談，從用戶選擇產品最關鍵因素提煉產品目前的核心吸引點。用戶的關心點也要跟產品本身的當前定位做對比，看用戶接受到的點是否是產品讓他們感受到的點，感受不到又是什么原因，不斷提煉核心競爭點的優勢。

成長期需要確認產品的定位，就是差異化的產品方向，即差異化的目標用戶群體（價值排序）、差異化的產品及服務（競爭優勢）、差異化的產品價值（核心優勢）。

價值排序：通過了解用戶特征，明確用戶分類及相關利益群體，然后明確把誰放在第一位。在實際產品設計過程中，我們也可以用價值排序，來設計產品功能和交互體驗，比如平臺收費是針對買方還是賣方。

競爭策略：避實就虛地找到競爭對手的盲區或自己的優勢所在，為用戶提供差異化服務。競爭策略主要依賴高層的洞見和判斷，如果你出產品和競爭對手沒有本質差異，那就考慮是否可以服務與不同種類的人群或者能提供不一樣的價值。比如同樣是做電商，你的質量、價格、物流、種類是不是有優勢。

5.2.2、確立增長指標

增長指標是對應于產品差異化定位的可量化指標。增長指標要符合：可成長性，客觀性，有方向性。避免主觀，虛榮的指標，最常見的就是過分關注獲客拉新指標，留存不足，及前后導向不一致的情況。至于用戶滿意度、任務完成度等主觀的體驗指標可以作為參考，但是不能作為最終的增長指標。核心關注點是轉化、留存、復購、活躍度等指標，既側面體現了良好的用戶體驗，增加了用戶與產品粘性，讓產品長期可持續發展。

5.2.3、利用用戶體驗地圖（E-Experience Map），同理心地圖，結合增長指標大膽提出假設，排優先級，并根據開發成本等因素通過四象限原則，選擇最小成本提升指標   

用戶故事地圖、用戶體驗地圖、同理心地圖的區別：用戶故事地圖強調用戶使用產品/服務的任務流程，用它來篩選當前最重要的任務及對應功能，以完成最小可行產品設計；用戶體驗地圖不僅包括任務流程，還包括與之對應的體驗問題，更關注用戶的體驗情緒，從而找到提升體驗的機會點；同理心地圖幫助我們在每個不同場景下與用戶換位思考、打開思路，挖掘用戶選擇決定的深層動機。在實際使用場合沒有嚴格界線，可根據實際情況使用核心點進行分析。

5.2.4、體驗升級——逐步發布驗證（設計接力）

大版本迭代的優點就是一旦成功，可以大幅度拉開和競爭對手的差距，但是一旦失敗，會影響業務的發展得不償失。所以為了預防風險，大多數公司會在上線前先進行可用性測試，進行必要的線上驗證再發布。通過不斷分析增長指標，找選設計方向，進行模塊拆分，接力發布，循環驗證，提升產品價值。

先驗證后發布方法：

a、A/BTest

制作兩個（A/B）或多個（A/B/n）版本，在同一時間維度，分別讓組成成分相同（相似）的訪客群組（目標人群）隨機的訪問這些版本，收集各群組的用戶體驗數據和業務數據，最后分析、評估出最好版本，正式采用（消除UX、bug帶來的影響數據），并不斷迭代進入一下個A/BTest。產品成長期，中小型企業可以用局部變量測試，大型成熟產品可以重疊實驗（更多、更好、更快）。

要求：1、隨機抽樣；2、足夠的樣本量。

優點：可以在同時段觀測效果，受到環境影響因素一致，容易客觀驗證方案

缺點：需要占用開發資源，完整的一次測驗需要花費時間較多

b、灰度測試

先進行一個小范圍的嘗試工作，然后再慢慢放量，直到這個全新的功能覆蓋到所有的系統用戶。比如Facebook先發布1%，慢慢推廣到全部，現在普遍大廠也會用到這個方法，減少大版本試錯帶來的損失?；叶葴y試的同時可以A/Btest，在灰度測試過程中選出最佳方案，然后全部發布。

合適:用戶群體較大，否則會因為流量小而導致結果不準確。

c、分時段測試

可以通過不同時段測試，對比數據。為減少對用戶過多干擾和負面影響，可以先用夜間或用戶量較小時段切換到新版本。

缺點：得到的是環比數據，不像ABtest對比結果明顯有參考意義。而且在沒有確定方向的摸索階段，用分段測試，數據指向不明確，通常會存在數據一直不好的情況，頻繁換方案， 自亂陣腳。

d、分渠道測試

渠道推廣對業務支出也是占比較大，優秀的商業設計也能讓渠道轉化提高，從而減小獲客單價。所以渠道上的設計都會做n版，優化總結，提升最終的數據。

e、新舊版本切換

新版本上線后留出”返回舊版“的入口，這樣一旦用戶不喜歡新版可以切換到老版本。這樣可以很大程度降低風險，還可以監測不同版本數據，還給用戶一個緩沖時間讓用戶逐漸接受新版本。

缺點：如果新版本運行效果不佳，決策者會進退兩難，一般在較有把握，或者想教育用戶新的體驗會局部用這個方法。

5.2.5、尋求差異，擴大競爭優勢

A、瘋狂聯想法

a、橫向聯想

結合產品定位，先得出核心關鍵詞，再在核心關鍵詞的基礎上繼續發散。比如一個男士護膚品電商網站，核心關鍵詞是：垂直、B2C、男用戶多、護膚品等，可以根據這些關鍵詞找到合適的參考。值得注意的是關鍵詞的選擇也可以根據你需要的提升的核心價值點去聯想。

b、縱向聯想

縱向聯想是從一個關鍵詞出發，縱向不斷延展出新的關鍵詞，并找到對應競品。比如保健品有一個重要的特征就是注重功效，我們可以想到具有同種特征的護膚品。

關于聯想，在頭腦風暴中并沒有特備嚴格的步驟方法規定，可以根據自己的認知由近至遠拓展。思維跟橫向縱向也是類似，可以先參考最典型接近的，再利用共同關鍵特征來擴散，也可以利用不同組合的關鍵詞重新找到相應的競品。最后根據四象限原則，把相關度高，體驗好的，更有參考價值的競品拿來精細分析。

B、競品對比分析法

通過聯想發我們也能聯想出不同維度的競品，這師我們需要考慮競品哪些部分類似可以參考的，哪些部分不同需要注意的，但同時也可以考慮借鑒不同部分的優勢轉化成自己的優勢。比如最早彈幕只出現在視頻上，抓住彈幕可以活躍氣氛，滿足觀眾發表評論和觀看時時評論達到的心里共鳴，增加用戶之間的互動性，從而提高用戶粘性的核心點后，彈幕也出現在直播、音頻、新聞，甚至是炒股軟件上。

5.2.6、做有創意且能落地的品牌設計

品牌的核心點就是讓人“記住”，最好能找到目標用戶心智中空缺的領域，在這個垂直領域占領優勢位置，所以品牌強調差異化。比如一想到打車就想到滴滴，一想到購物就想到萬能的淘寶，一遇到問題就上百度。

傳統的方法：了解業務——發散關鍵詞——情緒版——視覺方案

精益方法：內外調研——語言釘——個性關鍵詞——視覺錘（快速落地）

成長期的品牌建設更需要突出創新性，讓人眼前一亮，記憶猶新。這里展示展示了御膳房網站的品牌三元法示例，御膳房的風格的確做到了主題感強烈，讓人眼前一亮，不過個人認為作為科技網站，還是略顯了花哨，安全感不足。品牌三元法是也是通過對產品的了解，分別從理性業務層和感性業務層出發，延伸個性創造層，記錄關鍵詞展開設計，其本質還是圍繞業務拓展價值。成熟的品牌設計者，不僅要從業務出發，更要考慮不同場景的品牌應用，打造統一有個性的全方位品牌。

5.3成熟期（產品穩定期）

目標：提升產品價值（賺的多）

關注：商業變現

用戶：活躍用戶

策略：科學嚴謹提升商業價值

方法：用戶體驗地圖、設計跨欄法（定量為主）

關注數據指標：活躍度/流失率/營收/成本率/現金流

品牌：擴大品牌影響力和品牌價值

5.3.1、用戶分層，尋找核心價值用戶

a、核心價值用戶是留存用戶中最活躍的部分

b、找到核心價值的用戶特征

通過RFM模型來篩選核心價值用戶

R=Recency最近一次消費

F=Frequency消費頻率

M=Monetary消費金額

（RFM，1代表高，0代表低）

（111）重要價值客戶：最近消費時間較近、消費頻次和消費金額都高，典型的核心價值用戶，高留存、高活躍度

（011）重要保持客戶：最近消費時間較遠，但是消費頻次和金額都很高，說明這是一段時間沒來的忠實客戶，需要與他保持聯系，召回

（101）重要發展客戶：最近消費時間近、消費金額高，但是頻次不高，忠誠度不高，很有潛力的用戶，必須重點發展

（001）重要挽留客戶：最近消費時間較遠、消費頻次不高，但消費金額高的，可能是將要流失或者已經流失的用戶，應當采用措施挽留

一般公司都會有利用RFM來觀測核心用戶，針對不同類型來做不同的措施，但是所有數據的利用率都跟產品客觀成長度有掛鉤，成長期可能還不是那么細分，成熟期就會更精細的分析。最簡單粗暴的就是看看最近一次消費，超過多少天就短信消息召回給個優惠券之類的。

c、總結核心規律，改進產品，調整運營策略

找到核心價值的用戶特征后，需要探測他們的行為模式與貢獻的規律，從而激勵更多用戶貢獻更多價值。比如喜馬拉雅，找到訂閱節目的用戶明顯留存度更高，用戶活躍度也高于隨便聽聽的用戶的規律后，在產品設計時會把訂閱放在顯眼的位置，并且在首頁把用戶感興趣的模塊放在優先的位置來提升訂閱度。

5.3.2、商業價值提升

a、以科學創新為代表的產品核心競爭力：數據和技術驅動一切，科技提升效率。

b、用戶價值：用戶價值是商業變現的基礎，沒有人會在沒有用戶轉化的平臺上投入資金。

c、商業變現：用戶付費，廣告收入，與用戶體驗合理價值平衡。

在商業變現階段，除了要著眼于如何更的賺到錢，也需要平衡用戶體驗，且不斷提高產品本身的價值。百度在成為巨頭后，百度貼吧過多不相關的推送導致用戶粘性急劇下降，魏則西事件等負面消息，再到陸奇離職，目前市值縮水至365.38億，被拼多多趕超。而微信和抖音這方面做的較為出色。微信是迫不得已不愿打擾用戶，所以廣告頻率一直不高，廣告質量也有所保障，會根據用戶的喜好推薦廣告。抖音是沉浸式的廣告體驗，一不留神就進入了廣告的坑，而且廣告的形式與抖音原生用戶的不謀而合，有些有創意的網紅視頻用戶的接受度也很高，從而會極大的提高轉化，對用戶體驗的影響也較少。

5.3.3、增值假設——圍繞目標增長（量化設計師的價值）

設計策略：穩定、規范、統一、科學嚴謹

a、拆分變量科學測試

到了成熟期，設計師在修改設計方案的時候不是改的越多越好，有的時候一個模塊的重構，一個按鈕的顏色變化都能影響數據轉化，所以需要通過科學的方式，調整到合適的顆粒度去測試。  

b、把AB測試作為一項基本制度

如果想要驗證設計效果，那么可以在保持功能不變的情況下，只看設計方案的區別，這樣就可以有效的量化設計。

2018 年，中國移動互聯網用戶增長放緩，上半年僅增長 2 千萬。但是頭條系卻異軍突起，超過百度系、阿里系穩居總使用時長第 2 名。頭條系的崛起有許多的原因，強大的數據監控系統，成熟的增長引擎，上百組同時進行的AB測試等等都在幫助產品經理和運營們找到最優的方案。

c、用戶增長地圖

用戶增長地圖是借用AARRR概念作為骨架的展開的，通過AARRR模型針對沒一步提出增值假設，以提升總體價值指標。

5.3.4、提高整體效率：通過DPL（Design Pattern Library）組件庫批量優化；科技力量-人工智能

a、根據長期積累下來的AB測試結果，沉淀規范后，把這些規范內容快速復制到若干條產品線上。從產品周期來說，摸索期需要建立一定的視覺規范，但不合適做細致化的組件，等業務慢慢穩定下來，不會有大方向的改變后，需要慢慢建立細致的組件庫，以方便團隊合作。每個業務也有其特殊性，to B的業務一般建立組件庫會比較早，模式化的東西較多，針對不同的B端也會有定制化的內容，DPL可以大大提高整個業務的效率。

b、通過智能科技的力量來提升整體的效率。比如阿里的千人千面，通過消費者偏好進行個性化投放，魯班系統對banner進行簡單的合成，大大提高大促期間海報生成的效率。

5.3.5、打造統一的全業務線品牌設計

a、形成統一且獨特的品牌印記

成熟期面對繁多支線，先對內樹立統一的品牌形象；主品牌與產品調性統一；線上線下風格的統一。

b、品牌印記提取與深化

品牌趨勢都是化繁為簡，比如蘋果、奔馳的logo就越來越簡單，利于大眾記憶，也利于線下拓展。

提取出logo基因去強調品牌作為拓展延伸，比如天貓和考拉的吉祥物頭部圖形的簡化應用，都比較簡約，易記，易拓展

C、成熟期的品牌也不是一成不變的

成熟期，產品在市場中已經有了穩固位置，品牌不宜過度設計，而需要采取保守、穩重、擴展性強的風格。品牌的更新升級，一方面順應企業的戰略方向的改變，一方面順應整個設計前瞻潮流。比如美團變黃的品牌升級，是為了更好的從外賣這個觸點深入用戶心智，而OPPO ，vivo等品牌升級感覺更美有特色，其實也是順應國際化的設計趨勢，更有文字辨識度，更國際化。

5.4衰退期

每個產品都有一個生命周期，這是受市場因素導致的，此時用戶會逐漸流失，既被其它新產品的體驗模式所吸引，所以這時應該更關注用戶流失后使用的產品，分析競品的商業模式和功能，同時監測流失速度，需盡快拓展產品邊界，尋找新的切入點。不過好的產品都是在不斷優化，迎合新時代的需求，不斷擴大自己的影響力和產品價值。之前文章我也寫過關于微信的未雨綢繆，不斷優化。微信的用戶粘性強大，誰也不好說他能再打幾年，像抖音這種迅速崛起的產品是否是現象級的曇花一現，也要看它是否能與時俱進。

六、設計師順勢而為，自我定位

一般來說小公司的大部分項目處于探索期和成長期，而大公司的項目很多處于成熟期，也有一些孵化探索的項目。處于探索期的項目，需要大膽創新同時，有可能變化極快，無法冷靜下來根據數據用不同設計方式達成增長目標，我就經歷過一個首頁一星期全新大改版n次的慘痛經歷。反觀大公司很多流程復雜，驗證方式系統完善，有些設計師感覺沒有用武之地，不能施展才華。

根據不同階段采取適合自己的設計方法，驅動產品提高設計價值，切勿漫無目標、抱怨環境，浪費時間。

如果你思維極其顛覆愛挑戰可以選擇從0到1的新行業；如果你喜歡創新可以選擇成長型的行業及公司，或是成熟公司里的成長型項目；如果你追求科學、嚴謹、，那么可以選擇成熟型的公司、項目。

轉自-UI中國

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

本文列舉了交易型電商與內容型電商的對比，以及他們的消費者交易行為的四大區別。

No1  ：單獨評估vs聯合評估

消費者看到一個產品的時候，有兩種典型場景：?

在內容電商（比如看到新媒體文章推薦）時，用戶一般處于單獨評估狀態。

比如顧爺發過一個軟文賣“電表箱掛畫”——家里電表箱很丑、不美觀，用一副畫把它遮住，顯得家里美觀又有逼格。

當看到這個商品推薦廣告的時候，你就進入了“單獨評估”狀態，只比較眼前的畫以及你的現狀（沒有電表畫）。

這個時候你在意的是產品本身好不好，帶給你的感覺怎么樣，以及價格能不能接受。

很可能的結果是，你看到這幅畫200多塊錢，也不太貴，所以就買了。

而如果你不是在閱讀顧爺公眾號的時候看到商品，而是進入淘寶、京東這種交易型電商，心理就不一樣了。

在交易型電商中，用戶一般處于“聯合評估”狀態。

比如淘寶搜“電表箱掛畫”，你看到的頁面是這樣的：

這個時候，你進入了“聯合評估”狀態，你主要的比較點不再是“電表箱掛畫”和你的現狀（沒有電表畫），而是眾多的電表箱掛畫中哪個最好。

如果你仔細盯著上面的淘寶圖看，我想你此時的消費者心理已經發生了這些變化：想要看看不同價位的畫之間到底有什么區別。

材質？大??？印染工藝？誰畫的？急于尋找一些讓自己感覺到熟悉的信息。

比如掃一眼看看哪個品牌是你聽過的（即使是華為牌的畫，此時都更能抓你的眼球）。

趕緊比較哪個店銷量大、好評多（咦？剛剛看到顧爺的，怎么不這么關心銷量信息？）

開始在意價格，并且重新思考買這個畫到底值不值。

然后，你可能不會買電表箱掛畫了，甚至會覺得買一幅這樣的畫很多余，還不如買一箱牛奶補補身體。

表面上看，一樣的產品，你僅僅切換了評估方式（單獨評估VS聯合評估），你選擇產品的標準卻產生了巨大的變化。

而就像我們前面說的，為了“在競爭中存活”，你不得不了解，“決定用戶選擇”的因素，到底產生了什么改變：

NO2：感性線索vs理性線索

聯合評估環境下，消費者更加注重容易對比的理性線索，比如材質、大小、印染工藝等，這是因為聯合評估的時候，我們看的是選擇項之間的不同，而不是選擇項和現狀之間的不同。

而在單獨評估的時候，消費者會更加容易受到感性線索的影響，大腦進入的不是“計算模式”而是“感覺模式”，會更容易感覺到增加一個畫帶來的生活改變、這幅畫整體的設計感、流露出的藝術氣息等。

所以，如果你是在參數上占優的產品，比如小米或樂視的手機，進入聯合評估會非常有利，因為用戶非常在意跑分。

如果你是在參數以外的體驗上占優的產品，比如設計精美和有情懷的手機，進入單獨評估會比較有利，因為你的優勢無法被直接計算，難以在聯合評估中占優。

有研究發現，假設有兩款同等價格的冰激凌，一款是滿滿地裝在小杯子里，總共50毫升；另一款是在200毫升的杯子里裝了半滿，相當于100毫升。

看到兩款冰激凌，消費者卻又會選擇半滿但是量多的冰激凌——廢話，大家又不傻，看數據明顯這個給的多。

再比如，找工作的時候，如果只看到一個職業選擇，大部分人會對那種工作內容激動人心、公司名讓人仰慕、發展前景好的工作更滿意（而不是單純的薪水）。

而在聯合評估的時候（同時拿到很多offer），大家比較來比較去，最終更容易選擇薪酬更高但自己實際上并不喜歡的工作。

因為聯合評估的時候，我們更容易忽略主觀感受，選擇那些“數據”和“參數”上更牛的選項。

所以在淘寶上，你可以直接根據材質、大小等性價比選擇一個畫，即使這個畫買回去后你并沒有像買顧爺的畫那樣驚喜。

這也意味著，在交易型電商環境下，拼參數、拼數據的產品容易獲勝，而在設計感、原創性上占優的產品，難以贏得顧客選擇。

而在內容型電商中，我們是單獨評估，這時候設計師原創設計帶來的沖擊感，可能直接讓我們選擇去購買。

這同樣意味著，在交易型電商中，我們更容易受到銷量領先、知名品牌等信息的影響，因為這也容易比較。

而在內容型電商中，我們則直接感覺對這個產品喜歡不喜歡。

NO3：高端vs低端

• 聯合評估狀態下，我們會進入“計算模式”，更加注重價格信息（因為容易比較），所以低價品的銷售會非常好。
• 單獨評估狀態下，我們會更加注重主觀感受，更有可能忽略成本，放縱一下買個自己喜歡的，所以高價品、享樂品的銷售會非常好。

之前我遇到一個自媒體賣產品的客戶，同樣的產品（高端有設計感的杯子）推送給同樣的粉絲，一個用淘寶平臺，一個直接用微信嵌入的電商平臺，結果后者轉化率高了十幾倍。

其實一個很重要的原因就是：淘寶本質上屬于交易型電商，會強迫所有消費者自動進入聯合評估的狀態。

在這種狀態下，用戶會更加在意成本信息，價格敏感性增強，從而導致更少人選擇高端產品、享樂產品。

所以高端品牌（比如LV）在線下一定是用專賣店，而不會進入賣場，因為后者是聯合評估。

總結

在內容電商環境下，更多人會在單獨評估狀態下購物，出現這些變化：

• 性價比的作用性降低，而感性因素的影響會升高（比如設計感、悠久歷史、情懷、故事等）。
• 低端產品的銷售會降低，原來很難賣出去的高端產品、享樂型產品會更容易賣。

NO4： 主動搜索vs被動搜索

如果在淘寶、京東購物，此時你的心理狀態經常是：我要買東西。

你處于“購物”（shopping）心態中，大腦中經常裝著某個潛在的任務——比如要看看有沒有好看的衣服或者想買一箱牛奶存放到冰箱。

這個時候，我們就說你處于“主動搜尋”的心理，你會對將來可能會購買的產品信息更加敏感，而對無關信息不那么敏感。

而在內容電商環境中，你本身正在專心看網紅的直播或者某個自媒體的內容，這個時候突然看到有個產品信息（比如講健康的播主，推薦了新型智能牙刷），此時，我們說你處于“被動接受”的心理。

這有什么區別呢？

研究發現，在主動搜尋的心理中，我們會更加關心直接與任務相關的信息，而對與任務無關的信息減少關心。

比如你想挑一款面霜，會在大量的面霜相關的商品中進行比較，對面霜相關的信息非常敏感。

而如果此時偶爾看到有個叫做“面部噴劑”的新型產品，你可能壓根不會關心（因為你正在找面霜），即使它也可以幫助你改善和保養皮膚。

（ps：這個產品是我編的，用來制造未知感，實際上不存在這個產品）

所以在交易型電商中，各種新奇、未知的產品，其實并不好賣。

有個知名的“看不見的大猩猩”心理實驗證明了這一點。

心理學家召集一些志愿者，給他們布置任務：數一下在接下來的視頻中，球員一共傳了多少次球。

然后在視頻一半的時候，有個人穿著大猩猩的衣服進場并且做了歡呼的動作。

實驗結束，心理學家問志愿者：球員一共傳了多少次球？大部分人答案都對了。

但是接著問：你們有看到一個大猩猩嗎？結果超過半數的人聲稱沒有看到大猩猩。

這是因為看視頻的時候，大部分人聚焦于“數傳球”這個任務中，從而自動忽略了與任務無關的信息（大猩猩）。

這也導致了用戶在京東選購面霜的時候，可能更容易關注面霜本身，而不是主動好奇地去尋找除了面霜還有什么新型產品可以替代。

而如果是在內容型電商，用戶事先沒有覺得要買面霜，而是在看一檔教你如何保養面部的節目，就更容易接受一種新型的護理面部的方式（比如XX面部噴劑）。

總結

內容型電商，比交易型電商更適合銷售新奇產品。

文章來源：人人都是產品經理