運營類活動定義

運營類活動是在某一段時間內進行的，有明確業務目標（業務轉化、品牌傳播）及營銷群體，依賴游戲化手段帶來優秀用戶體驗，從而獲得成功的一類活動。

特征

1. 生命周期短

運營類活動生命周期較短，常在某一段時間（可能是周期性的），一般跟隨時節熱點或者運營節奏來進行。較短的生命周期給設計、開發、數據等帶來較大挑戰，設計程式化提供基本設計思路，組件化降低設計成本。

2. 業務目標明確

運營類活動一般以產品營銷、品牌運營為目標，發放各類優惠券大眾目標用戶，從而帶來業務轉化，或者營銷企業品牌，比如常見的年底 h5。

3. 有一定故事場景及氛圍

運營類活動需要較強的故事場景。良好的場景設計、氛圍營造可以帶來沉浸式的用戶體驗，與用戶建立情感共鳴。從而提升用戶參與度、帶來好的業務轉化。

故事場景結合時節熱點，同時考慮活動需要營造的體感氛圍。

4. 人群細分

運營類活動的特征在發起之初就有特殊的運營目的和特定特征的用戶群體。為實現最優的業務轉化，需要在設計之初明確活動覆蓋的用戶人群。同時在各個環節都能考慮到特定用戶群體的不同需求，尤其是在業務轉化的過程中，好的人群細分往往帶來事半功倍的效果。

5. 游戲化

引入游戲機制及游戲元素。

為什么有效

1. 場景化設計帶來沉浸體驗

運營類活動結合時節熱點，通過富有故事性的視覺傳達（插圖、動效、聲音等設計元素）帶給用戶沉浸式的體驗，與用戶建立情感共鳴，從而有效的鼓勵用戶行為。

沉浸體驗的營造對設計師提出了更高要求，可以從活動設計的故事感、用戶代入感、產品互動感、主體差異感幾個方面來思考入手。

2. 游戲化機制及元素

運營類活動中廣泛應用了游戲化機制和元素，它們是活動成功的有效保障。設計時綜合考慮業務及用戶需求，從用戶動機激勵、行為引導的角度出發，將運營活動游戲化?？梢栽诨顒訁⑴c深度的各個階段引導用戶操作，從而達成活動目標。以下列舉了運營活動中常見的用戶動機，后續我會從用戶參與路徑出發，盡可能詳細的描述在用戶參與的每一個階段起作用的為動機，以及實現的手段。

大獎帶來的誘因效應

動輒百萬的大獎獎勵幾乎已經成為運營活動的標配，在動機理論中，用戶行為的產生來源于需要，需要導致內驅力，引發行為，從而推動用戶實現特定的目標。當目標的誘惑力很大時，即使沒有內部驅動也能激發行為。這也是眾多運營類活動大獎存在的理由。

占便宜的心理

愛占便宜是人的本性，從心理學角度講，占便宜就像是額外得到的驚喜和獎賞，可以讓人產生滿足感！用戶在這種心理作用下，會為了小利益去做出設計預設的行為，將業務需求設置在‘占便宜’的路徑中可有效提高參與、轉化率。比如在設計中用中獎動態彈幕來強化用戶參與的動機，提高參與率。

有趣和好奇心

人天生具有好奇心，它幫助我們適應不斷變化的環境、發現新的資源，是一種「無法抗拒」的行為動機。在運營活動中，用戶會被有趣的活動頁面，未知的規則設計所吸引，從而開始主動「探索」。這也是用戶參與的動機之一，設計中精致的 UI、有效的頁面信息傳達保證了用戶好奇的有效性。

即時反饋及階段性成就

「即時反饋」是沉迷現象發生的原因。學習之所以痛苦正是因為其反饋鏈路太長，你只有在考試或者應用到所學知識時才能獲得反饋，還有可能是負面的。在活動設計中，每一次用戶操作都會有及時、細膩的反應，可以給用戶帶來精神愉悅，同時設計的階段性成就又給用戶帶來成就感，用戶會不知不覺中在活動中越走越遠。

隨機獎勵的多巴胺效應

人類的本能熱衷于冒險，隨機的、不確定的獎勵能夠刺激大腦分泌多巴胺，帶來愉悅感，從而刺激用戶行為的重復。在活動設計中，常用到這一理論，比如抽獎機制。

所有權與擁有感

當用戶感到他們擁有或控制某樣東西時，會自然而然的強化它的屬性、發揮其價值。尤其是通過適當的付出和自身努力，用戶還可能不合理的高估其價值。在活動設計中，常使用戶通過易實現的行為獲得權益，通過「幸苦操作」強化了擁有感，提升其心理價值，從而促進用戶對權益的使用。

稀缺性與用戶渴望

稀缺性的心理學原理在于人們想要獲得某樣東西的原因僅僅是它太罕見，或者無法立刻獲得。它破滅了人們對情況的控制感，人們會為了重獲控制而采取行動。設計時，可以利用這種心理鼓勵用戶做出期望的行為。常見的有時間限制、權利限制等。

使命感/社交影響/損失規避……

3. 數據與策略思維

運營類活動中數據和策略思維是保證活動效果最大化的有效手段?；顒有枨筇岢鰰r，即考慮可能的參與用戶細分；活動開始時，考慮引流途徑和引流方式、物料的差異化；活動進行時，根據用戶細分策略化任務推送，根據埋點數據監測積極調整相關設計元素。事無巨細才能確保活動成功。

文章來源：優設

JavaScript基礎知識——JS預解析

js代碼是由瀏覽器中的JavaScript解析器來執行的。JavaScript解析器在運行JavaScript代碼時分為兩步：1預解析、2代碼執行。



預解析

預解析是指js引擎會把js里面所有的var與function提升到當前作用域的最前面。（這里的當前作用域包括：全局作用域與局部作用域）。

預解析可分為：變量預解析和函數預解析

變量預解析：就是把所有的變量聲明提升到當前的作用域的最前面但是不提升賦值操作。如下例所示：



<script>

console.log(num);  //結果為undefined

var num = 10;

</script>

//其實際執行過程為

var num;

console.log(num);

num=10;



函數預解析：就是把所有的函數聲明提升到當期作用域的最前面 但是不包括調用函數。如下例所示：



var num = 10

fun();

function fun() {   //結果是undefined

console.log(num);

var num = 20;

}

//其實際執行過程為

var num;

funtion fun() {

var num;

console.log(num);

num=20;

}

num = 10;

fun();

在idea中使用jdbc往數據庫里儲存中文亂碼問題

這里使用的數據庫是mysql。

ide為idea.

有時做一些web項目時需要往數據庫里面儲存中文，就是需要用到jdbc往數據庫里面儲存數據時，參數改為中文。可是儲存完之后，打開sqlyog查詢又是???這樣子的亂碼



上網找了很多方法，數據庫的編碼問題都改了，而且統一成utf-8了，但還是儲存時為亂碼。

后面檢查時在sqlyog里改中文又可以正常顯示。

這就說明數據庫上是沒有問題的，應該是連接這塊，于是在連接的url上加入了參數就可以正常顯示了characterEncoding=UTF-8



這里使用的是c3p0的連接池，不同的連接池可以去對應的配置文件中加上參數

在Vue中，用watch來響應數據的變化，示例代碼如下，



第一種方式

<input type="text" v-model="userName"/>  

//監聽當userName值發生變化時觸發

watch: {

userName (newName, oldName) {

console.log(newName)

}

}



第一種方式有一個缺點： 就是當值第一次綁定的時候 不會執行監聽函數，只有當值改變的時候才會執行。



如果我們想在第一次綁定的時候執行此監聽函數，則需要設置immediate為true。比如當父組件向子組件動態傳值時，子組件props首次獲取到父組件傳來的默認值時，也需要執行函數，此時就需要將immediate設為true。



第二種方式

watch: {

userName: {

handler (newName, oldName) {

console.log(newName)

},

immediate: true

}

}



immediate表示在watch中首次綁定的時候，是否執行handler，值為true則表示在watch中聲明的時候，就立即執行handler方法，值為false，則和一般使用watch一樣，在數據發生變化的時候才執行handler。



當需要監聽一個對象的改變時，普通的watch方法無法監聽到對象內部屬性的改變，只有data中的數據才能夠監聽到變化，此時就需要deep屬性對對象進行深度監聽。



第三種方式

<input type="text" v-model="cityName.name" />

data (){

return {

cityName: 

{

name:'北京',

location: '中國'

}

}

},

watch: {

cityName: {

handler(newName, oldName) {

console.log(newName)

},

immediate: true,

deep: true

}

}



注：監測為對象的時候，newVal == oldVal



此時會給cityName的所有屬性都加上監聽函數，如果屬性較多時，每個屬性值的變化都會執行handler。如果只需要監聽對象中的一個屬性值，則可以做以下優化：使用字符串的形式監聽對象屬性：



watch: {

'cityName.name': {

handler(newName, oldName) {

console.log(newName)

},

immediate: true,

deep: true

}

}



數組的變化不需要深度監聽;

在watch中不要使用箭頭函數，因為箭頭函數中的this是指向當前作用域.

首先讓我們了解一下前端路由：路由router全部配置在前端，根據用戶權限判斷可以進入哪些頁面

缺點：



vue初始化的時候需要掛載全部路由，對性能有影響

安全性低，用戶可以在地址欄跳轉到無權訪問的頁面（可優化）

動態路由則是根據用戶信息獲取權限，簡單來說就是根據用戶信息獲取其對應的權限，生成對應的路由掛載，然后動態渲染有權限的菜單于側邊欄



實現

定義靜態路由（登錄或者公用頁面）、動態路由，vue初始化時只掛載靜態路由

用戶登錄后，拿到用戶token，調接口拿到動態路由權限DynamicRoutes，將DynamicRoutes和定義的動態路由比較，篩選出相應的用戶可訪問路由表

執行router.addRoutes(DynamicRoutes)添加動態路由

使用vuex存儲路由表，根據vuex中可訪問的路由渲染側邊欄sidebar

// beforeEach中

