查看: 58|回复: 0

    设计师一小步,程序员一大步

    [复制链接]

    该用户从未签到

    6

    主题

    0

    帖子

    30

    积分

    实习版主

    Rank: 7Rank: 7Rank: 7

    积分
    30
    发表于 2017-12-18 14:41:12 | 显示全部楼层 |阅读模式
    今天我们聊聊那些年的“小改动”,以及上下游协作之间的微妙关系。


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


    1,改改文字颜色而已;
    2,换个图标而已啦;
    3,只是一些小改动;
    4,很简单的啦~


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


    1,这里也要改?
    2,这里要可运营?
    3,这个布局完全变了啊!
    4,人与人之间的信任都哪去了?


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


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


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


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


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


    bJm4vOZ19ciMBnBp.jpg



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


    。。。


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


    dx61xtBE11169861.jpg



    上一篇:微信小程序模板商城开放后,开发者如何跟上节奏?
    下一篇:微信开放小程序公测做好这4件事抢占先机
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    QQ|Archiver|手机版|小黑屋|好站群 ( 苏ICP备15018248号-1

    GMT+8, 2018-5-22 21:43 , Processed in 0.064903 second(s), 43 queries .

    Powered by Discuz! X3.2

    © 2001-2013 Comsenz Inc.

    快速回复 返回顶部 返回列表