交互设计自查,是设计师完成交互稿后,自己发现问题查漏补缺的必要环节。交互稿考虑的细节是否完善,对特殊状态的描述是否有遗漏,对网络环境、交互控件等说明是否详细说明?

对于移动端应用来说,使用场景非常复杂多变,设备也很多样化。及时自己发现手误、考虑细节不完善之处、异常状态的遗漏,不但避免了Review时的尴尬场面,也有利于设计师自己形成更为缜密的思考方式,从而让自己的设计质量得到快速的提高。

经过这几年的工作总结,小编建立了一份交互设计自查表,这份表格梳理了用户在完成具体任务过程中的各种情况。但关于自查的角度有的偏重全面的异常流程处理,有的偏重UI细节的斟酌,有的则更关注平台、设备方面可能出现的问题,因为交互设计本身就是一个交叉性很强的位置,上有产品级别的模块设置,下有UI级别的元素样式位置,内有组件的交互规范,外有多平台多机型的适配,每个人在不同团队中所接触的项目特点不同,对自查中最常出现问题的类型也可能不同,所以交互设计自查表也不是适合所有的人,大家可以根据自身情况再作补充。

为了更好地把人、机、设备、使用情景等因素对设计带来的影响都考虑进来,我将这些影响因素按所在的模块进行分类,大致可以分为以下几类:

一、设计分析

在做交互设计之前,一定要充分理解需求的背景、目标、想要达到的目的,可以用5W方法去挖掘出真正的需求,才方便后续的交互原型设计,操作路径分析、信息布局等设计。

二、文档相关

如何建立交互设计自查表-UI头条

一份好的交互设计文档除了里面的内容之外,还需要注意文档命名,书写格式,文档的整体风格,以及线框图的绘制细节规范等等,都需要有一定的制作规范,因为一个公司里面不会只有一名交互设计师,而且交互设计师之间也是有交集存在的,为了阅读畅通,查找方便等,在做交互文档之前一定要把相关规范沟通清楚并输出制作规范供其他人员参考。

三、易理解性

如何建立交互设计自查表-UI头条

这一部分内容比较基础,我就不多加说明了,在打磨的过程中多思考、多尝试、多推敲、多做用户测试,有时候对业务太过熟悉会让我们意识不到文案理解上的问题,而身边不那么了解业务的同事会更容易发现,所以,一定要用开放的心态听取大家的反馈。

四、易操作性

如何建立交互设计自查表-UI头条

同样是一些比较基础的知识,在这里就不做赘述啦,详细可以去阅读尼尔森的十大可用性原则哦~

四、技术可行性

交互设计师不一定非要懂技术,但一次次技术评审下来,对于「什么能做、什么不能做」,心里要有底,并进行总结,必要时也可以体现在自己的设计文档上(让大家理解你这样设计方案的苦衷缘由)。设计过程中也要及时找技术同学沟通确认可行性、听取他们的建议和反馈,而不是次次都是等方案设计完成、正式评审了才发现技术上实现成本过高,而被迫放弃。

五、软硬件特性

如何建立交互设计自查表-UI头条

手机硬件以及平台的多种多样,给设计带来机遇的同时也带来了挑战。除了以上所列举的一些,我们要考虑的点还有很多,比如屏幕越来越大,当在摇晃的车厢内,大屏幕遇上单手操作,需要考虑如何通过设计使用户用起来更自然、顺畅。

六、网络特性

如何建立交互设计自查表-UI头条

移动应用使用场景中,遇到数据加载慢或者无网络的情况会很多,通常用户特别不愿意漫长的等待,会令用户抓狂。要处理好界面交互中的加载,确保用户在等待时不会枯燥,并且对加载后的内容有明确的预期,就能提供给用户较好的体验。因此在所有涉及到网络交互的模块中,要考虑清楚所有会遇到的情况,也可以合理地利用缓存,来提升界面的响应速度。

七、流程路径控件表现

如何建立交互设计自查表-UI头条

1、控件相关

控件的选用和设计是否合理、是否符合用户成型的认知习惯。比如形状、文字、用色、尺寸、位置、分组等方面。举极端点的小例子,“拒绝”按钮设计成绿色而“确认”按钮设计成红色、复选项用圆形而单选项用方形、过于口语化的控件文字、位置过于隐蔽、分组不符合用户习惯等等,都是不恰当的。在交互习惯已经逐渐统一的今天,不需要在界面上标新立异,挑战用户的使用和认知习惯。