if (getToken() && getToken() !== 'undefined') {

  // 權限判斷

  if (!store.state.app.menuPermissions) {

    / 獲取后臺給的權限數組 /

    return new Promise((resolve, reject) => {

      getPermissionList().then(response => {

        if (response.data.stat === 1) {

          const userRouter = response.data.data

          // 檢查并生成新的路由表

          const DynamicRoutes = ChecAndSetPermissionRouter(userRouter)

          // 默認使/重定向到第一個有效的路由

          for (let i = 0, leni = DynamicRoutes.length; i < leni; i++) {

            if (DynamicRoutes[i].children.length > 0) {

              DynamicRoutes[i].path = '/'

              DynamicRoutes[i].redirect = DynamicRoutes[i].children[0].path

              break

            }

          }

          DynamicRoutes.push({ path: '', redirect: '/404', hidden: true }) // 全局404

          / 生成左側導航菜單 /

          store.dispatch('SetMenuPermissions', DynamicRoutes)



          /  動態添加路由 /

          router.addRoutes(DynamicRoutes)



          // / 完整的路由表 /

          store.dispatch('SetRouterPemissions', [...constantRouterMap, ...DynamicRoutes])

          next(to)

        }

      }).catch(error => {

        router.push('/404')

        // / 生成左側導航菜單 */

        store.dispatch('SetMenuPermissions', [])

        next()

        reject(error)

      })

    })

  }

  if (to.path === '/login') {

    next({ path: '/' })

  } else {

    next()

  }

} else {

  if (whiteList.indexOf(to.path) !== -1) {

    next()

  } else {

    next(/login?redirect=${to.path}) // 否則全部重定向到登錄頁

  }

}



踩坑來了





Q：為什么404 頁面一定要最后加載，放置在靜態路由中會怎么樣？

放在靜態路由里，后面的所以頁面都會被攔截到404，所以應該獲取動態路由權限之后push

Q：權限獲取成功，不跳轉新生成的動態路由，跳404？

beforeEach中router.addRoutes之后的next()可能會失效，因為可能next()的時候路由并沒有完全add完成，可替換成next(to)，重新進入router.beforeEach這個鉤子，這時候再通過next()來釋放鉤子，就能確保所有的路由都已經掛在完成了。

Q：$router.addRoutes()動態添加的路由怎么刪除掉？

在開發中，有新增編輯刪除菜單并要求左側邊欄菜單及時更新的需求，如果直接addRoutes，warn如下：



解決：addRoutes之前要清除掉上次addRoutes的路由，所以操作菜單調取權限后重新初始化router，進行matcher賦值



// DynamicRoutes是權限路由

const createRouter = () => new Router({

  mode: 'hash',

  routes: []

})

const newRouter = createRouter()

// resetRouter()

this.$router.matcher = newRouter.matcher

this.$router.addRoutes(DynamicRoutes)



Q：莫名其妙的無限循環

vue-admin-template，遇到二級菜單children為空的權限，報錯如下：

解決：按照github-issues上方法，在SidebarItem.vue里改一下data就好了（沒想通為啥）



// 更改后如下，return {}

data() {

    this.onlyOneChild = null

    return {}

}



附：ChecAndSetPermissionRouter



import { dynamicRouterMap } from '@/router'



export function ChecAndSetPermissionRouter(permissionDatas) {

  // 獲取到權限hashmap

  var permissionHashMap = null

  permissionHashMap = GetPermissionHashMap(permissionDatas)

  // 標記路由表

  var newDynamicRouterMap = []

  newDynamicRouterMap = objDeepCopy(dynamicRouterMap)

  newDynamicRouterMap.forEach(item => {

    MarkRouter(null, item, permissionHashMap)

  })

  // 重設路由表

  for (let i = 0; i < newDynamicRouterMap.length; i++) {

    if (ResetRouter(newDynamicRouterMap, newDynamicRouterMap[i])) {

      i-- // 注意：防止移除后索引錯位

    }

  }

  return newDynamicRouterMap

}

function GetPermissionHashMap(permissionDatas) {

  var permissionHashMap = {}

  permissionDatas.forEach(item => {

    SetKeyValueOfNodes(null, item, permissionHashMap)

  })

  return Object.assign({}, permissionHashMap)

}



// 深拷貝，遞歸重新設置前端路由表，避免數據復用

function objDeepCopy(source) {

  var sourceCopy = source instanceof Array ? [] : {}

  for (var item in source) {

    sourceCopy[item] = typeof source[item] === 'object' ? objDeepCopy(source[item]) : source[item]

  }

  return sourceCopy

}



// 為權限hashmap的屬性賦值,新增屬性tempKey/tempKey2

function SetKeyValueOfNodes(p, c, permissionHashMap) {

  // 需要匹配的組合類型

  var tempKey = (p ? p.name : 0) + '' + c.name

  var tempKey2 = c.name + '' + c.name

  // 賦值

  permissionHashMap[tempKey] = 1

  permissionHashMap[tempKey2] = 1

  // 遞歸遍歷子節點賦值

  if (c.children != null && c.children.length > 0) {

    c.children.forEach(item => {

      SetKeyValueOfNodes(c, item, permissionHashMap)

    })

  }

}



// 標記路由表

function MarkRouter(p, c, permissionHashMap) {

  var key = (p ? p.meta.title : 0) + '_' + c.meta.title

  // 使用拼接的key作為參考標記去匹配有權限的路由表

  if (HasPermission(key, permissionHashMap)) {

    if (p != null) {

      p.keep = true // 保留當前節點

    }

    if (c != null) {

      c.keep = true

    }

  }

  if (c.children && c.children.length > 0) {

    c.children.forEach(item => {

      MarkRouter(c, item, permissionHashMap)

    })

  }

}



// 校驗后端接口是否存在當前節點

function HasPermission(key, permissionHashMap) {

  return permissionHashMap[key] === 1

}



// 重置路由表

function ResetRouter(p, c) {

  if (c == null) {

    return false

  }

  if (p.children && !c.keep) {

    p.children.splice(p.children.indexOf(c), 1)

    return true

  } else if (!c.keep) {

    p.splice(p.indexOf(c), 1)

    return true

  }

  if (c.children && c.children.length > 0) {

    for (let i = 0; i < c.children.length; i++) {

      if (ResetRouter(c, c.children[i])) {

        i-- // 注意：防止移除后索引錯位

      }

    }

  }

  return false

}

最近在工作時發現了一件很有意思的事情，不知從何開始，國內外的設計需求分化非常明顯。國內的公司在選擇產品平臺時，從幾年前的 PC 端網站，到如今已有大半的客戶考慮從小程序做起了。然而國外的創業者仍然以網頁為主，要說變化，大抵是在需求中多要求了響應式設計，以更好地適應桌面與移動雙端。

所以，今天我們無論坐在這里怎樣討論小程序的優劣得失，都不可否認的是，小程序確實給國內市場帶來了顯著的影響，而且人們已經逐漸接受，在產品初期，小程序是一個值得考慮的平臺。

但是到底小程序的市場是一片大好，還是只是一場危機四伏的狂歡？我將在本文中盡量以客觀的角度闡述，希望能夠給到各位設計師一些思考的方向。

同時，這幾個月來我參考了近 100 款小程序的設計模式，保留了500 張截圖和超過 10 分鐘的錄屏作為分析素材，來幫助那些想要邁入職場的設計師們，更好的上手小程序設計，不為信息和技術所桎梏。

小程序和App的區別

1. 開發成本、開發周期不一致

那么我們作為設計師，第一步需要了解的就是，究竟小程序和 App 之間有什么區別？作為設計師，應該注意哪些問題，這將是本篇文章前半部分的主要內容。

從開發成本看，小程序和 APP 有較大的區別。APP 開發需要兩個版本來適應不同操作系統的手機，產品開發周期長，開發人力投入多，因此開發成本高。而小程序只需要根據騰訊提供的開發平臺就能進行開發，無需考慮手機操作系統的區別，一次開發就能適配所有的機型，開發周期短，開發人力投入少，因此開發成本低。

一款 App 從提出需求到上線，通常的開發周期是 321 原則，即開發 3 個月，測試調整 2 個月，試運行 1 個月。而小程序開發周期在2 周左右，甚至功能簡單的 10 天內即可上線使用，所以是一種相對快速的模式。

小程序由于依附于微信，所以我們其實只需要制作一稿設計便可適配絕大多數的手機，而不像 App 那樣，需要針對不同的手機進行不同的適配。

事實上這是小程序相對于 App 的一個巨大的優勢。在開發 App 時，很多企業在初創期，由于成本問題不得不選擇到底是放棄Android 用戶還是 IOS 用戶。然而小程序只需要設計+開發一次的成本，在理論上就獲得了全部微信用戶接觸到產品的機會。所以從這個角度考慮，小程序是非常節省成本的一種模式。

2. App需要設置大量的數據埋點，而小程序則不需要

微信第三方后臺已經集合了諸多的數據供小程序方查看，在初級階段，這些數據已經足夠產品作為更迭的基礎了。

沒有做過小程序的朋友可能不太了解，微信提供的不僅僅是數量全面的埋點，而是可以自定義埋點位置以及爬取數據類型的系統。甚至還自帶一些簡單的分析系統，幫助運營人員更好的掌握小程序的總體運營情況。

除了已經封裝好的數據監控點，運營人員還可以自定義分析事件，這幾乎是一個可以達到「營銷平臺」級別的分析系統了。

同時，簡單明了的看版系統，也非常節省業務人員的數據清洗成本，的避免了開發人員由于機械重復性的埋點工作而導致的主觀漏采與錯采現象，這也是小程序的優勢所在。

3. 小程序有依附于微信的信息共享機制

小程序與微信形成的信息共享，可以非常方便的達到獲客目的。例如注冊登錄機制，我們幾乎不需要自己手動在小程序上進行注冊登錄。直接通過 Union ID 授權的方式，即可讓用戶用統一的注冊賬戶用遍所有的小程序。據測，用戶進入小程序時，同意微信手機號碼授權的轉化率大致在 35%，相對來說是一個非常可觀的轉化率了。

除此之外，微信給小程序廠商提供了諸多接口，不僅僅是方便了小程序廠商，信息風向更多的是能夠讓用戶更加快速便捷的在小程序中解決問題。這一塊內容會在之后章節中詳解。

什么樣的產品適合小程序

1. 具有社交裂變屬性

這類具有社交因子的小程序天生適合生存在微信的土壤中，通過微信龐大的社交流量助力優質社交小程序成為市場的爆品。比如拼多多、蘑菇街利用拼團實現社交電商的突圍。比如小年糕+通過社交場景實現低成本快速獲客，從而獲得很好的傳播效果，實現短時間的大量用戶增長 。

2. 垂直領域頭部

針對細分市場的小程序也容易受到傳播，比如汽車類小程序有多個排名靠前，用戶已經把小程序當做選車、購車、用車的重要入口，因為屬于低頻應用，沒有必要下載一個 app，如果切入的早，小程序場景的便利性就容易使其升到頭部。

