红绿灯与设计规范

过马路的时候突然注意到红绿灯，恰好最近的新交通规则也热火朝天，就顺势吐槽下关于“设计规范”的思考。

　　提到设计规范，很多人都觉得是个很虚、不务实的绩效工程，很多企业为设计规范而设计规范，拍脑袋定规则，投了精力进去，面子起来了，最后死掉了。以前也很不情愿去制定设计规范，经历多个终端的设计痛苦后，渐渐明白了设计规范“存在即合理”的意义。

红绿灯的启示

扯淡之前，还是先回到红绿灯这个事儿上：

　　这是再常见不过的红绿灯。当工业化城市化达到一定程度，出现车如流水马如龙的复杂交通，红绿灯也便应运而生。在这里，红绿灯起到的就是规范的作用，路人、司机达成一致共识：红灯停，绿灯走。一切有序进行。缺少它，过马路将变得惊心动魄。

　　这是再简单不过的常识，但同样的思维迁移到设计上来，会引发很多有趣的思考。

　　常看到产品设计团队经常对导航、反馈等交互问题进行激烈讨论，虽然多元碰撞是好事，但一旦系统开始庞大，问题也将显露水面：团队成员各有创意追求，尤其是视创意如生命的设计师，对规则创新的追求更为突出，如果团队缺少“红灯停绿灯走”这样的共识、缺少设计约束，将导致规则无序叠加，使得软件的整体交互变凌乱复杂。

设计规范三宗罪

1. 规范制定时机过早/过迟

　　小村庄的道路是不需要红绿灯的，因为压根用不着，红绿灯的存在反而限制了人们的自由走动。但却有那么一类公司，在早期产品野蛮成长、规模还小的时候，早早制定设计规范，花大功夫，却无人接受，难以执行。与过早相对，太迟也不合适，大公司也会犯这样的错误，如google，android在4.0之前出了个相当粗糙、有和没有一个样的规范，等到自家系统跑着很多长iPhone模样的app时才发现问题的严重。

2. 规范过于详尽

　　红绿灯是一个特别简单的“约束”，红灯停，绿灯走，至于怎么停、怎么走，交给甲乙丙丁自行决定。《iPhone Design Guideline》的制定者非常有先见之明，他们在撰写规范的时候，选择了一种宽泛的表述方式，没有定义“点击按钮”应该多大、没有定义“返回按钮”必须长左