今天想跟大家聊一下交互設(shè)計經(jīng)驗，不過要先說明，雖然文中， 有很多地方用到了“公式、概念、變量”，但是這些都不是“學(xué)術(shù)、學(xué)霸級”的，反而是精簡必要存在的。

 

“這個項目很急開發(fā)資源少，要設(shè)計地盡量簡單”

這可能是交互設(shè)計師最不喜歡的一句話。因為設(shè)計“創(chuàng)新、細膩、高級”的交互方案是我們的天職，“簡單低成本”這種設(shè)計需求簡直在褻瀆交互使命。最近筆者遇到了很多這類項目，但設(shè)計師總要幫助項目解決問題。于是最終還是很開心地把項目搞定，順便總結(jié)了一下：如何在交互設(shè)計層面，合理地降低開發(fā)成本，與大家分享。主要回答以下幾個問題：

 

． 

降低開發(fā)成本的“設(shè)計方案簡化工作”，應(yīng)當在什么時機進行？

． 

． 

簡化工作有著怎樣的底層原理？

． 

． 

具體如何開展簡化工作？

． 

． 

文末附贈簡化工作需要用到的工具

． 

 

1. 簡化工作的時機

若要簡化設(shè)計方案，首先需要有一個大致的方案。具體而言，在“功能架構(gòu)圖”的階段進行簡化設(shè)計工作是比較合適的。因為在這個階段，設(shè)計師已經(jīng)對未來的交互稿在范圍上有了比較清晰的了解。知道要做哪些功能，PRD中缺了哪些功能，大概有哪些交互流程。另一方面，這個階段還沒有開始繪制交互稿，所以變動成本相對較低，簡化起來可以大刀闊斧。

簡化工作對“功能架構(gòu)圖”的要求比較高，設(shè)計師需要將架構(gòu)圖寫得很詳細。如果架構(gòu)圖比較粗糙，簡化后可能會遺留各種潛在隱患，導(dǎo)致后期變動交互稿，從而讓前面的簡化工作失去意義（畫詳細的架構(gòu)圖并不會浪費時間，因為架構(gòu)圖里的很多細節(jié)，就算前期不考慮后期也是要花時間考慮的）。功能架構(gòu)圖可以按照下面的結(jié)構(gòu)來撰寫：

這部分比較基礎(chǔ)，就不具體介紹了。其中值得注意的一點是，架構(gòu)圖中不僅應(yīng)當包含功能，還應(yīng)當包含交互層面的描述。若有疑惑，可以參考下面的例子-Web端視頻評論功能架構(gòu)圖：

 

2. 簡化的基本原理

功能架構(gòu)圖中的條目，哪些應(yīng)該簡化，哪些不可以簡化呢？這個章節(jié)會詳細介紹一下具體的原理方法，做一個了解，實際“簡化工作”中用不到。

 

2.1. 優(yōu)先級公式

從交互層面而言，是否要開發(fā)一個功能/交互的決定因素，無非是“用戶體驗影響力”和“開發(fā)成本”。我們更希望做那些開發(fā)成本低，用戶體驗提升多的設(shè)計。不喜歡做那些開發(fā)成本高，但卻對用戶體驗影響不大的設(shè)計。所以可以得到下面的公式：

優(yōu)先級 = 體驗影響力 / 成本

上述公式中的“體驗影響力”，可以看作是某個功能給用戶所有使用場景產(chǎn)生的體驗影響力總和，而功能對每個場景的體驗影響力則是“完美方案的體驗值”與“妥協(xié)方案的體驗值”的差值，所以得到以下公式（場景使用率可以簡單理解為用戶的使用率，后文細講）：

體驗影響力 = （完美方案體驗值 - 妥協(xié)方案體驗值）*場景使用率

于是，對于某個功能/交互而言，它的優(yōu)先級公式是：

優(yōu)先級 = （完美方案體驗值 - 妥協(xié)方案體驗值）* 場景使用率 / 成本

接下來我們來聊一下上述公式中的每一個變量：體驗值、場景使用率、成本。

 

2.2. 場景的寬度與深度

在討論公式的3個變量前，我們首先要了解一下場景的寬度與深度。

