起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識【摹客RP測評大賽優秀作品】協作設計風云際會，藍湖摹客誰與爭鋒
#本文為2022摹客RP原型工具測評大賽三等獎作品
在項目進行過程中，產品、設計、研發、測試是項目的核心角色，但卻很少能夠做到信息同步，高效協作。對此，選擇一個良好的協作平臺能夠助力他們高效協作，推進項目落地。本文就當前原型協作設計市場中的藍湖和摹客作為分析對象，以此明確協作設計領域的關鍵。
我雇的明明是兩只手，怎么卻來了一個人。
亨利·福特的這句經典的話道出了企業演進的終局。在極致內卷的當下，企業的效率革命將是更多企業作為活下去與建立壁壘的重要手段。
最近，華為任正非內部講話的寒氣，不知道讓多少打工人感到瑟瑟發抖。全國的市場，其實早就感受到了凜冬將至。今年大廠、中廠降本增效的新聞一直不絕于耳。而作為身處漩渦之中的一名產品設計者，從團隊整體效率的視角出發，深感部門內耗造成的時間與成本上的浪費有多嚴重。
產品、設計、研發、測試等角色作為項目中的關鍵節點，很少能做到信息同步，高效協同。而作為單兵個體，每個角色又因為工作習慣的不同，常常要付出額外的學習成本去理解其他角色的產出物。在項目目標與最終成果上，經常出現偏差。產品經理、設計、研發之間因為協同效果差造出的段子，已經足夠養活一個脫口秀演員了。
市場中一直在涌現解決以上問題的解決方案，在這些解決方案中，通常會把主要用戶群體聚焦到設計師或產品經理。比如摹客、藍湖。
摹客對于協作設計工具的理解是通過打通產品經理、UI設計師日常協作場景，形成協作閉環。除了提供常規的原型設計工具、UI設計工具，還增加了UI設計規范模塊，為原型設計與技術執行賦能，提升協作效率。
藍湖對于協作設計工具的理解是偏向于設計團隊的，對于產品經理的工具搭建能力較弱（后面會專門針對相關模塊進行對比）。導致藍湖在應用時，基本是設計團隊專門使用的工具產品。只有在設計內容交付時，才會涉及到和產品經理、研發、測試的交互，并沒有很好的做到全流程協作。今年藍湖推出的MasterGo更是專門面向UI和UX同時設計交付的產品。
至于摹客和藍湖在用戶工作中是如何組織的，我們就通過用戶在摹客和藍湖上工作流程的拆解，橫向對比一下吧。
一、啟動項目/歸檔項目
一個項目從規劃敲定再到啟動，其實是有一套比較科學且規范的項目管理的。
首先，一個需要團隊協同的項目，需要從一開始就清晰的記錄項目的相關背景知識。這個將作為解釋項目的源起，也是達成團隊共識的利器。通常這種內容將以各種文字、表格、圖片等內容形式去呈現。然后團隊成員基于項目背景知識的理解，產出各自的內容交付。
產品經理會產出相關需求文檔與原型圖。UI和UE會產出設計稿，測試會交付測試用例，技術會交付代碼。不過基于當前協作設計產品的定義，基本都是停留在產品經理與設計師兩個團隊更顯性，更易傳播的內容的建設。不同公司對于項目知識的解構與協作不同，就會選擇不同的工具產品去組織業務。此時，則考驗不同協作設計工具，對于業務流程最優解的理解了。
摹客平臺在啟動項目時，會將不同載體的內容分類來組織項目知識。文檔作為輕量級的項目內容描述，更適合背景、目標、價值、用戶故事、其他項目知識等文字內容的描述。原型稿與設計稿分別針對原型文件與設計文件進行專業化的內容呈現。通過固定化的分類方式，引導項目團隊成員根據固定的文檔組織方式進行項目知識存儲。甚至在中大型項目中，在整個項目周期內沉淀出的資源、規范、動態和工作任務仍可在項目中進行協作。
在項目交付后，項目知識往往可以得到很清晰與完整的保留。
作為生產力工具，摹客RP、摹客DT是和摹客CC打通的，在摹客CC中創建好項目時，即可發布到項目中，保障項目從創建到執行都可以線上協同。
而藍湖在創建項目時，同樣是創建出產品與設計的模塊，不過在模塊設計中，更偏向于項目團隊成員在其他工具中設計完成后，在藍湖的項目中進行歸檔。
藍湖中也嵌入了MasterGo這個設計工具的引導，不過也只是引導而已，兩個工具的團隊沒有打通，導致用戶從藍湖跳轉到MasterGo之后，并沒有將內容回流至藍湖，導致內容斷層。
二、產品經理產出需求
產品經理作為項目的靈魂，通常也是項目組織中的關鍵節點。圍繞產品需求產出的設計圖與最終代碼交付產生的線上產品，都是以原型圖作為起點，進行項目串聯的。作為中間點，在團隊協作時，理應讓原型圖可以快速驗證。需求中的隱患越早暴露，影響越小。
摹客專門為產品經理搭建了一個原型產出工具摹客rp，通過解構產品經理輸出原型的流程與痛點，既提供了常用的組件工具與基本的交互設計，還打通了設計資源，讓設計師與產品經理在需求設計時即產生協作，在提升原型產出效率的同時，保障了設計規范上下共識。
同時，針對使用Axure的產品同學，仍然提供了項目上傳與管理的方法。
摹客對于產品經理的原型模板也做了重點支持，提供部分大廠的原型設計方案，幫助產品經理快速產出原型需求。
而對于產品經理的生產力工具的支撐，藍湖并沒有進行重點建設，只是提供了產品文檔上傳。這種設計思路大大降低了產品經理對于藍湖生態的粘性，無法完全保證項目完全在藍湖生態下運行。
三、UI、UE產出設計稿
目前國內設計團隊使用的軟件大部分還是依賴國外的UI設計軟件，但UI設計軟件是一個難度相對較低，壁壘不高的領域。設計師并不是一定要依賴國外的軟件的。今年figma斷供大疆，更是加速了國內設計師擁抱國產軟件的節奏，當前的UI設計領域當真是風云際會，今年上半年UI設計軟件更是迎來了一波流量高潮。其中摹客dt就是其中比較有代表性的產品，這里不討論運營向的動作，只聚焦一些產品設計方向進行產品力思考。
摹客針對UI、UE團隊設計了摹客dt這款工具，支持通過一款工具解決設計圖與交互的完成。從設計工具的角度分析，中規中矩，基于摹客團隊生態生長，基本滿足了設計師的日常內容產出需求。
在設計圖產出后，通過打開設計稿，設計師、產品經理、研發可以圍繞項目面板上的設計圖進行評論、定稿協同、矢量圖標注與生成代碼。不過這種工作流程的設計思路有個弊端，就是項目團隊要制定機制，保證團隊成員通過打開設計稿進行信息標記，同時信息可以及時反饋給設計師。當然，這里摹客提供了打通微信提醒的機制，但是這種機制仍然是后置的，需要團隊流程進行管控的。并沒有通過產品力形成團隊自組織。
四、需求評審
在需求評審時，一個能把需求描述清楚的線上內容載體至關重要，這個內容載體既要描述清楚需求的背景知識，還要描述清楚需求中研發需要做哪些工作，讓研發可以進行工作量評估。同時還要讓測試可以根據內容評估出測試用例。最終這個內容載體最好支持實時協同，一個高效的需求評審會，會后就要即時形成結論性的成果，即需求文檔里面有異議的地方應都有對應的結論與解決辦法。會后技術和測試就可以開工執行了。
在摹客的項目中，需求將圍繞CC中的項目文件進行評審。產品經理首先可以通過文檔模塊傳遞項目的基本背景，隨后即可針對原型稿進行具體的原型流程闡述。
不過這里有個細節其實可以拿出來思考一下，就是關于查看詳情模式與演示環節在項目流程中的作用。從目前摹客設計的流程來看，用戶需要先進入查看詳情模式，這里可以完成評論、定稿、開發標注等動作。這里的產品框架沿襲自摹客設計稿協作思路。不過通常原型稿不是實際的設計稿，在這里有這樣一個環節其實很容易讓人錯愕。
此時，產品經理如果想要針對原型稿進行原型稿的講解，需要點擊演示才能進行（因為產品經理的備注信息是在演示時才能展現出來的）。這樣就導致需求評審在這個環節加入了原型細節評論與原型整體呈現的二元割裂場景。無法讓產品經理判斷出要通過哪種方式組織需求評審的協作更加合適。
從我個人的角度可以發散個思路，就是把查看詳情的流程和演示的環節合二為一，讓需求評審的環節真正發揮原型講解與實時評論交互的操作。提升團隊協作效率的同時，也減少用戶在宣講需求時關于系統流程的冗余思考，縮短決策路徑。
查看詳情模式：
演示環節：
五、一個細節
關于摹客這款產品，有個產品體驗的細節還是想要單獨討論一下的。作為一個小白去第一次接觸摹客，實際上會發現這個細節剛開始感覺很奇怪，仔細一思考就理解了為什么這么設計。但是在理解過程中，就已經付出了學習成本，這些學習成本最終會反作用于產品增長。
場景是在項目創建多終端樣式的頁面時，會讓項目類型與實際項目中的頁面不符。這個體驗會導致用戶理解成本升高，此時用戶內心會感受到不安，因為無法預期項目能否順利演示。
當點擊確定時，發現頁面樣式與底部的項目類型不匹配，此時不安的情緒高漲，想要趕緊預覽一下，看到底是什么情況；
當預覽發現圖真的和內容不匹配之后，內心直接崩潰了。用戶面臨的要么是棄用，要么是繼續探索（還會面臨幾次精神崩潰），終于發現要按照終端規則進行項目創建。
這里還有一個細節比較反人性。當項目初始值設置為網頁項目時，在切換頁面為手機項目時，默認是橫屏。根據手機的硬件的設計原則，是鼓勵用戶豎屏使用手機的，這個原則遷移到移動端的項目中后，豎屏的設計就是是占大多數的。即使平臺希望用戶一直沿用橫屏的體驗，其實也應該考慮到，在這里創建移動端的項目究竟是為什么。這塊的細節實在是不應該漏掉這種設計認知。
這個模塊違反的設計原則是設計中重要的原則之一，所見即所得。當我們進行一項設計時，很自然的會根據我們的既有慣性去進行使用，摹客提供的畫板想要規范化每個項目的畫板，節省用戶操作的思考，這個思路很好，既可以讓用戶專注終端設計，又在項目結束時，可以自動的歸檔每個終端迭代的內容。
不過每個公司對于項目的組織形式是不同的。有的公司是以終端進行劃分的項目，比如做APP的一直做APP，而有些小公司的項目是綜合性的，一個項目往往要多終端，前后臺進行配合，當一次迭代在同一個項目中建立時，往往可以對項目描述的更加立體，更便于執行，且后續在歸檔時，往往會以迭代的里程碑進行歸檔，終端只是里程碑中項目范圍的描述。
在當前階段，小公司和小團體其實是摹客不可忽視的一股力量。這種多終端融合的項目執行在摹客上創建過程并不是很流暢，往往需要付出幾次調整后，才能慢慢的掌握使用方法。這也是為什么小公司還有很多仍然繼續使用Axure，因為Axure更加兼容并包，對項目的組織更加靈活，在設計中與設計完成后都遵循所見即所得的原則。
結語
通過以上的對比，摹客和藍湖體現了兩種協作設計平臺的設計方向，一個是平衡各角色在系統中的參與，從而讓各角色都通過系統中的工具實現無縫協作；另一種是打通單點，通過一個工具能力的突破，帶動其他角色參與到平臺上。
兩種方向哪種更優我先不說我認為的答案，我們可以先進行一個思考。
我們在抱怨PS太難協作，交付的設計稿到開發的過程中拉扯低效，本質的原因是什么？
我們還會抱怨axure操作繁瑣，制作高保真原型時間長，最后評審的時候，頻繁修改導致版本控制困難等，本質的原因是什么？
這些問題真的只需要在工具中加上協作方案就解決了么？只能說解決了一部分問題，設計師和產品經理的工作效率提升了。但是在團隊協作過程中，我們從項目發起到項目實施，最后到項目收尾，整體流程產品、設計、研發、測試等角色的整體協作流程還是會因為自己使用的工具不同，溝通仍然需要需要借助通信軟件進行項目實施的“最后一公里”。在項目完成后，項目產生的內容仍然是散落在不同地方。我們最后在組織過程資產的整理時，很容易遺漏關鍵知識，導致知識傳承斷檔，影響關鍵產品決策。
在產品設計工作中，我們會發現，不同角色的核心價值，通常都不是使用工具的熟練能力帶來的。比如產品經理，對用戶、對需求的洞察力的判斷，是衡量一個產品經理是否專業很重要的維度。反而在實施階段的原型設計，只能算作產品經理的一個基本功，做的再出彩也只是個人的特性，不會作為產品經理能力的體現。比如設計師，對設計方向的把控是其核心的產出，設計工具的運用也只是為了更快的實現其設計的思想。
團隊之所以被稱作團隊，是企業寄希望個體協作的力量要大于每個單體產出的內容，團隊協作最好能通過某種連接組成一個整體，而這種連接，我愿稱之為“生態圈”。就像我因為買了一臺iPhone，當我需要一個無線耳機的時候，我第一選擇往往是AirPods，然后在選擇其他電子產品的時候，都會在先去聯想蘋果生態有沒有對應的產品。
產品設計的“生態圈”就是類似這樣的感覺，每個人都期望在這個圈子里享受到觸手可得、快速響應的工作節奏。這種“生態圈”的建立，才是協作設計工具領域的終局。每一個工具縱深能力的探索，都只是創造了一個用戶選擇而已，并不是給用戶一個成熟的解決方案。比如我們選手機，大多數人不會因為moto razr手機真的很帥去選擇摩托羅拉的手機。反而是鴻蒙生態給了人們生活中各項需求協同的解決方案，讓人欲罷不能，大多數人最終會選擇購買華為手機。
摹客，是致力于搭建這種“生態圈”的。一旦用戶接觸了摹客，就會發現團隊協作的最優解，就可以通過摹客提供的各種工具去實現。這種自然生長出的用戶使用，是產品力的最佳體現。當然“生態圈”的搭建仍然任重而道遠，除了本文著重分析的產品力，還要有跟更多運營導向的設計介入其中，不過產品力始終是產品能否支撐起用戶體量的根本。
協作設計領域因為工具的低壁壘性，搶占用戶將是未來的第一要務。在更遠的未來，出需求，設計圖，寫用例，壘代碼這四個互聯網領域每天都在發生的行為終將走向自動化的方向。而到了彼時，站立舟頭的，又是哪位船客呢？
本文為2022摹客RP原型工具測評大賽的測評文章，如對摹客RP感興趣可點擊體驗鏈接：https://www.mockplus.cn/rp-event/?hmsr=woshipmsonghengda
專欄作家
宋恒達，微信公眾號：產品自由之路，人人都是產品經理專欄作家。深扎教育行業，以產品的視角探尋教育的本質。喜歡以閱讀去不斷破圈，也享受破圈帶來的認知提升。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論，等你發揮！
