听说你的设计稿 Lock 了？

2017-05-15 13:04:00

对于设计师来说，最开心的时刻无非是设计稿受到了肯定，可以定稿了，即被Lock下来了。那颗悬浮着的心也可以稍微松一口气了。那这个定稿的过程具体是怎样的呢？

设计稿的定稿流程

设计稿的定稿可以分为一下几个步骤，首先是自己把关，觉得没什么问题了然后拿去跟同部门同事（一般是跟这个项目相关的设计师）进行交流，如果重要的话，设计主管也会过来参加一些意见，再接着去跟PM进行商议，如果可以的话可能也会Boss进行商议。

定稿需要lock哪些内容？

拿最近阁主设计的徽章系统来举例吧。大家线缆看看草稿和lock版本的区别，如下图。（因商业机密，UI被楼主改过，请大家专注于UX逻辑方面的内容）

Badge_active_unlocked.png

Badge_active_locked.png

只是一个简单的徽章系统，在定稿前和定稿后的区别虽然不大，但每项都是经过深思熟虑的。
设计稿需要check的几个方面的内容如下：

1.页面跳转流程逻辑是否比较恰当

在考虑这个方面的时候，出发点是跳转的逻辑体现出页面与页面之间的层次与逻辑关系。比方说在“Badge view by myself”的这个页面，之前左上角是个back键，而在这里换成了叉（如下图），并且还有一个一起改变的是将徽章增加了一个由小变大的动效的过程，所以“Badge List”页面与“Badge view by myself”的页面可以说偏向于后者变成前者的一部分这样的关系，而back键更像是一个新的页面。

Badge_active_unlocked.png

Badge_active_locked.png

这样的改进点也是为了让用户在使用的过程中体会到画面更流畅的感觉。

2.逻辑是否影响到APP其它地方的考虑

比方说徽章系统，是一种成就的提现，对用户的一种激励，那么如果有好友的关注关系，用户在得到徽章的时候是否考虑到通过Notification（通知）系统去给好友发一条信息？如果社交性质比较偏重的话，是否Feed（信息动态）里面是否也可以支持用户直接进行分享？还比方说APP其他地方可能出现用popup（弹窗）的方式进行徽章的呈现

而在这个1.0版本里面的徽章系统比较初级，所以功能的定位也比较简单，所以最终并没有考虑这些。

3.每个页面的元素是否需要精简

对于页面元素的考虑每一处都要做到有理有据，精简团队的工作量。

比方说上图中，在“Badge List”页面，草稿是有分享按钮的，而在定稿将这个分享按钮去掉了。反问的原因是，用户在什么样的场景下会想分享“Badge List”。大家比较同意的就是，在徽章得到比较多的情况下，用户处于想炫耀自己徽章的数目想去分享。

这种情况下，一般人会截屏自己的手机发个朋友圈或者传给某个朋友。而如果做了这个分享按钮，那分享出去的是一个H5的页面吗？如果是的话，是不是为整个项目组增加了一个工作量，多做一个H5的页面出来。用户如果点击朋友的徽章页面也可以看到他的list，这个功能值得大家付出这样额外的劳动吗？经过大家商讨，觉得用户分享list的行为比较少，去掉这个分享按钮是最简单的做法。

其它细节阁主就不一一说明了，大家可以自己进行阅览与分析。

4.信息的展示顺序是否得到统一

展示顺序包括元素的展示顺序以及文字信息的陈列顺序。给用户更统一的体验，减少用户动脑适应的时间。

比方说定稿图中，所有有徽章的地方，都是按照徽章图、徽章名字、补充信息、时间这样的顺序进行排列。而在草稿中则比较混乱。

5.各种排列顺序或者规则是否得当

规则的制定更倾向于PM的工作，对于设计师来说了解一点也不错，技多不压身。这些规则包括图中各种徽章的排序规则，以及什么样的情况下用哪一种徽章的交互呈现方式比较合适（包括popup以及手机系统通知的方式等）。像这样的事情需要PM进行具体定义，但设计师需要提醒PM，以及推动事情往前走。

6.信息输出资源的管理

信息输出资源包括所有的icon和图片。而案例中最特殊就是徽章会分为两种状态（点亮与未点亮）、两种模式（简单与细节）、四种尺寸呈现出来，那么咱们提供给工程师的文件夹就应该在命名上都进行区分完善，比方说可以进行badgename_got_simple_150x150这样的命名等等。

以上是在设计稿被lock时需要考虑的几大方面，可能信息比较多，总结出设计师的思考原则就是，从用户的角度来看，交互和视觉呈现上是否可以有再进一步的改进空间，是否可以再为团队节省一些时间与资源。这样看来就比较好理解了。

设计是个细致的活，需要大伙一丢丢的耐心，不仅是对作品，也是对自己的一种磨练，人进步了，会发现做其他事情也没那么难了。

作者 Sophia的玲珑阁

关键字：设计, 设计师, 徽章