前端工程師的產(chǎn)品思維

最近幫中臺(tái)團(tuán)隊(duì)面試了很多前端，有些想法不吐不快：發(fā)現(xiàn)現(xiàn)在很多前端都喜歡去 ToC 的業(yè)務(wù)團(tuán)隊(duì)，認(rèn)為 ToB 的業(yè)務(wù)不就是去 XX 組件庫里復(fù)制粘貼代碼，然后增刪改查嗎？

但我想說，你那樣產(chǎn)出的內(nèi)容是沒有靈魂的！你要說復(fù)制粘貼組件庫可以幫助你來快速開發(fā)我信，但要是指望這種來輸出一個(gè)好用的管理端我是不信的。

不同的數(shù)據(jù)用什么組件來承載？不同的操作用什么交互來實(shí)現(xiàn)？為什么用的同一套組件庫我做的東西就總感覺差點(diǎn)意思？當(dāng)然了，有的人會(huì)說：反正都是給內(nèi)部人用的東西，能用就得了唄。好吧，只能說人各有志，這種心態(tài)來做前端，我是勸不了你的！

然后從技術(shù)上說，既然增刪改查的內(nèi)核是重復(fù)的，簡單的，那理論上是不是可以抽象出一些工具和輪子來？不過關(guān)于這部分內(nèi)容我之前的文章里有討論過，今天主要是想從產(chǎn)品和交互的角度再來思考一下造輪子的意義：

• 我點(diǎn)擊提交的這個(gè)按鈕它一定會(huì)在數(shù)據(jù)提交的過程中變成 loading 狀態(tài)

• 數(shù)據(jù)提交完畢之后一定會(huì)有一個(gè) tip 來給我反饋結(jié)果

• 提交完畢后當(dāng)前頁面的數(shù)據(jù)一定會(huì)被更新，而且會(huì)有個(gè)動(dòng)畫提示我哪部分?jǐn)?shù)據(jù)發(fā)生了變化

• 我輸入完了表單數(shù)據(jù)一定可以用回車來代替點(diǎn)擊提交

• 如果是一個(gè)創(chuàng)建操作，那創(chuàng)建完成后當(dāng)前的表單一定會(huì)被重置

• 如果是查詢操作，我查詢的參數(shù)一定會(huì)映射在 url 中，我即使刷新了頁面也不會(huì)丟失它們

• 如果我想獲得幫助，那去這個(gè)頁面的右下角一定能找到一個(gè)幫助圖標(biāo) ......

以上這些如果不靠技術(shù)手段去抽象出一個(gè)個(gè)輪子和范式來約束，你是很難保證團(tuán)隊(duì)中的每個(gè)成員都能“記得住”的。所以造輪子本身除了可以少寫代碼，我覺得更是為了產(chǎn)出一份“穩(wěn)定”、“統(tǒng)一”的產(chǎn)品。

統(tǒng)一的交互才能產(chǎn)出完整的產(chǎn)品，完整的產(chǎn)品的所有反饋都是符合用戶直覺和預(yù)期的。這可以讓他們用起來莫名的爽！學(xué)習(xí)起來莫名的快！———— 前端怎么深入思考

然而，對于一個(gè)中臺(tái)團(tuán)隊(duì)來說，一般是沒有產(chǎn)品和設(shè)計(jì)的，你的直接用戶就是身邊的開發(fā)者們，他們給你提需求，你負(fù)責(zé)實(shí)現(xiàn)。在此情境下，懂點(diǎn)產(chǎn)品和交互設(shè)計(jì)就很重要了。

那我們一直說產(chǎn)品思維，產(chǎn)品思維，說的是什么呢？舉個(gè)簡單的例子：某開發(fā)跟你說，我想要在某頁面顯示一個(gè)警告信息，告訴用戶這個(gè)頁面的數(shù)據(jù)不要輕易修改。

記住，這種直接面向頁面設(shè)計(jì)的要求一般都是有問題的，你要相信你作為前端工程師在交互和設(shè)計(jì)方面一定是比他們更專業(yè)的，你要問清楚他們背后的需求是什么？

比如這個(gè)事情你問了之后，可能真實(shí)需求是希望盡可能保障生產(chǎn)環(huán)境數(shù)據(jù)的安全，讓用戶不能隨意操作。于是，你要做的正確的事情就成了：好好設(shè)計(jì)一下前端所有生產(chǎn)環(huán)境操作的權(quán)限控制，不能操作的人直接就不給操作入口；能操作的人在真正操作的步驟里再給個(gè)醒目的提示，或者來一個(gè)嚇人的彈窗。