控件交互行为是否具有一致性

相同控件的操作,反馈也要相同,简单地说,长得一样的控件操作起来也是一样的。交互行为的一致性和样式的一致性是相形而生的。对外要符合整个平台的产品设计规范,对内要与同一产品内”兄弟姐妹“们的行为一致,这样才能更好地降低交互模式的学习成本。

控件的不可用状态如何呈现

控件常常需要一定的条件触发才变得可用,例如表单页中只有在必要信息全部填写得符合要求的情况下,”提交“按钮才可用。那么,在不可用时,是直接将控件显示为不可用,还是在点击后提示用户需要完成哪些条件才可用?两者各有优缺点,前者让行动点的不可用状态外化,让用户直观地理解自己的状态,但假如用户不熟悉当前场景,会难以知道是缺了哪些条件导致不可用;后者在点击后可以通过toast清晰地告知用户需要哪些条件才能触发可用,但这需要增多一步点击操作。因此,两者都是可行的做法,但无论采用哪种做法,都需要在交互说明中写明,前者需要写明可用条件,后者需要写明toast的提示文案。

2、流程设计与反馈

在具有相似度的任务中,用户体验路径的设计是否清晰,并具有一致性?具有相似度的任务是指虽然在具体步骤和任务目标上有所差别,但流程上有较大部分是类似或共通的流程。

正常来讲,任何流程都应当允许用户返回上一步,以及退出当前流程,而返回和取消操作的跳转目的应当符合用户期望,让用户返回其认为最合理的位置。

关于流程设计与反馈提示方面会涉及到很多情况,比如逆向流程设计是否考虑周全?每个跳转入口的控件名称与目的页面名称是否一致?在删除、返回和取消等危险操作执行时,是否为用户提供了二次确认的机会?执行一个操作后是否允许用户撤销?在操作失败后是否提供了必要的解释或其他可行的建议?在用户每一步的操作后是否给到合理合适的反馈,让用户了解当前的状况?

八、内容呈现

如何建立交互设计自查表-UI头条

内容呈现包含数据上的呈现,比如空数据、空状态、排序、日期、不同用户的权限、数据过期等等情况,在交互文档中是否有详细说明?出现这些情况要怎么处理?

还有文案呈现,语句是否通顺、描述是否让用户感到温暖?

关于情感化设计网上已经有很多分享,比如转场动效、特殊状态等都是我们融入情感化细节的好地方,除了对一些过渡与边界场景的关注,我们也可以带着全流程的意识去审视现在的界面设计,比如在用户操作之后,如何更贴心的给予反馈,或者让用户感到惊喜?

九、用户属性

如何建立交互设计自查表-UI头条

在大多数应用中,每个用户都有自己账号,用户登录与未登录,所享受的权限也不尽相同。所以要考虑到用户的所有可能有的状态,以及状态间的切换对于设计时的影响。

十、特殊情境

如何建立交互设计自查表-UI头条

特殊状态是指为了满足用户某些特定的需求而存在的一种模式,这些模式往往由于平时曝光率不是特别大,因此在设计过程中有时会被遗忘。但一旦没考虑到的话,非常影响用户的体验。因此将特殊的使用场景梳理一下很有必要。

十一、自查表如何使用?

反复进行“设计自查”,交互设计师如此反复几次,可以规避并解决绝大多数的问题,避免返工,给其它角色造成困扰。

自查表也不是固定不变的,可以根据不同的产品去做迭代更新,最终都是为了使用,提高工作效率。

最后:

移动场景很复杂,除了软硬件特性、网络特性、流程路径控件表现、内容、用户个人属性、特殊情景以外,影响因素还很多。正确分析并记录各种影响因素,处理好并运用到设计中,都能使产品的体验获得更好的提升,并且在此提升过程中,我们可以将他们形成规范。

每个迭代版本做新功能时,我们可以把新增的影响因素添加进去,留待后续的交互设计自查。这样积累下来,我们提前考虑到的异常点就会越来越多,从而考虑得会越来越完善,效率越来越高。