企业产品交互设计杂谈 #悲伤的故事还在继续

#节制
并非每个产品的使用者都是理性，周全，有足够的时间。设计师和产品都很容易自以为是，我们细心设计表单的校验方式，要求表单内容必须合法（合符一定条件）用户才能继续下一步操作。可是真的有必要吗？比如身份证号，或许有的公司有外籍员工呢？为什么一定要强制性的校验呢？我们是否有足够强的业务上的理由，真实世界中的各种可能性或许我们并不知道，对吧？或许如非必要，并不强迫，在某些情形下远远好于过度仔细的为用户着想重要。在不太重要的场合下，系统保留一定的开放性和容错性，并且能领悟到这一点（通过了解用户以及真实需求）远远比一些生硬的交互设计原则和已有惯例重要。


#界面化 or not 这是个问题
一个功能可以有很多种呈现方式，其中一种呈现方式是非界面化直接通过命令行附加参数实现。其实软件最初并没有没有gui界面，gui界面是随着软件发展满足更多受众需求而产生。因此交互设计师在面对某些特殊场景（极少客户的特殊需求，以及部分相当复杂依赖log和代码调试的功能），应该思考有没有必要多做一个界面多提供一个选项。为了那极少数的人或是一个根本不适合以界面呈现的功能，gui界面是无能为力的。特别针对于某些特别高级的功能，操作者面对终端操作甚至可能更方便一些。

界面化与否不仅仅是一种产品存在形式，甚至代表着某种研发上的倾向。一个较为大型的企业软件与应用，底层相当可能存在许多半吊子未经充分包装和开发的功能。这些功能如果未能很好的被整理以及记录，可能在后续造成重复开发。（尤其在核心人员离职后，这类关于项目过程中的细节和不被文档所提及的远景，都会深埋于代码内）。


#deep down inside
每个系统都有很多功能永远埋没在角落，等待着被人发现以及以被用户接受的方式打包组合成一个“新”功能。当一个产品足够大，功能足够多，那么就很可能有很多缺乏恰当包装的沉没功能。很多顾客所需要的功能在系统内并非没有提供，而是产品本身对那些功能缺乏足够包装。这种包装上的缺乏体现在没有完整的设计相关功能或功能只有底层却没有相对应的界面，抑或是分散在角落缺乏整合也可能是根本没有包装组合好并且充分告知用户。

作为企业产品的交互设计师，很有必要通过各种途径发现这些缺乏包装的功能（比如查看jira上的需求，再如和老员工交流，再如有空就玩一下系统内的各种功能）。当了解这些状况后，才能更好避免重复制造轮子或是重复掉入陷阱的悲剧。


# 像游戏一样精细运营
如何引导新用户，如何提高转换率，如何更好的推介新功能，如何让用户逐渐从新手变成有经验的使用者？或许我们可以思考游戏如何做到这一点。现代游戏要么通过极强的数据运营（国内手游）要么通过业界多年服务用户的经验（ 荒野大镖客  by rockstar）很好的发展出完整的方法论。

关于引导与吸引用户有很多具体的理论和技巧，但是这些零碎的技巧可以通过游戏中采取的技巧形成更为完整的理论。个人认为游戏是对于虚拟世界的构造以及互动方式构建，普通软件和网络服务只不过更接近于真实世界的构造和互动（假设的确存在一条一边是现实另外一边是虚拟世界的轴）。

或许会有那么一天，也会发展出现代游戏那样服务用户的复杂交互方式。可以通过用户过往行为以及人口学特征针对性的推送帮助以及组合呈现功能（现代fps游戏可是根据玩家状况控制弹药枪支攻击甚至是敌人ai的行为）。


#研发的风险
有一些功能之所以需要被反复开发以及在上线后依然出现大量问题，与前期的技术和产品设计上的懒惰不无关系。假如一个顾客相对重视但是却没有太多技术难度的功能，贸然交给没有相关经验的新人（或是最初功能开发从未从产品的角度开发而是一味简单完成需求或者满足技术指标），可能会带来一些后续的问题。我能理解每个企业都会以各种kpi的方式对绩效进行考评，但是对于一些事故本身如果不进行思考并且加以记录，可能在老员工走后那么这些经验和教训无法转化为日后的研发和管理上的有效积淀。对于kpi的追求可能还会带来下属从功能设计到实现上的取向，比如偏向于保守的开发功能，再如倾向于保持研发的审美（通常这种审美都意味着保留较高复杂性给普通用户）。

很多公司都会追求某个功能能直接带来的效益（对于企业产品而言这点尤甚），但是部分功能以及其优化和提升并不一定构成核心要素吸引顾客购买。然而，他们却对于留住核心用户以及培养核心用户有帮助。因此，过度简单粗暴的追求数据，不如仔细思考和定位每个功能和开发行为的价值所在。否则从产品到研发和设计，都会努力挖坑而非填坑。