案例

说三个事，来进行反思

第一

运营需求：希望在管理后台看到每个标签的更多信息（eg.参与人数、帖子数量、创建时间等等）。

我的设计结果：在管理后台添加了「标签详情页」，在里面放了标签的「基础信息」「帖子列表」，还自以为很贴心地加上了「查看所有发帖用户」的功能。

第二

运营需求：希望管理后台的文章列表里将「精品」和「置顶」分开，并能用「拖拽」的方式来更改置顶文章的排序。

我的设计结果：在管理后台文章列表里新增了「置顶」tab，并支持「拖拽」来改变置顶文章的排序。还自以为很贴心地为文章详情页的「置顶」按钮也改成了「拖拽」的交互方式。

第三

运营需求：管理后台在设置延时评论的时候，能对「发送时间」有「快捷选择」，而不是每次都需要用时间选择器去选择具体的 月-日 时-分-秒

我的设计结果：暂不考虑，优先级 Low

反思结果

如何排优先级

这里撇开开发难度，就针对以上三个事情，在接需求做产品设计的时候应该如何考虑。问自己几个问题：

1、用户能感知到吗？

2、用户的感知程度是多少？

3、对用户完成主线任务有多大帮助？

以第一、二个例子为例，都只能帮助到运营去管理。更别说第二个例子中，「置顶」帖子的数量最多就四、五篇，人工操作就算有些困难，但是也不会真的难倒要死要活。用户感知不到这些优化点，因此优先级非常低，甚至完全可以不考虑。

反观第三个例子，因为当前操作确实繁琐，容易误操作，所以非常容易给用户带来直接的影响（每次评论都会给用户发通知）。所以这个才是相对来说需要优化的地方。那么其实第二个例子中，「置顶」顺序变化也会被用户感知到，但是顺序错误又如何，且极少有用户关注版块里的置顶部分。

但是给自己的「评论」通知，用户都是会仔细看的，若时间不真实，很容易穿帮。

需求处理产品设计

光是理解需求是不够的，那理解目的呢？也是不够的。

理解需求，弄清目的，结合当前产品设计，再设计  才是正确的思路。

在第一个案例中

1、我忘了我们现在能在客户端上让管理员进行操作的功能，就不要再放在后台了这个事

2、运营用标签做了一个活动，活动结束后查看活动结果。那么我不应该按照他们说的需要哪些信息、功能来一个个照搬照抄地做。而是思考我应该如何使用标签来组织一场活动，并且结合当下已实现的功能（进行优化），需要考虑的包括：活动前期（组织阶段）、活动中期（进行阶段）、活动后期（结算阶段）