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

　　在小公司，尤其做移动应用的初创小公司，资金、资源有限，请不起技术大牛，也组建不了坚实的研发团队，整个应用的开发往往交给一到两个人。
　　而这些人的Web研发能力尚可，App研发参与过，经验不多，如果项目时间允许，也能应付过来。
　　但是项目时间有限，研发实力有限，人手有限，这三个有限加在一起，再完美的设计最后呈现出来的界面美观值、操作流畅值、整体体验值都会大打折扣。
　　是的，很多在小公司供职的设计师都会有这种苦不堪言的经历，我也是。
　　在没接手A项目之前，与两个初创人第一次见面聊的很兴奋，通过两小时聊天式的头脑风暴，找到了这款应用的突破口。四个人一致认为照着这个思路重新设计，不管是从应用的视觉、操作、传递的价值观、整体体验，将是一场完美颠覆。
　　通过一个多月的原型与UI输出，几番修改敲定，最终呈现的高保真界面让参与项目的所有人都感到十分满意。
　　然而，当技术正式切入的时候，发现事情没有想象中那么简单。原本我和nana以为技术按照高保真界面开发就行了，界面中采用的布局和交互并没有刻意标新立异，都是比较常见的，研发起来应该不费事。
　　结果，看到研发出来的页面，我和nana差点哭了…..
　　……
　　好吧，该是认清事实的时候了。
　　我们做了一些补救措施，比如，UI界面上的行距、色值都逐一详细地标注出来，让技术一目了然，能UI和切图做的尽量不让技术做，减少技术负荷。
　　像这样：
　　然后技术根据这些值一遍遍的调整，貌似有点效果，后来的验收界面确实比之前好很多，越来越接近高保真了。
　　但是，由于UI和切图都是一个人，把40多张界面一一标注，真苦了nana同学。
　　设计与研发衔接的不对等，绝对不是一个非典型事件。特别是C端产品，强烈要求界面美观友好，操作简单流畅，体验美轮美奂。这对设计师是一个挑战，但对技术更是一个挑战。
　　设计师凭借自身经验，再适当借鉴优秀的设计，设计出一套大家都满意的方案不是太难的事情。而技术容易被自身经验束缚，做惯了Web端开发，遇到新锐的移动端有点手足无措。
　　再加上新技术的持续学习，比如2014年兴起的HTML5。据说HTML5.1将在2016年底发布，做技术的是否能积极应对新技术对互联网产品的侵润。
　　还有个很客观的问题：人手不够。
　　互联网公司加班最多的莫过于研发，研发人手应该远多于任何一个职位（销售地推除外）。
　　小公司为了节约成本，研发就一到两个人，甚至就一个人。项目时间紧，通常2个月就要发布一个完全不一样的新版本。时间和精力的双重压力让程序员来不及多思考多研究，出来的东西自然不会达标。
　　所以，靠谱设计难免会遇见不靠谱技术，咋办呢？撕逼？毛用！撕完还是得继续合作。再说，人也是辛辛苦苦赶出来的，说不定还熬夜了呢，要相互体谅。
　　其实这就跟小夫妻相处是一个道理，找到问题所在，磨合磨合再磨合…
　　当设计师接到一个项目，激情满满的撸袖子准备大干一场的时候，记得先跟项目里的技术先沟通沟通。
　　不是说根据技术呈现能力来进行设计。咱设计的产品是以用户为中心，不是以技术为中心，更不是为完成项目为中心。
　　跟技术沟通的时候，听听他的项目经验，看看他自认为最满意的作品是什么样子，从而能对他的能力水平有个大致了解。
　　如果技术人手充分，都有成熟的App开发经验，项目时间也充足，那就使出浑身解数地大胆设计吧，把最完美的一面展现出来。
　　如果技术人手不够，只参与过一两个App开发，有的甚至没有接触过，项目时间又催得紧，这就需要设计师多做一些工作，甚至要做一些牺牲。
　　原型设计阶段就邀请技术介入，遇到较特别的布局和交互，最好分A/B稿。A稿是设计师的实力和初心，B稿是考虑到技术呈现退而求其次，又不是很糟糕的设计。
　　如果自己的设计与市面上的App有相似之处，可以拿来给技术做参考。
　　当然，也许有的技术会否定大部分的设计，认为不好实现，或者没时间细细研究。设计师也不能一味的委曲求全，全面衡量方案的难度，必要的时候了解一些技术相关的知识，该争取的还是得争取。