3. 高頻場景喚醒產品

這些場景本身高頻發生且原有的體驗流程存在資源損耗，小程序優化解決了很多商家和用戶的痛點。 比如 KFC 小程序解決等位排隊、點餐、買單付費、發放優惠券、客戶消費分析、基于 LBS 的信息推送等問題，比如視頻、直播、K 歌等娛樂小程序因為輕應用的特點給了用戶娛樂多樣化的選擇,并且用戶可以直接將有趣的視頻、 直播等通過微信快速分享給好友，實現比 App 更好的傳播效果。

4. 不適合作為小程序的產品-工具類產品

相反，我們所推崇的工具類產品，在企業的角度來說，卻是最不適合做成小程序的產品。張小龍所賦予小程序的意義就是：「有用，不會給用戶造成打擾」，所以其實說實話，基于微信生態圈工具類的小程序比 App 更容易爆發。

但是這只是用戶增量提高，工具類 App 短暫的爆發卻很難維持存量。做工具類小程序和工具類 App 一樣，變現周期會非常長。從用戶體驗的角度來說，微信小程序里面的工具比起 App 的用戶體驗會好很多。

• 沒有廣告和外部鏈接，使得工具類小程序非常專注與。
• 工具的理念和小程序的理念非常一致，都是即用即走，沒有任何冗余的操作路徑，也不占用大量的內存。
• 但是從產品的角度而言，過于簡單與就意味著更加難以變現。所以企業應該把核心功能放置在小程序，附件功能依舊放置在 App 中，從而實現從小程序向 App 端倒流，小程序也有效彌補了工具類 App 的社交屬性不足的缺陷。

應該如何設計小程序

其實在張小龍的嘴里，我們已經得到了答案。他對于小程序的幾項基本原則已經足以說明問題，比如其中的一項就是「用完即走」，其實這不僅僅是張小龍給到的小程序的定義，而是小程序本身擁有的屬性。在現代這個時代，用戶的注意力被越來越分散，我們很多的設計其實都是為了緩解用戶焦慮。

在小程序的官方文檔中也提到了相關的元素，在現代社會，大家拿到一款新的產品之后都喜歡自己研究而非去研讀說明書。但是實際上，小程序的官方文檔是非常值得閱讀的內容，里面的規范內容目的不僅僅是為了讓小程序整體顯得整齊劃一，更多的內容是為了保證小程序能夠有良好的用戶體驗。從而增加用戶的留存率。

所以，本篇文章的主要內容是在「小程序官方文檔」的基礎之上，來探索更多的小程序設計的規律，建議大家在閱讀之前，可以先自行閱讀小程序官方文檔，再來看本文，才會有更多收獲。

1. 小程序的用戶路徑必須單一

App 的功能點可以很多，但是小程序的用戶路徑必須單一。

當然，這句話只符合想要入局的中小型企業，在建立小程序的初期，沒有額外的流量渠道，那么最好的留存用戶的方式就是讓用戶能夠的解決問題，對應到小程序的框架設計，即是簡短的用戶路徑。

不止中小企業如此，也有很多大型企業，開始從「復合型小程序」轉向小程序矩陣，目的就是為了給用戶提供專一的體驗路徑。因為從 PC 到 APP，再到小程序，用戶場景和時間在被不斷切碎，產品功能也要不斷簡化，更專注，才更能吸引用戶進行完整的體驗用戶流程。

2. 良好的一次性使用機制

設計一次性引導機制。

在用戶第一次使用小程序時，一些必要的提示是提升用戶體驗的關鍵因素。

減少特殊的交互模式的設計，必要時要進行足夠的引導。

運用用戶更熟悉的交互模式，更能讓用戶擁有良好的體驗，更快速的完成整個路徑與流程。

3. 減少動態設計和裝飾性元素

同樣這個原理只適用于剛剛布局小程序的企業，而不適用于大廠的小程序設計。但其實在 App 中，為了凸顯品牌調性，動態元素和裝飾性元素是一定會出現的。品牌調性幾乎是 App 設計的一個非常重要的環節。

這并不意味著小程序中的品牌調性不重要，而是說在某些環節中，良好的交互體驗比品牌調性重要的多。

4. 頁面扁平化

即減少頁面跳轉，能不跳轉就減少跳轉，跳轉新頁面會增加用戶適應新頁面元素的成本，同時小程序的頁面層級過多，會讓用戶感覺到繁瑣焦慮。這個方法可以縮短用戶觸達產品的路徑，也是小程序用來減少用戶干擾的重要手段。

這樣做的好處就是讓用戶對小程序的架構有更全面的理解。用戶在較少的跳轉路徑中，始終清晰的知道自己處在小程序中的位置。這也是增加用戶對于產品安全感的一種方式。

5. 用選項和自動填充代替輸入和表單

在小程序初期，還未擁有懸浮窗功能。這個時候的表單輸入對于用戶和產品來說簡直是噩夢。比如用戶需要輸入一個信息，而這個信息儲存在手機中，那么用戶就需要中斷當前操作去查看信息。再通過其他的方式回到目前的操作填寫信息。在此過程中，很有可能由于操作過于繁瑣而喪失客戶。

即使增加了懸浮窗功能，用戶輸入信息的操作干擾也還是存在，所以能夠盡量避免信息輸入就要避免，以點選、拖動等手勢操作代替文字輸入。將熱門的、常用的、歷史信息前置，減少用戶的重復勞動。

在其他的小程序對比中，我們一樣可以發現類似的在用戶體驗上的差別。

有一次一個朋友來向我咨詢關于他司電商小程序轉化率如何提高的問題，我便運用了這個理論，去給他們的產品做了一個梳理，最后切實的獲得了數據上可觀的提高。

6. 減少等待，反饋及時

小程序官方文檔里花了大量的篇幅去闡述給予用戶「加載狀態」與「完成狀態」反饋的重要性，而反饋設計的好壞，對留存率存在著至關重要的影響。除了「微信官方文檔」中提到的「啟動頁加載」「頁面下拉刷新加載」「頁面內加載」「模態加載」「局部加載」「全局加載」外。

另外一種加載狀態同樣至關重要，即「預加載狀態」。預加載是一個老生常談的話題，如果一款產品沒有設計預加載，會給用戶心理造成很強的不安全感，這點在小程序尤為明顯，所以設計預加載場景是提高用戶體驗至關重要的因素，尤其針對一些網絡狀況不好的用戶。

其中以百度云盤的尤為出色，他的預加載模式是動畫效果呈現的，可以讓用戶清晰的了解數據正在加載。

如果沒有設計預加載，可以自行設計加載模塊，或者用微信提供的通用加載模塊，也是一個退而求其次的選擇。

而最壞的做法，就是完全不設計任何用于提醒的內容，這種極差的用戶體驗幾乎會全盤勸退用戶。

小程序設計的實戰經驗

想必大家在看完了上述內容后，已經對小程序有了一個初步的概念，上述內容主要是一些理論層面對于小程序設計的分析，那么這個章節主要就是通過大量的線上案例和截圖來講述一些小程序設計的規律。

1. 引導收藏小程序機制

小程序的「即用即走」的機制，同時也促成了各個小程序的形成了一套應對機制，其中之一就是引導收藏小程序機制，目前這個機制幾乎成為了商業小程序的標配，大體分為三種類型：

• 從效用角度出發：引導型 > 彈窗型 > 占位型。
• 從對用戶的體驗出發：占位型由于不遮擋任何信息，對用戶的影響最?。粡棿靶驼趽跻徊糠中畔?，所以次之；而引導型由于直接阻擋了用戶的操作區域，所以對用戶體驗的影響是最大的。不過即使是彈窗型和占位型的引導，也是在過 3-5 秒后會消失，避免進一步干擾用戶體驗。

2. 導流公眾號/App機制

我們在設計小程序時可以酌情參考這三種形式，簡單來說，用戶粘性高，用戶群體年齡偏高可以采用引導型，反之可以嘗試彈窗型和占位型兩種形式。

類似于「引導收藏小程序」，「導流公眾號/App」也是只有小程序中存在的一種模式。不同于「引導收藏小程序」，「導流公眾號/App」的方法可謂是百花齊放，不過渠道卻只有一個，就是客服會話系統。

在客服會話中回復「1」。

在客服會話中，回復「小程序」。

客服會話中的拇指圖設計非常有講究，一般的拇指圖設計都分為兩段文本，字號較大的文本用來在上述步驟二中提醒用戶點擊，而字號較小的文本則是用來在步驟三中提醒用戶點擊鏈接/掃碼來下載 App。

一些小程序會有彈窗提醒我們關注公眾號，但為什么我們不能通過這種簡單的方式讓用戶關注公眾號，而要用跳轉客服這么麻煩的方法。很簡單，仔細觀察就可以發現這是微信的廣告投放（看彈窗的左上角的標簽）。小程序即使接了廣告，也只能給別的公眾號導流。

雖然說小程序有辦法將用戶引導到 App 中，但是小程序和 App 的聯動非常有限，基本上局限于通過小程序引導用戶去下載/打開App，用戶無法在小程序和 App 切換時仍然保持完整的用戶體驗流程。

但是我同時也發現了一些產品運用巧妙的方式使得用戶體驗流程可以延續的產品。在愛奇藝小程序中，當用戶需要觀看一些 App 才能觀看的內容時，用戶可以通過復制一段口令從而在打開 App 時自動跳轉到相應視頻，使得用戶流程不中斷。

同樣一段內容，如果我想看高清版，或者想要給視頻評論，我需要自行在 bilibili 的 App 中搜索相關視頻，這種繁瑣的方式幾乎讓我放棄評論的興趣。

3. 分享機制

除了引導收藏和導流機制之外，在小程序里第二個重要的機制就是分享機制。如何做好分享機制是提高增量的一個必須要思考的問題。 正常的小程序分享分為兩種渠道，分享給好友和群聊，以及分享到朋友圈中。

分享給好友，一般就是以小程序鏈接的形式分享。因為小程序的優勢就在于依附于微信，其社交屬性被大大增強，所以分享按鈕往往要設計的引人注目。常見的設計方式有以下幾種。

在分享時，會有彈窗狀態讓用戶選擇分享的渠道，事實證明，這個彈窗也是可以被設計的。而其中被大部分小程序所選擇的設計感和實用性兼具的這種樣式。

