感謝導(dǎo)語(yǔ)：在互聯(lián)網(wǎng)時(shí)代，各種各樣得APP不斷地推陳出新，系統(tǒng)和功能也在不斷地升級(jí)，本篇文章感謝分享通過(guò)從大廠APP中同類型得APP進(jìn)行同款功能得PK，分析其中得優(yōu)缺點(diǎn)以及存在得問(wèn)題，感興趣得一起來(lái)看一下吧。

互聯(lián)網(wǎng)信息化時(shí)代，隨著產(chǎn)品越來(lái)越多，我們打開(kāi)手機(jī)仔細(xì)看得話會(huì)發(fā)現(xiàn)，頁(yè)面布局都是類似得甚至交互方式也很像。

確實(shí)，大多數(shù)產(chǎn)品設(shè)計(jì)顯示出一種趨同性，但是趨同性并不是缺點(diǎn)。

降低用戶學(xué)習(xí)成本要求盡可能依據(jù)用戶既有經(jīng)驗(yàn)進(jìn)行任務(wù)和流程設(shè)計(jì)。

雅各布定律認(rèn)為，用戶將大部分時(shí)間花在別人家得產(chǎn)品上，而不是你得。

這意味他們希望你得產(chǎn)品跟別人得有相同得操作方法和使用模式。

但筆者也注意到，一些產(chǎn)品在這樣得趨勢(shì)中仍然保持著難以被模仿得水準(zhǔn)，及優(yōu)秀得用戶體驗(yàn)。

筆者列舉了6個(gè)產(chǎn)品中得3個(gè)功能進(jìn)行思考分析：為什么他們能夠脫穎而出？

一、哈啰出行 VS T3出行1. 對(duì)比分析

在這特定景下二者流程基本是一致得，從截圖可以得知得區(qū)別在于：用戶強(qiáng)制退出后，哈啰出行并沒(méi)有調(diào)用取消訂單得下車點(diǎn)數(shù)據(jù)返回到前端顯示在【下車點(diǎn)】供用戶選擇。

在正常流程下：用戶打車取消訂單后，哈啰出行和T3出行都會(huì)有一個(gè)【是否重新叫車】得選項(xiàng)，選擇【是】則會(huì)調(diào)取用戶之前已取消訂單得數(shù)據(jù)作為上車點(diǎn)和下車點(diǎn)，用戶不需要重新選一遍。在異常流程下：用戶強(qiáng)制退出后重新叫車，那么哈啰出行得體驗(yàn)就沒(méi)有超出用戶預(yù)期，因?yàn)楣鲂嗅槍?duì)異常流程并沒(méi)有提供給用戶解決方案。

注：感謝所述得是，用戶打車后—取消訂單——強(qiáng)制退出——重新打車，這一特定使用場(chǎng)景。

因此其他（比如是否聯(lián)網(wǎng)、訂單是否付款、預(yù)付車費(fèi)等）這些異常流程沒(méi)有體現(xiàn)在流程圖上。

1）哈啰出行

強(qiáng)制退出APP后，用戶重新叫車得下車點(diǎn)和取消訂單得下車點(diǎn)一致，那么就需要重復(fù)操一遍，增加了用戶使用成本，降低了用戶打車效率。

2）T3出行

強(qiáng)制退出APP后，用戶重新叫車，直接選擇將取消訂單得下車點(diǎn)，作為本次訂單得下車點(diǎn)。

不需要重新操作一次。

提前偵測(cè)用戶預(yù)期，自動(dòng)把期望得操作結(jié)果呈現(xiàn)出來(lái)，而不需要用戶參與。

看似很小得功能，但是結(jié)合特定得使用場(chǎng)景，為用戶多想一步，直達(dá)快捷得操作入口，提供最短得操作路徑完成需求，降低用戶操作得成本與時(shí)間。

3）設(shè)計(jì)思考

如何做出超出用戶預(yù)期得產(chǎn)品體驗(yàn)？

為用戶多想一步，考慮用戶在不同場(chǎng)景下使用過(guò)程中會(huì)出現(xiàn)得問(wèn)題；在設(shè)計(jì)中非常有必要考慮防錯(cuò)機(jī)制，尤其是用戶得操作具有毀滅性效果得功能時(shí)。

在偵測(cè)用戶預(yù)期上：T3出行做得比哈啰出行更出色。

二、感謝閱讀朋友圈 VS 感謝對(duì)創(chuàng)作者的支持空間說(shuō)說(shuō)

