企业软件开发中低保真原型和UI设计规格有什么不同-原型软件规格设计开发

我同意打日本 02-20 07:31:53 129

实际很多设计工程师在给研发人员时,只有真原型,所以很多人还不知道产品的UI设计规格有什么作用。我们下来仔细分析一下:
低保真原型是模拟产品特定功能和界面计作品,并非实际的最终产品。低保真原型往往主要是线框图或草图等实现的,在企业软件中往往体现的是一个或多个场景任务下的界面设计内容。当然很多也有采用ppt或其他工具实现的。有的工具看起来视觉效果很好,似乎和真实界面一样,但不能交互。开发人员由于觉得也足够了,一般也会认为低保真原型就够了,不用再交付更多的文件说明了。
UI设计规格实际上是为了更好的交付给软件开发实现人员而给出的产品设计规范类文档,主要明确了产品在实现人机交互时应当必须满足的设计点,文档内容可以分成这几部分:
概要。主要说明本规格主要包含哪些内容,以及低保真原型和本UI规格的关系。如后面的关系说明就可以明确并清晰地写“xx低保真原型所体现的界面设计和明显的交互关系不在此规格内重复说明”。
系统交互框架:主要说明软件界面的框架组成和界面内典型的各个模块说明、关系的说明。同时,建议说明设计此框架所适用的用户和业务场景任务及页面之间的关系,使开发人员对设计的背景、人机交互的框架有一个基本的了解,而且可以找到自己业务相关的关键场景任务信息。
设计要素:主要说明对屏幕分辨率、文本的字体及大小、排版的样式和颜色、标点符号和编码等视觉所能看到的设计要素、后面实现需要满足的视觉对象规格的一个清晰的说明。
交互设计:一般至少需要说明键盘交互和鼠标交互的设计要求,因为计算机的输入基本是这两类。但也有新的交互技术应用如语音、动作输入等,这些如果在业务使用中体验非常关键,也需要给予明确说明。同时,在界面操作中,浏览类的视图控件如菜单、Tab、树类视图、表格和隐藏区等,编辑类控件如按钮、文本框、下拉列表、列表框、单选框、复选框和弹出窗口等,这类控件的操作有时在低保真原型很难表达清晰,可以在UI规格中给予清晰的说明。例如按钮,至少可以有三种状态:无效、有效和被点击状态,如果体验要求高,状态可能更多,如鼠标悬浮在按钮上也特殊设计成不同的颜色或质感状态,使用户明确可以点击按钮。在Web界面上,链接就是一类很特殊的按钮,其状态可以多达5种以上。在线帮助的交互要求也可以写,不过这部分往往由于和信息架构、资料开发相关,往往会单独放在资料的设计要求中。
最后还建议附上在产品设计中所依赖的设计原则,使开发人员了解到相关的设计哲学思想,同时培养开发人员尽量掌握更高的体验设计技能,在基本设计原则上要求开发人员也应当能够遵守。
那好,如果没有设计规格,只有原型是否可以呢?实际现在是很多产品都不重视UI设计规格,包括交互设计人员也觉得写这个文档要化很多时间,平常很多问题都已经沟通了,没有动力写。结果呢,好一点的产品,开发人员感觉好一点,代码复用多一些,有时能够将风格不一致的现象减少很多。但由于缺乏规范规格的约束,开发人员很多由于开发时间和效率的问题不会有这么多的考虑和交流,最后实现的产品界面存在很多小问题。只不过企业用户,忍受能力比较强,毕竟是为了工作,不会在意那些小问题,任务一定要完成啊。
但实际从工作效率来看,成功完成项目,有过高质量交付的工程师,可以理解这个文档可以起到很多提升效率的作用。比如同样的设计问题,如果一个人问了,或UE问了跟踪了就解决了,用文档的意义就没有了。但在企业中,产品往往开发人员很多,有上百甚至上千个页面需要开发完成,这时很多问题重复率很高,这些问题在文档中写清楚使开发人员准确理解比每次重复答复要有效、高效得多。而且文档写出来,往往其语义和语法要比口语严格得多,可以防止口头传递的信息质量衰减。俗话说"好脑瓜不如烂笔头",很多时候人们口头交流会很高效,但会忽略很多因素,例如默认的设计风格和图标,但每个开发人员往往由于自身经验理解又不一样。所以即使对于很多聪明的人来说,形成一些好的想法、通过口述把这样的好想法表达出来都不难。但是,对于一个比较复杂的软件,几十人合作开发的人,即使通过口头传递也很难去检查想法中存在的各种各样的漏洞和需要解决的问题。
但是如果把规格写下来就不同了。大家可以一遍又一遍地审视文档,一遍又一遍地补充和完善表达中存在的不完善和不严谨的地方。文档可以在任何时候拿来慢慢思考、理解和优化,无论对自己还是开发人员,大型团队的沟通绝对需要这些关键的文档,否则会出很多问题。
另外文档写出来,可以以后有新的UE或其他工程师在新产品开发版本或老版本上优化时,进行更好的优化,比重新理解系统,重新整理规格的难度要小得多。而且企业如果不重视框架文档的说明,很可能到了后面来一个新人就会上一个新框架,因为人们总是喜欢做自己擅长的、能够理解的事情。而且企业往往存在人员流动和流失的问题,夸张的企业可能过几年虽说研发部门还存在,但可能的感觉是物是人非吧。对于这样的生存环境,企业产品研发中没有相应地设计文档传递,企业的设计风格会非常混乱。企业形象也会受损。
同时,在复杂产品中,往往企业本身产品开发出基线版本后,还需要根据现场环境进行定制开发。这时,如果没有UI规格文档指导,很可能设计的其他页面和原有页面差异很大,而且用户会觉得很不习惯。为了保证好的定制产品开发体验,企业还可以将UI规格相应改动为体验设计指导书,指导本地或合作外包或其他研发企业尽可能使用自己的提供的组件和一致的风格,保证企业品牌形象的传递和延伸。在这点上,我非常佩服苹果公司的体验指南和实践,具体和原则都写得很到位,而且在app审核中如果没有按照规范要求使用相应的图标就不会给予通过。
当然,在实际企业软件开发中,很多软件不一定是需要考虑这么多,更多要考虑效率,先开发出来满足客户需求,争取机会让内外部客户认可先活下来,这样没有必要一定要按照上面的要求输出很僵化的文档,可以在相应原型或视觉效果图中标注清晰也是一个好方法。只要将必要的UI设计要素给需要的研发人员说明清楚了,后面若需要组织起来还是很容易的一件事。
软件积累很深的企业还可以通过高保真原型和组件化降低产品UI设计规格的复杂度,因为直接将高保真原型和组件列在文档的相应说明中,开发人员会直接下载或拷贝相关代码,这样编程中很多需要组件内部实现的交互就不用重新编程了,开发人员也可以通过继承样例代码快速实现高质量的界面交互。不过,这个需要产品或企业先做好平台积累或高保真原型和组件,开发或体验管理者需要有远见和良好的合作共享精神。
所以这个道理一定要和产品说清楚,使产品业务开发人员真正理解和配合UI设计规格的写作,做好产品的设计实现。否则,有些开发人员只看到了低保真原型,但还是不清楚交互设计人员或可用性工程师的作用,就会说交互设计不就是个画破图的吗?然后我们不解释不好,解释呢,有点被动,例如:交互设计师不仅仅是个画破图的(交互设计的输出不仅仅是线框图和单页面设计图),他的交付还可以包括视觉要素设计、特殊交互说明、高保真原型、用户情景(user scenario)、准则(style guide)等等。这样解释感觉真是有点损己利人。