小程序以圖片形式保存后的樣式，由于就是我們常見的 H5 設計，所以在此不做贅述，如果有感興趣的朋友，可以站酷私信的方式或者評論區聯系進行討論。

分享在聊天窗口的小程序，也是可以被設計的內容。這種小程序鏈接一般分為兩個模塊：標題文字 + 配圖。標題文字可以自定義 22個字，起一個有吸引力的文案可以有效增加轉化率。

一般配圖的設計有以下幾種分類：

4. 技術上限

很多同學會有一種擔心，覺得小程序既然如此輕便，會不會在技術上也會受到很多限制，很多特殊的功能無法在小程序當中實現。

這種擔心有依據，但不全對。事實證明，小程序在動效方面，確實被舍棄了很多，很多情況下甚至動效與跳轉邏輯無法匹配，會讓用戶體會到不安的感覺。但是在功能方面，很多已經存在的小程序已經證明，幾乎可以在 App 里實現的功能，小程序均可以實現。

VR看房

貝殼找房和同程藝龍的小程序都可以實現 VR 實景看房，而且在用戶體驗上是可以讓我感受到其真實用途，而不是我一開始認為的噱頭所在。這是我覺得在小程序上最令我吃驚的功能了。

可以發現的是，兩個 VR 看房的功能都是一家叫「如視」的公司提供的技術支持，其實這是一種小程序的發展趨勢，越來越多的功能模塊被第三方機構所替代，而小程序的持有者只需專注于服務與流程設計。那么小程序的門檻將會越來越低，小程序的運營團隊也會越來越精簡，推動著整個生態向良性發展。

地圖導航

另一個技術就是騰訊自家的「騰訊地圖」，可以在小程序端實現實時導航。這也能證明小程序在功能方面的強大屬性。

5. 精美的設計

其實小程序也能做到很精美，下面我將帶大家看一些優秀的小程序設計案例：

京東良研通過良好的視覺設計、動效設計和信息展示方式，使得簡單的投票功能變得生動有趣，簡約明了。

在旅游行業，如何將繁冗復雜的信息排布的清晰易懂是非?？简炘O計師能力的。

同程藝龍就在不增加頁面跳轉的情況下，同時將信息以良好的視覺展示了出來。而在同樣領域的馬蜂窩的設計卻在對比下顯得混亂，除了設計方面的問題，BUG 頻發，諸多的彈窗與廣告也是影響用戶體驗的因素之一。

6. 其他有趣的小功能

設置更新用戶數據功能。

有些小程序一次登陸后，就會永久將用戶數據定格在此，所以當用戶許久后重新打開小程序，陳舊的數據會讓用戶對小程序產生類似的許久不更新的感覺，所以一個更新數據的按鍵是必要的。

誘人點擊的文案。

有時，我們可以通過一些有趣的方式讓用戶完成流程，「JZ多媒體解決方案」的用戶登錄就是其中之一，不像普通的設計，它選用「點擊顯示微信頭像」這樣一個有趣的文案來吸引用戶點擊，從而完成登錄。

外部顯示名稱和小程序本體名稱可以不一致。

同樣的，名稱為「JZ多媒體解決方案」的小程序，外部顯示名稱為「除了干貨其他什么都沒有」。這給我們提供了一種新思路，在初期推廣時，不如把我們的 Slogan 當作名稱寫在外部，是一種推廣的更好方式。

小程序的頂部狀態欄。

我們都知道小程序的頂部狀態欄，右半部分是不可編輯的，那么怎樣可以既適應這個規則，又可以保持小程序的設計感呢？我在諸多小程序中發現了這樣兩種特殊的設計方法。

將 LOGO 放置在頂部狀態欄中。KeepLand 將 LOGO 放置在狀態欄中，既與其他小程序做到了區分，宣傳了品牌，同時又保持了整體的設計美感。

搜索欄不必要非放置在下方。放置在頂部導航欄的左端同樣可以實現空間利用的最大化，同時保持整體的設計美感。

將彈窗設計成系統樣式。

將彈窗設計成系統樣式，可以有效增強小程序的正規感和用戶對于品牌的印象，微信讀書就是用這樣的方法，使得用戶在使用小程序時，同樣體會到與 App 同樣的品牌與視覺感受。

為什么我比看好小程序

結束了上半部分的理論分析，那么我們來聊一聊到底我是怎么看待小程序這個平臺以及這個生態的。

其實不只是企業家需要考慮這個問題，設計師同樣也需要考慮這個問題。前一陣子我一個朋友就來找我訴苦，說他不想在現在這個公司做下去了。原因就是，公司布局了五六個小程序，就是沒有一款 App 的項目提上日程，他以后不想走小程序設計這條路，所以不得已跳槽到一家有 App 產品的公司。其實這個問題轉化出來也很簡單，就是小程序到底有發展前景嗎？小程序是否會成為一個和蘋果搭建起來的 AppStore 一樣的平臺？

事先聲明一點，我不針對個人、企業或者某家資本，對這些將要提及的名字也沒有惡意，還是老規矩，對于商業，我們不談道德，只看決策。

1. 工具無界限，產品有派系

曾幾何時，我們在解鎖共享單車時，第一個打開的就是微信；現如今微信這樣一個培養了我們使用二維碼習慣的產品，卻無法成為人們解鎖單車的首選。

北京市面上存在的單車總共有 7 種：美團單車，摩拜單車，ofo，青桔單車，小藍單車，哈啰單車，永安行。但是目前只有舊版的摩拜單車，青桔單車能用微信小程序掃碼解鎖。（小藍單車小程序已經停止運營，ofo 雖然沒有停止運營，但是在小程序中已經無法搜索到單車服務了）而同樣，摩拜單車和美團單車可以通過美團 App 解鎖，小藍單車和青桔單車可以通過滴滴 App 解鎖。

可以發現，微信對于共享單車界的統治力早已不復存在，現在無論用哪款單車，微信都不是人們首先能想到的入口了。

雖然技術水平上小程序完全可以承載市面上大部分的工具，但是產品之間的派系分別，導致我們可能永遠不可能在微信一款軟件上一勞永逸的體驗到所有服務。就像我們永遠無法在微信小程序中發現「淘寶」小程序一樣。其實小程序在這一步上，已經不可能像App Store 一樣打造一個完整的生態了。阿里一家的存在，就已經讓微信失去了電商行業的半壁江山。

甚至更有趣的是，在小程序熱度排行榜中，位居前十的小程序中有 5 個是騰訊投資的企業下屬產品，還有 1 個是騰訊自身的產品。

但這本身無可厚非，因為這就是正常的商業競爭策略，只是選擇了這種策略生長的小程序，優勢就是可以將流量最大化的向自己的生態中轉化，缺點就是會有很多產品因此無法融入其中，小程序的生態，終究不會是一個全面而完整的生態。

2. 很多小程序都是完整產品的試用版

很多人曾在小程序風靡時預言，將來很多的產品都會入駐小程序，閹割掉次要功能，只保留核心功能在小程序中，這樣才可以既遵循小程序的輕量化原則，又可以讓用戶體驗到產品的優勢，形成轉化。但有趣的是，市場卻形成了另一套完全相反的機制。

Bilibili 小程序可以便捷的讓用戶隨時隨地觀看視頻，但是卻機智的閹割掉了畫質選項。這個小程序確實解決了一部分用戶對于觀看視頻的便捷性、分享視頻的傳播性的需求，但在這個手機流量多到可以鋪張浪費的年代，「高糊畫質」無異于加重了用戶被「望梅止渴」欺騙的想法，而更多的轉向了下載 App 只為了更高清的畫質與更多的操作自由。

微博小程序與 bilibili 小程序的做法如出一轍，雖然微博小程序的功能也很全面，看起來幾乎和微博 App 所具有的功能幾乎一致，但是一旦我們妄圖用微博小程序代替 App 來使用時就會發現，微博小程序竟然不能發帶圖片和視頻的微博。

知乎小程序亦是如此，他幾乎閹割掉了所有用戶和社區互動的渠道，用戶在小程序中只能接受知乎的信息，而無法發布回答與評論（只能點贊或者反對）。

甚至從名稱我們就可以看出微博和知乎想要突出的重點（熱門微博與知乎精選），在于讓用戶瀏覽微博和知乎中已經存在的信息，而當用戶想真正參與進整個社區時，發現幾乎所有的入口都被封死。在知乎中甚至連互動中的評論功能都被閹割掉了，完全給用戶一種隔著玻璃罩看珍藏品般的感覺。

所以各個互聯網產品不約而同的選擇了同一種方法來運營小程序，即小程序永遠是正規 App 的試玩版。因為微信的重點在于社交，而用戶在社交過程中能使用「嗶哩嗶哩」「微博」與「知乎」的場景只有分享社區中的內容這一種場景了。所以所有的互聯網產品都將社區中的主要內容呈現在了小程序中，而所有與分享無關的功能，即使滿足「即用即走」的特性，也并沒有在小程序中保留下來。（比如發帶圖片的微博，這應該非常符合即用即走的特性了，但并沒有被小程序保留下來）

3. 流量與格局

張小龍對于小程序有很多設想，其中一個就是打造一個屬于微信的生態系統，有人曾問我微信小程序生態系統會不會最終能成長為和 IOS 抗衡的力量？

我覺得很難。

2017 年 5 月 18 日開始刷屏，第二天即 5 月 19 日便被微信叫停服務，微信方面給出的理由是，小程序匿名聊聊「涉嫌誘導分享」。這是第一款被騰訊官方明確封殺掉的微信小程序。之后匿名聊聊換殼上線，改名「走心聊聊」。但可惜的是，走心聊聊依然沒有逃過被封殺的悲慘結局，上線沒過多久，走心聊聊便因違反《即時通信工具公眾信息服務發展管理暫行規定》，再次被暫停服務。

如果說「匿名聊聊」觸碰的是微信社交的這塊蛋糕，被封殺是情有可原的。那抖音被微信封殺的過程簡直是讓很多互聯網企業都大失所望。

在第一次封殺 H5 時，微信方給出了明確的回應。該 H5 在最后一頁存在誘導分享行為，違反《微信外部鏈接內容管理規范》，因此平臺對其進行了處理，分享到朋友圈僅自己可見。 但是在微信全面封殺抖音外部鏈接以及切斷使用微信賬號登陸抖音的功能時，微信方卻完全沒有給出任何官方解釋。

如果說封殺抖音是因為頭條系產品（包括今日頭條與抖音）有運用 cookie 機制挖掘用戶在騰訊體系內更多好友關系的嫌疑。但是接下來微信的做法無疑是令眾多互聯網中小企業看到了自己依附微信生存的結局。

