作者：臭脸任。作者授权早读课发表，转载请联系作者。
微信公众号：臭脸任的慢生活（ID:choulianren-renyi）
欢迎投稿到早读课，投稿邮箱：mm@zaodula.com
问题起源于臭脸君开始转战给iPhone做交互。从云音乐团队的节奏来说，我们会将最新的需求以移动优先、其他逐步跟进的方式展开工作。以往负责PC，当需求延伸到这个平台时，多半处于功能已验证、技术已跑通的状态。跟开发的沟通多是在讨论平台设计，并未有机会触及到他们用代码编制的世界。
接手iPhone的两个多月来，前后大大小小已经历了4个版本。在一次次洗礼后让我对工作的专业性有了进一步的思考。所以今儿个旧话重提，跟大家分享一下进阶版的心得。
我是主题分界线
“陪产婆”指的是（交互稿产出后）开发实现环节中，交互人员在产品从无到有整个过程中所担任的角色。我将这个环节简称为“开发跟进”。
很多团队把交互职责仅定位于交互稿产出，完成后便丢给PM执行余下的任务。在我看来只会画图的交互不是好设计，合格的设计师不但要能作出好的方案，还要为其保驾护航使之成功落地。前者和后者分别体现了专业能力和综合素质，二者共同组成所谓的专业度。
为什么说开发跟进很重要
1：如果不能做到一稿胜千言，就不要指望开发人员对着交互稿就能完成一切工作。为保证方案可以顺利执行，需要不断地确认和验证。
2：人无完人，即使是已经确定的交互稿也难免存在纰漏，甚至有时还会涉及到需求变更。
3：职业壁垒造成交互阶段产出的方案可能过于“理想化”，等到了真正技术实现环节才发现需要修改或补充。
4：为保证开发效率，遇到问题时需要有一个人第一时间回应解决。
为什么说开发跟进对个人提升有很好的帮助
1：做交互的过程是跟自己的逻辑作斗争，开发跟进是跟一群人的逻辑作斗争。交互稿的每一位评阅者都会从自己的角度去理解验收你的产出，是不是真金就看你能不能被炼出来了。
2：画图只代表出活能力，开发跟进将全方位解锁你的技能。多线程配合、沟通表达、协商决断、应急抗压，每一个姿势都是需要锻炼技能。
3：除了对自己的产出负责外，还要对其他人负责。要有主人翁意识，以协调好视觉、开发、测试为目标，万事都要多问问自己怎样才能做到让各方更好工作。
4：画交互是经验的输出，开发跟进是能力的增长。开发环节会让你走入另一个世界，那里充斥着日常鲜少听到见到的知识，让没有技术背景的你在短期内紧凑地了解代码实现逻辑，让设计做的更加有理有据。
5：充分感受合作带来的喜悦和快感。
时间就是金钱，对于互联网公司更是如此。开发总量不变的情况下，减少时长就是提升效率的有效方式。下面来说说我的一些小方法，如何在力所能及的范围内为技术人员争取更多的时间，减少不必要的时间浪费。
ps方法来源于同事建议以及自己的经验总结
技术人员会根据收到的任务单（ticket）然后去交互稿上找对应的页面来执行工作，这样就存在任务与交互稿相脱离的问题。收到的任务会有集中的列表，但在交互稿上相应的页面可能是离散的，这中间就存在了“找”的成本。
发现这个问题后，我会将已做好的交互地址补充到对应的ticket后，这样看到需求便可以直接打开交互页面。
简单功能，直接放上交互稿的截图。（要注意的是如果修改了交互稿，截图不要忘了一并更新哦）
在交互稿的每一页加一个Title，附上对应的需求链接，让二者无缝连接。
开发跟进过程也是交互稿不断完善修改的过程，对于看的人来说面对几十页交互稿第一反应就是“改了哪里？”、“是否与我相关？”、“与上一次有何不同？”。方法是：
在左侧数轴上标明[新增]或是[修改]，让观者先快速定位到目标页面。
在页面上不要直接更换掉要改的内容，而是在原有方案的基础上用红色明确标注最新方案的修改方法。一页交互稿内容说多不多、说少不少，但如果不加任何标注的情况下，想让观者在茫茫文字和线条之间一眼就看出你改了什么，还真是有点难为人。
在交互稿上专门建一个页面放置[修订记录]，以天为单位将所有的修改顺次汇总在这里。方便大家查看的同时也给方案迭代留下可寻的依据。
通常只有交互会去详细阅读策划的需求文档或ticket任务单，技术人员和视觉设计会将交互稿作为终极对照物。因此遇到不涉及交互的视觉需求就很容易出现设计遗漏，等到技术人员要稿子时候才豁然发现。这个时候再去匆匆补稿从质量和时间上都会有影响。
无论过失出在哪一方，如果能想出办法避免这个问题才是关键。既然大家都习惯以交互稿作为对照物，我就在每个版本的交互稿中专门整理一个页面，用来放不涉及交互的视觉修改功能。有效起到提醒视觉设计师，避免发生丢稿现象。
可以说交互稿写的再详细都不为过，因为懒省事或者没想到带来的细节说明缺失，都会造成技术开发时需要来再次确认进而补稿的问题。
“没想到”这个是专业能力问题，必须通过不断提升个人让逻辑尽可能缜密无缝。粗心懒省事就是专业素质问题了，既然想到了就应该极尽可能的阐述清楚每一个细节，如果文字太晦涩也可以通过别的方式来描述自己的想法，比如给视觉贴几张参考图、给技术做个小动画。
当交互有了明确的修改方案后先口头通知开发，然后再将具体方案稿补好。这样做的目的是，你不知道开发是否正在做、正在思考你打算修改的部分，越晚告知就越有可能出现刚开发完就又要修改的问题。尤其是涉及逻辑较多的功能，越早通知技术人员越可以有效避免上述情况，也可以在沟通中进一步验证新方案的可靠性。
等到技术老大把任务单（ticket）分配到人以后，便可以留意一下每个功能对应的技术人员。相应功能有变更时除了在群组里通知大家外再单独告知一遍对应的开发。不要怕麻烦，一定要确保最新消息能顺利传达无遗漏。
作为一个没有技术背景的设计师，我曾一度很讨厌开技术来跟我讨论实现上的问题，一心想着‘我不懂技术我只管设计，只要不涉及方案有问题就跟我没啥关系’。
其实想一下，我能接受确定的交互因为视觉效果不好看而推回来改方案，那么为什么不能去尝试性地理解一下开发人员呢？虽说好的技术应该什么都能做，但也存在性价比这个问题。如果A、B两个方案无更好一说时，根据技术人员的反馈来做选择岂不是更好。
ALL~如何才能真正成为一名“好”交互，是我一直在努力探索的事情。职场不只教会我们做事更教会我们做人，去做一个有用的社会人。在新环境、新团队的磨合过程是技能解锁的开始，当你感觉到“不舒服”存在时，说明你已经开始为“更好”在思考。
版权声明：早读课文章均来自作者投稿或者授权文章，部分文章为转载均尽量注明作者和来源，文章版权归作者所有，若涉及版权问题，请添加momo微信：qqj5211314，感谢。
原创文章，作者：Tinadmin，如若转载，请注明出处：https://www.iamue.com/32912/
