前言

团队里越来越多的设计师正在寻求职能领域的转型,由原来品牌、运营设计向产品设计方向转变。设计角色本身的转变,带来上下游接触的角色也相应发生了变化。拿做运营设计的同学举例,以前做运营设计的时候主要负责相关专题的设计,上下游接触的是运营同学,而当你变为产品设计师后,负责的往往是一个项目全流程的设计,上下游接触的人变成了产品经理和程序员,此时如果还像以前提供一张张png图片的话,你很难从全局阐述你的产品内容和设计思路,产品经理与程序员浏览你的设计产出物时,理解成本相对也会比较高。作为一名交互设计师自己很清楚一份能完整呈现产品需求和设计思路的设计稿,不仅能便于各方理解,提高各方工作效率,还能提高后期开发对设计的还原度。这篇文章,主要想结合之前自己在对接产品和开发同学时,走过的一些弯路,爬过的一些大大小小坑的经历,罗列了在输出设计文档时的一些注意点。

定义全局的设计符号

在开始设计前,我们可以先定义设计文档中用到的符号,包括交互手势、箭头、判断菱形等。通过定义全局的设计符号不仅能保证后续产品设计的一致性、减少认知负荷,同时能提高设计师的工作效率。

全局的设计符号,是产品设计稿的重要组成部分

尽可能地细化设计,不要遗漏细节

产品主流程的设计,是最基本的,而很多边际条件下出现的界面也同样是一份完整设计稿的重要组成部分,这需要我们完成产品主流程设计后,要开始考虑每一个可能的使用场景,包括极多、极少、报错等特殊情况。当我们设计越来越细化,越来越全的时候,与你协作的开发的疑问也就会越少,总之不要让开发帮你想后续的交互场景是如何。一份细节完善流程完整的设计文档,不仅能便于各方理解,也体现了设计师思维的严密性,这也是考量设计专业性的一个方面。

相同的一个元素或页面也可能含有多种状态,在细化设计的时候要尽可能的考虑

记录一些客观限制

在做产品设计的时候,有时候会碰到技术无法实现或者业务需求的限制,这个时候就需要我们设计上做妥协以适应技术或者业务上的种种限制,这会让我们的设计方案有时候看上去并不是那么合理。所以当我们碰到这种客观限制,而做出折中的设计方案时,我们最好也能将这种客观限制条件整理记录下来,既帮助别人更好地理解我们这么设计的原因,也能在后期限制条件解除时,帮助我们及时跟进优化设计。这个对于迭代周期短的项目,作用可能并不明显。但是如果是那种设计评审已经结束,项目却延期好几个月才开发的项目,没有这些记录的话,开发可能会有疑问同时会来挑战我们的设计,而过了这么长时间,也许我们也忘记了当初这么设计的原因,这个时候就又需要我们耗费时间重新跟产品沟通确认一遍以前讨论决策过一次的方案,这样的话就增加了更多的沟通成本。

最近更新的内容,记得打上标签

如果你参与的项目,涉及的流程比较复杂,界面比较多,每次评审结束后更新修改的内容,如果不做标记,产品与开发可能查阅的时候会比较费力,所以最好是在更新的内容上打上标签,这样不仅节省了协作方的时间,同时保证了没有遗漏。

标签可以让更新内容一目了然

确保每次交付是一份完整的设计

不同于运营活动设计,很多情况下,产品设计师负责参与的项目往往是长期的需要不断迭代更新的,而后续要结合你设计文档开展工作的有产品、开发、测试等各方人员,由于是长期的项目,这期间难免有人员的流动,所以如果后续迭代更新的设计文档只涉及最新更新的部分,那么对于新接触项目的人员,还需要翻阅之前的版本,这增加了合作方的学习成本,所以保证每次交付是完整的设计时更有利于各方协作。

要有历史修改记录

修改记录对于持续迭代更新的产品设计文档是不可或缺的,通过修改记录,产品与开发能快速了解到此次修改的设计内容,而不用自己去全局查找或者找设计师确认哪些地方做了更新修改,提高了协作方的效率。在项目review的时候,设计师可以清楚的了解到哪些是由于需求变动而导致的修改,有哪些是由于设计时没思考清楚而做的修改。有时会碰到项目回滚,历史记录也可以方便追溯之前的版本。

对于长期迭代更新的项目,更新日志是不可或缺的

结语

一份好的设计文档不仅是设计师本人专业思考、表达和品牌的体现,而且能提高项目各方协作效率,能够让各方工作人员有一致的工作目标。这篇文章只是罗列了在输出文档时一些我认为的比较重要的点,每个人的设计习惯工作方法都不尽相同,我们团队也有很多设计输出、版本管理做的很好的同学,大家有时间都可以交流学习。