交互设计师的60日计划第十五天

今天晚上去上了想上已久的舞蹈课，超级超级开心。说要学舞说了这么久，总是不能兑现。今年的另一个要实现的事情，就是每周坚持学舞蹈吧。

20150813 产品经理的自己提的方案也可能并不是他想要的

很久以前师父和老大就跟我说过，产品需求文档里的方案不要太当真，产品有的时候可能也不清楚自己想要什么，所以需要我们经过深入沟通和理解之后总结出产品想要达到的目标，再独立进行设计，不用被产品画的交互稿干扰。

今天做的需求就是这样，经过昨天和产品沟通，理解了那一堆复杂概念之后，今天来看产品的需求文档发现可以完全推翻他的方案，自己根据目标设计一套完全不同的方案。

这个需求的目标其实有两个：

1.给用户提供配置消息的快捷入口。因为当前配置消息的功能隐藏在动作和触发器中，要配置消息还要先理解动作和触发器是什么，相互之间的关联是怎样。

2.公有功能中有两种不同种类的功能，用户无法区分，容易混淆，所以需要作出优化。

针对这两个目标，产品经理给出的方案是：

1.给用户提供配置消息的快捷入口，但一类消息入口放在每一个功能的编辑弹窗中，另一类消息入口放在属性配置中。这样消息虽然拿出来了，但太分散，隐藏的也很深，并不是一个好的方法。

2.为了区分这两种不同种类的功能，产品经理将一类功能拿出来单独放到一个tab里，叫属性配置。但实际上没有必要这么大动干戈，占用这么多位置。

所以我针对目标给出了不同的方案：

1.将消息配置单独拿出来，给其一个单独的承载页面，将两类消息都放在一起，但是在添加时填写的表单里做区分。这样功能比较统一，用户比较容易理解这两者之间的关系，从功能中抽离出来也比较清晰。

2.去掉属性配置tab，给消息配置腾地方，直接在公有功能中进行区分。

很多产品经理也很喜欢画交互稿，但是交互设计师不能被他的交互稿限制住，要跳出他的思路独立理性的思考，帮产品找到他真正想要的，做出更合适的方案。

此次分享的 [button type="info" text="交互设计师的60日计划" url="https://www.iamue.com/tag/interaction-designers-of-60-days" open_new_tab="false"]

来自 Killa.G 让我们一起跟着学习和并学会做自己的总结与分享。

作者信息：

  Killa.G