感謝閱讀朋友圈發(fā)動(dòng)態(tài)和感謝對(duì)創(chuàng)作者的支持空間發(fā)說(shuō)說(shuō)，業(yè)務(wù)流程基本一致，甚至界面布局也比較相似。

區(qū)別在于用戶感謝文字內(nèi)容超出蕞大字?jǐn)?shù)限制后，二者得交互細(xì)節(jié)。

1. 感謝對(duì)創(chuàng)作者的支持空間寫說(shuō)說(shuō)

觸發(fā)：用戶感謝文字時(shí)，內(nèi)容超出蕞大字?jǐn)?shù)限制（10000字）。

行為：右上角得【發(fā)表】按鈕置灰，右下角提示當(dāng)前內(nèi)容超出得字符數(shù)，用戶可以感謝但不能發(fā)布。內(nèi)容在蕞大字符數(shù)內(nèi)，【發(fā)表】按鈕恢復(fù)。

2. 朋友圈發(fā)布動(dòng)態(tài)

觸發(fā)：用戶感謝得內(nèi)容超出蕞大字?jǐn)?shù)限制（2000字），感謝閱讀【發(fā)表】。

行為：?jiǎn)未_認(rèn)按鈕提示彈窗頁(yè)面居中出現(xiàn)，出現(xiàn)后感謝閱讀【我知道了】按鈕，彈窗消失。

1）對(duì)比分析

用戶在感謝閱讀朋友圈發(fā)動(dòng)態(tài)，在感謝內(nèi)容時(shí)如果超出蕞大字?jǐn)?shù)限制（2000）系統(tǒng)不會(huì)提示用戶，用戶只有感謝閱讀【發(fā)表】才知道，原來(lái)自己得內(nèi)容超出限制了不能發(fā)表。這種反饋相對(duì)來(lái)說(shuō)是非常遲鈍了，雖然不會(huì)影響主流程得提交，但是會(huì)導(dǎo)致用戶不能及時(shí)發(fā)現(xiàn)錯(cuò)誤，需要重新回過(guò)頭再感謝、再提交、再報(bào)錯(cuò)，這樣會(huì)嚴(yán)重影響使用效率。用戶在感謝對(duì)創(chuàng)作者的支持空間寫說(shuō)說(shuō)，當(dāng)感謝內(nèi)容超出蕞大字符限制后，即被告知用戶字符超出限制，而不是等用戶全部感謝完內(nèi)容感謝閱讀【發(fā)表】后才提示，實(shí)時(shí)狀態(tài)將錯(cuò)誤扼殺在搖籃中。感謝對(duì)創(chuàng)作者的支持空間有效得在用戶出錯(cuò)之前就盡量避免錯(cuò)誤得發(fā)生。

2）設(shè)計(jì)思考

感謝閱讀如此國(guó)民級(jí)產(chǎn)品會(huì)犯這種低級(jí)錯(cuò)誤么？

“感謝閱讀朋友圈不鼓勵(lì)發(fā)文字，是因?yàn)樾畔鞑ビ械燃?jí)，支持門檻低”?！獜埿↓?/p>朋友圈功能存在意義在于：促進(jìn)用戶朋友之間得關(guān)系，使其更加親近、相互了解。用支持、視頻、文字等功能…可以更詳細(xì)、更形象地描述用戶得生活。讓朋友間得生活、思想有更進(jìn)一步得了解。試想，朋友間相隔兩地用照片或者視頻再加上用戶內(nèi)心感受得文字描述，來(lái)闡述事情所發(fā)生得過(guò)程，才能達(dá)到即使朋友不在現(xiàn)場(chǎng)也可以感受到現(xiàn)場(chǎng)氣氛得水平。另外，朋友圈非張貼復(fù)制得文字內(nèi)容如果超過(guò)100字就會(huì)在顯示得時(shí)候被折疊。更何況用戶文字感謝2000字以上得內(nèi)容發(fā)朋友圈概率是很小得。

所以感謝閱讀在極限字?jǐn)?shù)得處理從實(shí)際使用場(chǎng)景上看：并不能算做bug。

從程序角度看：感謝對(duì)創(chuàng)作者的支持空間在內(nèi)容錄入字?jǐn)?shù)極限值得交互細(xì)節(jié)上比感謝閱讀朋友圈體驗(yàn)更細(xì)致。

三、美團(tuán)截屏分享 VS 百度網(wǎng)盤截屏分享1. 百度網(wǎng)盤

觸發(fā)：截屏觸發(fā)分享控件，浮層由下之上滑出，頁(yè)面其余部分顯示為半透明遮罩。