場景寬度比較容易理解，比如上文中的評論功能，用戶評論時可能想要使用文字評論、圖片評論、動圖評論、語音評論等等，如果每一個場景都能滿足就是場景很寬。而場景深度則指一個具體場景的細膩程度，比如同樣是文字評論功能，用戶輸入文字時候，如果輸入文字比較多，文本框就會響應(yīng)式變高，方便輸入大量文字。這種設(shè)計就可以看作是場景深度上的拓展。

在一般意義上，場景越寬意味著覆蓋的場景越全面（滿足更多用戶需求），場景越深意味著某一場景的體驗越好。這兩者組成的面積就是產(chǎn)品體量，也就意味著成本（如上圖）。但如果需要削減成本，我們就不得不減小場景的“寬度”和“深度”。

 

2.3. 體驗值

首先我們簡單介紹一下體驗值。上圖描述的是“體驗”和“場景深度”的關(guān)系，體驗值的原點是“正常體驗”，向上是體驗極好，向下是體驗極差。一般而言，如果在場景深度上太淺，場景內(nèi)的很多細節(jié)沒有考慮，則體驗值會低于“正常體驗”，如果場景深度很深，設(shè)計細膩，則體驗值則會高于“正常體驗”。對于具體的項目而言，還會有產(chǎn)品方的“目標體驗值”和“底線體驗值”。目標體驗值是產(chǎn)品方希望這個產(chǎn)品/功能給用戶帶來的體驗效果，底線體驗值是能夠接受的最低體驗效果。

那么我們?nèi)绾稳ズ饬矿w驗值呢？為了衡量的簡單方便，筆者不建議將體驗值再進行維度細分，其實只要通過主觀評分量表進行評估即可（非單人評估，所以客觀性有一定保障），如下圖：

體驗值的主觀評分量表，0代表正常體驗，50%代表體驗極好，-50%代表體驗極差。由于“是否低于目標體驗值”、“是否低于底線體驗值”對于衡量設(shè)計方案較為重要，所以在量表中需要用顏色標出來。上圖是一個“評論內(nèi)容懶加載功能”的“優(yōu)先級評估表”，當前項目的“目標體驗值”是5%，“底線體驗值”是-10%?？梢钥吹健巴昝婪桨浮边_到了“目標體驗值的”，而妥協(xié)方案沒有達到“目標體驗值”，所以標注了黃色（如果不能達到“底線體驗值”就標注紅色）。

 

2.4. 場景使用率

嚴格意義上講，場景使用率應(yīng)當指：一個功能/交互被使用的場景在所有用戶使用場景中所占的比例。比如，500個用戶1天內(nèi)產(chǎn)生了1000次訪問，在這1000次訪問中每個用戶有10個訪問場景，也就是共計10000個訪問場景，其中使用“評論點贊功能”的場景有1000個，那么這個功能的場景使用率就是10%。但為了方便，我們可以把場景使用率簡單理解為用戶使用率，也就是500個用戶中，有幾個用戶會使用這個“評論點贊功能”，比如是50個，那么這個功能的使用率就等于10%。

這里我們插敘一下“場景使用率”和“場景寬度”的關(guān)系。上文中我們講到，場景越寬越好，因為可以滿足更多用戶的場景。但如果要節(jié)約成本就必須壓縮場景寬度，那么壓縮場景寬度有著怎樣的原則呢？產(chǎn)品中的所有場景一般遵循類似于“冪函數(shù)”的分布方式（如下圖），使用率高的場景較少且集中。如果要壓縮場景寬度，應(yīng)當優(yōu)先刪除那些“場景使用率較小”的場景，這樣不僅減少了工作量，且對大部分用戶產(chǎn)生的負面影響都比較小。

 

說回場景使用率，場景使用率的評估方法同樣推薦使用主觀評估法，評估的數(shù)值填寫在“優(yōu)先級評估表”中（如下圖，同上文的表）。需要說明的是，如果評估人對產(chǎn)品的日常數(shù)據(jù)不了解，可能會降低評估的準確性。

 

2.5. 成本

