附交互设计知识点 产品用户体验设计在交互上的问题( 四 )


举一个最近的例子来说明 。
应用程序表单创建功能 。在设计PC机时 , 设计了通过excel批量导入数据的功能 。但是这个功能完全复制在APP端 , 完全是反例 , 也是脱离使用场景的产品 。
设想一下:APP端本身不适合Excel处理编辑 , 但难点在于APP端的应用表单创建 。我们也是先在PC端处理Excel , 然后发送到app端 , 再在APP端导入 。如果有问题 , 需要在PC端进一步修改 , 然后同步到手机上 。
显然 , 上述场景本身并不存在 , APP本身也不应该设计上述功能 。
效率和易用性有时是矛盾的
最近看到一个PC端功能的实现 , 整体采用了向导式的设计风格 。看起来挺好的 , 每一步都做了详细的讲解和改进 。即使是第一次操作该功能 , 也可以在没有他人帮助的情况下完成 。
不要让我思考 , 这是产品可用性设计中常说的 。但是不思考不代表用户是傻子 。而是要尽量通过引导来减轻用户的记忆负担 。
什么是记忆负担?
如果一个月只用一次功能 , 下次再用的时候很可能就记不清楚一些操作步骤或者输入要求了 。但是如果你每天用一个功能 , 每天用100次 , 这个场景你就没有任何记忆负担了 。
比如上面的功能 , 这个功能只针对企业的财务人员 , 不针对所有用户 。财务人员每天都可能使用该功能进行成本核算相关的工作 , 并且该功能的使用频率相当高 。
那么我们的导轨设计就是一个糟糕的设计 。
也就是说 , 因为向导设计 , 一个文档的处理时间会增加20秒 。如果财务人员一天要处理100个单据 , 就要多花半个小时 。
反而大大牺牲了功能的可用性和效率 。
单功能设计到多功能协作
正如我们在之前的采访中谈到交互设计的核心 , 交互设计往往需要基于场景的多个功能之间的动态协同设计 。基于业务场景实现各功能点之间的自连接 。
要做到这一点 , 交互设计者或需求者必须对业务场景有深刻的理解 。任何功能都不应该孤立存在 , 除非是为了实现业务场景或目标 。
或者以一个报销制度为例 。系统提供业务申请、在线酒店机票估算、业务报销等业务功能 。员工出差的场景是:
首先提交出差申请单 , 出差申请等待主管领导审批 领导审批通过后 , 进行机票预订 , 进行酒店预计 出差返回后进行报销那么 , 如果考虑场景中的多功能协同 , 是在出差申请提交通过后快速引导我到机票预订界面 , 还是让我找到半天机票的预订位置?其次 , 旅行申请已经填写了旅行的地点和日期 。在进入飞机票预订界面时 , 能否快速默认输入地点和日期 , 从而减少输入工作量?最后 , 我基于出差申请报销时 , 出差过程中产生的机票、酒店、出租车等费用是否会自动归集 , 而不是手动导入?
当我们谈到这些内容时 , 我们可以看到 , 即使是最简单的出差场景 , 我们也可以做大量的场景分析 , 在此基础上 , 我们可以分析功能节点如何协作 , 如何更加自动和智能地连接 。
易用性和软件智能
对于整个软件的可用性设计来说 , 一个很大的发展趋势就是向智能化方向发展 。
比如首页的快捷功能入口 , 不是简单的固定快捷功能 , 也不是让用户自定义快捷功能 , 而是系统要自动分析哪些功能是用户最常用的 , 然后列出常用的功能 。
比如一个APP在提供搜索功能的时候 , 一般都会有搜索的历史真实性 , 方便我们用已经搜索过的历史查询条件快速搜索 。这个功能本身可以提高效率 , 减少内存 。
但是这个功能并不是简单的将所有的搜索历史进行整理 , 而是分析哪些查询条件是用户频繁搜索并大量使用的 , 而最需要显示的也只有这些搜索条件 。而不是展示大量的搜索历史 , 用户被困在信息冗余中 。
如果定义了一个新词 , 即AI-可用性 , 智能可用性 。
有些可用性、高效性、便捷性并不是一开始就设计或固化的 , 而是系统可以智能分析用户的行为和操作 , 然后给出优化的可用性调整设计 。


推荐阅读