每一做一個項目都應當有所收獲，面對千變萬化的長尾問題，如何提供更優解？作者復盤了其一個搜索長尾流量項目，談談當中所做和所思，希望對你有所啟發。

你好，我是檸夢百香果，做過大廠交互、普通公司資深UI和小組長、創業合伙人、入門自媒體等。

介紹是為了讓你愿意聽聽這樣的我，是怎么被項目碾壓的。

這是個復雜項目復盤反思文。文章較長，因為不僅從設計角度來分析，預估17-25min閱讀吧。

畢竟復盤它，從思維整理+腦暴上就花了熟悉項目的我2天時間，還只是輸出了個簡單的解決方案雛形。

前置一下這個復盤最重要的收獲——復雜需求產品設計的全局思維。

一個復雜需求的解決方案，先定義好要解決的問題，然后從工程化開始思考解決方案；從工程出發，找到不同角色更適合賦能的地方，最終合并成一個綜合解決方案。

這里的復雜，主要在于解決方案的復雜性?？赡苁?strong>信息量、服務量、物件量、角色量等。我涉及的主要是信息量。

其他還有一些額外的跟項目、技術、設計、內容更結合的感觸，放在了具體項目拆解中。

文章節奏分為：Foreword前言 – Star伊始 – Think思考 – Solution工程方案 – Design設計 – Expand擴展 – Summary總結。

我且烹茶煮酒，各位看官，去留隨意。

一、Foreword：一頓操作猛如虎，一看輸出0.5的項目，倒逼解決方案的思考

這是一個復雜的搜索問答項目。當時投入了好幾個老板、一群產品、技術、設計，涉及20人+了（記不清了）。瘋狂加班，輸出+修改了n次設計，開n次會，看n個文檔，做n次調研。

可以看下圖設計側部分文件，每個文件至少page有8個以上，多則25+，每個page都很大。圖為保密做了縮放+模糊處理 ??（注：非我一人輸出，是團隊總體輸出）

圖1 設計側部分文件

圖2 隨便找了個設計文件（縮放了很多倍，右側有20個pages）

還沒放產品側一堆文檔。當時文檔已經多到找文件都很困難了?？吹竭@里會不會覺得：哇！好多好多，666！

No！它只是個成果很難應用的輸出。也就是這里的輸出，大部分當時沒找到合適的落地方式。

也正因它價值難判，卻又如此的占用時間，倒逼我在離開這個項目后重新反省這個需求的解決方案。

二、Star：需求定義

搜索問答項目，聽起來太學術了。換一個說法介紹一下：

用多了谷歌的，相信都對精選摘要有印象。em···沒印象就看下圖3，其實就是谷歌搜索引擎整理網頁內容，提煉出的第一個搜索結果，直達問題的答案。讓用戶更快Get到有效信息。

圖3 谷歌的精選摘要

我們當時要做的就是類似優化這塊精選摘要的工作，只是產品是其他瀏覽器（名字保密，不影響復盤）。

項目目標在文檔中的說法是：高效解決用戶疑惑。關鍵詞有可信、直觀、有用。數據指標就是提升問答覆蓋率和滿意度。

說到這里，初步對這個需求重新定義問題：

針對用戶的搜索問題，怎么提供更優質的解答？

這里做一個重要申明，定義問題非常非常非常重要！

定義問題其實就是怎么去拆解看待問題的角度，會影響你解決方案的出發點。

不得不說做項目踩的認知第一坑——我們沒有定義問題。也是我覺得費力不討好的關鍵因素。

當時拿到項目，我們就很著急去分析搜索答案的框架，劃分了單維多維、唯一不唯一、有趣或專業什么象限圖，最后發現應用的時候很難套上用處，因為它很難對應的用戶真實數據覆蓋面統計，必須繼續細分，但又很難判斷細分度。尷尬到我跟產品介紹框架、框架設計case時都要摳腳指甲了！

圖4 分析時做的框架最后很難應用

更糟糕的是，因為我們花了很多時間做了分析，導致我們后面一直被這個分析思維纏住了，沒辦法很好的跳出不好的框架來看?，F在看來，有點歪了路。

額外多嘴：

• 項目特意摘出問答來做項目，其實也讓我有點不解。因為用戶搜索的，都是用戶的疑惑需求，只是不一定用問題的方式作為關鍵詞，谷歌搜索引擎研究中是搜索的都合并分析。這算后話了。
• 項目文檔中部分說法，其實有些常規項目執行的坑點。等后面分解。

三、Think：定義的問題在項目中的特性

問題：針對用戶的搜索問題，怎么提供更優質的解答？

這個問題，在這個項目中，有什么特性呢？這些特性會影響整體解決方案及后續驗證的輸出。

