设计师,你的方案是否有“安全感”

从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情

作为一个设计师,你输出的设计方案,是否也应该具有“安全感”呢?

不仅在职场中要不断刷“存在感”,以寻求获得老板的“信任感”,从而获得内心的“安全感”,在任何一个团体中,“信任感”和“安全感”都是一种适合团队发展的氛围。因为他避免了团队成员因为追求片刻的“安全感”而将主要精力和注意力放在盲目刷“存在感”、划分地盘或者寻求“依附感”的行为上,降低工作效率。

言归正传,本片文章并不是什么职场软文,而是想到,作为一个设计师,你输出的设计方案,是否也应该具有“安全感”呢?

答案的肯定的。方案的“安全感”所赋予的目标对象,主要产品和开发人员。

一、通用的“安全感”

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,比如:浮层样式等。但是一些成熟的产品,在不同端上的设计风格,还是会遵循平台本身的规范的。

所以设计师在给出方案时,需要有所分端处理:

  1. 控件的样式:弹窗、提示灯样式平台有各自的规范,在不影响需求的前提下,尽量使用平台现成的样式;
  2. 系统实现效果要有所了解,例如:iOS系统支持点击状态栏返回顶部操作,但是Android本身是不支持的,如果页面增加当前操作,iOS端不需要开发,但是Android需要提新的需求排期。

四、结语

输出一份具有“安全感”的方案,也是设计师必备的素质,为自己的方案负责,也为整个项目流程负责。

#专栏作家#

虾米&胖喵,微信公众号:pangmiaodesign,人人都是产品经理专栏作家。高级交互设计师(百度/爱奇艺),夫妻搭档,猫奴。曾做过公益产品、影音媒体产品,目前专注于企业级产品、娱乐社区产品体验设计。“有猫,就有一万种美好!”

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pexels,基于 CC0 协议

给作者打赏,鼓励TA创作!
5人打赏
评论
欢迎留言讨论~!