当靠谱设计遇见不靠谱技术

浏览量:20 次

在小公司,尤其做移动应用的初创小公司,资金、资源有限,请不起技术大牛,也组建不了坚实的研发团队,整个应用的开发往往交给一到两个人。

而这些人的Web研发能力尚可,App研发参与过,经验不多,如果项目时间允许,也能应付过来。

但是项目时间有限,研发实力有限,人手有限,这三个有限加在一起,再完美的设计最后呈现出来的界面美观值、操作流畅值、整体体验值都会大打折扣。

是的,很多在小公司供职的设计师都会有这种苦不堪言的经历,我也是。

在没接手A项目之前,与两个初创人第一次见面聊的很兴奋,通过两小时聊天式的头脑风暴,找到了这款应用的突破口。四个人一致认为照着这个思路重新设计,不管是从应用的视觉、操作、传递的价值观、整体体验,将是一场完美颠覆。

通过一个多月的原型与UI输出,几番修改敲定,最终呈现的高保真界面让参与项目的所有人都感到十分满意。

然而,当技术正式切入的时候,发现事情没有想象中那么简单。原本我和nana以为技术按照高保真界面开发就行了,界面中采用的布局和交互并没有刻意标新立异,都是比较常见的,研发起来应该不费事。

结果,看到研发出来的页面,我和nana差点哭了…..

……

好吧,该是认清事实的时候了。

我们做了一些补救措施,比如,UI界面上的行距、色值都逐一详细地标注出来,让技术一目了然,能UI和切图做的尽量不让技术做,减少技术负荷。

像这样:

8557bdf40f583.png" />

然后技术根据这些值一遍遍的调整,貌似有点效果,后来的验收界面确实比之前好很多,越来越接近高保真了。

但是,由于UI和切图都是一个人,把40多张界面一一标注,真苦了nana同学。

设计与研发衔接的不对等,绝对不是一个非典型事件。特别是C端产品,强烈要求界面美观友好,操作简单流畅,体验美轮美奂。这对设计师是一个挑战,但对技术更是一个挑战。

设计师凭借自身经验,再适当借鉴优秀的设计,设计出一套大家都满意的方案不是太难的事情。而技术容易被自身经验束缚,做惯了Web端开发,遇到新锐的移动端有点手足无措。

再加上新技术的持续学习,比如2014年兴起的HTML5。据说HTML5.1将在2016年底发布,做技术的是否能积极应对新技术对互联网产品的侵润。

还有个很客观的问题:人手不够。

互联网公司加班最多的莫过于研发,研发人手应该远多于任何一个职位(销售地推除外)。

小公司为了节约成本,研发就一到两个人,甚至就一个人。项目时间紧,通常2个月就要发布一个完全不一样的新版本。时间和精力的双重压力让程序员来不及多思考多研究,出来的东西自然不会达标。

所以,靠谱设计难免会遇见不靠谱技术,咋办呢?撕逼?毛用!撕完还是得继续合作。再说,人也是辛辛苦苦赶出来的,说不定还熬夜了呢,要相互体谅。

其实这就跟小夫妻相处是一个道理,找到问题所在,磨合磨合再磨合…

当设计师接到一个项目,激情满满的撸袖子准备大干一场的时候,记得先跟项目里的技术先沟通沟通。

不是说根据技术呈现能力来进行设计。咱设计的产品是以用户为中心,不是以技术为中心,更不是为完成项目为中心。

跟技术沟通的时候,听听他的项目经验,看看他自认为最满意的作品是什么样子,从而能对他的能力水平有个大致了解。

如果技术人手充分,都有成熟的App开发经验,项目时间也充足,那就使出浑身解数地大胆设计吧,把最完美的一面展现出来。

如果技术人手不够,只参与过一两个App开发,有的甚至没有接触过,项目时间又催得紧,这就需要设计师多做一些工作,甚至要做一些牺牲。

原型设计阶段就邀请技术介入,遇到较特别的布局和交互,最好分A/B稿。A稿是设计师的实力和初心,B稿是考虑到技术呈现退而求其次,又不是很糟糕的设计。

如果自己的设计与市面上的App有相似之处,可以拿来给技术做参考。

当然,也许有的技术会否定大部分的设计,认为不好实现,或者没时间细细研究。设计师也不能一味的委曲求全,全面衡量方案的难度,必要的时候了解一些技术相关的知识,该争取的还是得争取。

 

本文由 @老美(微信公众号 laomay325) 原创发布于人人都是产品经理 ,未经许可,禁止转载。

 
®关于本站文章™ | 若非注明原创,默认 均为网友分享文章,如有侵权,请联系我们™
㊣ 本文永久链接: 当靠谱设计遇见不靠谱技术