行為：感謝閱讀遮罩處或右上方浮層關(guān)閉按鈕，浮層向下收起，半透明遮罩消失。

2. 美團(tuán)

觸發(fā)：截屏后生成當(dāng)前頁(yè)面縮略圖且居中出現(xiàn)，其余部分為半透明遮罩。觸發(fā)分享控件，浮層由下之上滑出。

行為：感謝閱讀遮罩處或底部取消按鈕，浮層向下收起，頁(yè)面縮略圖及半透明遮罩消失。

1）對(duì)比分析

如果單看美團(tuán)截屏得第壹張圖——都會(huì)認(rèn)為左邊屏幕留白太多 空著一大塊，視覺(jué)上極不協(xié)調(diào)。

甚至?xí)朊缊F(tuán)也會(huì)犯這種低級(jí)錯(cuò)誤？相信大部分人對(duì)于這種“分享控件”需求會(huì)這樣設(shè)計(jì)：

【左右對(duì)齊、水平分布排列3個(gè)分享圖標(biāo)】，因?yàn)榘俣染W(wǎng)盤確實(shí)就是這么干得。

在百度網(wǎng)盤截屏分享時(shí)：ios用戶（沒(méi)有關(guān)閉感謝截屏功能得）截屏后左邊感謝閱讀好友得按鈕，被系統(tǒng)得“感謝截屏窗口 ”遮擋了一半，導(dǎo)致用戶難以準(zhǔn)確感謝閱讀。因?yàn)閕os用戶 截屏后左下角都會(huì)出現(xiàn)感謝截屏窗口，只有左滑才會(huì)消失，否則感謝窗口會(huì)停留5秒鐘。如錄屏所示：用戶很容易點(diǎn)到截圖感謝，再返回需要退出2次，操作路徑很繁瑣。因此美團(tuán)左邊得留白其實(shí)是為ios用戶截屏后“感謝截屏窗口”特意預(yù)留得位置。用戶在美團(tuán)截屏后感謝閱讀好友感謝閱讀就不會(huì)受到影響。美團(tuán)考慮到了當(dāng)前產(chǎn)品得交互方式和系統(tǒng)“沖突”時(shí)，根據(jù)系統(tǒng)得特性做出調(diào)整。美團(tuán)靜態(tài)圖上看似不協(xié)調(diào)得布局方式實(shí)際是考慮到了不同得用戶在實(shí)際使用中得真實(shí)場(chǎng)景。

2）設(shè)計(jì)思考

為什么眾多大廠產(chǎn)品都中意這種底部浮層得截屏分享交互方式？

缺點(diǎn)：分享圖標(biāo)容易與ios系統(tǒng)截屏感謝窗口沖突。

優(yōu)點(diǎn)：

方便用戶感謝閱讀，也是費(fèi)次定律運(yùn)用得體現(xiàn)。并且據(jù)研究表明，人們?cè)谑褂檬謾C(jī)得時(shí)候，75%得交互操作都是由拇指驅(qū)動(dòng)得，而拇指默認(rèn)懸停得位置恰好在屏幕下方，用戶操作成本小。對(duì)用戶干擾程度低，浮層在底部屏幕展示得內(nèi)容多，對(duì)用戶瀏覽其他內(nèi)容影響較小。比較符合用戶預(yù)期。拓展性強(qiáng)，如果在版本迭代中遇到增加或者修改得需求，改動(dòng)很方便基本上不影響界面布局，前端調(diào)整起來(lái)很快。用戶習(xí)慣，不僅局限于分享，很多功能都采用這種底部浮層得交互方式，遵循培養(yǎng)出來(lái)得用戶習(xí)慣操作。

當(dāng)產(chǎn)品交互方式與系統(tǒng)“沖突”時(shí)美團(tuán)注意到了這一點(diǎn)，并且做出了解決方案應(yīng)對(duì)。

四、結(jié)語(yǔ)

盡管有越來(lái)越多得產(chǎn)品趨同，但是在用戶體驗(yàn)、交互設(shè)計(jì)得每一個(gè)流程，我們依然能體會(huì)到差異。

誰(shuí)能夠更好地把握用戶得情感訴求、站在用戶角度考慮設(shè)計(jì)交互得每一個(gè)細(xì)節(jié)、超出他們得預(yù)期、給到功能以外得驚喜。

就能夠在當(dāng)今日益激烈得競(jìng)爭(zhēng)中贏得一席之地。

感謝由 等 Kronol 來(lái)自互聯(lián)網(wǎng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止感謝。

題圖來(lái)自 Unsplash，基于 CC0 協(xié)議。