界面名字

每个界面需定出一个前缀。比如主页，前缀是 home，设置前缀为 settings，课程表是 lesson。

定好前缀之后。设计师就可以建立文件夹：

主页(home)
设置(settings)
课程表(lesson)
课程概述(overview)
共用(shared)

之后将素材放到对应的文件夹下，这样就容易找了。假如很多界面都用到的素材，比如一些按钮之类，就放到shared目录下。

设计师的英文似乎不是很好，他们的喜欢用中文命名，但是程序需要使用英文。假如一开始不约定好，程序员需要使用素材的时候，就很难跟设计师取的名字对应起来，往往会不知道素材放到什么地方。

素材名字

最终的素材名字，只使用小写字母和数字，单词的分隔用中划线 - 分隔起来，不同界面的素材前面加上对应界面的前缀。比如

home-background.png
settings-icon-email.png
settings-icon-help.png
shared-button-0.png

名字使用对应的界面前缀，是为了知道素材原始出处。这样有问题了，可以找到原始文件重新导出。也避免了名字冲突。

只使用字母和数字，中划线，是为避免出现中文、空格、标点、斜杠等特殊字符。在不同的系统上，字符编码会有所不同，而一些特殊字符会有特别的含义。中文或者特殊字符容易出些古怪问题。比如程序员写个脚本去统一拷贝、处理素材，中文或特殊字符就特别容易出问题。

只使用小写字母，是为避免写错大小写。比如 Mac 系统，默认情况下对于大小写是不区别的，假如图片

home-background.png

错写成

home-Background.png

在模拟器中显示是没有问题的。而真机中名字是区分大小写的，这样模拟器跟真机的行为就不对应了。全部使用小写字母就直接杜绝了这问题。

使用中划线 - 而不使用下划线 _ 分隔。是为了将来更好地搜索查找。工程中的程序变量的名字，不会出现中划线，只会使用下划线。当素材名字使用中划线，就可以跟程序变量名字区别开来，以后在工程中就容易搜索。

这些名字规范，看起来简单，但可以杜绝很多问题。项目中，素材名字应该是设计师导出的时候就取好了，这样一旦需要修改，直接复制过来就行了。但现实中，我发觉设计师往往不会注意这些，经常需要程序员重新命名。这样修改起来就多了一个步骤。

尺寸单位

设计师往往使用像素作为设计单位，但是对于 iOS 来说。使用像素来思考是不好的，应该使用点(point)来思考。点和像素的区别，参考我的旧文。

比如

• iPhone 6，尺寸为 375 x 667 个点，2x 模式。
• iPhone 6 Plus，尺寸为 414 × 736，3x 模式。
• iPad，尺寸为 1024 × 768，有 1x 和 2x 模式。

使用点为单位，容易跟程序对应起来。并且每个 iOS 设备，相同的点数，物理上的长度是差不多的。44个点，就是手机上导航栏，工具栏的高度，这样的思考方式可以大致估计到真实的物理长度。而用像素，容易使得做出的图片过大或者过小。

当使用非矢量图片时，将点数乘以对应的 x 模式，就等于需要做的像素大小。

当矢量工具来做素材的时候，应该直接做点那个尺寸。比如44 x 66 个点的按钮。就建立一个44 x 66的场景。之后再导出成 2 倍图，3 倍图，或者直接导出成 svg 的矢量图片。

最终标注设计稿的时候，也使用点作为单位来标注。其实标注的时候，只要导出一个 1x 的预览图，就可以用工具来标注了。当 1x 的时候，点和像素就是直接对应的。

设计尺寸

手机 App 只需要一个设计稿，不需要设计多个。假如平板上的布局跟手机是不一样的，需要再出一个设计稿。假如是基本一样的，连平板的设计稿也不需要。比如微信的的 iPhone 版和 iPad 版，流程布局是一致的，其实只需要出一个 iPhone 的设计稿。

设计的时候，选取一个现在最主流，你最容易获取的设备的尺寸来设计。比如现在 iPhone 最主流是 6 的尺寸，就选择

375 x 667 点，2x 模式

作为设计尺寸。之后整个设计稿就使用这个尺寸来设计，不要一时一个样。假如你是个人开发者，身边只有 5s，就使用 5s 的尺寸来设计。

这样就可以将设计稿截图，放到手机中看效果。适配不能直接按比例放大或者缩小，假如你将 iPhone 6s 的设计稿，放到 5s 中看，图片按比例缩小了，但你看到的并非最终效果。

标注

设计师来标注？

其实我自己觉得让美术标注，是浪费人力的。只要出个 1x 的预览图，再让程序员装个马克鳗、或Pixel Winch、或 PS，就可以让程序员来测量尺寸了。

但很多程序员都会推卸责任，说标注是美术的事情。

还是需要讨论一下如何标注。标注有主要有 3 种，颜色、字体、尺寸。

颜色标注

颜色应该先定义一个色板。比如按照下面方式

1. [颜色色块] #bcbcbc。用于文字。
2. [颜色色块] #ff8c0f。主色调，橙色。
3. [颜色色块] #dddddd。主要用于列表项的分隔线颜色。

其中[颜色色块]，就是一个小色块，用来看颜色的预览。

之后在设计稿的预览图中，就可以使用颜色编号来标注。这样标注比较清晰，一个项目中出现的颜色不会出现太多中，基本不会超过 10 种颜色。这样也容易跟程序对应起来，程序写这些界面，也需要定义一个色盘。这种方式也容易切换主题。比如白天模式和夜间模式。

字体标注

字体也应先定义出一个字体的字体盘，比如：

1. 系统字体，14号。主要用于文字的内容。
2. 系统字体，18号。用于文字的标题。
3. 等宽字体，14号。用于显示时间。

之后在设计稿的预览图中，就可以使用字体编号来标注。一个项目的字体也不会出现太多，大概也就 5、6种。这样也容易跟程序对应起来。

尺寸标注

只需要标注一些不会变化的地方尺寸。比如按钮大小，边距、图标大小等，无论屏幕多大，都是固定不变的。而一些随着会拉伸的地方，就直接注明会拉伸。间距之类就注明，哪几个间距是一样的就行。

有些需要等比例放大或者缩小的，就注明一个比例。

标注就如同程序中的注释，并非越多越好。假如是可以看预览图就明白的，其实是没有必要做标注的。

最后

设计图只是参考，最终以跑到机子上的效果为准。设定规则的时候，需要大家一起参与制定，共同遵守，并解释好为什么需要这样做。

其实我清楚，现实中的项目，是不会这样理想的。往往会相互扯皮，推卸责任。一个项目，需要一个了解设计和程序两方面的强有力的人来协调，并在有纠纷的时候可一锤定音。这个人就是所谓的产品经理。

但现实中的产品经理往往是不了解设计，也不了解程序，并没有决策权，这种所谓的产品经理光有个名字，其实是没有什么用处的。而有了决策权之后，也需要承担义务，当决策错了的时候，最大的责任就在产品经理。而错的次数多了，这个产品经理就不能让人信服，也基本无什么用处了。