如何让开发人员按照UI标注还原设计?

2015-10-21    用心设计

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供有效的UI界面设计BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

如果您想订阅本博客内容,每天自动发到您的邮箱中, 请点这里

来源:莫贝网

首先回答问题,程序员不配合,90%以上的情况是需求人员工作不到位。

目录

  1. 像素这样的细节是否重要?
  2. 为什么程序员不愿意修改?
  3. 产品人员该如何解决?
  4. 程序主管应该做什么?

一、像素这样的细节是否重要?

产品人员,一定要了解1个像素在不同情况下,重要程度是不同的,这是你是否要去找程序员修改的大前提。比如

1,产品战略层面是否重视体验?

公司是技术驱动,设计驱动还是市场驱动?这款产品是面向什么用户的?这直接决定了细节在产品中的重要程度。不知道题主所在公司情况,就直接告诉题主“体验为王”或“设计师工作是可选的”,这样真的好吗?

于UI\UE的重要程度,绝大多数情况下,企业软件<专业工具<大众产品。

举个例子,我老东家金山的后台管理系统,烂的简直让人发指,别说易用了,连能用都达不到,不让你撤销重填就算谢天谢地了,可用了多年也没换过。你说 1像素重要吗?对于很多企业用户来说,企业软件最重要的是安全、易于部署、维护和扩展,而不是UI是否好看/UE是否完美。所以如果你是做这种产品的UI设计师,长时间纠结1像素被鄙视也是稀松平常的。

而对于像Zaker这样的大众产品,在底层技术能够到位的情况下,用户体验就成了极其重要的一环。任何UI无法对齐、图标大了4个像素、出现“iphone”这样的文字、配色有些烂俗的情况,都会让用户认为“这个产品比较山寨”,“用着有点别扭”的感觉,直接会造成流失/评价下跌。我想,用过知乎iPhone和安卓客户端的人一定深有体会。

2,细节在应用层面的重要程度如何?

同样是1个像素,在不同地方是有不同效果的,不能直接就说重要还是不重要。举个例子

【我的收藏】前面的图标,如果往左挪1个像素,你觉得怎么样?

我的头像这张图和名字,如果整体往左挪1个像素,你觉得怎么样?

我想,大多数人都会同意,第一条更不能忍。也就是说同样的细节,是否重要一定要看它所处的环境,必须具体问题具体分析。对于任何提需求的人,都要自己先搞清楚,再灌输给制作的人,不能一股脑全都丢过去。

3,项目进度和优先级是否允许?

一根筋,是绝大多数新的策划\产品\设计人员最常犯的毛病。他们分不清楚轻重缓急,总是抱着“我是为产品好”的想法去做不合适的事。

举个例子,一个游戏出现刷钱的严重bug,运营要求1小时必须解决。在你的眼里,顺便调整1像素,也就是调一下坐标的事,没什么难的。但在程序员眼 里,这代表着要重新编译、打包上传,会极大增加出问题的风险。哪怕前端程序员没有工作,你也不能去找他改这1像素。这个时候,1像素绝对是无足轻重的。

而当你记下这个需求,等发版以后,程序们有时间开发时再提交,这1像素就有可能重要了。

二、为什么程序员不愿意修改?

这一点上,我要为程序员们喊冤。绝大多数情况下,都是需求提供人员自己本身没有做到位(大部分情况是极不到位)。包括但不限于以下情况:

1、需求提的不明确\有明显问题

2、需求人员平时没有展示出足够的产品能力,造成无法让人信服

3、需求人员极少给程序人员灌输细节的重要性

4、加班时没给程序买可乐

5、……

程序员们,大多数都是非常单纯的人,没有那么多花花肠子,很少有故意给你脸色、撂挑子的情况。只是有些时候他们会一根筋,只要你足够专业,勤于沟通,一般都没有问题。所以是因为设计师不懂代码?部分技术人员的审美意识?还是大厂心态或者其他什么原因?这种状况怎么解决?到什么时代或是契机才能够被解决?

这种抱怨的话少提,与人方便自己方便,自己既然是提需求的人,就要多为对方考虑。

三、产品人员该如何解决?

假设真的出了问题,我们该如何面对?首先要寻找原因,是自己没做到位,还是对方没理解你的想法,还是单纯瞅你不顺眼?假设是1和2,那我们要做到:

1,先搞清产品战略。

自己弄明白这1像素细节是否对产品有足够的重要性。如果不重要,那请把工作中心转移到重要的事情上。

2,绝对自己把该做的事情先做好。

这里边包括自己先弄明白修改的意义,画好标注色值、像素的示意图和文档,做好产品原型等任何能让对方不需纠结,直接可以上手的工作。自己的专业、努力是赢得程序员尊重的前提,赢得他们的尊重你才能顺利开展工作。