1. 搜索問題是長尾流量，難以統計出有共性設計需求的大覆蓋面比例

這其實也是是項目上踩的認知第二坑。當時項目從用戶的問題進行分類：是什么、為什么、怎么辦這些角度，確實可以得到數據占比。

但是，“水果籃子是什么時候播出的？”、“天官賜福是哪些人在拍”、“女生主動給男生發消息是啥意思？”這三個“是什么”的答案可是不一樣的。前者是一個具體時間，中間是涉及多個主體，后者則是行為代表的多種含義猜測。對應的是單答案、多答案不同結構呈現。

所以我現在重新翻看數據分析，發現它難以產生足夠有效的參考。為此，我暫時放棄的數據的參考，回歸問題本質之一——回答各種各樣、千變萬化的問題。

好在這個千變萬化長尾的煩惱，搜索技術是可以解決的。

搜索引擎技術可以通過分析用戶輸入的搜索詞，進行分詞、詞性判斷等，通過貝葉斯概率、向量分析等方法來處理識別用戶問問題的意圖，也就是長尾問題是可以習得分析的。這個解釋起來比較復雜，認真解釋的話可以扯出另一篇技術文章來。隱約記得吳軍的《數學之美》有提到過類似的技術解答，感興趣可以去看，或是查閱論文、解析什么的～

如果你耐心看到這，你也發現了——技術在這里面，是絕對的大王。這也是后文工程化最主要的地方。我也一直疑惑，當時為啥不是技術來主導···

pps，數據永遠不絕對，如果它無效，就要回歸問題本質思考解決方案。

2. 搜索引擎工具主打信息瀏覽服務，追求高效滿足，鏈接第三方網頁

這是很搜索的特性了，也是項目踩的認知第三坑——無法在短期通過數據驗證方案的結果。

代入細想一下，如果真的做了優化，能讓用戶獲得更優質的解答（比如更高效、更好用），用戶會在瀏覽器搜索數據上表現出什么呢？

（1）單次搜索問答瀏覽時長縮減量。更短時間瀏覽就能找到答案——這個對于業務來說，并不一定是一個好消息，雖然長期來看可能增加了用戶使用生命周期。

（2）相關問題搜索頻率增量。會更常在這里搜索相關問題——這個要考慮驗證的時間窗口是一周還是一個月內？畢竟長尾需求剛性有，但弱，隨機性較強，而團隊跟進能否支持得了拉長的時間窗口。

（3）答案摘要的點擊率。這個指標，到底用戶是因為滿意想看更多所以想點擊，還是因為不滿意想看更多才點擊呢？——不知道，所以不算得好指標。

所以，當時項目文檔提到的提高用戶滿意度，是什么呢？

很難定義，一直在討論，沒有很好定下來數據指標。唯一比較肯定的就是，可以通過用戶訪談、問卷來進行簡易驗證。

這就是我在前面Star多嘴處說到文檔執行坑點：數據指標量化有困難。

客觀來說，這個特性導致追求短平快的團隊難以驗證設計。但這個也正是需要辯證考慮的，到底要不要追求長期主義？短期難以驗證，但長期是可以的，比如你的用戶量會增多，你的搜索頻率會增高，你的LTV會增長，你的廣告收入會拉高，窗口拉得足夠長，確實是存在可驗證性的。

3. 最優答案的呈現形態是動態變動的

團隊當時有從信息可視化、動態化、海報、貼紙、互動等等角度去優化一些答案Case，Case做的很完美（大家都很有設計力），可惜到了落地都是遇到了技術實現、影響覆蓋面問題，無法很好繼續談下去。

回看一番，這些解答不一定就是最好的設計方式。因為哪怕整個產品團隊去優化特定類型問題的解決方案，在海量長尾面前，無異于螳臂當車。

圖5 鮮活直觀信息呈現的方式的調研收集（Case就不放出來啦，團隊Case涉及保密問題）

那么最優答案是怎么樣的呢？

答案就是知識。知識的傳播，最開始是死記硬背，再演變到講故事更容易讓人記住、漫畫講解有圖示、視頻講解更有臨場感、游戲化寓教于樂，同一個知識有完全不同的解釋方式，被不同時代的不同人所喜愛。

同樣的，我在觀察社區類競品時發現：UGC知識的好處是每個人解答方式或角度的不一樣，活靈活現，總有適合不同人的最優解。

我不禁反思，或許解決這個問題真正一勞永逸的方法，就是要設計一個可動態變化追尋最優解的工程。

??！Bingo！就是這個——可動態變化追尋最優解的工程。這就是我的答案。

四、Solution：可動態變化追尋最優解的工程

