作为一个设计师,你输出的设计方案,是否也应该具有"安全感"呢? 不仅在职场中要不断刷"存在感",以寻求获得老板的"信任感",从而获得内心的"安全感",在任何一个团体中,"信任感"和"安全感"都是一种适合团队发展的氛围。因为他避免了团队成员因为追求片刻的"安全感"而将主要精力和注意力放在盲目刷"存在感"、划分地盘或者寻求"依附感"的行为上,降低工作效率。 言归正传,本片文章并不是什么职场软文,而是想到,作为一个设计师,你输出的设计方案,是否也应该具有"安全感"呢? 答案的肯定的。方案的"安全感"所赋予的目标对象,主要产品和开发人员。 一、通用的"安全感" 1. 方案易读性强 方案的易读性,主要是指页面整体信息的清晰度要高,除了基本的版本号、标题、设计者等头部信息外,还要注意整体方案的排版布局。 以移动端举例,如果不是线上预览方案的话,一般输出的文档内容是图片格式或者pdf格式,这是需要考虑到图片输出质量的问题。一些软件输出的图片质量品质不同,很影响阅读体验。所以有一个小技巧可以使用,那就是横向上页面不要过长。 人们在电脑上的阅读习惯是从左向右,翻页是从上至下,所以为了提升阅读的便捷性,在全屏播放时,横向空间上不超过一屏空间,可以在纵向上延伸,这样用户在浏览时仅需点击或者滑动鼠标即可,会极大提升阅读的便捷性。 2. 标注准确 每个设计师都有自己的标注习惯,但是无论使用引线标注,还是底部注释等,精确性都是必须的;同时引线标注时,尽量避免引线之间出现交叉点。 3. 及时定义规则 在输出方案的时候,很多细节是可以复用的,以及一些全局性质的交互操作,可以及时定义相关的统一交互规范。一来可以减少每次都要标注的重复操作,二来可以提升整体效率,及时查漏补缺。 交互规范可能不需要定义完整的从框架层、结构层到视觉层的所有规范,但是基本的控件规范制定的必要性还是很强的,包括弹窗样式、加载样式、手势操作区域、文案使用等。 二、产品角度的"安全感" 有"安全感"的设计方案给到PM时,不仅能够快速评审通过,同时还可以完善产品策略,推动项目落地。 1. 方案多样性 给出不同版本方案,提供多种选择思路,体现对需求的理解深度与专业性。因为产品可能只是给了一个参考或者框架,但是并不一定是适合自己产品本身的,这时候需要根据需求和预期结果来优化方案,这样也是对需求深度理解的一个展现。 2. 流程细节完整 PRD更多涉及到页面间的逻辑关系,页面信息架构等问题,但是对于一些细节或者是边界状态,在方案形成初期,是很难预料到的。所以设计师在输出方案时,要不断去触碰方案的"边界"条件,找到极端情况、边界状态以及对应的反馈。 所以很多时候,PRD描述只是几行文字,但是交互稿却要给出几十个页面,就是这个道理。限于公司规范、项目紧急程度以及产品靠谱程度的影响,设计师无法奢求PRD里面面俱到。所以,大部分情况下的边界条件这些交互细节,需要设计师自己去主动补充完善,让整个产品流程形成闭环。 3. 方案的后续扩展性 互联网产品开发本身就是一个快速迭代过过程,所以对于某个功能模块,很少会所有功能部分都完整后才上线,都是本着敏捷开发的原则,快速上线,快速迭代。 这种情况下,同一功能模块每一版本的方案都是有联系的,往往是递进的状态。对于一些喜欢加功能的产品而言,会不断的向页面中增加功能入口。对于这种常规情况,设计师在设计方案时,需要考虑到方案后续的延展性,不能局限在一个版本内。 尽管用户体验是优先的,但体验不是一个短期或者几天就能获得收益的过程。设计过程不是直线,而是弯曲上升的折线,需要根据实际情况平衡方案与体验。 例如:产品版本每周都上线一次,一周的时间,开发的工作量是一定的,能够支持上线的功能必然有限,所以PM给出的功能方案很多时候是分拆来让设计师支持的。 然后就会出现两种情况: Case1:设计师接到本期需求后,开始绞尽脑汁给出当前最优的、体验最好的方案——(努力说服)产品通过——开发上线。然后下一期接到新的迭代需求后,继续绞尽脑汁给出新的方案,不过这次给的真的是"新"的方案,很可能推翻或者重构了前一版的方案。 Case2:设计师接到本期需求后,优先向PM了解功能的迭代计划——给出扩展性强(当前来看可能不是体验最好)的方案——产品通过——开发上线。然后下一期接到新的迭代需求后,只是根据需求微调或者简单增加功能入口即可,同时达到最优的体验。 两种情况显而易见,可扩展性的设计方案需要时刻保持对需求的敏感性,因为可能PM不会及时与设计师沟通后续计划,所以当面对并不完善或者简陋的PRD时,设计师需要主动与PM沟通了解产品迭代计划,增加方案的扩展性。 三、开发角度的"安全感" 1. 复用相关样式 页面逻辑清晰的方案,除了必要的信息需要特殊标注,对于一些不影响体验和满足需求的前提下,复用已有样式是开发同学最喜欢的,这意味着工作量的降低。予人玫瑰,手有余香,设计师在输出方案时,对于以下相似的模块或者功能,复用已有模块,可以不必要再"炫技"似的给出一副华而不实的方案。 2. 逻辑清晰,标注准确 很多时候,开发可能会不看PRD内容,而是照着交互文档开发,所以这个时候,除了清晰的逻辑以外,文档上的标注要清晰、完整,避免一些"手快"的开发快速实现后,验收时发现冒出来很多细节的bug。 3. 方案要分端 目前很多产品的Android端实现风格偏向于iOS,比如:浮层样式等。但是一些成熟的产品,在不同端上的设计风格,还是会遵循平台本身的规范的。 所以设计师在给出方案时,需要有所分端处理: 控件的样式:弹窗、提示灯样式平台有各自的规范,在不影响需求的前提下,尽量使用平台现成的样式; 系统实现效果要有所了解,例如:iOS系统支持点击状态栏返回顶部操作,但是Android本身是不支持的,如果页面增加当前操作,iOS端不需要开发,但是Android需要提新的需求排期。 四、结语 输出一份具有"安全感"的方案,也是设计师必备的素质,为自己的方案负责,也为整个项目流程负责。