如何在交互设计层面,合理地降低开发成本?
- By 本站 - 2023-06-12 17:16
- Read:468
“这个项目很急开发资源少,要设计地尽量简单”
这可能是交互设计师最不喜欢的一句话。因为设计“创新、细腻、高级”的交互方案是我们的天职,“简单低成本”这种设计需求简直在亵渎交互使命。最近笔者遇到了很多这类项目,但设计师总要帮助项目解决问题。于是最终还是很开心地把项目搞定,顺便总结了一下:如何在交互设计层面,合理地降低开发成本,与大家分享。主要回答以下几个问题:
降低开发成本的“设计方案简化工作”,应当在什么时机进行?
简化工作有着怎样的底层原理?
具体如何开展简化工作?
文末附赠简化工作需要用到的工具
1. 简化工作的时机
若要简化设计方案,首先需要有一个大致的方案。具体而言,在“功能架构图”的阶段进行简化设计工作是比较合适的。因为在这个阶段,设计师已经对未来的交互稿在范围上有了比较清晰的了解。知道要做哪些功能,PRD中缺了哪些功能,大概有哪些交互流程。另一方面,这个阶段还没有开始绘制交互稿,所以变动成本相对较低,简化起来可以大刀阔斧。
简化工作对“功能架构图”的要求比较高,设计师需要将架构图写得很详细。如果架构图比较粗糙,简化后可能会遗留各种潜在隐患,导致后期变动交互稿,从而让前面的简化工作失去意义(画详细的架构图并不会浪费时间,因为架构图里的很多细节,就算前期不考虑后期也是要花时间考虑的)。功能架构图可以按照下面的结构来撰写:
这部分比较基础,就不具体介绍了。其中值得注意的一点是,架构图中不仅应当包含功能,还应当包含交互层面的描述。若有疑惑,可以参考下面的例子-Web端视频评论功能架构图:
2. 简化的基本原理
功能架构图中的条目,哪些应该简化,哪些不可以简化呢?这个章节会详细介绍一下具体的原理方法,做一个了解,实际“简化工作”中用不到。
2.1. 优先级公式
从交互层面而言,是否要开发一个功能/交互的决定因素,无非是“用户体验影响力”和“开发成本”。我们更希望做那些开发成本低,用户体验提升多的设计。不喜欢做那些开发成本高,但却对用户体验影响不大的设计。所以可以得到下面的公式:
优先级 = 体验影响力 / 成本
上述公式中的“体验影响力”,可以看作是某个功能给用户所有使用场景产生的体验影响力总和,而功能对每个场景的体验影响力则是“完美方案的体验值”与“妥协方案的体验值”的差值,所以得到以下公式(场景使用率可以简单理解为用户的使用率,后文细讲):
体验影响力 = (完美方案体验值 - 妥协方案体验值)*场景使用率
于是,对于某个功能/交互而言,它的优先级公式是:
优先级 = (完美方案体验值 - 妥协方案体验值)* 场景使用率 / 成本
接下来我们来聊一下上述公式中的每一个变量:体验值、场景使用率、成本。
2.2. 场景的宽度与深度
在讨论公式的3个变量前,我们首先要了解一下场景的宽度与深度。
场景宽度比较容易理解,比如上文中的评论功能,用户评论时可能想要使用文字评论、图片评论、动图评论、语音评论等等,如果每一个场景都能满足就是场景很宽。而场景深度则指一个具体场景的细腻程度,比如同样是文字评论功能,用户输入文字时候,如果输入文字比较多,文本框就会响应式变高,方便输入大量文字。这种设计就可以看作是场景深度上的拓展。
在一般意义上,场景越宽意味着覆盖的场景越全面(满足更多用户需求),场景越深意味着某一场景的体验越好。这两者组成的面积就是产品体量,也就意味着成本(如上图)。但如果需要削减成本,我们就不得不减小场景的“宽度”和“深度”。
2.3. 体验值
首先我们简单介绍一下体验值。上图描述的是“体验”和“场景深度”的关系,体验值的原点是“正常体验”,向上是体验极好,向下是体验极差。一般而言,如果在场景深度上太浅,场景内的很多细节没有考虑,则体验值会低于“正常体验”,如果场景深度很深,设计细腻,则体验值则会高于“正常体验”。对于具体的项目而言,还会有产品方的“目标体验值”和“底线体验值”。目标体验值是产品方希望这个产品/功能给用户带来的体验效果,底线体验值是能够接受的最低体验效果。
那么我们如何去衡量体验值呢?为了衡量的简单方便,笔者不建议将体验值再进行维度细分,其实只要通过主观评分量表进行评估即可(非单人评估,所以客观性有一定保障),如下图:
体验值的主观评分量表,0代表正常体验,50%代表体验极好,-50%代表体验极差。由于“是否低于目标体验值”、“是否低于底线体验值”对于衡量设计方案较为重要,所以在量表中需要用颜色标出来。上图是一个“评论内容懒加载功能”的“优先级评估表”,当前项目的“目标体验值”是5%,“底线体验值”是-10%。可以看到“完美方案”达到了“目标体验值的”,而妥协方案没有达到“目标体验值”,所以标注了黄色(如果不能达到“底线体验值”就标注红色)。
2.4. 场景使用率
严格意义上讲,场景使用率应当指:一个功能/交互被使用的场景在所有用户使用场景中所占的比例。比如,500个用户1天内产生了1000次访问,在这1000次访问中每个用户有10个访问场景,也就是共计10000个访问场景,其中使用“评论点赞功能”的场景有1000个,那么这个功能的场景使用率就是10%。但为了方便,我们可以把场景使用率简单理解为用户使用率,也就是500个用户中,有几个用户会使用这个“评论点赞功能”,比如是50个,那么这个功能的使用率就等于10%。
这里我们插叙一下“场景使用率”和“场景宽度”的关系。上文中我们讲到,场景越宽越好,因为可以满足更多用户的场景。但如果要节约成本就必须压缩场景宽度,那么压缩场景宽度有着怎样的原则呢?产品中的所有场景一般遵循类似于“幂函数”的分布方式(如下图),使用率高的场景较少且集中。如果要压缩场景宽度,应当优先删除那些“场景使用率较小”的场景,这样不仅减少了工作量,且对大部分用户产生的负面影响都比较小。
说回场景使用率,场景使用率的评估方法同样推荐使用主观评估法,评估的数值填写在“优先级评估表”中(如下图,同上文的表)。需要说明的是,如果评估人对产品的日常数据不了解,可能会降低评估的准确性。
2.5. 成本
成本主要指开发成本,可能包含:前端/客户端开发成本、服务端开发成本、应用服务端开发成本、算法开发成本、QA测试成本。为了评估的便捷性,我们可以邀请项目中的技术负责人笼统地评估“整个开发成本”,以“天”作为单位,评估的结果同样填写在“优先级评估表”中,如下图:
2.6. 计算优先级系数
在得到几个变量的值后,便可以代入上文中的公式,得到优先级系数了(文末附件的表格中已经做好公式,公式中对“成本”一项开了1/2次方降权,如果项目很急成本控制很重要可以不开),如下图所示。为了优先级系数查看起来比较直观,可以在公式中加一个常量系数,笔者用的是1000。可以看到这个“评论内容懒加载”功能的优先级系数是32 。
转载请保留出处及原文地址:https://www.shishangjue.com/article/540.html