以物业公告为例，谈谈功能设计的一些事

　　产品之路上，逐渐发现：把一件简单的事情做好，并不简单。

　　

　　作为乙方的产品经理，从需求分析到产品交付，需求方除了领导，还有甲方和运营;初始需求是由甲方提出的，更多深层次的需求需要来自于产品经理的发掘，而实际上的使用者又是运营人员。

　　面对需求，需要形成怎么样的设计思路，使自己工作事半功倍?

　　以下，用工作中遇到的一个简单的示例来表达一下自己的想法：

　　一、功能背景

　　传统社区的物业公告大多数是一种推式的展示形式，采用公告板或纸质;随着智慧社区概念的发展，物业公告线上化成为一种常见趋势，相比于前者，后者大大的降低了用户观看的成本，减少了物业维护的工作量，以及更丰富的展现形式深受双方的喜爱。

　　基于最近实施的一套物业系统，想借物业公告功能设计上的细节之谈，开场自己的第一篇文章。

　　二、功能概述

　　功能主要分为两大部分，其一是用户体验的移动端;其二是运营操作的后端;

　　1. 移动端：公告入口、公告列表及公告界面;

　　2. 后端：通过运营操作，实现移动端的公告展示。主要是：新增、排序、编辑等操作。

　　需求层次概述：初始需求-需求雏形-深层需求-优化需求

　　三、功能设计细节

　　1. 功能的规划

　　因为公告在移动端不需要用户互动的场景，所以重点在于后端功能的规划;

　　1.1 主要功能也是大多数功能的后端都会有所体现的，如公告新增、编辑、修改、删除等。

　　1.2 物业公告属于甲方需求，意味着规划上要考虑甲方思维的操作思维，如公告置顶、公告排序。

　　1.3 其次，结合长期运营的实际情况，需要考虑到定期管理的便捷，如定期展示关闭、时间记录。

　　2. 功能的设计逻辑

　　在设计上将公告功能设计成活动功能，通过设置内容、开始关闭时间满足基本需求;但在测试阶段，发现设计逻辑上的一些闭环式缺陷;

　　

　　(截图来自系统原型)

　　2.1 自定义排序

　　优点：通过排序值的大小设定，展示想要向用户展示的公告信息的顺序;

　　缺点：不需要考虑顺序的公告，会因为相同排序而出现扎堆问题;

　　解决：

　　设定一个默认值，默认不作排序，而是按照创建时间来排序;

　　排序值不作为必要的属性，方便运营人员设置管理;

　　设定置顶项，其他按照排序设置排序(最优)。

　　2.2 公告展示顺序

　　已有的公告按照列表展示时，优先级排序的公告位于前页位置，而其余不属于排序类的公告应考虑创建时间先后顺序，早创建的公告应该在列表后面;

　　这点，运营者更考虑到的是当前公告信息的编辑和优化，而历史信息则成为一种记录无须占用前页位置。

　　2.3 编辑的情况

　　公告在展示期间内是否要做修改?因为不存在因修改导致以往记录数据混乱等风险问题，所以对于公告此类文本内容是可以修改的，这是从运营工作的层面上考虑;

　　但避免误删情况，在展示期间内操作删除，应有温馨提示。

　　2.4 开启关闭状态

　　新增公告设置保存后默认关闭状态，独立的开启操作可以使公告的展示更安全;

　　而关闭操作，既是对过期公告的一种关闭展示，也是后期运营的记录。

　　四、功能优化细节

　　为什么要将功能优化这一块单独讲，而不是一起放在功能设计上呢?

　　现阶段系统正处于验收阶段，考虑到时间和成本问题，有一些功能优化的细节会有所考虑，而一些没有考虑到的希望有读者可以提出，共同探讨。

　　1. 用户互动性

　　如果公告只是一面墙，业主除了看公告，是不是会对公告内容蠢蠢欲动，想要发言?

　　优化点：选择性开放留言点赞功能，活动型公告可通过开放留言，形成一种互动交流，物业管理需要建设性的意见(这属于线下层面的考虑)。

　　2. 编辑日志

　　什么时间，什么操作人物，对公告的编辑动态信息作记录，增加问题追溯源。

　　3. 用户浏览数据

　　统计用户对公告的浏览数据，对于物业公告这个模块的长期运营起到较为重要的作用。

　　五、总结

　　以上，是结合最近实践中物业公告功能提炼的内容，可能存在一定的局限性。

　　物业公告在物业管理系统中是一个基础性功能，可能在设计阶段会因为浅层次的需求分析，对功能雏形会有初步的规划;

　　即使后期产品成功交付，也要多多考虑后期运营上的规划。

　　这是第一次通过文章对产品设计上的总结，希望自己能坚持，也欢迎大家多交流学习。

　　本文由 @Miss思思 原创发布。未经许可，禁止转载

　　题图来自 Pexels ，基于 CC0 协议

*请认真填写需求信息，我们会在24小时内与您取得联系。