我以前给策划审文档,一个3页的doc我打回去过7遍,改了几天,最后才到程序员那里开始执行。虽然还是有些问题,但至少程序看到了这个策划的努力。你想想一下,如果不审核就发给程序,程序会不会拿刀砍人?

3,弄清进度和优先级,弄清对方手头工作

在搞清楚产品进度、优先级的情况下,尤其要注意一点:“绝对不要想到一个需求就跑过去要求程序改!”

程序也是人,很可能正在苦思一个重要问题时,你跑过来打断他的思路,还是用在他看来毫无价值的需求,更糟糕的是你直接要求他放下自己的工作,立即修改,是个程序员都会爆掉的。别说是程序员,要你你也受不了。

好的方法是记录所有需求,自己标记优先级,定期(每天定时)跟程序员沟通,跟他一起制定解决方案和时间。记住不要替他做主!他不是你的下级!他是帮助你的伙伴!

4,私下给老板和程序员不断灌输用户体验的重要性

这是很多人经常疏漏的地方。每个人的思维模式都不同,你不能要求别人也按照你的思维模式来看待问题。想要让大家认同你的看法,就要在平常不断的潜移 默化影响别人。比如没事多跟公司其他人聊产品,聊体验,聊感受,慢慢给他们灌输体验的重要性。只要你的话题有趣,人有趣,没有人会拒绝跟你聊,时间长了, 整个团队的思路就会有所转变。

说个小技巧。程序员大多比较孤高,如果你想让他改什么,你可以有意无意的跟他说,你觉得某个跟你们很像的产品某个体验做的很好,你不知道怎么实现的,一定要摆出一脸羡慕的样子,说他们太牛逼了。你们程序员一定会一脸鄙夷的看着你,说这破玩意有啥难的?老子半天搞定,绝对比他强百倍。多吹捧吹捧,你的目的就达到了,你俩都挺爽,是不是不错?

5,搞好同事关系

程序员加班多,偶尔在他们加班时买瓶可乐,装作一脸坦然的放到他桌子上,他就算嘴上不说,心里也会感激你的。这不是歪门邪道,而是人之常情。社会上你上哪去找一瓶可乐就可以买通的朋友去?

如果还不管用,请用这张图诅咒他

如果你都做好上面5点,对方还无理由拒绝,那问题就不在你这边,也不是你一个人能解决的了。请找你们共同的主管(比如项目经理),三人一起当面沟 通,为什么会出现类似的情况,要有不解决我就拉你们住在会议室的决心。绝大多数情况下,你是能听到程序员告诉你为什么他会不配合的。

切忌私下找对方上级。职场上任何时候,都要做到我对你说的话,对别人都敢说,千万不要做背后议论,抱怨,捅刀子的人。

如果你已经做到位,还是无法解决,那不是这个程序员的问题,就是你们主管的问题,请考虑换工作吧。

四、程序主管应该做什么?

这一条是我看了排名第一CTO的同学,有感而发。同样作为管理人员,我坚信没有任何一个工种是“可选”的。绝大多数产品,无法单靠某一类人就能做到100%的,再好的产品也有改进空间。而这个改进空间,无法靠设计者自己解决,需要借助外力。所以我不认为产品人员不给力,就可以把他们边缘化。

我自己是策划出身,如果我是这个公司的CTO的话,我想我会从下面几个角度让程序和产品人员更好合作。

1, 不断给团队灌输产品为先。

我们每一个人,都是为了这款产品的成功而努力。在这里面,每个人的工作都是为了产品成功负责,而不是谁是做什么的,谁专业不专业。只要能够让产品质量提高,任何提出的方案、修改都是可以讨论的,即使进度不允许,也可以记录下来。

让团队每一个人不再关注自己的角色(策划、程序、美术)、职位,改为关注产品本身,是我的职责所在。

2,抓好培训。提供工具。

抓好培训:为程序人员培训产品的意识。为产品人员培训开发的流程与经验。不求互相替代,只要能两拨人能互相理解,能从对方角度考虑问题就够了。

提供工具:为产品人员提供更好的开发、设计工具,能够让需求从设计者到开发者之间,尽量少出现因沟通产生的歧义。

3, 制定规范和流程

包括需求制作规范、文档规范、开发流程、需求变更规范等等,减少项目中因人的因素带来的不可控。

4,搞好团队建设和人际关系,尽早解决问题。

打破工种的圈子,一起出去吃个饭,打个球,其乐融融多好。

总结一下吧,程序员不配合,不用找那么多理由,大多数情况是需求人员没做到位,请继续修炼自己的专业能力和人际关系。

原文地址:zhihu
作者:@逍遥老李

分享本文至:

日历

链接

个人资料

蓝蓝设计的小编 http://www.lanlanwork.com

存档