开发思惟方式浅谈

以前看了腾讯高级交互设计师WingST写的一篇《交互设计技能书——开发思惟》的文章提到的“开发思惟”深有感触，结合实际工做中遇到的一些问题，谈谈我对“开发思惟”的理解。

身为一个网络公司的UI组成员，公司里几乎都是有开发背景的同事，当组成一个项目组时，咱们根据本身的专业各司其职，可是愈来愈多的问题开始出现，其中一个很是重要也很是常见的问题就是——跨领域沟通问题。

最初的计算机是没有界面的，经过一些列复杂的命令运算使用，外形也很是复杂庞大；随着科技的进步，渐渐出现了我的电脑（PC），做为施乐最出名的研究机构，PARC为随后大范围普及的我的电脑的设计型态和交互逻辑定下了基调。Bob Taylor，做为一名训练有素的心理学家和工程师，带领着他的团队构建出了人机交互领域最重要也是最普及的工具，包括图形化界面（GUI）和鼠标。（随后乔布斯和盖茨前后访问了PARC，参考了施乐之星的设计，为今天的苹果和微软开辟了通向将来的道路。）

（第一台搭载图形界面的苹果电脑）

若是看看整个计算机的发展史，很早以前，前辈们就开始注重“用户体验”了。设计师做为用户和产品开发之间的桥梁，不只应该有用户思惟，也须要有开发思惟。由于若是不明白自家的产品究竟用的是什么技术，那设计出的产品极可能是天马行空的。

1、理解限制，实现设计价值

「不要将系统的限制或条件视为局限性，把他们当作构建创意设计的根基。」 ——Luke Miller，《用户体验方法论》

设计师最擅长的是构想

开发关心如何实现这个功能，逻辑是否是和其余功能相容等；设计师关心这个功能能不能帮到用户，怎么让这个功能一会儿就让用户找到，同时让用户眼前一亮，欣喜的使用咱们的软件。正由于咱们的专业背景不一样，角度不一样，若是只是各想各的各说自话，就很容易致使设计构想与技术基础都漂浮着，没有链接在一块儿。我举个栗子：

有一次，为了不用户等待时间过长形成烦躁和重复操做，咱们用AE画了一个很具公司特点的小动画，一个开发拿到手以后，这个不行，很差实现，我得写一个星期；另一个开发拿到手以后，沉吟了几秒，说“我能够试试，可是你得把xxxxx参数给我”，咱们的设计人员傻眼，“啥？”犹豫了一下，“我能够把AE里的公式给你，而后它是这么这么转的”，设计人员用手势表达了一下这个动画的运起色制。开发人员说，“再见！”。这个动画基本上是开发猜着写的，结果可想而知，效果仍是差那么一丢丢，对于咱们“像素眼”来讲，但是大事，一直让开发人员调整，调来调去仍是不对，开发人员大怒，直接撂挑子不干了。设计人员很委屈，我就是是让你改改，一点小细节不行在用户看来都是不专业的表现；开发人员也委屈，你就扔给我一个gif，就让我本身把过程猜出来写，能写出来都不错了，还挑！

让咱们时光倒流，若是，咱们稍微了解一下动画的实现机制。是否是能够把开发人员须要的参数给他呢？若是能够这样，开发人员可能就不会猜着写，偏差就不会那么大，结果可能就不会闹的那么僵。

再举个例子，咱们用代码写段文字时，会有一个行高的概念，好比一个tab标签的标题，选中时下面会有一条横线，咱们为了实现这个效果，会给这个标题加一个行高，这样能够直接给盒子加底部线条。可是呢，在设计人员标注时，其实是没有行高的概念的，通常都是贴边算间距，这样比较规矩。这时候咱们又产生了分歧，致使的是，设计这边辛辛苦苦标注了好久，到开发那边没什么用，最终出来了效果图仍是差距很大，一度让设计人员认为，我标那么就你根本不看！可是开发人员也一肚子苦水，你只给我两行字的间距，这个行高你让我咋算，其余的行高是否是都是一致的我也不知道！为了解决这个问题，咱们两个组就标注的问题，开了好几回会，最终定下来的标注规范，效果甚微。由于设计人员的不理解，行高标注了可能也不适用。

后来，为了两个组更好的沟通，设计人员开始学习html+css，前端开发开始熟读交互设计规范；到真正本身去用代码还原一个页面时，才了解到，什么样的行高是有效的，即便咱们对比着设计稿一比一还原，仍是有视觉差等等等等。设计组和前端组的沟通才渐渐好转。