據不完全統計，在短視頻盛行時期，微信已經將 20 多款短視頻類 App 的分享鏈接封殺。

但是此時微信卻力推騰訊系的短視頻 App – 微視，甚至為了微視打破了自己既定的規則 —— 開放了在朋友圈上傳 30 秒視頻的權限。

所以其實根本就沒有什么「誘導分享」這樣的說法，網絡上流傳著一句話「微信封殺是中國互聯網公司躲不過的一道坎兒」。

微信封殺你不需要理由，畢竟微信的違規內容中有一條明確地寫道：通過明示或者暗示的方式誘導點擊。但是回過頭一想，廣告的文案不就兩種，明示或者暗示都被微信說了，你放個廣告就不能有文字，既然有了文字，你不是明示就是暗示。

在微信規則范圍內，其對于誘導分享的懲戒存在很大的自由裁量權。所以懲罰你與否，歸根結底就是看你是否觸動了微信的利益，一旦觸動，你就會變成微信重點關照的對象。

事實上，微信這樣的做法也不是一兩天了。在三英（聊天寶、多閃、馬桶 MT）戰微信時，三款產品都被微信封殺了分享渠道。我們其實深知他們很難動搖微信的地位，但是還是很快遭到了封殺，甚至不惜動用其他渠道的力量，阻斷馬桶 MT 的傳播。這種寧可錯殺一千不可放過一個的行為，使得微信再也無法樹立起與蘋果/微軟等平臺公司齊平的公正性。

事實上不僅僅是騰訊如此，中國目前的互聯網環境都清晰的告訴我們，企業之間很難構建真正的信任。我一個美團的高管朋友告訴我，美團在進行設計與開發協作時，并不會使用藍湖，因為他們不信任國內企業。然而在國內使用 invision 又會受限于網速的影響，所以美團干脆開發了一款自己內部的切圖與協作的軟件：印跡，只為協調實用性與保密性。

有朋友可能對這款軟件比較感興趣，我也同樣如此，就問他美團之后會不會讓這款軟件開發注冊，走商業化道路。他說一開始在研發時他們也有這樣的想法，但是由于要提率，所以這款軟件越來越針對美團業務邏輯的方向制作優化，所以即使公開，也會很難為他人所用了。

入駐小程序，有時候也意味著需要將自己的數據交給他人管理，在小程序中，所有基于地理位置為用戶提供服務的小程序，幾乎全部都接入了騰訊地圖。

我雖然不了解其中的運作機制，但是不難看出，很多企業應該跟我抱有類似的想法。當所有數據集于騰訊一家時，自己是否還有立足于市場的根基呢？

4. 那些已經成為平臺的企業是如何看待小程序

在 2018 年 11 月 7 日中國烏鎮的互聯網大會上馬化騰說，微信現在有超過 100 萬個小程序，而在同年 4 月份，Appstore 才收錄了210 萬個應用。也就是說從 2008 年到 2018 年，蘋果用 10 年的時間打造的一個龐大的應用公園，被小程序不到 2 年的時間就從數量上追上了一半。這無疑會讓蘋果與 Google 重新審視小程序這款產品。

事實上，平臺與平臺之間的博弈從來沒有停息過。頭號玩家需要借助平臺來壯大自己，平臺需要頭號玩家來壯大自己的生態系統，但是也會忌憚這些頭號玩家有一天會強大到自己無法掌控，甚至反噬自己。

我們在國內一直看到的微信在自己的平臺上打壓其他的產品，但是反過來在國際市場上，微信何嘗不是架構在別人的平臺上？所以其實我們遍歷微信對待其他產品的策略，反過來，都會成為蘋果制約微信的策略。

還記得在 2017 年 4 月時，蘋果就根據自己的《開發者協議條款》第 3.1.1 項，對蘋果端微信內所有的贊賞內容強行征收 30% 的費用，雖然最終微信和蘋果雙方都做出了不同程度的妥協，但是微信還是做出了「斷臂」一般的抉擇，裁掉了微信公眾號的打賞功能。

雖然表面上看是蘋果對于開發者協議條款的嚴格把控，將公眾號打賞行為歸結為 APP 內購功能，因此要求微信改用蘋果的 IAP（in-AppPurchase 應用內付費），但實際上從時間節點上看，我們很容易發現，蘋果這次的發難明顯是針對小程序以及微信的「鏈接一切」的戰略的，一旦微信將「微信公眾號、朋友圈、微信支付、小程序」這幾個核心功能打通，勢必會對蘋果的生態系統產生較大的影響，蘋果不可能坐視不管。

為什么小程序值得入局

雖然這件事結束后，蘋果和微信再沒有大的爭端，但是外媒卻風評不斷，他們雖然不認為小程序會最終成為制衡 AppStore 的力量，但是卻會搶占中國市場大部分的 App 開發人員的資源，使其向小程序設計與開發傾斜，一旦這種現象嚴重起來，蘋果勢必不能坐視不管。

興許下一次大戰就是微信與小程序進軍國際的那一步。我無法預測這場戰爭的結果，畢竟騰訊做了那么多年的生態，深諳自己是如何通過平臺一步一步贏到現在，現如今他也站在了劣勢方的一邊，勢必也會做好充足準備，但是這對于騰訊也一定是一個傷敵一千自損八百的戰役，而對于我們更重要的是，小程序到時還能不能是我們可持續發展的一個平臺，恐怕誰都不敢保證。

雖然小程序的限制與克制如此之多，但是我并不認為這代表著小程序不適合我們入局，相反我覺得微信的克制是一種純粹的理想，只能存在市場的初期，隨著行業的發展，越來越多的變量已經不在微信的掌控范圍內。小程序已經不再是微信能夠全權把控發展節奏的產品了，而需要主動去迎合時代做出改變。就像現如今的微信一樣，我們無數次在公開場合聽到張小龍說，他不希望用戶在微信上浪費過多的時間，但是微信已不可避免的成為一款超級 App，集合了越來越多的使用場景，甚至有時，手機里只有一個微信就夠了。

1. 頭部復合型小程序出現，使小程序無法保持初心

小程序發展到這一步幾乎是小程序團隊和張小龍沒想到的，本來小程序的屬性是「用完即走」，但是由于微信本身的流量龐大，所以在微信內部不可避免的會出現超級個體（即流量巨頭），這種復合型小程序（也可以稱之為「超級小程序」）幾乎可以不用遵守小程序的規范一樣可以獲得流量，那么越來越臃腫，幾乎是這類小程序不可避免的現象。

比如說在小程序領域耳熟能詳的「美篇」，美篇從微信朋友圈只能發布 9 張圖片的痛點出發，以圖文創作工具切入，成為了當時首屈一指的小而美的工具類產品。但隨著流量逐步增大，美篇開始尋求商業化變現的道路，從工具類產品向社交類產品轉型，最后形成了編輯、分享、閱讀、社交 四大功能的復合型小程序。

而基于圖文內容，以興趣聚合的交流社區，圍繞老師的家長社群，圍繞公務員的同事社群，圍繞攝影旅行的興趣社群，這些都是普通工具類小程序不具備的，但是卻是小程序發展的一個必經之路，同時也是轉型的一個典范。

所以同樣的道理，這就是為什么我不推薦大家在學習如何制作小程序時，去參考頭部的那些復合型小程序。體量大不意味著正規，不意味著遵守規范。

很多復合型小程序的設計其實是和小程序的初衷以及適用場景背道而馳的。這對產品本身并不會有什么過大的影響，因為在他們的考量范疇里，有比遵守規范優先級更高的事情。但是我們如果盲目借鑒，以為這就是小程序的規范，那么最終得不償失。

所以同類型的小而美的小程序，往往更應該成為我們的借鑒對象。

2. 友商的步步緊逼

雖然從數據上看，微信首發優勢明顯，但是其他平臺也不容小覷。從 2019 年上半年開始，各大應用廠商開始逐步布局小程序。小程序平臺從一開始的 2 家到現在已經覆蓋了 8 個平臺。這些平臺也都在積極的擴張小程序：阿里將支付寶小程序擴展到整個阿里系；百度創立了開源聯盟；騰訊旗下的第二大 App-QQ 也正式上線了小程序。

并且在數據上雖然有很大的差距，但是還沒有到達不可逾越的地步。并且除了微信外，幾乎所有的小程序走的都是中心化流量分發的模式。這時由于微信的克制與去中心化，反而讓其他的廠商逐步縮短了差距。

所以，隨著其他平臺的小程序步步緊逼，微信小程序急需一條出路打破目前的困局。某種程度上說，小程序對微信來說，是一場只能進不能退的戰爭，最終也會迫使微信妥協很多本來視為底線的規則。

張小龍在公開場合多次提到，他希望小程序廠商能夠專注于內容本身，而不要去思考流量紅利和不符合規定的裂變玩法。但是如果說市面上只有一款「微信小程序」，那么廠商可能還會更愿意去沉淀自己的內容。但是現實是面對這么多家平臺都開放小程序，那么熟悉平臺規則與政策，研究對應的策略與玩法，幾乎是必然會發生的事情。這基本就意味著，隨著各大平臺紛紛入駐小程序生態，微信對于小程序的底線遵守恐怕是越來越難。

3. 小程序已經成為一種任何平臺都可以復制的商業模式

小程序已經不止代表著「微信小程序」，而是一種任何平臺都可以復制的商業模式，那么去研究小程序的規則和玩法自然是值得的，因為它具有通用性。就像，如果我們一般人都會去學英語而不會去學習都可以法語一樣，因為英語在全世界都可以通用，但是法語基本只能在法國應用。

事實上，已經有小程序廠商開始在跨平臺之間進行積極的布局和嘗試了。汽車之家就是其中典型的例子。通過多平臺布局的方式，大大降低了小程序的開發與學習成本，實現一舉多得。這也是我覺得小程序值得研究和入駐的原因。

4. 微信仍然是目前的一個流量巨頭

據市場研究公司 comScore 稱，智能手機用戶用在設備上的所有時間幾乎都被放在他們使用率最高的 5 款應用上，而且幾乎一半的時間都被用到了使用率最高的那款應用上。

所以在中國，這就意味著大部分用戶的時間都被微信占據，而剩下的 App 則搶占用戶剩余的時間。所以入局微信對中小型企業來說是一個巨大的蛋糕，很少有人會不為此觸動。

總結

