针对于设计解决方案，同样也具有可复用模式，不同业务或许会有些许差异，但基本思路依然可复用。本文复盘工作中所遇到的问题，针对发布功能如何设计进行分析，希望对你有所启发。
前几天在看《设计体系》，书里提到了设计模式的概念。此概念最早是建筑师克里斯托弗·亚历山大在他的著作《建筑的永恒之道》和《建筑模式语言》中提出的。
在《建筑模式语言》里是这么描述模式的：“每种模式都描述了一个在我们的环境中反复出现的问题，以及该问题的解决方案的核心思想。”在《设计体系》中，将模式描述为一种用于解决特定设计问题的可复用的方案。
在《界面设计模式》中也详细介绍了不少的界面设计模式。我想对于设计解决方案也同样存在可复用的模式，只不过会根据业务的不同存在个体差异，但基本思路依然可复用。
所以本文重点针对发布功能，复盘一下工作中遇到的问题。
需求是这样的：
高等院校针对每一个专业会有相对应的一份人才培养方案。培养方案中包含培养目标、毕业要求、课程等相关设置项。教务处的老师在平台内完成培养方案录入和设置，其中课程目标会分配给相关授课老师去设置。大家各自完成自己负责的部分后，由教务处的老师发布培养方案，培养方案的相关数据就可与学习活动关联起来，计算每个学生对应培养方案中的各个要求的达成情况。
在系统原有的设计中，培养方案发布功能不可逆，一旦发布就不可再进行编辑、撤回。这导致培养方案发布后若老师发现部分课程尚未完成维护或者目标设置有误却无法修改的情况。所以为了解决该问题，需在培养方案发布后增加允许重新编辑的功能。
想想你会如何增加？
在原有的功能设计中，对于每一个培养方案仅存在一个版本。若允许已发布的培养方案重新编辑，则对于同一个培养方案会存在 2 个版本，编辑中和已发布的。你也许会想到很多产品发布后也允许编辑，但只有一个版本啊～那么接着往下看～
为什么要发布，实时同步不可以嘛？
发布从字面解释为公开宣传或发表（来自Oxford Languages）。可以理解为将仅自己可管理的内容公开给其他人。发布按钮存在的意义在于让创建者能够控制内容公开的权限。当创建者需要公开时，点击发布按钮就可公开给其他人。若创建者不想拥有内容公开的控制权，实时同步当然也可以。那么什么内容用户想拥有对其公开的控制权呢？
（1）内容的隐私性
比如社交媒体的帖子、个人的照片或视频等，用户希望对自己的创作有一定的控制权，以确保在网络空间中的隐私和安全。
（2）内容的准确度
像学术论文，法律法规，科研报告等一些对内容表达的准确度要求较高的，用户需要仔细斟酌后，使用发布的动作确认公开给其他人或者是允许被其他数据引用。我们产品中培养方案也属于其一，需要确保内容的准确度和严谨性。
（3）公开范围
公开范围越大，代表内容的影响力和传播范围也就越广，错误或者不准确的内容可能会对很多人产生负面影响，从接受者考虑，为了保证内容的准确度需要发布按钮。从内容创建者考虑，内容的准确度会给创建者带来积极的社会效用，所以也需发布按钮。
这种比较常见的就是内容类产品，比如知乎、微信公众号、人人都是产品经理等。发布后通过审核，就会公开给其他人。对于已发布的内容需修改时，点击编辑，完成修改后需点击更新，则更新已发布的内容。若编辑后不更新，退出该页面后，修改的内容就会丢失，所以除了编辑中的状态，并不会存在 2 个版本。
这种设计方案适合内容需要多人协作维护的产品，对于已发布的内容重新编辑时，可暂时保存编辑后的内容，例如 Figma 组件库。
这种方案下，我们可以根据发布人和接收者这两种角色思考其中的设计点。
（1）发布人
a. 发布人如何判断是否需要发布？——提示是否有修改，以及修改了什么？
b. 发布人如何查看修改前后的具体内容？——是否提供预览2个版本？或者在一个预览中标注修改的内容？
c. 发布人发布时，仅支持全部发布？还是可选择发布的内容？
d. 发布人发布后是否可取消发布？
看看 figma 是如何设计的。
（2）接收者
a. 当内容有更新时，首先需提示用户有内容更新
b. 若是自动同步内容，是否需要告知用户变更的具体内容？
c. 若是给予用户自主选择更新的权利，是否告知用户内容有哪些更新？以及用户可否选择要更新的具体内容？
具体设计案例可查看数据更新｜不只是一个更新按钮而已这篇文章。
以上例子中，不论是否发布，用户仍可编辑内容。但当编辑权限被发布影响后，该如何考虑呢？接下来带入我的需求中看看我的设计方案。
学校并不希望对于已发布的培养方案随意变更，但是又要解决老师设置有误的状况，所以我们将对编辑功能增加权限和时间的限制。对于已发布的培养方案增加允许编辑的功能，并且设置截止时间，到期后自动发布。
在实际的业务中，教务处将培养方案某些模块的设置工作分配给其他老师，对于其他老师来说就是一项任务，所以设置截止日期是合理的，截止日期到达自动发布也减少了教务处的工作。
将上面发布流程中思考的设计点带入实际业务中，可得到最终的设计方案如图：
首先从培养方案状态的维度来区分，分为草稿和已发布。这两种基础状态下的操作功能相差很大，草稿状态下是可编辑，可发布的。对于已发布的培养方案仅查看，所以无需发布，也不能编辑，但新增加了允许编辑的权限设置。
那么对于已发布的培养方案又可分为能编辑和仅查看，仅查看就是已发布的默认状态，能编辑被允许编辑的权限所影响。对于已发布状态下能编辑时展示发布按钮，没有内容变更时发布按钮禁用，有变更内容时，发布按钮被激活，可主动发布或者等到截止时间自动发布。
这里一定需从基础状态分层级来梳理，才能更清晰的判断操作按钮是隐藏还是显示禁用更合理。
原本到这里就已经结束了，但在跟产品确认方案时发现还有一个新的模块，这个模块的内容不会受发布状态的影响，可随时编辑，且编辑结果也需告知发布人。所以对于已发布，又多了一种状态——已发布未设置编辑权限仍会发生数据变更的情况。
套用之前的解决方案，先将这个结果塞进去看看。
如图，就会出现，在同一状态下，发布按钮时有时无的情况，这样肯定是不合理的。这种隐含的平台规则没有直观地告知用户，会造成用户困惑，增加产品使用难度。
所以退一步重新思考下问题的本质。展示发布按钮的原因是当内容有变更时，需发布。而当内容仅查看，永远都不会发生变更，所以也就无需展示发布按钮。之前的设计方案中编辑被权限按钮影响，所以当允许编辑后再展示发布按钮，然后根据有无内容变更来判断发布按钮的显隐就很合理。
但现在内容变更不会受权限操作的影响（允许编辑会提示用户可编辑模块），那么发布按钮就需要常显。最终的设计方案如图。
本文主要内容依然是发布功能中需要思考的点，这些思考点是可复用的，竞品的解决方案也是可参考的。但复用到自己产品中仍需针对具体业务设计出满足自己产品业务目标的设计方案，其中肯定会遇到各种限制或者特定的需求，别忘了退一步站在全局视角再思考一下～
大概是这样～感谢阅读～
专栏作家
阿青，公众号：阿青碎碎念，人人都是产品经理专栏作家。B端UX设计师。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。