对于产品设计师来说，基于严谨缜密的思维与过往积累的经验，考虑全面各种可能的边界场景状态，输出逻辑完整清晰的设计稿是一项比较基本、重要的素质。但有的时候，产品的业务架构会很复杂，牵涉到的目标人群也很多，甚至相关的市场战略目标也在瞬息万变；若果我们仍在一开始就对各种场景细节近乎面面俱到地追求，则难免会陷入为兼容各种复杂逻辑而纠结痛苦的境地。好不容易绞尽脑汁想出一个看起来逻辑完美、各种可能的需求行为都兼顾到、咋一看无可挑剔的方案，却走入各种尴尬境地：考虑了所有可能的操作路径，最终呈现的界面却不能被多数用户认知理解；为某个潜在场景精心设计了一套流程逻辑，整体复杂度也直线上升，却发现最终真正用到的人寥寥；因为涉及到的开发工作量大、对于短期业务目标的提升又不明显等缘故，被优先级的大棒直接砍掉最后不了了之……
大众用户与专家场景
产品可能需要同时服务于好几类用户，而各类用户的需求存在差异甚至矛盾冲突，如果一开始就想着把所有用户的所有潜在需求场景都考虑到，不仅设计过程中会纠结，最后的产出也难逃给人复杂的印象。
有时候，一些造成设计复杂度上升的功能，并不会被80%的大多数用户介意，而只有少数的专家用户有用到它们的场景；专家用户可以相对轻松地理解和使用这些高级功能，但当它们呈现在大众用户面前的时候，却会让后者产生困惑甚至畏惧的心理。
当这些专家用户并非我们产品的核心目标用户，或高级功能于他们来说只是对体验影响不大的锦上添花时，不妨尝试对这些影响整体设计复杂度的功能做做减法，使用如《简约至上》里删除、组织、隐藏、转移的四大原则，保证呈现给大众主流用户的使用场景是简单的，而复杂藏匿在背后角落。
复杂也许并不存在
当需求方提给我们一个复杂的设计需求时，要追问清楚具体的用户使用场景和背后业务缘由，验证复杂设计需求的必要性，而不是强行yy出伪场景并为此纠结。对场景的完美主义让我们为复杂而痛苦，但复杂本身可能并不存在。
有时我们可以凭直觉感受到复杂的需求本身不是很站得住脚，但说服对方砍掉却困难重重，这时就要更依赖数据或用户来说话。比如可以围绕这个需求快速出一个粗糙的 Demo，找几个真实用户或非常熟悉真实用户的人测试，询问他们是否在意这个功能，是否有想用到它的场景，还是觉得可有可无或者根本用不到；而不是强行根据需求倒推伪场景，陷入根本没有存在必要的纠结。
拆解排期与主动跟进
经过了减法的整体设计方案，也可能仍然会需要较大的开发工作量，在上线时间紧迫的时候被 PM 根据优先级选择直接砍掉几个模块也情有可原。于是有时我们发现自己耗费心神想出各种方案，最终却白白浪费了精力。
若一味听信他人随口说的「之后再上」，而缺少自己主动去跟进和推动的意识的话，有可能「之后再上」会慢慢变成「永远上不了」。
市场、战略和目标用户不会一成不变，项目每一阶段的业务目标也会有调整。除了关注当前手中的工作之外，也要带着更全局、前瞻一点的意识去规划未来的产品设计。了解项目组中长期的规划蓝图，根据各阶段业务目标拆分和调整设计方案并与大家达成一致，在每一阶段主动跟进一部分设计方案的落地上线，而不是让设计稿永远沦为飞机稿式的存在。
网友评论