寻找设计的支点

给出的设计构想是很漂亮，可是不少设计师到了实现的这步就傻眼了：剩下的交给开发啊，我切图你实现不就行了，怎么这也不能作，那也实现不了？

不少时候其实并不能怪开发，不如一块儿来帮开发同窗想一想，你的设计究竟要怎么落地才能实现地更好？

• 好比你想快速掌握用户的地理位置，你就应该知道手机上是有 GPS 模块的，APP有接口可以快速获取到用户的手机定位信息，定位的经纬度能够换算成省市地区；
• 好比你想作一个能够根据用户的手机倾斜角度改变形态的设计，你就应该知道手机上有一个叫陀螺仪的模块，它具体是怎样感知手机的倾斜角度的，又能传回怎样的参数来表明这些角度？它的精度如何，可以很好地还原你的设计吗？
• 好比你想实现一个很酷炫的动画效果，你就应该知道 Android、iOS 这两个系统上的动画实现原理。若是你作的是 Web 或者是 PC 端的设计，那和移动端的动画实现方式又不同，这些实现方式能还原你的动画效果吗？
• 好比你想作一个图像智能识别的功能或者智能语音翻译的功能，你就应该明白这种功能是哪些公司作得比较强，他们分别能实现的程度是怎样的？大家的开发团队有相应的技术储备吗？是否能直接找这些公司合做呢？

就算你作的不是什么创新的设计，可是要保证你作出的设计可以很好地被开发还原出来，你也应该知道点九切图法、Retina 屏幕的切图比例、iOS 的基本控件库、响应式设计的实现原理等等，明白这些，你的设计才算找到了和技术链接的支点。

实现设计的价值

只有基于这些和技术链接的支点，你的设计构想才能真正落地，构成了一圈新的「承重墙」。因为技术基础和开发周期的限制，你的设计一般没办法100%实现，但只要你的支点够牢，你的设计构想就可以最大程度地进行还原。

只有真正还原了的设计，才构成了设计的价值。

就像符合格律的诗歌才有韵味同样，设计师也是戴着镣铐跳舞的舞者，这些「技术镣铐」不是羁绊你舞步的阻碍，相反的，正是由于戴着它们你还能跳得比别人好，你才变得不同凡响，你的设计才比别人的更有价值。

千万不要让你的设计变成了天马行空的「大胆构想」，想得再好却缺少实现的可能，落地就会变成薄薄的一层烂泥，那些只是无价值的设计。常常看到dribble、站酷上很华丽、炫酷的移动端概念稿，这样的概念稿仅限于拓展思路，若是盲目的使用...看你的开发搭档会不会打你。

无价值的设计

2、拥抱限制，寻找技术边界

「尽量地去了解你为之设计的系统的性能和限制。这有助于你提高绘制用户理想流程图和在设计中加入新特点和交互的能力。」 ——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毫秒播放一帧，我就写明白了每一个时刻要从哪一帧播放到哪一帧。 写完，我带着这份说明书，搬一把椅子就坐在开发同窗后面了。

这样一来，咱们的设计支点就提升了，离咱们的设计构想近了不少，最终实现的效果很是赞。

原做者的不屈不挠的精神很让人佩服，咱们在工做过程当中，何不试试优化本身输入的方式呢？咱们在寻找最优“输入方式”的同时，其实也就有了算法的思惟，不断改进本身的“输入”，开发给出的“输出”就越接近咱们想要的。

模块化设计

为何每次咱们都要这么麻烦地搞什么输入、输出和算法？为何不能把已有的算法给固定下来呢？

咱们设计这边的“模板”或者开发用到的“组件”，就是模块化的设计。

好比说一个弹窗组件，开发人员引用后，只须要修改几个参数就能够直接复用了。

模块化设计对于设计的意义：

• 是在特定场景下的最佳展示方式
• 能保持产品的交互、视觉风格一致性
• 便于协做、修改

模块化设计对于开发的意义：

• 下降耦合度
• 减小冗余代码，提升性能
• 便于协做、修改
• 便于查错

...

所以，时刻心中都有模块意识的交互设计师，他会在合理设计页面功能的状况下，尽量地复用设计，和视觉设计师一块儿把它们固化成模块，就像在生产乐高积木同样。这样一来，只要完成了主要页面和主风格的设计，剩下再多的页面也不过是一种理性地拼装和因地制宜地修改而已。