針對于設計解決方案，同樣也具有可復用模式，不同業務或許會有些許差異，但基本思路依然可復用。本文復盤工作中所遇到的問題，針對發布功能如何設計進行分析，希望對你有所啟發。

前幾天在看《設計體系》，書里提到了設計模式的概念。此概念最早是建筑師克里斯托弗·亞歷山大在他的著作《建筑的永恒之道》和《建筑模式語言》中提出的。

在《建筑模式語言》里是這么描述模式的：“每種模式都描述了一個在我們的環境中反復出現的問題，以及該問題的解決方案的核心思想?！痹凇对O計體系》中，將模式描述為一種用于解決特定設計問題的可復用的方案。

在《界面設計模式》中也詳細介紹了不少的界面設計模式。我想對于設計解決方案也同樣存在可復用的模式，只不過會根據業務的不同存在個體差異，但基本思路依然可復用。

所以本文重點針對發布功能，復盤一下工作中遇到的問題。

背景

需求是這樣的：

高等院校針對每一個專業會有相對應的一份人才培養方案。培養方案中包含培養目標、畢業要求、課程等相關設置項。教務處的老師在平臺內完成培養方案錄入和設置，其中課程目標會分配給相關授課老師去設置。大家各自完成自己負責的部分后，由教務處的老師發布培養方案，培養方案的相關數據就可與學習活動關聯起來，計算每個學生對應培養方案中的各個要求的達成情況。

在系統原有的設計中，培養方案發布功能不可逆，一旦發布就不可再進行編輯、撤回。這導致培養方案發布后若老師發現部分課程尚未完成維護或者目標設置有誤卻無法修改的情況。所以為了解決該問題，需在培養方案發布后增加允許重新編輯的功能。

想想你會如何增加？

在原有的功能設計中，對于每一個培養方案僅存在一個版本。若允許已發布的培養方案重新編輯，則對于同一個培養方案會存在 2 個版本，編輯中和已發布的。你也許會想到很多產品發布后也允許編輯，但只有一個版本啊～那么接著往下看～

一、為什么要發布？

為什么要發布，實時同步不可以嘛？

發布從字面解釋為公開宣傳或發表（來自Oxford Languages）?？梢岳斫鉃閷H自己可管理的內容公開給其他人。發布按鈕存在的意義在于讓創建者能夠控制內容公開的權限。當創建者需要公開時，點擊發布按鈕就可公開給其他人。若創建者不想擁有內容公開的控制權，實時同步當然也可以。那么什么內容用戶想擁有對其公開的控制權呢？

（1）內容的隱私性

比如社交媒體的帖子、個人的照片或視頻等，用戶希望對自己的創作有一定的控制權，以確保在網絡空間中的隱私和安全。

（2）內容的準確度

像學術論文，法律法規，科研報告等一些對內容表達的準確度要求較高的，用戶需要仔細斟酌后，使用發布的動作確認公開給其他人或者是允許被其他數據引用。我們產品中培養方案也屬于其一，需要確保內容的準確度和嚴謹性。

（3）公開范圍

公開范圍越大，代表內容的影響力和傳播范圍也就越廣，錯誤或者不準確的內容可能會對很多人產生負面影響，從接受者考慮，為了保證內容的準確度需要發布按鈕。從內容創建者考慮，內容的準確度會給創建者帶來積極的社會效用，所以也需發布按鈕。

二、發布后，有更新如何同步？

1. 編輯后確認即更新

這種比較常見的就是內容類產品，比如知乎、微信公眾號、人人都是產品經理等。發布后通過審核，就會公開給其他人。對于已發布的內容需修改時，點擊編輯，完成修改后需點擊更新，則更新已發布的內容。若編輯后不更新，退出該頁面后，修改的內容就會丟失，所以除了編輯中的狀態，并不會存在 2 個版本。

2. 編輯后可暫存，當需要同步時，觸發按鈕同步更新內容