這樣才算是從產(chǎn)品的角度來實(shí)現(xiàn)需求。

總結(jié)一下：不要面向接口編程，要面向需求。從需求出發(fā)，你甚至可以反過來去要求他們來修改接口。

恰好這兩天幫一朋友改造他們的管理端，有一些很典型的場景可以分享一下。改造的模塊是下單部分，如下圖：

剛拿到這個(gè)頁面的我是一臉懵逼的，我完全不知道這個(gè)用來創(chuàng)建訂單的頁面要怎么去創(chuàng)建訂單。因?yàn)槭紫葟闹庇X上頁面上的這些元素就不符合我對一個(gè)創(chuàng)建類的表單頁面的預(yù)期，而反直覺的設(shè)計(jì)一定不是好的設(shè)計(jì)！（但有可能是好的藝術(shù)。。

然后經(jīng)過了一番詢問，我終于知道了下單的完整邏輯是什么了，那么來一點(diǎn)一點(diǎn)拆解，我們先來看這部分：

用到了兩個(gè) Tab 選項(xiàng)。Tab 組件一般用于承載一些“平級(jí)的”數(shù)據(jù)，這意味著 Tab 中的內(nèi)容是不分主次的。而對于一個(gè)用來創(chuàng)建訂單的頁面，為什么要有一個(gè)跟創(chuàng)建行為平級(jí)的 Tab？而且是看起來并沒有什么關(guān)聯(lián)的 Tab。

詢問之后我才知道，那個(gè)叫做快捷查詢欄的 Tab，title 寫錯(cuò)了，其實(shí)應(yīng)該叫創(chuàng)建用戶。那么問題又來了，為什么要在創(chuàng)建訂單的頁面去創(chuàng)建用戶？

詢問之后我又知道了，原來創(chuàng)建訂單的時(shí)候需要先選擇用戶，如果沒有自己想要的用戶可以去創(chuàng)建。ok，即便如此，創(chuàng)建用戶在這里也不應(yīng)該和創(chuàng)建訂單來“平分秋色”，它應(yīng)當(dāng)只是作為訂單中用戶這個(gè)字段的輔助功能而已。

所以，以上啰嗦內(nèi)容的核心意思是頁面要分主次。那這部分該如何改造呢？很簡單，首先把 Tab 干掉，然后把創(chuàng)建用戶的入口放在用戶選擇器的下方，即把功能的入口放在真正需要它且觸手可及的地方。如下圖：

繼續(xù)來看下一部分：

上圖的電話號(hào)查詢會(huì)把結(jié)果展示在那個(gè)叫查詢結(jié)果的表格中，然后點(diǎn)擊表格中的數(shù)據(jù)來實(shí)現(xiàn)選擇用戶。這部分的主要問題首先還是沒有分清主次：用了一個(gè)輸入框，一個(gè)按鈕和一個(gè)表格。其中表格還占了頁面很大的空間來展示對于這個(gè)頁面來說不怎么重要的用戶列表，而真實(shí)需求卻是為了給這筆訂單“輸入用戶”。

那這部分該如何改造我想大部分人都能想得到了。是的，一個(gè)支持搜索的選擇器：

不過這里值得一提的是很多人會(huì)亂用 AutoComplete 組件和支持搜索的 Select 組件。二者的區(qū)別是前者只是提供輸入建議，我可以不接受建議自己輸入任意內(nèi)容；而后者只允許選擇給定的選項(xiàng)。所以顯然這個(gè)場景下使用 Select 才合適。

再繼續(xù)看：

剛開始我了解到的上圖中表格的功能是：在選擇完用戶之后，去加載該用戶的默認(rèn)地址和最近的 10 筆訂單中的地址，然后點(diǎn)擊地址可以自動(dòng)填充到下面的地址輸入框中去。

所以和上面那個(gè)需求類似，第一想法還是把這兩個(gè)表格給干掉，然后地址輸入框采用 AutoComplete 來提供地址輸入建議來解決快捷引用相關(guān)的地址的這個(gè)需求，而不是本末倒置地去花大量的篇幅來展示地址。

