设计师的一小步,程序员的一大步_平面设计理论教程-查字典教程网
设计师的一小步,程序员的一大步
设计师的一小步,程序员的一大步
发布时间:2015-12-25 来源:查字典编辑
摘要:今天我们聊聊那些年设计师的“小改动”,以及上下游协作(设计师、产品经理、开发、运维等)之间的微妙关系。那些所谓的&l...

今天我们聊聊那些年设计师的“小改动”,以及上下游协作(设计师、产品经理、开发、运维等)之间的微妙关系。

那些所谓的“小改动”通常在设计师或产品经理的嘴里,有以下几种描述:

改改文字颜色而已;

换个图标而已啦;

只是一些小改动;

很简单的啦~

可是到了程序员这里,往往就变味儿了:

这里也要改?

这里要运营?

这个布局完全变了啊!

人与人之间的信任都哪去了?

那么,究竟是什么让人与人之间的信任变得如此淡泊呢?还穿什么安全裤!

首先,从产品人员这里,如果一开始就不信任开发人员,总想把东西往简单了说,或者排上了时间又插需求,那么开发人员也会产生相应的不信任:反正你是要插需求的,不多估算点时间怎么行?

而从设计师的角度,往往设计师的思维更奔放自由一些,同样的设计稿,在设计师眼里就是一副完美的画布任我挥洒。

当然,资深的网页设计师还是熟悉基本的页面布局实现,不过与程序员眼里的结构与逻辑还是两个世界。

所以往往设计师感觉,我的结构没怎么动,只是这里加了个小东西,或者各个元素都调了些位置颜色,因为要符合现在的设计风格嘛。结果到程序员那里就悲剧了:这相当于重做啊!

在完善的开发流程中,上下游的方向是非常牢固的。

产品与交互可以探(si)讨(bi)确定方案,定好的交互到设计师那里,就没有太大发挥余地。

设计师做好的设计稿,到前端开发那里,除了一些特效与实现细节,基本上就是照做而已。而前端开发如果区分重构和 JS,那么 JS 基本也只能拿着重构写好的结构继续开发。

前端跟后台的关系倒不像是真正的上下游,应该说是并行的,甚至大部分时候前端要按照后台的规矩来玩。

而测试同学,在这个流程的最后端,却要从产品文档开始介入整个流程,设计测试用例。从产品逻辑,设计还原,兼容性问题,接口自动化测试,安全问题,性能问题等都要关注。

更别提还有运维哥要跟着改定时任务,优化 DB 等等了。

那么可想而知上游的一些看似微小的变化,会给下游的人员造成多大的蝴蝶效应。

所以,除了我们喊成口号的“理解万岁”之外,其实上游的角色应该更多的去了解下游的工作,才能更好的推进下去。

比如产品运营同学可以多了解一下交互为什要这么执着,这个弹窗为什么不能这么弹?

交互同学可以看看我的交互形式是否太过限制设计,能否有更好的展现形式?

设计师多想想,我这个改动到底会对页面结构有多大影响,这个设计到底是如何变成页面的?

前端同学多想想,我做的模板 JS/后台 能不能用?我是否有考虑到各种状态的变化,各种扩展的能力?

后台的同学多考虑一下我这个接口真的好用吗?有没有哪些参数可以省略?有没有那些信息不该暴露?是否接口过于臃肿?是否字段表意不清晰或各处不一致?

测试同学多想想,我 TM 怎么这么苦逼?

运维同学多想想,我 TM 还没说话呢,你们也好意思吐槽?

哎,古人云,我住长江头,君住长江尾,滚滚长江都是水,理解万岁吧。

欢迎关注作者的微信公众号哟:

相关阅读
推荐文章
猜你喜欢
附近的人在看
推荐阅读
拓展阅读
  • 大家都在看
  • 小编推荐
  • 猜你喜欢
  • 最新平面设计理论学习
    热门平面设计理论学习
    平面设计子分类