這種設計方案適合內容需要多人協作維護的產品，對于已發布的內容重新編輯時，可暫時保存編輯后的內容，例如 Figma 組件庫。

這種方案下，我們可以根據發布人和接收者這兩種角色思考其中的設計點。

（1）發布人

a. 發布人如何判斷是否需要發布？——提示是否有修改，以及修改了什么？

b. 發布人如何查看修改前后的具體內容？——是否提供預覽2個版本？或者在一個預覽中標注修改的內容？

c. 發布人發布時，僅支持全部發布？還是可選擇發布的內容？

d. 發布人發布后是否可取消發布？

看看 figma 是如何設計的。

（2）接收者

a. 當內容有更新時，首先需提示用戶有內容更新

b. 若是自動同步內容，是否需要告知用戶變更的具體內容？

c. 若是給予用戶自主選擇更新的權利，是否告知用戶內容有哪些更新？以及用戶可否選擇要更新的具體內容？

具體設計案例可查看數據更新｜不只是一個更新按鈕而已這篇文章。

以上例子中，不論是否發布，用戶仍可編輯內容。但當編輯權限被發布影響后，該如何考慮呢？接下來帶入我的需求中看看我的設計方案。

三、實際案例

學校并不希望對于已發布的培養方案隨意變更，但是又要解決老師設置有誤的狀況，所以我們將對編輯功能增加權限和時間的限制。對于已發布的培養方案增加允許編輯的功能，并且設置截止時間，到期后自動發布。

在實際的業務中，教務處將培養方案某些模塊的設置工作分配給其他老師，對于其他老師來說就是一項任務，所以設置截止日期是合理的，截止日期到達自動發布也減少了教務處的工作。

將上面發布流程中思考的設計點帶入實際業務中，可得到最終的設計方案如圖：

首先從培養方案狀態的維度來區分，分為草稿和已發布。這兩種基礎狀態下的操作功能相差很大，草稿狀態下是可編輯，可發布的。對于已發布的培養方案僅查看，所以無需發布，也不能編輯，但新增加了允許編輯的權限設置。

那么對于已發布的培養方案又可分為能編輯和僅查看，僅查看就是已發布的默認狀態，能編輯被允許編輯的權限所影響。對于已發布狀態下能編輯時展示發布按鈕，沒有內容變更時發布按鈕禁用，有變更內容時，發布按鈕被激活，可主動發布或者等到截止時間自動發布。

這里一定需從基礎狀態分層級來梳理，才能更清晰的判斷操作按鈕是隱藏還是顯示禁用更合理。

原本到這里就已經結束了，但在跟產品確認方案時發現還有一個新的模塊，這個模塊的內容不會受發布狀態的影響，可隨時編輯，且編輯結果也需告知發布人。所以對于已發布，又多了一種狀態——已發布未設置編輯權限仍會發生數據變更的情況。

套用之前的解決方案，先將這個結果塞進去看看。

如圖，就會出現，在同一狀態下，發布按鈕時有時無的情況，這樣肯定是不合理的。這種隱含的平臺規則沒有直觀地告知用戶，會造成用戶困惑，增加產品使用難度。

所以退一步重新思考下問題的本質。展示發布按鈕的原因是當內容有變更時，需發布。而當內容僅查看，永遠都不會發生變更，所以也就無需展示發布按鈕。之前的設計方案中編輯被權限按鈕影響，所以當允許編輯后再展示發布按鈕，然后根據有無內容變更來判斷發布按鈕的顯隱就很合理。

但現在內容變更不會受權限操作的影響（允許編輯會提示用戶可編輯模塊），那么發布按鈕就需要常顯。最終的設計方案如圖。

最后

本文主要內容依然是發布功能中需要思考的點，這些思考點是可復用的，競品的解決方案也是可參考的。但復用到自己產品中仍需針對具體業務設計出滿足自己產品業務目標的設計方案，其中肯定會遇到各種限制或者特定的需求，別忘了退一步站在全局視角再思考一下～

大概是這樣～感謝閱讀～