系列之三 实现与跟进

#团队沟通

本人一直都认为,普通设计师不应该过度承担团队教育的功能。比如提供很多高大上但是明显与当前团队需求有所偏差的产品作为案例,抱着展现更好的选择以及提高团队其他成员审美基准,导致案例无法评审通过反而leader不满意回头做更佳保守的方案。

首先这种做法浪费了时间,其次很多公司并不需要多好的方案(受众需要或是领导个人偏好)——既然他们没有需求就没有必要主动提供不符合他们需求的方案给他们。领导当然希望设计师提高最好的方案,可是当他们并没有鉴别能力的时候(或是不理解业务局限的时候),设计师一味制造他们所认可的更好方案来彰显价值,其实对于最终的成品并没有好处。其一是加长了设计流程导致评审不过关(通常这都意味着许多对设计师的质疑和批评),其次是这种团队教育本身很难成功(因为这通常意味着不太合理的流程和不太专业也不愿意相信专业人士的伙伴),反而会被误解为设计能力不足等等损坏设计师的专业声誉。

至于产品最终成果是否能有好的视觉表现和交互体验,应该把责任和决策都留给真正的决策者。决策者应该为团队支付代价以及承担责任,并且如果他们并不愿意支付成本的时候设计师的做法是应该根据他们实际确切的资源和要求提供产出(假如审美很差又想高大上就只能提供他们喜欢的高大上)。如果设计师有更高的追求应该在业余项目中实现或是干脆用脚投票去那些更需要高质量产出的公司。商业社会自然会优胜劣汰淘汰某些公司,市场的残酷本身远远比设计师单方面的死谏有意义。不在其位而过度谋其位很容易导致设计因为努力设计但是却最终只能大幅修改方案带来的落差和时间损耗,而且也没有仔细优化好较为保守的方案导致最终产物较为粗糙。

那些鼓吹设计师应该努力改变流程教育团队的人,要么就是坏心眼要么就是缺心眼。他们肯定知道同时产出质量较好的两套方案(保守和先进)都需要时间,而这个时间通常不够所以设计师很可能需要背负骂名以及加班来完成两套方案(甚至更多)。这种鼓励加班的工作方式变相促进设计师提供的较为先进或是保守的方案都不够好(时间不足),同时也不利于团队成员的自我学习提高等等,更容易导致靠谱设计师的流失。

在这个过程中,部分设计师可能很喜欢(或是刻意表现)某种作为牺牲品和殉道者的姿态。比如我为了好的设计如何如何牺牲等等,我如何为了客户用户产品如何如何努力教育团队成员,我为团队提高多少改变推进多少变化等等。设计师当然可以为团队提高知识,但是这仅仅基于团队成员有意愿和能力接受并且有一定专业水准的情况下,并且团队leader有足够的意愿的情况。但是一味鼓吹自己的困难和苦衷,高喊着自我牺牲,团队至上,有着一种诡异的思路——依靠着道德准则(单纯概念上的设计师对美的追求以及设计师对团队的责任(没有任何对应流程和团队投入哦 需要设计师单方面遵守的原则哦))而不是流程机制进行工作。

比较可笑的是,喜欢鼓吹这套东西的人通常并不愿意为此而亲自加班干活,他们更喜欢表现悲情的姿态或是用此争取话语权(但是其他团队成员对此可能并不在意更不理解,甚至让事情显得更坏)。工作不应该成为过度刻意表演的场合,工作本身也不应该成为无聊的中二恋爱剧。(啊,我好爱你(这可能不一定是真的),都憋在心里,我为你做了很多东西,虽然你不喜欢,但是我期待你总有一天会爱我会理解我的 ==!)


#设计师的技能树扩张
设计师特别是交互设计师需要拓展技能,但是可能的方向并不唯一。或许了解产品知识尝试完整介入产品生产全过程比较容易获得成就感(当然还有更多钱)。当然设计师也可以选择学习更多开发知识尝试开发完整的产品实现自己的设计。关于前者,已经有太多纷纷扰扰的讨论,但是关于后者这里还有一点儿需要讨论的。

或许设计师没法如科班开发者那样刷过很多算法题,了解计算机软件与硬件的底层运作与实现。但是至少借助于许多高级的编程语言与库的帮助,设计师能更好的实现自己的想法,在开发过程中更好的控制具体的样式和交互实现就足矣。因为假如没有经受过足够训练,单纯指望跟进开发就能获得良好成效是极难的。同时,设计师对于编程的投入和贡献,也能有助于设计师更好的维护与督促开发实现整套设计方案。

(在此就不抱怨好前端多难找,以及多少公司甚至抓写java的来写界面的问题)


#开发百态
在一个公司内,不同部门的对于产品的贡献决定了这个部门的强势程度。常见的状况是研发较为强势而设计团队被视为画图工具。如果开发抱着一种反正产品会迭代/反正设计不太重要设计得不好都是你们的错/我希望你们针对我专门产出最适合我的文档,那么除非某些特殊的产品,否则很容易不受待见。因为即便这个产品再稳定功能再齐全,也可能因为视觉与交互上的各种简陋与混乱流失很多客户。

当我们看到一个有着功能与体验上都较好的产品,我们不仅可以看见背后的投入,甚至能看见这个公司不同人员之间的地位以及合作沟通方式。或许产品经理在人员选择方面,也应该让更加有耐心的同事负责直接与用户有交互的功能模块开发,而让那些比较急躁的同事负责后台的其他模块。团队成员之间的性格契合能够更一定程度提高最终产品的水准,而性格差异过大且难以很好的沟通的同事直接相处可能造就挖制度空子减少自身责任而不管顾产品质量的悲剧。


#产品验收方式


产品实现过程应该有意识安排多个小节点让设计师进行验收以及沟通介入。最好在开发流程中就对思考如何规划进度方便设计师/产品经理分批验收。假如设计师不能分期介入并且持续跟进,那么问题可能就会遗留到上线前的最后关头。



评论

此博客中的热门博文

关于产品设计 #这是个巨大的坑

书单 披着用户研究的皮却有着一颗好奇心(更新20140919

设计工具吐槽 之 protopie