之前看了腾讯高级交互设计师WingST写的一篇《交互设计技能书——开发思维》的文章提到的“开发思维”深有感触，结合实际工作中遇到的一些问题，谈谈我对“开发思维”的理解。
身为一个网络公司的UI组成员，公司里几乎都是有开发背景的同事，当组成一个项目组时，我们根据自己的专业各司其职，但是越来越多的问题开始出现，其中一个非常重要也非常常见的问题就是——跨领域沟通问题。
最初的计算机是没有界面的，通过一些列复杂的命令运算使用，外形也非常复杂庞大；随着科技的进步，渐渐出现了个人电脑（PC），作为施乐最出名的研究机构，PARC为随后大范围普及的个人电脑的设计型态和交互逻辑定下了基调。Bob Taylor，作为一名训练有素的心理学家和工程师，带领着他的团队构建出了人机交互领域最重要也是最普及的工具，包括图形化界面（GUI）和鼠标。（随后乔布斯和盖茨先后访问了PARC，参考了施乐之星的设计，为今天的苹果和微软开辟了通向未来的道路。）
如果看看整个计算机的发展史，很早之前，前辈们就开始注重“用户体验”了。设计师作为用户和产品开发之间的桥梁，不仅应该有用户思维，也需要有开发思维。因为如果不明白自家的产品究竟用的是什么技术，那设计出的产品很可能是天马行空的。
一、理解限制，实现设计价值
「不要将系统的限制或条件视为局限性，把他们看成构建创意设计的根基。」 ——Luke Miller，《用户体验方法论》
设计师最擅长的是构想
开发关心如何实现这个功能，逻辑是不是和其他功能相容等；设计师关心这个功能能不能帮到用户，怎么让这个功能一下子就让用户找到，同时让用户眼前一亮，欣喜的使用我们的软件。正因为我们的专业背景不同，角度不同，如果只是各想各的各说自话，就很容易导致设计构想与技术基础都漂浮着，没有连接在一起。我举个栗子：
有一次，为了避免用户等待时间过长造成烦躁和重复操作，我们用AE画了一个很具公司特色的小动画，一个开发拿到手之后，这个不行，不好实现，我得写一个星期；另外一个开发拿到手之后，沉吟了几秒，说“我可以试试，但是你得把xxxxx参数给我”，我们的设计人员傻眼，“啥？”犹豫了一下，“我可以把AE里的公式给你，然后它是这么这么转的”，设计人员用手势表达了一下这个动画的运转机制。开发人员说，“再见！”。这个动画基本上是开发猜着写的，结果可想而知，效果还是差那么一丢丢，对于我们“像素眼”来说，可是大事，一直让开发人员调整，调来调去还是不对，开发人员大怒，直接撂挑子不干了。设计人员很委屈，我就是是让你改改，一点小细节不行在用户看来都是不专业的表现；开发人员也委屈，你就扔给我一个gif，就让我自己把过程猜出来写，能写出来都不错了，还挑！
让我们时光倒流，如果，我们稍微了解一下动画的实现机制。是不是可以把开发人员需要的参数给他呢？如果可以这样，开发人员可能就不会猜着写，误差就不会那么大，结果可能就不会闹的那么僵。
再举个例子，我们用代码写段文字时，会有一个行高的概念，比如一个tab标签的标题，选中时下面会有一条横线，我们为了实现这个效果，会给这个标题加一个行高，这样可以直接给盒子加底部线条。但是呢，在设计人员标注时，实际上是没有行高的概念的，一般都是贴边算间距，这样比较规矩。这时候我们又产生了分歧，导致的是，设计这边辛辛苦苦标注了很久，到开发那边没什么用，最终出来了效果图还是差距很大，一度让设计人员认为，我标那么就你根本不看！但是开发人员也一肚子苦水，你只给我两行字的间距，这个行高你让我咋算，其他的行高是不是都是一致的我也不知道！为了解决这个问题，我们两个组就标注的问题，开了好几次会，最终定下来的标注规范，效果甚微。因为设计人员的不理解，行高标注了可能也不适用。
寻找设计的支点
给出的设计构想是很漂亮，但是很多设计师到了实现的这步就傻眼了：剩下的交给开发啊，我切图你实现不就好了，怎么这也不能做，那也实现不了？
很多时候其实并不能怪开发，不如一起来帮开发同学想想，你的设计究竟要怎么落地才能实现地更好？
- 比如你想快速掌握用户的地理位置，你就应该知道手机上是有 GPS 模块的，APP有接口能够快速获取到用户的手机定位信息，定位的经纬度可以换算成省市地区；
- 比如你想做一个可以根据用户的手机倾斜角度改变形态的设计，你就应该知道手机上有一个叫陀螺仪的模块，它具体是怎样感知手机的倾斜角度的，又能传回怎样的参数来代表这些角度？它的精度如何，能够很好地还原你的设计吗？
- 比如你想实现一个很酷炫的动画效果，你就应该知道 Android、iOS 这两个系统上的动画实现原理。如果你做的是 Web 或者是 PC 端的设计，那和移动端的动画实现方式又不一样，这些实现方式能还原你的动画效果吗？
- 比如你想做一个图像智能识别的功能或者智能语音翻译的功能，你就应该明白这种功能是哪些公司做得比较强，他们分别能实现的程度是怎样的？你们的开发团队有相应的技术储备吗？是否能直接找这些公司合作呢？
就算你做的不是什么创新的设计，但是要保证你做出的设计能够很好地被开发还原出来，你也应该知道点九切图法、Retina 屏幕的切图比例、iOS 的基本控件库、响应式设计的实现原理等等，明白这些，你的设计才算找到了和技术连接的支点。
实现设计的价值
只有真正还原了的设计，才构成了设计的价值。
就像符合格律的诗歌才有韵味一样，设计师也是戴着镣铐跳舞的舞者，这些「技术镣铐」不是羁绊你舞步的阻碍，相反的，正是因为戴着它们你还能跳得比别人好，你才变得与众不同，你的设计才比别人的更有价值。
千万不要让你的设计变成了天马行空的「大胆构想」，想得再好却缺乏实现的可能，落地就会变成薄薄的一层烂泥，那些只是无价值的设计。经常看到dribble、站酷上很华丽、炫酷的移动端概念稿，这样的概念稿仅限于拓展思路，如果盲目的使用...看你的开发搭档会不会打你。
无价值的设计
二、拥抱限制，寻找技术边界
「尽可能地去了解你为之设计的系统的性能和限制。这有助于你提升绘制用户理想流程图和在设计中加入新特色和交互的能力。」 ——Luke Miller，《用户体验方法论》
要理解开发思维，就要先解释一下程序员常常挂在嘴边的「算法」究竟是什么，只有理解了算法，才算真正理解了开发思维。
算法的本质
算法（Algorithm）是指解题方案的准确而完整的描述，是一系列解决问题的清晰指令，算法代表着用系统的方法描述解决问题的策略机制。也就是说，能够对一定规范的输入，在有限时间内获得所要求的输出。——百度百科
关键字：解题方案、输入和输出。
根据这三个关键字我们可以得出算法的数学方程式：
Y = U(X)
X 是输入，Y 是输出，U(X) 是基于参数 X 最终能得出 Y 的函数（解题方案），也就是算法。
比如，你的拇指按下了手机的HOME键，手机屏幕亮了。你按下HOME键的动作是输入X，手机屏幕亮是输出Y。当我们拇指按下HOME键后，手机的系统可能需要判断是不是手机主人的指纹、是否解锁手机，解锁手机后是不是屏幕亮起等等一些列的判断过程，这整个的过程就是算法U（X），它解决了按下HOME键让手机屏幕亮的需求。
开发同学的伟大之处就在于，他们会很多厉害的算法，能把你的设计通过代码还原成 APP、Web 网站以及各种形态的软件产品，你的设计方案对于他们来说就是输入，最终的产品就是输出。
所以说，上面的这个方程式 Y=U(X)，其实就是算法的本质：你想要得到输出 Y，那就给我输入 X，我会找到一个算法 U(X) 帮你解决的。
改变输入方式
很多同学会抱怨开发同学水平不行，实现不了他们的设计，这种时候不妨想想，你给开发同学的是不是下面这种传统的输入方式：
你的设计构想是很完美很厉害，但是你给开发同学的不过是一张简单的原型图和交互说明的交互稿，以及一张看起来华丽却不会动的视觉稿，你觉得他们对你的这种输入方式能理解多少？恐怕只有不到一半吧。剩下的那些，开发同学只好自由发挥了，不然东西做出来可是会有Bug 的。何况开发时间还那么少，老大们可不会找设计师催进度。
这下你明白了，在开发同学眼中，你给的输入 X 就这些，我只能尽量用算法实现我想象中的输出 Y 了，至于和你想的一不一样我不知道，先做出来看看再说。
但现实是残酷的，最终实现出来的往往是南辕北辙。
何不试着改变一下输入方式？
接下来是原作者超厉害的例子
我们为小火箭重新设计了一套新的发射动画，相比原来的时间更短、加速感更强，火箭在上升过程中还会旋转，确实很酷。这要靠交互稿和视觉稿当然都是说不清楚的，为此我们为它做了个高保真视频 Demo：
开发同学：「嗯，看懂了，确实很快，但快到我都看不清啊，这要怎么做？」
我和视觉：「稍等，我们想想办法。」
我们当然不会让开发同学对着视频一帧一帧研究，他们没那个功夫，我们反其道行之。我们用 Visual Basic 语言写了个程序 Demo，用一个很精简的函数就实现了视频 Demo 中的那种多段加速的动画：
然而，对方长久的沉默让我看出了他的心声：「这什么鬼，懒得研究！」
所以我只好使出「终极大招」，我自学了 Visual Basic，自己看懂了函数，然后在纸上一番埋头苦算，终于给出了一份详尽的动画「说明书」，
整个小火箭的动画，从点击开始，小火箭每一步的动画分解，细致到了每毫秒的动作； 在每毫秒的过程中，每个组件分别是怎么动作的，方向、速度如何，当然也包括了小火箭上升的几段过程的分解； 小火箭旋转需要播放一套序列帧动画，开发能实现的最小颗粒度是10毫秒播放一帧，我就写明白了每个时刻要从哪一帧播放到哪一帧。 写完，我带着这份说明书，搬一把椅子就坐在开发同学后面了。
原作者的不屈不挠的精神很让人佩服，我们在工作过程中，何不试试优化自己输入的方式呢？我们在寻找最优“输入方式”的同时，其实也就有了算法的思维，不断改进自己的“输入”，开发给出的“输出”就越接近我们想要的。
模块化设计
为什么每次我们都要这么麻烦地搞什么输入、输出和算法？为什么不能把已有的算法给固定下来呢？
我们设计这边的“模板”或者开发用到的“组件”，就是模块化的设计。
比如说一个弹窗组件，开发人员引用后，只需要修改几个参数就可以直接复用了。
模块化设计对于设计的意义：
- 是在特定场景下的最佳展现方式
- 能保持产品的交互、视觉风格一致性
- 便于协作、修改
模块化设计对于开发的意义：
- 降低耦合度
- 减少冗余代码，提高性能
- 便于协作、修改
- 便于查错
...
因此，时刻心中都有模块意识的交互设计师，他会在合理设计页面功能的情况下，尽可能地复用设计，和视觉设计师一起把它们固化成模块，就像在生产乐高积木一样。这样一来，只要完成了主要页面和主风格的设计，剩下再多的页面也不过是一种理性地拼装和因地制宜地修改而已。