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