作为一个设计师，你输出的设计方案，是否也应该具有“安全感”呢？
不仅在职场中要不断刷“存在感”，以寻求获得老板的“信任感”，从而获得内心的“安全感”，在任何一个团体中，“信任感”和“安全感”都是一种适合团队发展的氛围。因为他避免了团队成员因为追求片刻的“安全感”而将主要精力和注意力放在盲目刷“存在感”、划分地盘或者寻求“依附感”的行为上，降低工作效率。
言归正传，本片文章并不是什么职场软文，而是想到，作为一个设计师，你输出的设计方案，是否也应该具有“安全感”呢？
答案的肯定的。方案的“安全感”所赋予的目标对象，主要产品和开发人员。
一、通用的“安全感”
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需要提新的需求排期。
四、结语
