一款具有社交屬性的產品往往能夠建立用戶間的關係鏈，從而使用戶黏性更強，實現更好的留存，那麼對於一款工具類產品，如何合理的加入社交元素呢？作者分享了自己的一些思考。
不知從什麼時候開始，「社交」成為了網際網路圈討論的熱詞。
我們可以看到，不僅是傳統社交產品諸如微信、陌陌，不斷的為了適應用戶日新月異的需求而打磨產品，比如微信推出的飽受詬病的「朋友圈可以看最近三天的朋友圈」，以及陌陌大刀闊斧的直接將曾經的LBS陌生人社交神器砍掉再造，變身為視頻社交與直播互動的新平臺。
無論實際效果如何，但是傳統社交產品一直在不停的努力迭代新功能，創造新玩法。
還有非社交軟體諸如今日頭條、搜狐新聞等新聞、信息聚合分發平臺，也在不斷在向社交模塊的方向探索。除了內部的社交功能孵化，關於「社交」的新聞更是層出不窮。（見上圖）
對於此類產品，龐大的信息流與在線廣告除了可以通過自推薦策略分發給大量用戶實現曝光，也非常依賴用戶通過社會化媒體向外分享，吸引外部流量。
同時，也依賴用戶利用產品平臺的社交屬性建立泛關係鏈，增強用戶粘性，建立歸屬感。
在新的移動網際網路時代，每一個人都是一個信息的出口，都成為了一個媒體節點。
媒體有兩層含義，一是承載信息的物體，二是指儲存、呈現、處理、傳遞信息的實體。
顯然，我們每一個人在微信、微博等社會化網絡媒體中，已經成為了一個儲存、呈現、處理、傳遞信息的實體：
移動網際網路時代，「用戶」即渠道，「用戶」即媒體。與其研究通過哪些優質渠道可以迅速、精準、全面的覆蓋產品市場針對的用戶，為何不藉由用戶的媒體屬性，利用用戶社群眾多短渠道的快速、垂直化傳播來達到營銷與宣傳的目的？
廣告主、服務商在掌握了用戶社群特性、用戶群體畫像與模型後，為何不基於群體的垂直化需求以及高密度興趣點，有針對性的推送原生、精準、互動性的在線廣告，效果最大化的達到營銷目標？
這是「社交」要素趨於火爆的原因，但「社交」所能帶來的強大賦能還遠遠不止於此。
「社交」可以增強用戶粘性，可以利用社群網絡提高傳播度，可以通過多種互動行為背後的數據，幫助產品更好的規劃功能，制定內容，策劃活動，甚至有針對性的推送線上廣告。
這也很好解釋，為什麼越來越多的產品開始像社交方向傾斜。
但反觀社交產品，將社交作為主要功能的產品除了微信、qq等傳統霸主之外，鮮有新的火爆產品誕生。因為社交產品具有兩種類型：
工具型社交產品雖然可以通過穩定的性能表現與完美的用戶體驗吸引大量用戶，但產品商業模式難於推進，變現能力較弱，無法為產品生命周期延續提供資金支持，無法構建長期發展的產品生態鏈條；
微信作為非常傳統的工具型社交產品，一直在努力尋求更好的產品商業模式。通過微信支付、微信錢包、朋友圈原生廣告等第三方支付與理財模塊可以為微信提供一定的變現能力，但數億的微信用戶群體的利用價值遠非於此。這也就是目前微信向內容方向布局的主要原因。擁有中國最大基數用戶數據模型的微信產品，不做興趣聚合信息流，簡直是浪費的。
同樣的，除了工具型社交產品，其他工具型產品，例如騰訊翻譯君、有道翻譯官，也面臨著一樣的問題。他們也同樣擁有著大量的用戶，但用戶價值並沒有很好的被利用。
傳統的工具型產品，存在著以下的幾點問題：
1.用戶即用即走
工具型產品都存在著非常固定的需求場景。有翻譯語音需要的時候，才會產生使用翻譯工具如騰訊翻譯君的需求。而用戶的需要被滿足之後，需求場景瞬間消失，工具型產品對其不再有意義，隨即退出。這也就意味著，用戶在使用工具型產品時，產品使用時長較低，產品使用頻率較低。對於網際網路產品，無法佔據用戶的時間，是非常的危險的。
2.流量加工能力弱
工具型產品信息流縱深度極低，產品結構簡單。工具型產品屬於後反饋裝置，用戶在工具型產品中扮演的角色是信息輸入源，只有信息輸入，才會對用戶產生相應的功能反饋。用戶輸入的信息，對建立用戶模型是沒有參考意義的，因為沒有商業價值；用戶輸入的信息沒有其他出口，也沒有被分發，每一個用戶與產品的使用過程信息流都及其的封閉。大量的流量沒有被深度加工，而是在滿足工具需求後即被釋放。
3.用戶容忍度較低
工具型產品能夠吸引大量用戶使用的原因，主要在於產品的性能表現。如果產品性能沒有滿足用戶的心理預期，例如翻譯響應時間長、翻譯精確度不夠等，用戶的滿意度瞬間下降，對產品的容忍度急劇降低。用戶可能會馬上選擇其他的競品，或選擇其他方式滿足工具需求。用戶對工具類產品容忍度低的原因在於，用戶對其沒有情感寄託，工具類產品就像一臺冰冷的機器，用戶根本愛不起來。機器稍加犯錯，用戶自然不顧情面，選擇拋棄。其他的產品可能像是在與用戶「談戀愛」，工具類產品更像是用戶的同事或下屬。
4.商業模式不明朗
這部分已經在上文中提到過，眾多工具型產品在業務線中扮演的角色可能更多的是積累用戶建立資源的作用，其自身變現能力很弱。大多數的工具型產品要麼像垂直化需求縱深例如有道詞典向線上教育轉型，或者通過提供更高性能的服務吸引高端用戶付費體驗。
工具型產品存在的這些問題，通過加入社交因素，可以得到良好的解決:
現在我們通過具體研究如何為「騰訊翻譯君」加入社交因素，來做一個實際的闡述與解釋。
下圖分別是騰訊翻譯君，與有道翻譯官的主界面：
通過上圖我們可以看出，兩者保持了工具型產品的共性：簡潔。
除了基本的工具功能，不再加入其他的功能模塊對用戶產生幹擾。界面要足夠清爽、簡單，保持工具類產品的基本調性：我是「實力派」，不是「花瓶」。這是為了滿足用戶的使用體驗，無可厚非。
但分別解構騰訊翻譯君與有道翻譯官的主界面後，我們還是可以看出騰訊翻譯官的一些「小心機」：
通過上圖我們看出，有道翻譯官為了追求工具類產品的調性，以及整體頁面的簡潔性，犧牲了大量的頁面分配給信息輸入欄。
這在一定的角度來看，確實極大的提高了產品的工具屬性，但從另外的角度來說，又是對產品自身發展的禁錮。從有道翻譯官的產品結構框架上來看，產品戰略層面並沒有給其廣闊的發展空間，而是讓其在翻譯領域做到專注，從體驗及性能上製造差異化。
但這無疑扼殺了一款工具類產品的創新發展空間。同時，這種純粹的工具型產品很難讓用戶產生情感寄託，無法改變用戶即用即走的殘酷現實。
同時，產品的流量加工能力依舊很弱，產品沒有有效的流量流入，也沒有流量分發的出口，甚至無網絡狀態下也可使用。商業模式就更不用多說，依舊走了諸多工具類產品的老路，泛泛可陳。
而反觀騰訊翻譯君，其在首頁面的規劃上讓人看到了工具類產品的一線生機。首先，在關鍵位置：底部與頂部設置的語音翻譯功能欄以及文本翻譯功能欄，實現了翻譯體驗的需求閉環。
同時，在頁面中部布置了瀑布流信息欄。這是非常有想法的設計，因為當用戶看到瀑布信息流，很原始的就會產生向下滑動的衝動。假如用戶在瀏覽信息的過程中發現有吸引力的，或者滿足自身興趣點的標題、視頻、圖片時，點擊、瀏覽、轉發、點讚、收藏等一系列互動行為會同時伴隨發生。而用戶一旦參與到了與信息的互動中，社交行為即時引爆。
當用戶被內容吸引而在產品內停留或發起互動行為的同時，也就意味著延長了用戶的使用時長，為在線廣告提供了更多的展示時間。也就意味著用戶向產品輸入了自身的興趣數據模型、使用習慣模型。
此處需要強調，我們的目的是為騰訊翻譯君加入社交元素，而不是為其加入社交功能。就像微信之父張曉龍說的：「一個產品只應該有一個主線功能。」
騰訊翻譯君的產品slogan始終還是強工具類產品，我們為其社交元素，只是為其添加輕社交屬性，提高其產品生命力，為其賦能。社交因素的植入，應該是適度的，適時的。
下面筆者提供兩種不同的方案：
在瀑布流信息欄，我們不應對其功能結構做過大的改造，而是在其現有功能基礎上，明確內容分類，強化內容屬性，優化內容體驗。
那麼針對英語翻譯類軟體，提供哪些內容是用戶會需要的呢？
用戶產生文本翻譯或語音翻譯行為的需求場景其實很多，我們不應把內容單純定位成英語學習類。
因為也有商務人士只是在出國時需要使用語音翻譯，用戶本身並沒有學習英語的需求。內容的定位應該圍繞在英語這件事情發生的場景本身，並與翻譯君的工具屬性結合。
針對騰訊翻譯君對自己的產品使用場景的概括，主要包括旅遊翻譯、口語學習、搭訕等場景。
覆蓋的場景廣度很大，但除了口語學習存在一定的高頻性與高使用時長，其他場景的出現頻率較低，同時並不會佔用很多的使用時長。
這也就意味著，我們不能輸出過多的英語口語相關內容的信息流在首頁上。
因為除了英語學習，這些信息流並沒有場景的延續性。用戶搭訕完一個外國妹子之後，不會繼續瀏覽英語學習的信息。用戶出國旅遊回國後，可能長時間都不會再打開翻譯君這款產品。騰訊翻譯君的功能受場景驅動性太強，過度的、過於垂直的信息傳達並無益處。像下圖有道詞典的瀑布信息流模式，對騰訊翻譯君並不適用。
那麼騰訊翻譯君的瀑布流信息欄，應該是什麼樣的形式呢？
騰訊翻譯君的瀑布流信息欄，不應對信息類型做過於清晰的分類，例如上圖的TAB欄。因為還是上文提到的，翻譯的需求場景很寬泛，對內容強行進行分類為用戶建立興趣導向的做法並不可取。
信息內容上，應以視頻為主，少量文字型專欄。取材應貼近翻譯使用場景進行，場景越具體、越清晰越好。內容不宜過長，應控制在五分鐘，或者1500字內，以抓住用戶碎片化時間為主。內容應風趣幽默，極具生活化，且與翻譯君相結合。內容應論點明確，有乾貨，用戶讀過後會有收穫。
下面舉例幾個可以取材的方向：
此處需要注意的是，每一個信息內容的標題都要與翻譯君聯繫在一起。因為翻譯君這個名字，本身就是帶有擬人化的意味，不斷在信息流中重複這個名字，有利於加深用戶對產品的認知，有利於品牌傳播。
如果可以的話，最好的其實是為翻譯君設計一個形象，例如一個可愛的機器人，或者寵物狗。
名字為用戶帶來直覺記憶，形象為用戶帶來感官記憶。當用戶的直覺與感官都被抓住後，情感的寄託與依賴感也會隨之產生。
另外，通過在內容中的評論，分享，收藏，點讚，轉發等互動操作，加深泛關係鏈的建立與連接。通過加入微信登錄、QQ登錄等第三方登錄平臺機制，可以有效利用接口，實現話題、用戶、流量的跨平臺傳播。此處不再贅述。
競品方面的話，百度翻譯已經加入了瀑布信息流模塊，見下圖。但筆者認為，百度翻譯並沒有深刻理解翻譯的場景解讀。信息流內容上過於上浮，雖然也很生活化，但是過於脫離翻譯場景。風趣幽默的配圖與文字、標題雖然能夠確實吸引用戶閱讀，但閱讀很難真正的讓用戶學到東西，學以致用。更多的還是消遣用戶時間，豐富用戶見識。
借鑑微信小程序的形式，結合翻譯工具使用場景的深度挖掘，加入小應用模塊。下圖為設計草圖，並非最後的交互效果。
實用口語：
實用口語小應用入口，內置餐飲、購物、遊玩娛樂、交通、住宿、旅行必備等不同場景下常用的口語場合。再將對應的場景細分，例如餐飲分為尋找餐廳、訂座找座、點餐用餐等。
在此處添加社交因素的關鍵點在於，每個口語語句下方應該設計跟讀功能，並在下方展示網友的優質跟讀錄音，方便其他用戶學習。同時，也有利於社交互動等功能的展開。
翻譯擂臺：
翻譯擂臺的小應用，主要通過用戶與翻譯君PK的形式展開。
用戶首先利用翻譯君工具翻譯一條語句，用於在將自己認為更合適的翻譯結果上傳到擂臺。
其他用戶也可以參與，將自己認為可以超越其他用戶的翻譯結果上傳。此功能可能更適用於英語翻譯成漢語的這一功能，因為在漢語中「信達雅」的要求，翻譯君的翻譯結果往往很難達到，這也就給了網友發揮的空間。
另外，也可以參與翻譯君發出一條「徵集令」，給出一條英文句子或語音，吸引用戶前來翻譯，給出最理想的翻譯結果。用戶可以參與，也可以瀏覽其他人的翻譯結果，進行點讚、收藏、分享等操作。最贊回復與神回復置頂，製造話題性。
身邊的翻譯君：
此處內容更偏向平臺本身的PGC，每周徵集一位口語達人、搭訕達人、旅行達人，分享自己在各種不同的翻譯場景中，自己實際遇到的問題，踩過的坑。
這種內容與上文中提到的瀑布信息流中的信息內容相比，首先作者形象鮮活，自己的親身經歷也很容易讓人感同身受，激發用戶共鳴。用戶可以在內容下方給出自己的評價意見，也可以分享到其他社交平臺，當然也可以自己推薦自己，成為下一期的「身邊的翻譯君」。這樣，用戶不僅成為了參與者，傳播者，最後甚至會成為內容的領導者。
通過每個月的一次「最強翻譯君」的選拔，選出前三名用戶心中最實至名歸的翻譯君，給予現金獎勵與支持。甚至可以和在線旅行、電商網站、英語培訓機構合作，豐富獎品樣式，拓展活動方式，共享流量分成。通過這種活動，翻譯君的商業價值，將得到很大的提升。
翻友互助：
此應用的出發點，在於將翻譯工具這件事，拓展到線下網友互助這一方向上。
工具類產品的發展除了提高自身產品性能，還在於將「提供工具」轉變成「提供服務」。
那麼從社交的角度上來講，通過翻譯君搭建平臺，為翻譯技能優秀、翻譯經驗豐富的大神，和翻譯中處處碰壁、缺乏實際經驗的小白聯繫在一起。騰訊翻譯君只是提供一種結果，但翻譯這件事本身，是需要結合很多實際情況來考慮的，翻譯工具不能解決所有問題。而這也是翻友互助存在的意義。
翻友互助應用，主要內容是由用戶發布需求，例如出行中的翻譯問題、看不懂的英文文獻、提高商務口語等任務，任務周期，並提供一定的懸賞金額。能夠提供支持的用戶可以與內容發布者聯繫，並通過第三方支付確立互助協議的達成（必然應用微信支付）。
任務完成後，內容發布者對服務提供者進行評價。多次得到好評的服務提供者，將得到翻譯君的額外獎勵，從多方面激勵用戶貢獻自己的價值，參與到翻譯君的這一應用中，將自己的價值分享給其他人並幫助到他人。據此，翻譯君平臺本身也就擁有了價值。
無論如何，對於傳統工具類軟體的社交化探索，始終都是超前的。
因為工具類軟體講究的是效率，解決時間，解決問題。可產品為用戶創造了使用價值，產品自己是否應該得到用戶給予的價值呢？這到底是應該苛責產品本身不應該具有功利心，還是說，在商業世界中一切為了利益，這是應該遵循的自然規律？
過去我們常常追求於「無私奉獻」型的「小而美」的產品，他們的功能垂直、專注，他們界面優美、精緻，他們總是不求回報的為用戶付出自己的一切，以滿足用戶的特定需求。但這種「無私的愛」，往往最後讓這些產品沒有走到最後，逐漸消失在用戶的視線中。而用戶也不會任何留戀，轉而再次打開APP商店，尋找下一個「無私」的產品。
問題的關鍵並不是在於如何加入社交因素，而是在於如何讓用戶潛移默化中，為產品本身奉獻價值。我們的目的不是為了打開用戶的錢包為產品付費，而是為了讓用戶情感上認同產品，願意為產品做傳播者，願意為產品貢獻內容，願意為產品提出建議，願意讓產品越變越好。
實現這一目標還有很長的路要走，但讓工具類產品具有一定的社交化屬性，是第一步。
作者：CHinos，從傳統製造業半路出家轉行網際網路的產品經理。公眾號：chinoslab，歡迎交流
本文由 @CHinos 原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議