然而，再溝通之后我才了解到，原來地址表格中不單單只有地址字段，還有充裝站 和 供應(yīng)站，所以點(diǎn)擊之后同樣還要關(guān)聯(lián)它們。如果是這樣的話，顯然不能夠給所有要關(guān)聯(lián)的字段都做成 AutoComplete，那樣的話字段與字段之間會(huì)丟失相關(guān)關(guān)系。

所以最終列表還是要展示的，不過肯定不能在創(chuàng)建區(qū)域占用地方了，類似上文提到的創(chuàng)建用戶改造，把它的入口也給挪到一個(gè)正確的地方：

Go on:

它們是一個(gè)二級(jí)聯(lián)動(dòng)的下拉選擇器。然后對于多級(jí)聯(lián)動(dòng)場景來說，如果多級(jí)聯(lián)動(dòng)的內(nèi)容存在嚴(yán)格的父子關(guān)系， Cascader 絕對是更好的選擇。因?yàn)榧?jí)聯(lián)選擇器首先是省地方，然后可以讓用戶專注于當(dāng)前的關(guān)聯(lián)選項(xiàng)，整個(gè)操作過程是自然和連貫的，且選擇完成之后在單行內(nèi)容上就可以清楚的看到包含父子關(guān)系的選擇結(jié)果。就像這樣：

Let's continue：

這部分要吐槽的點(diǎn)就太多了！令人發(fā)指的設(shè)計(jì)！令人智息的交互！為什么要用單選項(xiàng)來控制折疊面板？折疊面板不會(huì)自己折疊嗎？我打開了面板為什么單選項(xiàng)沒有被選中？傳說中的單向綁定嗎？這么多的選項(xiàng)為什么還要用單選項(xiàng)？Select 了解一下？

然后再從交互心理學(xué)上（我發(fā)明的！）吐槽一下：這個(gè)需求是不同的下單類型對應(yīng)不同的表單內(nèi)容，如果你使用了折疊面板作為不同的表單內(nèi)容的容器，這很容易讓人誤會(huì)成無論我選擇的下單類型是啥，折疊面板里的內(nèi)容都是可以填的，不同面板里的內(nèi)容如果我填了最后都會(huì)被提交出去！因?yàn)檎郫B面板本身只是對內(nèi)容的收納設(shè)計(jì)，可以節(jié)約空間，還可以讓使用者隨意切換自己想要看的那一級(jí)的內(nèi)容，但從來沒有內(nèi)容如果被收起就不存在（不提交）了的意思！

所以。。。請來看一下我的設(shè)計(jì)（正確的設(shè)計(jì)！）：

總結(jié)一下：堅(jiān)決使用 Select 來選擇超過 x 個(gè)的選項(xiàng)，堅(jiān)決的使用 Option 來選擇少于或等于 x 的選項(xiàng)（x 取決于頁面空間和選項(xiàng)肉眼識(shí)別的復(fù)雜度，一般等于 3）；如果是是否型的選項(xiàng)，那建議使用單個(gè) CheckBox 或 Switch。然后不需要填寫的表單就不要顯示出來！

RangeWoMenJiXuBa:（已詞窮

這里倒是不難看出來交互的邏輯是：輸入完相關(guān)內(nèi)容后點(diǎn)擊增加，內(nèi)容會(huì)被添加到表格中。

只是不知道原開發(fā)者為什么會(huì)在一個(gè)主交互是輸入的頁面里對表格這個(gè)偏展示的組件如此情有獨(dú)鐘，而且只管輸入不管修改和刪除，以至于如果你這一步增加錯(cuò)了東西得刷新整個(gè)頁面重來。。。

然后結(jié)合上文的一些類似場景，不難發(fā)現(xiàn)類似的交互處理是有套路的：一個(gè)表單里面如果出現(xiàn)了需要額外輸入的東西，比如上文的添加用戶和這里的添加物品，那么就把他們挪到別處去吧！PC 端可以用彈窗，可以用側(cè)滑抽屜；移動(dòng)端則可以 Push 一個(gè)新頁面。于是改造的結(jié)果如下：

再強(qiáng)行總結(jié)一波：讓表單頁面放眼望去都是表單元素（最好長得都是像輸入框的元素），且每個(gè)表單元素上展示的都是確定要提交的表單數(shù)據(jù)。

關(guān)于本文 作者：@阿偉 原文：https://zhuanlan.zhihu.com/p/84597015