从追求逻辑完美到思考化繁为简

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

对于产品设计师来说,基于严谨缜密的思维与过往积累的经验,考虑全面各种可能的边界场景状态,输出逻辑完整清晰的设计稿是一项比较基本、重要的素质。但有的时候,产品的业务架构会很复杂,牵涉到的目标人群也很多,甚至相关的市场战略目标也在瞬息万变;若果我们仍在一开始就对各种场景细节近乎面面俱到地追求,则难免会陷入为兼容各种复杂逻辑而纠结痛苦的境地。

hongying

好不容易绞尽脑汁想出一个看起来逻辑完美、各种可能的需求行为都兼顾到、咋一看无可挑剔的方案,却走入各种尴尬境地:考虑了所有可能的操作路径,最终呈现的界面却不能被多数用户认知理解;为某个潜在场景精心设计了一套流程逻辑,整体复杂度也直线上升,却发现最终真正用到的人寥寥;因为涉及到的开发工作量大、对于短期业务目标的提升又不明显等缘故,被优先级的大棒直接砍掉最后不了了之……

大众用户与专家场景

产品可能需要同时服务于好几类用户,而各类用户的需求存在差异甚至矛盾冲突,如果一开始就想着把所有用户的所有潜在需求场景都考虑到,不仅设计过程中会纠结,最后的产出也难逃给人复杂的印象。

有时候,一些造成设计复杂度上升的功能,并不会被80%的大多数用户介意,而只有少数的专家用户有用到它们的场景;专家用户可以相对轻松地理解和使用这些高级功能,但当它们呈现在大众用户面前的时候,却会让后者产生困惑甚至畏惧的心理。

当这些专家用户并非我们产品的核心目标用户,或高级功能于他们来说只是对体验影响不大的锦上添花时,不妨尝试对这些影响整体设计复杂度的功能做做减法,使用如《简约至上》里删除、组织、隐藏、转移的四大原则,保证呈现给大众主流用户的使用场景是简单的,而复杂藏匿在背后角落。

复杂也许并不存在

当需求方提给我们一个复杂的设计需求时,要追问清楚具体的用户使用场景和背后业务缘由,验证复杂设计需求的必要性,而不是强行yy出伪场景并为此纠结。对场景的完美主义让我们为复杂而痛苦,但复杂本身可能并不存在。

有时我们可以凭直觉感受到复杂的需求本身不是很站得住脚,但说服对方砍掉却困难重重,这时就要更依赖数据或用户来说话。比如可以围绕这个需求快速出一个粗糙的 Demo,找几个真实用户或非常熟悉真实用户的人测试,询问他们是否在意这个功能,是否有想用到它的场景,还是觉得可有可无或者根本用不到;而不是强行根据需求倒推伪场景,陷入根本没有存在必要的纠结。

拆解排期与主动跟进

经过了减法的整体设计方案,也可能仍然会需要较大的开发工作量,在上线时间紧迫的时候被 PM 根据优先级选择直接砍掉几个模块也情有可原。于是有时我们发现自己耗费心神想出各种方案,最终却白白浪费了精力。

若一味听信他人随口说的「之后再上」,而缺少自己主动去跟进和推动的意识的话,有可能「之后再上」会慢慢变成「永远上不了」。

市场、战略和目标用户不会一成不变,项目每一阶段的业务目标也会有调整。除了关注当前手中的工作之外,也要带着更全局、前瞻一点的意识去规划未来的产品设计。了解项目组中长期的规划蓝图,根据各阶段业务目标拆分和调整设计方案并与大家达成一致,在每一阶段主动跟进一部分设计方案的落地上线,而不是让设计稿永远沦为飞机稿式的存在。

 

本文由人人都是产品经理专栏作家 @鸿影 原创发布于人人都是产品经理 。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中