大家可以發現，其實我所說的不看好小程序的未來，只是不看好微信小程序的未來，但是小程序這種生態模式，絕對是未來的一個趨勢所在，因為它擁有特定的應用場景，符合人們對于碎片化，場景化的功能與服務的期待。

所以我認為，小程序的設計模式是設計師一定要去學習的，而企業也一定要研究自己的產品是否在小程序下有應用場景，因為誰都不能保證，小程序是否也會有像 App 一樣，發生流量井噴的一天，到那時候如果再上車，真的就為時已晚了。

很多朋友問我為什么挑選這個時間來寫小程序？為什么不趕小程序大火的時候寫？或者為什么不寫一些別的流行趨勢上的話題？

• 第一，寫文章不是為了追趕流行趨勢，而是寫我想寫的內容。
• 第二，只有市場冷靜下來，我們才能更清晰的分析一件事情，包括我在內也是。只引入我思考的過程，而不帶有主觀的偏見，是我寫文章的原則。

希望我能一直帶著這樣的態度給大家帶來更多有益的內容。

另外，由于文章的篇幅有限，很多的內容其實經歷過了很多次篩選，才最終呈現給大家，希望能幫助到正在研究小程序的你。

文章來源：優設

您最近填寫過在線表單了嗎？

答案應該是肯定的。根據最近的研究，84% 的人每周至少會填寫一份線上表單。

雖然你可能沒有感受到，但在線填表單已經成為我們生活中不可或缺的一部分了。

其實，幾乎每個把用戶由 A 帶向 B 的線上交互都是一個網絡表單：與某個公司聯系、訂火車票、購物、訂一晚酒店等等。

網絡表單最早在 1994 年開始用于在線銷售，第一個拖拽式表單 2006 年在屏幕上出現。從那時起，表單已經成為線上交互的關鍵。

企業和客戶之間需要通過網站進行聯系，小到縣城的官網，大到國家政府網站，現在很難想像一個沒有網絡的世界。

但為什么線上表單一直備受詬?。?

當然，確實沒幾個人喜歡填表，但大多數人絕對不會介意填寫那些清晰、簡潔、設計優秀的表單。

其實這也就是癥結所在。太多的在線表單冗長、令人迷惑或讓人感到有所冒犯（有時甚至三者同時出現）。

當表單產生讓人迷惑，或提出的要求超出必要范圍時，用戶的放棄幾率就會大大增加。 有些用戶可能會放棄填寫，甚至退訂整個業務。無論是以上哪種情況，您都不會再有第二次機會。

在設計一個表單的時候，我們怎么保證用戶能填到最后一步？

「創建一個表單很簡單，難的是讓人填完它?！?

在幫助 420 萬用戶創建線上表單后，我們在 JotForm 發現了一件重要的事情，就是一些小小的改變會讓整個事情大有改觀。通常，這些改變都是從那些被放棄的表單中獲得的靈感。

例子：

• HubSpot 發現，當一份 14 頁的潛在用戶登記表，被放在一個單獨的登錄頁上時，用戶填完的可能性要高出 17%。
• Marketo 發現，一些非關鍵的填寫區域，反而讓每位潛在客戶的線索成本上漲了 25%。

表單設計成什么樣呢？應該直觀、簡單以及體驗友好。以下是一些推薦的參考方法。

第一部分：表單的主要元素

1. 歡迎填表者：標題與介紹

無論是誰，歡迎朋友的時候難道不會說「你好嗎？」我們都知道禮貌的重要性，但是在線上卻往往忽略了這一點。

歡迎頁和標題讓您有機會以一種清晰而友好的方式介紹表單和自己，而且還會留下一個良好的第一印象。

看看 BettingExpert 的數據吧：通過修改表單標題來強調「注冊理由」以后，他們的注冊率提高了31.54%。

標題是對下文最短最精的概括。用戶一般都會跳過表單內容，而且幾乎都不會仔細閱讀那種特別詳細的描述。所以用最少的文字說清楚一個表單的目的尤其重要。

標題可以簡單理解為描述被調查者對表格的期望。盡可能保持中立：要確保應答者誠實回答，而不是去滿足出題者的設想。甚至像陳述一個目標這樣簡單的事情，也可能會不知不覺地誘使應答者試圖迎合。

而且現在也需要一份清單，說明應答者應該事先準備的外部文件，沒人想中途去滿屋子找納稅證明或者護照。

如果填表需要很長的時間去完成，一定要提前告知用戶。不過如果是又快又簡單的？讓用戶感到驚喜吧(但不要冒險侮辱任何人的智力，以防萬一)。畢竟，他們能夠通過查看進度條或字段數量來推斷出這一點。

2. 放置相關的標題和副標題

一個有趣的事實：人類會在 50 毫秒內形成第一印象。重點：由于時間不夠長，他們無法仔細閱讀你的作品。

表單用戶很可能就是快速瀏覽一小部分內容，忽略大部分內容。而且有很大可能是他們正在忙著其他事情，無法集中注意力或者幾乎就沒有什么耐心，只想要快點結束。

顯然，我們無法阻止用戶，所以只能通過簡潔明了的標題來引導他們。標題絕對是個得力助手：可以將文本結構化、清晰化、保持用戶的參與度。

用戶應該可以看一眼標題就知道他們應該怎么做，而不是非得把剩下的全部看完。

測試這一點的最好方法是單獨閱讀標題，是否能讓人看懂呢？

3. 問題之間要有分隔符

分隔符很重要。就傳統表單來說，在視覺上把問題隔開以達到減少干擾的最好方法，就是使用分隔符。并不需要在視覺上做出很大的區別，區別太大反而容易分散用戶注意力。

4. 多頁面表單或單頁表單？

這主要取決于表單有幾個議題。

如果只有1，2個議題，單頁表單肯定是最佳選擇。但是如果一個表單有很多議題，那么就需要多頁表單來呈現。想象一下：用戶在面對一個似乎有成千上百議題的表單時，得有多心煩。

5. 強調「行動召喚」（CTAs，Calls-to-Actions）

成功的「行動召喚」強調的是「行動」部分：單擊這個按鈕，用戶要執行什么操作？類似「發送」，「注冊」或者「過程」之類的通用標簽并不會削弱召喚機制。描述越多越好。

為了消除不確定性，試著從用戶的角度回答一下這個問題「我想干什么？」舉個例子，如果是某項服務的調查表單，那就應該是「我需要免費咨詢」。

還需要更多證據嗎？在這類研究中，Unbounce 發現只是把「開始你的試用」換成「開始我的試用」，就提高了90% 的點擊率。

6. 標明表單中的區域

這并不是說要弄得花里胡哨的……

單選框、挑選區域和復選框之所以有效，是因為它們既簡單又常見。表單元素的標準格式等同于更好的可用性。

單選框適用于有很多選項而只有一個可選的情況。復選框用在多項選擇的情況下最好。

為了更短的認知適應過程，要盡可能地使用多選框或者單選框而不是下拉菜單。就像 Luke Wroblewski 說的：「下拉菜單應該是 UI中的最后選擇。」

7. 別忘了「感謝」頁面

記住用戶是花時間的。所以千萬不要唐突結束，要記得說謝謝。

第二部分：怎么寫用戶才愿意看

以下是一些關于表單書寫藝術的小建議。

1. 言簡意賅

從形式上來說，我們都更喜歡簡單的語言，尤其是那些學者，天才和專家。那為什么還有那么多線上對話像是復讀機一樣？

「請接受來自我們最誠摯的道歉。即便如此，我們還是希望能知道您的建議。除此之外……」

像一個老學院派那樣說話只會疏遠用戶，讓他們瞠目結舌。

簡單不意味愚蠢，而是等于可讀性。這意味著最清晰的平白直述。每個詞語都應該是最短，最直接的版本，能用「不過」就別用「盡管如此」。不用行話，不寫復雜句。

你可以通過大聲朗讀來檢查連貫性。耳朵能夠聽到眼睛看不到的東西，特別是在描述那些冗長復雜概念的時候。

2. 擬人化

一份表單應該就像是你和填表者之間的對話。通過用「我」，「你」，「你的」這些代詞來擬人化。

3. 減少被動句

主動語態的表達（比如：約翰寫了一封投訴信）比被動語態（比如：一封投訴信由約翰寫出）更加有力。

被動語態會更冗長，不夠集中。

（譯者注：以下文章中帶橫線的內容適用于英語語法，不感興趣的讀者可自行跳過。）

一個被動語態句子究竟有多糟？這是兩點教訓：

• 動作的執行者不夠清晰（一封信被寫錯了）
• 這個句子的 Be 動詞（to be ,has been,was）后面跟著一個過去分詞。

還是不確定？你可以去查一下微軟 Word 可讀性標準，或者普渡大學語句方法。

4. 盡可能地刪減詞語

許多作者都會陷入這樣的思維誤區：用的詞越多，就顯得他們越聰明。其實不是這樣的。在表單編寫方面，或者說各種寫作中，刪減詞語都要比添加詞語更加有益。

「你刪掉的每一個詞，都會為你多增加一個讀者?！?

在仔細檢查不必要的詞語后，文章會更篤實，更連貫，更吸引人。

刪減重點：

• 副詞（以ly結尾）。
• 無意義的量詞（很多，大量）。
• 空洞的程度形容（副）詞（非常，特別，尤其）。
• 「that」這個詞。
• 非必要信息。
• 模糊詞（東西，少量，大量）。

5. 盡可能使用縮寫

比起完整形態（比如 cannot，is not），語句的縮寫形式（比如 can’t，isn’t）能夠讓文章看起來更簡潔，友好和易讀。

另外，還能節省文字篇幅。一份優秀的表單閱讀性都不錯。

What’s 優于 What is。很簡單。

6. 長句變短句

冗長曲折的句子容易讓人難以理解。密密麻麻的文字堆也是如此。

對于大多數讀者來說，每個句子最多 20 個單詞，每個段落最多 3 個句子，是最合適的。把每個長句都擴成兩個短句。短句實際上并不遜色。

使用空格，項目符號，表格以及打破繁瑣說明的任何其他元素，都會使您的讀者松一口氣。

7. 檢查文字

在我寫博客的過程中，我（艱難地）認識到，優秀的文章是 30％ 的寫作加上 70％ 的編輯。

當你完善了問題，精簡了文字和內容后，把表格存儲好。隔幾天再回過頭來看，你會發現有些之前沒有發現的地方還可以再改進。

第三部分：表單心理學

