杭州设计师和开发怎么配合：滨江外包项目的6次踩坑记录

杭州滨江一家做SaaS考勤的公司，去年把APP界面外包给城西科技园的工作室。第一版交付后，开发小哥对着稿子骂了半天——标注用的是英寸，代码要的是像素。这一仗打得双方都累。说白了，配合差不是谁不行，是没把话说在同一个频道。

稿子交付前先对齐单位

麦芽海贸的iOS项目踩过同样的坑。设计师给的是750宽的设计稿，开发按375写，结果一半元素溢出。后来约定统一用375基准、@2x切图，返工从每次5天降到半天。别被忽悠了，以为给个图开发就能懂，差一像素都是事故。

切图命名也得讲规矩。未来科技城鹿岛出行早期图标叫图层12、组3，开发找图找疯。改成ic_home@2x、ic_back@3x后，联调效率高一倍。这事儿小，但能省下整周的扯皮。

交互说明别省

余杭一家医疗预约APP，设计师只画了静态页，没写弹窗怎么关、空状态显示啥。开发按自己理解写，验收时改了11处。补一份交互说明文档后，同类改动降到2处。踩过坑的人都知道，口头说的需求，上线就变样。

版本管理更要命。拱墅鹿野文化同时跑设计和开发，设计师改了按钮圆角没通知，开发用的还是老稿，上线出现两个版本的圆角。现在他们用蓝湖同步，每次改动自动留痕，冲突归零。

验收要一起看真机

下沙教培机构第一次验收只在电脑上看，真机上字体被系统放大，排版全乱。第二次拉上开发对着三台真机过，问题一次提清。杭州机型杂，真机过一遍比开十次会都管用。

需求变更走流程。滨江那家SaaS公司中途加了扫码登录，设计师口头答应，开发没收到通知，两边各做各的。后来定死变更必走文档，每周对齐一次，类似事故再没发生。配合的本质，是把默契写成规则。

排期也要咬合。未来科技城团队把设计交付拆成三批，开发并行写框架，整体工期从八周压到五周。别天真，等全部画完再开发，时间都耗在等待上。

文件组织也别乱。未来科技城那家SaaS公司收过一版源文件，所有页面平铺在一个画板，找一页要翻半天。后来约定按频道分页、命名带版本号，交接时间从一天压到两小时。配合的收尾一步，是让接手的人看得懂。