因为设计师是用户和产品开发之间的桥梁，所以设计师不仅应该有用户思维，也需要有开发思维。因为如果不明白自家的产品究竟可以用哪些技术，那设计出的产品很可能是天马行空的。俗话说得好，比创意谁不会，能落地才算成功
一、寻找设计的支点
在没有设计介入时，光是靠技术构成的产品易用性是很差的，就像一片光秃秃的陆地，看着确实很踏实，但毫无生气，还容易迷路。这时设计师来了，说这不行啊，我给你做个优化吧，然后给出了一个完整的设计构想，确实很漂亮。这时地面上有了绿植、建筑、河流，构成了一个新的产品，老板一拍桌子说，「看着不错啊，我们开工吧！」
往往给出的设计构想都很漂亮，但是很多设计师到了实现的这步就傻眼了：剩下的交给开发啊，我切图你实现不就好了，怎么这也不能做，那也实现不了？
例如：你想快速掌握用户的地理位置，你就应该知道手机上是有 GPS 模块的，APP 有接口能够快速获取到用户的手机定位信息，定位的经纬度可以换算成省市地区，如果默认没有开启定位，提示去设置开启；
例如：你想做一个人脸识别的功能，你就应该明白这种功能是哪些公司做得比较强，他们分别能实现的程度是怎样的？现有的开发团队有相应的技术储备吗？实在不行是否能直接找这些公司合作呢？
就算我们做的不是什么创新的设计，但是要保证做出的设计能够很好地被开发还原出来，也应该知道屏幕的切图比例、iOS 的基本控件库、响应式设计的实现原理等等，明白这些，我们的设计才算找到了和技术开发连接的支点。（目前我们也正在这样
二、实现设计的价值
只有基于这些和技术连接的支点，我们的设计构想才能真正落地。由于技术基础和开发周期的限制，我们的设计通常没办法100%实现，但只要我们的支点够牢，我们的设计构想就能够最大程度地进行还原。只有真正还原了的设计，才构成了设计的价值
三、拥抱限制，寻找技术边界
要理解开发思维，就要先解释一下程序员常常挂在嘴边的「算法」究竟是什么，只有理解了算法，才算真正理解了开发思维。
1.算法的本质
关键字：解题方案、输入和输出。根据这三个关键字我们可以得出算法的数学方程式：
Y = U(X)
X 是输入，Y 是输出，U(X) 是基于参数 X 最终能得出 Y 的函数（解题方案），也就是算法。
举个最简单的算法，你按下了开关，电灯亮了。你按下开关的动作是输入 X，电灯亮是输出 Y，而从开关的结构到电线的排布、电源的引入，这一整套电路方案和开关的设计就是算法 U(X)，它解决了按下开关让电灯亮的问题。 同样的，你在微信上长按发送一段语音，这是输入 X，朋友收到你发来的语音，这是输出 Y，让这段语音从你的微信到朋友的微信的解决方案，就是算法 U(X)。
开发同学的伟大之处就在于，他们会很多厉害的算法，能把我们的设计通过代码还原成 APP、Web 网站以及各种形态的软件产品，我们的设计方案对于他们来说就是输入，最终的产品就是输出。 所以说，上面的这个方程式 Y=U(X)，其实就是算法的本质：我们想要得到输出 Y，那就给开发同学输入 X，他会找到一个算法 U(X) 帮我们解决。
2. 改变输入方式
很多同学会抱怨开发同学水平不行，实现不了我们的设计，这种时候不妨想想，我们给开发同学的是不是下面这种传统的输入方式：
我们的设计构想是很完美很厉害，但是我们给开发同学的不过是一简单的低保真原型，以及一张看起来华丽却不会动的视觉稿（有可能没有），剩下的就交给开发同学了。 在开发同学眼中，我们给的输入 X 就这些，他们只能尽量用算法实现我想象中的输出 Y 了，至于和我们想的一不一样他不知道，先做出来看看再说。现实总是很残酷的....
所以们就要改变一下输入的方式，多多了解开发知识，让我们的输入更加详细，交互稿标注清晰，交互样式做好说明，确保传达给开发同学的「输入 X」足够精准，这样他才能够通过算法来帮我们实现足够完美的「输出 Y」。
3. 模块化设计（组件库）
为什么每次我们都要这么麻烦地搞什么输入、输出和算法？为什么不能把已有的算法给固定下来呢？ 当然可以，开发同学最喜欢的就是把算法给固定下来了，那就是规划设计模板，搭建组件库。这样可是达到可复用的目的，也大大节省了开发时间（这也是我们眼下正在做的事情。）
因此，我们时刻心中都有模块意识，应在合理设计页面功能的情况下，尽可能地复用组件库。
总结
在我们在设计时，需要站在开发的角度上去思考论证我们的设计是否可以完美落地，这就要我们多多了解开发知识，尽量做到与开发可零障碍沟通，让其能够准确的理解我们想要的是什么，拒绝天马星空。