大多數用戶體驗的心理學原理其實都在人們的潛意識中，所以難以讓人注意到。

但是每種顏色，字體，線條和按鈕都有其用途。

日常的小規模設計可能不如十億美元的營銷活動那么引人注目。但小設計也需要花心思。而且，研究令人愉悅的設計背后的心理學機制很有意思，成本也不高。

以下是一些關鍵的心理原則，這些原則構成了設計優良的表格的堅實基礎。

1. 比較成本和收益

我們做出的每一個決定，從倒垃圾到訂婚，都要經過我們頭腦中的自動成本收益分析。一項任務的成本是否值得完成后的收益？

設計師的工作是確保用戶在感知上收益是大于成本的。

當然，成本與收益是主觀的，填表通常源于義務，而不是受訪者希望從中獲益的行為。除非給受訪者獎勵，否則無法確保收益。但是我們可以把成本降到。

降低受訪者成本的一些關鍵策略:

2. 使用文本塊

+1-919-555-2743 vs 19195552743.

哪個電話號碼會留在你的腦海里？當然是第一個。那是因為它被分塊了。

組塊是一種方便的記憶技術：我們把它用于銀行個人識別碼、社會安全號碼和儲物柜代碼。它指的是將信息排列成「塊」的過程，使內容更容易保留、處理和回憶。

研究聲稱數字 3 是幫助人們吸收和回憶信息的神奇數字。所以盡可能使用它：針對段落，列表，關鍵步驟等等。

3. 定義格式要求

如果可能，避免任意格式化規則。但如果是必要的規則，用紅色記號筆拼寫出來。填表單時，沒人愿意猜。密碼要求、語法規則、編號間距等等，如果一個字段需要特定的輸入，告訴用戶。

席克定律

如果我要舉辦一個晚宴，我總是選擇從當地一家小雜貨店購買我的配料，而不是從一個雜亂無章的超市購買。那是因為有太多的選擇往往會讓人感到麻木。這就是席克定律：它指出，隨著選項增加，做出決定的時間也在增加。

應用到用戶體驗領域，席克定律簡直就是去繁求簡的一劑良方：限制導航選擇，給用戶明確但受限的選項。因為隨著設計靈活性的增加，它的可用性會降低。少即是多。

4. 下定決心（再次）刪除

這個鏈接有什么用？還是右上角的按鈕？如果并沒有增效，那就是減效。每一個字，每一張圖片，鈴鐺圖標或者口哨圖標都不是100% 必需的，這些都會降低你表單的轉換率。

尼爾·帕特爾稱只需刪除一個字段，他的聯系人表單提交率就可以提高 26%。

正如杜魯門·卡波特曾經說過的，「我更相信剪刀，而不是鉛筆?！?

5. 減少打字需求

打字是在線表單中最耗時、最密集的部分，而且經常會導致錯誤——尤其是在手機上。用按鈕、滑塊替換文本框并使用自動完成功能，將減少工作量并提高轉化率。

6. 用條件邏輯縮短表格

根據 Marketing Insider Group 的調查，有 78％ 的互聯網用戶表示來自品牌的個人相關內容會增加他們的購買意愿。而當體驗與用戶無關時，營銷活動的效果將降低 83％。

因此，感謝條件邏輯！

條件邏輯（或「分支邏輯」）通過允許基于特定響應的附加指令——類似：「如果這樣，那么」，簡化了復雜的流程。

使用條件邏輯將不會顯示與用戶無關的問題，從而減少完成表單的時間，從而使他們不太可能放棄前面的任務。

是的，這聽起來像是常識，但是大多數表單都會向每個用戶（無論他們是誰）提出相同的問題。使用條件邏輯是雙贏的，因為通過明確定義用戶細分，可以捕獲更干凈，更有用的數據。

雙重編碼理論

我說樹時。您就會想到樹干、綠葉、樹枝。

我們的大腦就像這樣聰明：它把圖像和文字聯系在一起。

這是雙重編碼理論背后的關鍵原則，該理論指出記憶有兩個不同但相互關聯的系統，一個用于文字信息(「樹」)，另一個用于視覺信息(「樹干、綠葉、樹枝」)。

當某樣東西以兩種方式(圖像和文字)被「編碼」時，它被理解和記住的幾率比僅僅以一種方式(圖像或文字)被編碼的幾率要高。

換句話說，將單詞和圖像配對會使它們更容易記憶。兒童書籍充分利用了這一點。在設計表單時，有兩種方法可以將雙重編碼理論付諸實踐。

7. 信息可視化

我們的大腦處理圖像比處理文本快得多。使用圖標、照片、形狀等線索——無論什么有助于說明你的觀點——都會讓用戶體驗更加直觀。

表單設計應該是一致的，但這并不是說就不能加入一些小驚喜。通過使用非標準的界面元素——如可點擊的圖像和切換的滑塊——可以使表單填寫更加愉快和直觀。

8. 顏色

你知道嗎：用戶最初對產品的判斷有 90% 僅僅基于顏色？

實際上，根據營銷大師尼爾·帕特爾（Neil Patel）的說法，色彩是「購買特定產品的原因的 85％?！拐_的組合可以使讀者人數提高 40％，理解力提高 73％，學習能力提高 78％。

你不需要成為一名設計師來找出哪種配色方案和對比效果最好。像 Adobe Color CC  和 Paletton 這樣方便的程序可以幫助你選擇一個能反映你公司形象的調色板。

9. 讓表單更漂亮

我們是膚淺的生物，習慣于相信有吸引力的設計在其他方面也更好：更快、更智能、更易用。這被稱為「審美可用性效應」，漂亮的界面增加了我們的耐心和忠誠度，甚至讓我們更有同理心。

如果內容或布局不吸引人，38% 的人會停止使用頁面。換句話說，如果線上表單看起來不漂亮(也不容易填寫)，那就是浪費時間。

當然，一百個人心里有一百個漢姆雷特。但是一個簡單的界面、干凈的字體和時尚的造型絕對會贏得用戶歡心。

進度條效應

如果我們知道我們已經取得的進展，我們就更有動力去完成一項任務。特別是已經領先進度的時候，感知上的工作量會相應減少，最終達到超預期效果。美國教授約瑟夫·努內斯和澤維爾·德雷澤將這種現象總結為「進度條效應」——「當人們能看到已付出的努力時，會更有動力完成任務。」

10. 以下是一些適用于表單的進度條效應的應用方式：

問題排列從易到難

如果表單里的問題按照從簡單到困難的順序排列(而且保持邏輯順序)，用戶將快速完成表單的初始階段。這反過來會觸發連勝效應：快速進步和動力感帶來的滿足感，讓用戶不愿意打破連勝。這意味著，當表單變得更加苛刻時，用戶會繼續堅持下去。

畫出進度條

隨時反映用戶的進度。用戶越接近目標，就越有可能完成。如果表單是多頁的，請指出還有多少頁要完成。

一份來自 Clutch 的研究表明 90% 的用戶希望在線表單能有進度條來管控他們的花費時間。

第四部分：問題、回答和分組

1. 用頭腦風暴討論題目

所有的表單的關鍵都是題目。特別是在頭腦風暴討論題目的時候，最好的就是從目標出發，倒推回來。

所以你的第一個問題就是：你的表單的目的是什么？入職表？反饋意見？研究表單？

盡可能地記下你希望從表格中獲得的信息。把它表達為題目(以問號結尾)，而不是靈光一閃。一定留足時間反復推敲。

然后，寫下一些可能的答案，這些答案可能會給你一些靈感。

最后，頭腦風暴討論這些題目，這些題目就會解答剛才提到的第一個問題。

作為調查后的回顧，寫下每個問題的回答百分比。將這些猜測與你的實際結果進行比較，會發現下一輪要注意的盲點。

這種回顧過程還有助于您的設計并節省您的時間。

關于板塊的科學

根據表單轉換率報告，表單類型直接影響表單的板塊數量。仔細考慮每一個板塊的每個問題。

現在，問問自己：你真的、確定、必須要問哪些問題？

多數情況下都不是必要的。但是，即便我們明白少即是多原則，但是真的有機會去用戶的腦子里一探究竟的時候，我們還是希望問題越多越好。

當然，這些問題的答案是很重要。但真的重要到失去用戶都在所不惜么？

你需要用戶的配合。但是每加一個板塊，他們的耐心就會失去一點。所以，在你把所有的題目和答案全列出來以后，能刪盡量刪掉?？紤]收集數據的其他方法，并考慮這個題目是否可以推導出來，或者以后再說甚至完全排除。

盡量避免可選問題。如果必須，請在表單最后列出來。

2. 正確地分組題目

將線上表單結構化是成功的關鍵。

在你經過頭腦風暴討論，修剪精煉得出了最終的問題清單后，就該組織他們了。用一個「主題」標題將它們組織成組和子組，比如說聯系方式，工作經驗等。

這樣一來，用戶不用去讀具體的問題就大概知道自己接下來要做什么。

3. 定義問題的邏輯序列

現在要考慮問題的順序了。按照經驗來看，主題相似的問題，就應該放在一起。

每一個問題，每一個板塊，都應該激勵用戶到下一步。大跨步似的前進會讓用戶困惑，所以要用一種一步一步引導用戶往前的模式。

用戶會通過調節對信息的流動有一種預判。比如說，「你叫什么名字？」應該在「你住在哪兒？」之前，而「介紹一下你的工作經驗？」應該再往后。

4. 決定「必填 vs 選填 vs 友好」

最好的做法是把你的表單只限于必填的問題。選填問題將毫無必要地延長表單并激怒用戶：「你從哪里聽說我們的？」 「你想收到營銷郵件嗎？」

不過對那些非強制性的但是友好的問題，將它們放在表單的末尾，作為可選的后續內容。這樣，他們會感覺不那么有侵略性，也不會影響你的轉化率。

5. 一次只問一件事

雙管齊下的題目會讓用戶覺得模棱兩可。而且——你已經猜到了——模糊的答案無法量化。

看看題目中有沒有用「和」，「或」。找到了嗎？如果有，把這個題目改成兩個。

題目越清楚，答案就越清楚。答案越清楚，數據就越清晰。

6. 提供便利

優秀的表單描繪了一條清晰的路線，通過線索、提示等引導用戶完成表單。路線越短，用戶完成的可能性就越大，所以盡可能地給用戶提供便利。

以下是比較有用的便利方法：

郵編索引

要求用戶填寫地址的時候，最好的方式是只讓他們填寫門牌號和郵編，然后使用郵編索引服務完成地址信息的其他內容。（譯者注：此條比較適用于國外。）

