阅读 67

开发思维

因为设计师是用户和产品开发之间的桥梁,所以设计师不仅应该有用户思维,也需要有开发思维。因为如果不明白自家的产品究竟可以用哪些技术,那设计出的产品很可能是天马行空的。俗话说得好,比创意谁不会,能落地才算成功

一、寻找设计的支点

在没有设计介入时,光是靠技术构成的产品易用性是很差的,就像一片光秃秃的陆地,看着确实很踏实,但毫无生气,还容易迷路。这时设计师来了,说这不行啊,我给你做个优化吧,然后给出了一个完整的设计构想,确实很漂亮。这时地面上有了绿植、建筑、河流,构成了一个新的产品,老板一拍桌子说,「看着不错啊,我们开工吧!」

往往给出的设计构想都很漂亮,但是很多设计师到了实现的这步就傻眼了:剩下的交给开发啊,我切图你实现不就好了,怎么这也不能做,那也实现不了?

所以很多时候其实并不能怪开发,不如一起来帮开发同学想想,我们的设计究竟要怎么落地才能实现地更好?

例如:你想快速掌握用户的地理位置,你就应该知道手机上是有 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. 模块化设计(组件库)

为什么每次我们都要这么麻烦地搞什么输入、输出和算法?为什么不能把已有的算法给固定下来呢? 当然可以,开发同学最喜欢的就是把算法给固定下来了,那就是规划设计模板,搭建组件库。这样可是达到可复用的目的,也大大节省了开发时间(这也是我们眼下正在做的事情。)

因此,我们时刻心中都有模块意识,应在合理设计页面功能的情况下,尽可能地复用组件库。

总结

在我们在设计时,需要站在开发的角度上去思考论证我们的设计是否可以完美落地,这就要我们多多了解开发知识,尽量做到与开发可零障碍沟通,让其能够准确的理解我们想要的是什么,拒绝天马星空。

关注下面的标签,发现更多相似文章
评论