对于用户体验设计师来说，基于严谨缜密的思维与过往的项目经验，考虑全面多种的用户使用场景状态，输出逻辑完整清晰的设计稿是一项基本、重要的素质。但有的时候，产品的业务架构会很复杂，牵扯到的目标人群也很多，甚至相关的市场战略目标也在瞬息万变；若我们一开始就对各场景细节近乎面面俱到的追求，则难免会陷入为兼容各种复杂逻辑而纠结痛苦的境地。好不容易绞尽脑汁想出一个看似逻辑完整，各种可能的需求都兼顾到、咋一看无可挑剔的方案，却最终走入各种尴尬境地：自以为考虑了所有可能的操作路径，最终呈现的界面却不能被多数用户认知理解；市场变动，被迫导致业务目标的频频调整，设计稿一改再改，面目全非；或因为开发工作量大、对于短期业务目标的提升又不明显等缘故；被优先级的大棒直接砍掉最后不了了之...
大众用户和专家用户
产品可能同时服务于好几类用户，而各用户的需求存在差异甚至矛盾冲突，如果一开始就想着把所有用户的潜在场景都考虑到，不仅设计过程会纠结到死，最后产出也难逃复杂难用的印象。
有时候，自以为设计出甩竞品几条街的牛逼功能，其背后复杂度的提升也一并存在。这些看似高级的功能，其最终结果是被80%以上的大众用户给忽视，而只有为数不多的专家用户才有用到它们的场景；专家用户可以轻松地理解和使用这些高级功能，但它呈现在大众面前的时候，却会让后者产生困惑，不知所措，甚至卸载你的产品。
让永久的中间用户感到愉悦，因为他们的技能将稳定的处于中间层。中间用户才是最多、最重要、最稳定的用户群。
而当这些少数专家用户非产品的核心用户，或高级功能对于他们来说只是体验不大的锦上添花，不妨尝试对这些影响整个产品复杂度的功能做做减法，使用如《简约至上》里删除、组织、隐藏、转移的四大原则，保证呈现给大众用户的使用流程是最简单的，而复杂藏匿在背后角落。
复杂也许并不存在
当pm提供给我们一个复杂的需求时，要追问清楚需求的来源，是否是目标用户在真实使用场景下迫切需要解决的问题，以及背后的业务缘由。验证复杂设计需求的必要性，而不是强行yy出伪场景并为此纠结。对场景的完美主义让我们为复杂需求而痛苦，但复杂本身可能并不存在。
有时，凭我们的经验可以快速判断某些复杂的需求本事并不是很站得住脚，但说服对方砍掉需求又困难重重，这时我们需要借助数据和用户来说话。比如可以围绕这个需求快速作出一个粗糙、完整、可交付的demo，找身边的真实用户做一个小范围的测试，询问他们对于这个新功能的看法，并观察他们在使用过程中遇到的问题。
错误的解决方法还可以被修改，但是不存在的问题是无法通过修改来解决的。
实际上，我们无法100%的确认，但是我们可以通过观察和沟通来尽可能的降低风险。从而发现实际的问题，并搭建符合用户预期的解决问题的方案。
拆解排期与主动跟进
经过了减法的设计方案，也可能仍然会需要较大的开发工作量，在上线时间紧迫的时候被pm根据优先级选择直接砍掉几个模块也情有可原。于是有时候发现自己耗费心神想出的各种解决方案，最终白白浪费了精力。
若一味的听信别人随口说出的“之后再上”，而缺少自己主动去跟进和推动的意识的话，有可能“之后再上”就变成“永远不上了”。
市场、战略目标、核心用户不会一直不变，项目每一个阶段的业务目标也会时时调整。除了关注当前手上的工作之前，也要带着全局的、前瞻性的意识去规划产品未来的方向。与pm、项目负责人了解和商讨项目的中长期的规划蓝图。根据各阶段的目标拆分和调整设计方案，并于大家达成共识。尤其是在每一阶段主动跟进设计方案的开发情况，落地上线，而不是让设计稿永远沦为飞机稿式的存在。
网友评论