默認提示

默認文本提示是出現在表單字段中描述其預期值的淺色文本。只有在存在潛在歧義的情況下，才應該使用它。

字段標簽

字段標簽是出現在字段上面，關于問題性的文本。它經常都會出現，并且不應該用占位符提示來替代。人們常常為使用默認提示同時作為字段標簽，但卻引發了可用性的問題。

換句話說，你可以使用字段標簽，不用默認提示；但是不能在沒有字段標簽的情況下只有默認提示。

預設答案

大家都喜歡做選擇題。它們可以節省讀者的時間，并且易于評估。

你可以通過回答「是/否」、「單選」或「多選」來預定義答案。如果有一個你無法預測的答案，添加一個「其他」文本框讓讀者輸入一個自定義的答案。

搜索預測

在要求用戶選擇他們的國家、職業或具有大量預定義選項的其他內容時，搜索預測會減少所需的打字量(和認知負荷)。

第五部分：表單的受眾，目的以及環境

表單只完成了一般的工作。它是被動的，不是主動的。表單的效果依賴于填表者。它們需要從一開始就嵌入到框架中。

表單是交流的工具。需要兩方來參與。

因此，在設計表單時，你還需要從用戶的角度考慮……這從他們的目的和環境開始。

為什么要有人填寫你的表格？他們的目的是什么？把它們寫下來。

目的和環境息息相關，所以要讓環境在你的頭腦中具體化。他們在哪里以及如何填寫表格？在家嗎？在筆記本電腦上？在手機上？在地鐵上？

環境不僅僅是場景。關鍵是用戶能明白在他們的幫助下你的表單可以實現什么目的。

1. 知道你的受眾是誰

表單需要吸引目標受眾的注意力——那么，這些受眾由誰組成？

在泛泛人群中思考是沒有意義的。要集中你的注意力，集中在一個人身上——或者說，一個「買家畫像」比任何一個普通人群給你的信息都多。

試著描繪一個理想的用戶畫像，有工作、個性、家庭、希望和夢想。集中思考這個理想用戶群體。他們在哪里生活和工作？他們的觀點和價值觀是什么？他們與你的業務有什么關系？

如果你發現對這些理想群體來說什么是有意義的，你就離最終給你帶來高價值數據的那些問題又進了一步。

這些人就是你需要反復思考的人。這些人就是會給你答案的人。

表單視覺和結構

填表單肯定不會像過生日一樣充滿驚喜。

一致性是保持表單填寫體驗順暢的關鍵。一致就是指顏色要一致、視覺感受要一致、主題調性要一致。

你的公司形象是什么？什么短語和單詞能概括這一點？你的價值觀是什么？在 JotForm，我們注重包容性、友好度和腳踏實地——我們的語言就在傳達這些主旨。

當你定義了品牌調性后，在所有的表單中保持住——你的用戶應該感覺到他們每一步都在和同一個友好的人互動。

視覺一致性同樣重要。在整個表單中都應該用一種視覺風格(以后創建的其他表單同樣如此)。

2. 左上對齊標簽

Google 的 UX 研究人員發現，將標簽左上對齊會減少表單完成時間，因為它需要的「視覺注視」更少。

3. 避免將問題并排放置。

眼動研究表明，簡單的單列布局比并排放置的多列布局要好。

該規則的唯一例外是要求輸入日期（日，月，年）或時間（小時和分鐘）時，其中多個字段應在一行上。

4. 嘗試一頁一事

每頁一件事是一種心理技巧，定義為：

「將一個復雜的過程分解成多個小步驟，并將這些小步驟單獨用一頁來呈現?！?

本質上，用戶只需要關注一件事。一條信息、一個決定、一個問題要回答。

整潔的頁面鼓勵用戶繼續執行任務。

5. 用輸入框長度提示用戶

把輸入框的長度控制到正好能夠包含所有的輸入字符的長度（用戶可以看到填入的完整內容）。

輸入框的長度應該反映用戶預期輸入的文本量。郵政編碼或門牌號等字段應該短于地址行。

貝馬爾德研究所的可用性研究發現，如果一個字段太長或太短，用戶開始懷疑他們是否正確理解了標簽。這尤其適用于具有異常數據或技術標簽的字段，如信用卡背面的 CVV 碼。

表單設計中的錯誤和完成路徑

就像生活中一樣，填寫表格時有可能出錯就像生活中一樣，關鍵問題是發出錯誤信號并允許快速糾正。

6. 不要只靠顏色

十分之一的男性有一定程度的色盲。

當顯示驗證錯誤或成功消息時，不要依賴使用綠色或紅色文本(因為紅綠色盲相對常見)。使用文本、圖標或其他東西。JotForm Cards 用一個微動畫警告用戶，當出現錯誤時，該動畫會說「錯誤」。

7. 在同一行內指出錯誤

向用戶顯示錯誤發生的位置，并說明原因。
如果您必須使用驗證，請確保它是內嵌的(在字段的右側)，并提前報告錯誤。不要等到用戶點擊提交來報告驗證錯誤。但是同樣，內聯驗證不應該是實時的，因為這可能會在用戶完成字段之前報告錯誤。

8. 使用字段驗證

你需要一個電子郵件地址，你會收到一個沒有@符號的回復。你要求一個電話號碼，而你的回答中有一半位數不夠。

打字錯誤不應該成為表單可用性的障礙。

使用「字段驗證」來確保得到您需要的答案，例如，「答案必須包含__」

JotForm Cards 恢復錯誤輸入域名的用戶的電子郵件地址；約翰@ gnail . com 應該是 john@gmail.com。

9. 但別太苛刻

如果用戶回答的方式有很大差異(例如，用+12345678912、+44 12345678912、012345678912回答「電話號碼」)，請將其轉換為一致的格式。

第六部分：關于支付表單

什么是支付表單？

支付表單就是線上的收銀臺。它授權在線支付，驗證用戶的詳細信息，檢查資金是否可用，并確保你收到支付。

支付整合有很多優勢。他們幫助你 ：

• 銷售產品或服務；
• 在結算過程中進行復雜計算，例如增加稅收和運輸成本或減去優惠券；
• 呈現你的產品描述，如圖片、數量、顏色和尺寸選項；
• 收集固定金額的捐款和付款，或者通過訂閱服務保證周期性付款。

在設計支付形式時，遵循最佳實踐是至關重要的。以下是一些關鍵規則。

1. 限制付款步驟

Baymard 研究所分析了支付表單，發現支付過程太長或太復雜是放棄支付的主要原因之一。所以一定要分塊，分得越細越好。

2. 使用安全視覺提醒

當輸入敏感的細節，如信用卡細節時，用戶會對任何看起來可疑的東西保持高度警惕。最近的一項研究顯示，出于安全考慮，17%的購物者沒有付費就離開了頁面。

專業的支付形式讓用戶感到輕松，而任何看起來「不舒服」的東西都會讓他們感到緊張。這就是為什么你應該從頭開始構建支付表單時就保持謹慎——即使是最小的錯誤或不一致也會嚇跑用戶。

它還有助于在表單上啟用 SSL 來幫助保護數據。用戶知道所有的互動都是加密的，因此可以安心。JotForm 是最安全的數據傳輸方式:我們符合支付卡行業數據安全標準 (PCI DSS) 1級，并啟用了 SSL。

3. 清楚地解釋你為什么要求敏感信息

人們越來越關注隱私和信息安全。如果你要求必須填寫敏感信息，請確保使用字段下方的注釋文本解釋為什么需要這些信息。

4. 保存數據

讓用戶可以選擇保存他們的地址和支付信息，可以使這個過程更快、更簡單——尤其是在手機這樣的設備上。這同時也會給回頭用戶一種獎勵和忠誠的感覺。

5. JotForm添加支付集成的方式

• 第 1 步:添加你的品牌標志和定制風格。
• 第 2 步:使用鏈接按鈕輸入集成憑據，或者直接輸入。
• 第 3 步:添加產品圖像、產品細節，如數量、顏色、尺寸。
• 第 4 步:計算優惠券、稅金和運費。（你可以使用集成采購訂單來檢查通用付款字段創建的詳細信息和選項(這不需要任何憑證，因為它不會創建真正的交易)。你可以查看 Sofort 集成指南作為示例，了解整個支付過程。）
• 第 5 步:寫一封私人感謝信——自動回復郵件。

一切就緒。現在你可以在網站、博客或社交媒體上輕松銷售你的產品。當你完成表單后…萬歲！完成了！但是……等一下。你的表單可能已經完成，但現在還不是發出去的時候…

還有最后一個步驟。

6. 發出前，測試您的表單

我們都有盲點。所以保持謹慎很重要，畢竟數據的質量決定了表單的成功。因此，需要事前檢查一下調研題目，確保答案選項的完整可靠，沒有任何遺漏。

把表單發送給家人/朋友，并要求他們記錄填寫表單需要多長時間，以及對這一連串的問題他們體驗如何。這也將有助于你下次評估表單的設計。

文章來源：優設

畫插畫可以用哪些構圖方式？他們的優缺點是什么？本文總結了9種常見的構圖方式。

框式構圖

對角線構圖

向心式構圖

對分式構圖

三角構圖

垂直線構圖

緊湊式構圖

S型構圖

三分式構圖

近一年多接觸到了插畫 Banner 設計，算是自己邊做邊摸索，還在學習探索期，目前總結了一些做稿的思路，分享的目的是為了梳理完善自己的方法論，讓自己繼續向前進一步。

本篇文章分享內容：插畫 Banner 的三個層次。

插畫 Banner 的三個層次：文案層、畫面元素、背景層。

文案層

• 文案樣式：左對齊、居中對齊、右對齊。
• 文案組合設計形式：上下組合、上中下組合、一體組合。

畫面元素層

• 主體元素
• 相關聯元素
• 點綴元素

相關聯元素和點綴元素可以二選一，也可以同時使用，具體根據設計畫面而定。

背景層

以下內容是我目前總結的背景層類型。選擇背景時的注意事項：背景一定要和元素風格一致。我經常會出現這樣的問題，主體物和背景不融合，導致設計看起來主體元素是貼上去的。

注：以上所用到的圖片素材均來自于懶設計、稿定設計

Banner 設計畫面千千萬，套路來回就幾樣。希望大家能在框架的基礎上進行思維發散，創作出好的作品。

定量的設計套路（不變）+百變的設計風格（變）=屬于你的千變萬化的 Banner 作品