動態變化，就意味著要存在對答案內容的解析、提煉、評分。而且評分的等級是一直變化的。我修修改改，簡陋的弄了一個工程流程圖。

圖6 設想的解答背后工程構想

構想畫的比較粗糙，背后技術省略了很多，原諒我一個沒啥技術背景的小白的表達方式。

這個構想是需要一整個大團隊才可以完成的事情。但私以為，不要覺得動態變化如此大成本投入不可靠。說一個個人的感觸，在高中時期，我還覺得百度搜索中文結果特別方便，等到我大學畢業后，反而覺得谷歌搜索非常精準，而百度搜索出來一堆無用的解答。

這是因為谷歌專注于對于中文的搜索理解優化以及對應的中文內容匹配抓取，它專心優化的是自己的搜索技術；而百度是專注于做中文內容結構化鋪開，比如百度經驗、百度知道、百度文檔，所以搜索內容時，匹配結果時部分依賴自己搭建的結構化內容，導致搜索引擎看著可用但實際上尋找的不夠精準問題被掩飾了。

而當初谷歌離開中國市場時，互聯網上的中文內容還太少了，谷歌跑不出數據量訓練自己的模型?，F在隨著互聯網跑了十年，這兩個搜索引擎就出現了區別——海量中文內容加持下，谷歌是越找越精準，百度卻是越找越乏力。

所以要做好，跑長期工程，或許更適合。驗證也走長期思路。長遠來看，用戶對于搜索的評價是上升還是下降，使用頻率增高還是降低，使用時長是增高還是降低，用戶量是增高還是降低等等。

工程出來，每個角色適合賦能位置就清晰許多了。拆解一下如圖7。

技術主導整個流程，其中產品設計可以參與設計答案框架，涵蓋所有適合的答案框架。內容或活動運營可以考慮在建立優秀答案內容池上做運營活動，比如“答案點評官活動”投放活動到福利中心，讓用戶實際參與點評篩選，持續豐富內容池等等。

圖7 角色賦能拆解

五、Design：設計賦能清晰化的框架呈現

圖7建議設計工作落到設計更適合的答案框架上。

答案框架一直是我們當時在研究的重點，Star 部分講的圖4 已經表明前期框架我們將其分類做的復雜了。后來我們按照單答案、多答案分別細分，雖然分得較為雜亂，但算是較合理的處理方式。如圖8。

圖8 單答案部分框架提取

這里提一下我們當時認知上的第四坑——將單答案、多答案分開看待的，但實際上在技術側不是這么分的。

答案框架的應用取決于答案內容。如果答案提煉到是多維答案框架（多維=多角度、多分類），那么就是用多維答案框架，如果沒有多維，技術只能爬到單答案，那就按照單答案展示。其實就是類似“自主適配”。

綜合思考后，我覺得需要設計的是一個遞進交合結構的基礎答案框架。初步構想如下圖9。

圖9 基礎答案框架

遞進交合應用取決于答案內容的知識圖譜節點識別。

如果存在多層節點，就套上一二級標簽結構去應用，就會變成一個多答案結構；如果是沒有節點，就是只有答案內容的單答案結構。

初步構想很粗糙，還可以細分，比如一個級別的標簽下可能有多個內容、圖片大小不同的情況、視頻橫豎+不同時長+是否可自動播放情況、文檔存在下載操作按鈕、內容為操作步驟有流程性、內容是表格如何呈現比較好等等；

甚至再細分一些特殊模式，比如二級標簽只是2個比較的情況，可以直接用PK模式呈現。展開的話也是一大設計文件說明，圖9基本已經把我的主要思維體現了，所以細節就先不展開了。

提一個框架設計中體驗的關鍵點：

（1）增強答案的認同感

其實用戶尋找問題，得到答案，是為了得到自己更認同的答案。

那么影響認同感的因素有哪些呢？——答主身份、用戶認同數。后者其實比較難抓取，但前者屬于內容源，是可以固定下來的。當時團隊對專業領域的答主就很看重其身份的展示。

故我在圖9的結構末尾加了內容源的身份解析，但是這個為不干擾主體答案畫的比較弱，必要情況下可以加強視覺呈現，比如特別專業領域使用內容源or答主身份前置到頂部，或是直接把這塊的頭像面積變大修改版式。

（2）服務于答案內容的情緒感知

在工程圖6的設想中有提到答案的情緒感知。

當時團隊討論觀察提到的方式是該怎么去回答一個問題，有些適合搞梗，比如互聯網熱詞，有些適合專業比如法律咨詢，有些適合安撫比如傷心情感問題。