成本主要指開發(fā)成本，可能包含：前端/客戶端開發(fā)成本、服務(wù)端開發(fā)成本、應(yīng)用服務(wù)端開發(fā)成本、算法開發(fā)成本、QA測試成本。為了評估的便捷性，我們可以邀請項目中的技術(shù)負責人籠統(tǒng)地評估“整個開發(fā)成本”，以“天”作為單位，評估的結(jié)果同樣填寫在“優(yōu)先級評估表”中，如下圖：

2.6. 計算優(yōu)先級系數(shù)

在得到幾個變量的值后，便可以代入上文中的公式，得到優(yōu)先級系數(shù)了（文末附件的表格中已經(jīng)做好公式，公式中對“成本”一項開了1/2次方降權(quán)，如果項目很急成本控制很重要可以不開），如下圖所示。為了優(yōu)先級系數(shù)查看起來比較直觀，可以在公式中加一個常量系數(shù)，筆者用的是1000?？梢钥吹竭@個“評論內(nèi)容懶加載”功能的優(yōu)先級系數(shù)是32 。

3. 開始簡化工作

3.1. 材料準備

詳細的功能架構(gòu)圖（不是PRD中的功能列表），電子版即可；

優(yōu)先級評估表，文末有下載方式，同樣電子版即可；

 

有投屏的會議室；

3.2. 評估對象

一般而言，功能架構(gòu)圖中的大部分條目都是“無需商量必須要做”的，只有少部分是需要商榷。所以，設(shè)計師只需要挑選出來可能有爭執(zhí)的條目進行優(yōu)先級評估。這種做法也大大減少了“簡化工作”本身的工作量。

3.3. 評估人員

交互設(shè)計師；

 

產(chǎn)品經(jīng)理：對方案的簡化很多時候會涉及到需求層面，所以在做評估時需要產(chǎn)品經(jīng)理在場；

 

項目技術(shù)負責人：因為要評估開發(fā)成本，所以需要邀請“項目技術(shù)負責人”或者其他“能夠評估項目開發(fā)成本的人”參與；

 

3.4. 評估過程

評估過程就是將“優(yōu)先級評估表”填好（如下圖），建議采用“所有人一起協(xié)商”的方式進行評估，無需分別評估最終求平均值。因為協(xié)商評估的效率更高，且有討論過程，不會出現(xiàn)評估后仍有疑義需要二次討論的情況。在得到“優(yōu)先級評估表”后，所有人共同決定“簡化哪些功能/交互點”，達成一致后評估過程就算結(jié)束，整個過程耗時一般在40分鐘左右。

 

4. 最后總結(jié)

1、雖然本文比較長，但大部分都在敘述基本理論，實際操作其實很簡單。一次評估工作大概40分鐘左右，但卻能節(jié)省大量的開發(fā)時間，以及后期變動引發(fā)的多方時間浪費。

 

2、可能有些人會質(zhì)疑，為何不在需求評審會上完成“簡化工作”。這是因為PRD的粒度一般比較粗，設(shè)計師在動手設(shè)計時經(jīng)常會加入一些場景中需要的小功能點，而這些小功能點并不在PRD范圍內(nèi)。另外，同樣的功能，在PRD功能列表里看起來好像很簡單，但經(jīng)過設(shè)計師細化后就不好說了，所以在需求評審會上很難真正意義完成“簡化工作”。

 

3、簡化工作一定要安排在設(shè)計師剛產(chǎn)出“功能架構(gòu)圖”的階段，如果稿子已經(jīng)開始畫了，此時簡化方案就會陷入“一直改稿子”、“修修補補”的窘境，最終你的稿子一定會有各種邏輯漏洞。

 

4、對于比較緊急的項目，如果前期沒有做好簡化工作，后期開發(fā)人員會漸漸發(fā)現(xiàn)一個問題–時間不夠了，因為在正式寫代碼前大家對于開發(fā)量總是抱有非常樂觀的態(tài)度。直到意識到問題后他們才會跑過來要求“刪掉某些復(fù)雜的交互”、“刪掉各種他們覺得不重要的功能點”，這樣的故事經(jīng)常發(fā)生。

 

5、簡化掉的“功能/交互”，最好記錄在協(xié)作平臺上，安排到未來的某個版本中；