只是當時切入的應用角度是垂直領域細分，比如安撫就是情感領域。但實際上這樣還不夠嚴謹。因為有些情感是向上的，不一定需要安撫。

所以我傾向于直接解析答案內容的情緒，這需要借助機器模型學習。

識別內容判定總體情緒，是否安撫性強。比如是否出現安撫性詞語“抱抱”、“加油”、“你可以的”等等字眼。如果判斷出答案的情緒屬于這一類，那么就可以在掛載區增加一些互動安撫功能。比如類似壹心理的抱抱互動按鈕，增加xx人在這里與你擁抱、xxx位陌生人給你鼓勵+鼓勵彈幕；

同類擴展，搞梗有趣的可以增加熱詞段子彈幕到擴展區；不過專業的更建議提供咨詢的掛在服務了。

當然體驗關鍵點還有其他，比如統一簡潔化呈現，這些屬于基礎要求，就不細提啦～

六、Expand：項目復盤的可復用性討論

寫這篇文章之前就在想，做這個復盤，除了給自己一個交代外，還能有什么復用擴展？

1. 復雜需求產品設計的全局思維

與開篇呼應，這是最重要的思維收獲。面對一個復雜的需求，定義問題是基礎，它可以避免費力不討好的嘗試。然后從工程化角度去思考解決方案，而不是一下子就從細節入手。工程化可以讓自己從全局角度來看待這件事，也能找到每個角色更好賦能的方式。

2. 這種搜索設計思路能否用于社區類搜索邏輯？

社區類App鏈接的是人和產生內容的人，也就是至少存在KOL和粉絲兩種角色。兩者之間存在情感聯結。如果使用了提取答案摘要的能力，平臺自己生成一個答案，可能會減少KOL的SEO搜索導量，引起KOL流失、粉絲流失，損益過重。

所以精選摘要更多是在搜索工具這種純粹的工具中存在，因為搜索工具鏈接的是網頁。

當然也有一種折中解決方案，也就是官方自己下場到社區中，成為社區的某一類生產內容的人。比如小紅書的運營官建了很多官方賬號，比如吃貨薯、知識薯，且會做部分小專題內容。搜索一些相關內容可能就會看到官方的結果也混在SEO之中。

不過這種官方不會做的太過，怕搶占KOL的盤面，或是即使做多了，也是會給提供對應內容KOL引流。

總體來說，現在這個搜索工具的復盤，更多適合在工具屬性強的產品中的搜索應用。如果是在社區中應用，可以建立官方賬號，以官方賬號人這個角色去產出精選摘要內容呈現。

3. 這種動態工程化解決設計的思維就是AI背后的工作

隨著 ChatGPT 大火，深感未來搜索革新之重。昨晚甚至覺得，我做的復盤，其實是AI的工作，而現在國內大家都集體搬用API，其實就是直接借用了國外的工程化結果。

記得去年 leader 說過，現在搜索引擎其實我們是在用機器的方式跟機器對話，未來也許會用跟人對話的方式跟機器對話。目前看來已經走在這條新路之上。

圖6的工程化 = AI背后的工作，技術設定優化好好學習模型，基于標記好的內容庫訓練機器，最后得到一個可動態學習自我更新的 AI 。想想 Open AI 2015年成立，2022年底引爆行業，近乎8年的投入，確實有勇有謀。側面也可看出：但凡需要考慮工程化去解決一件事的需求，要么是長期主義的需求，要么是需要投入大量人力的需求。篳路襤褸，以啟山林。不過人多本來也就意味著時間長，因為溝通邊際效益就高很多了。

活久見，也幸得活久見。

不過多嘴一下：私以為，AI和搜索引擎，或是說和任何一個信息傳播的平臺都具備的問題，就是信息繭房或是頭部效應。哪怕是機器，也逃不開這個問題，這跟機器的數據源、處理方式、傳遞給人類時人類的學習能力有關。我其實在設計問答時也在思考，如何讓少數或是說厚數據也能被人看到？暫未有解，只能先記著。

看，寫到這里就會發現，其實還是解決方案思維上的學習。

Summary：最后一杯茶

回顧一下：

項目復盤從一開始介紹了需求背景后，開始定義問題——如何面對千變萬化的長尾問題，提供更優解？

然后確定問題的特性，也就是把問題放到項目中去判斷它的特性，推斷解決方案可以落在工程化思路上。

之后設計工程化解決思路，從整體流程出現確定每個角色更適合賦能的地方。圍繞其中產品設計的賦能之處，思考設計構想與體驗關鍵點并體現在設計框架之中。

最后反思復盤的擴展應用可能，除開最重要的工程化解決思路外，也談及如果要應用到社區內容搜索的可能方式，也感慨其實這個就是AI背后思路。