最近做了不少设计评论相关的功能，图书详情页评论，书评区，书评广场，书单评论，名家评论等等，牵一发而动全身。尤其是中途请了个长假，是的该优化的图书优化了，该上线的也上线了，但是，当初你提的那些优化点，开发一句做不了，产品就妥协了，对无关流程呀。好，达成协议，上线后看反馈，上线后看效果。。这些常挂在嘴边的借口说服了他们。此刻强烈的使命感油然而生：为用户体验负责是交互最基本的职责。然已有很多文章，大侠们从各个方面告诉我们该如何去设计一个体验好的产品。而我从设计以外，交互设计还会做哪些杂事，来确保产品的优质体验。
1）考虑现实因素，设计不要太理想化
设计时，一定要考虑所有的现实因素。比如我们的视觉设计师喜欢用出版类图书封面作为提案，在做毛玻璃效果时，同样采用偏文艺类的封面来做效果。而实际场景用户看到的是网文类图书。最终实现的效果它就不够英俊了。此时交互设计师要记得提醒设计师们。
2）认识自己平台的能力
对平台能力有一定的了解，比如互动站点一直以来加载就会慢很多，那在设计互动站点的时候，需要注意避免一次加载过多内容，多用分布加载，局部刷新，提早预加载，提早开始数据交互，等等这些加载的小细节先抛给开发，让开发提早评估提早预估；再比如咪咕阅读互动站点与图书站点的交互能力，评论（图书站点）中嵌入道具功能（互动站点），他们之间的交互事先没有预先抛出来，开发也就没有考虑进去，最后连流程都是走不通的。然这部分的能力是需要长期与开发磨合学习，慢慢积累才能提升的。一个建议：遇到开发做不了的问题，试着去了解为什么做不到，去刨根问底，再不懂自己去学习涉及到的内容。其他别无他法
3）跟进视觉
首先对接视觉时，交互有必要跟视觉设计师表达清楚项目背景，设计目标，用户背景等，如果是大项目这部分会要求视觉设计师提早参与，而小需求，可以通过交互来表达，最后是否达到效果交互要好好把控。
跟进视觉的过程其实很大一部分是对自己画的交互再验证的过程，不要简单对待。认真细致，不放过每个细节，跟着视觉稿来回反复多走几次流程，有时间可以做个demo。然自己却常常只是简单带过。到后面视觉很多状态会忽略，毕竟视觉设计师对业务的熟悉度有限。。另外对于好看不好，有意见提出来，由视觉设计师来定，术业有专攻，这样也便于更好的合作，互相提升。
最后交互呀 你也要有一定的审美，人家好看的你非要说不好看，那惨爆了
4）跟进开发是大头
前两天真的很生气，开发信誓旦旦的说我们从来不看交互稿，只看产品文档与视觉稿，那交互存在的意义何在呀，弱爆了。一些细小的微交互都由产品经理在产品文档中来传达，或者到后期的体验环节来补救，这样真的好吗？经过与前端头头的一番沟通，终于交互文档可以在整个流程转起来了。同时增加了交互参与技术需求评审环节。又给自己摊活了。。。
来说说体验吧 ，一般的流程我们都会去点点，有问题的话测试一般也都能测出来，交互主要还要关注1.加载速度，比如页面加载的速度有没有超过最大值，2.页面跳转过程是否顺畅是否合理：比如用户从列表进到详情页，再次出来有没有保留在进入后的页面，尤其是B测页面，通常会从新加载页面，所以页面会回到顶端；3.响应是否及时：用户触发一个触点，会有两处甚至三处应该有相关响应，是否都同时做出了响应；比如用户点赞后当时会有颜色 相关的反馈，因为只做了本地缓存，传到服务器的过程失败了，再次刷新后，这些数据又倒回来了；4.页面刷新效果，响应流畅度，异常情况（0 太少 太多 中途离开。。。）等微交互都是测试人员会忽略的点。
在开发过程中，我们会被告知什么效果实现不了，因为什么什么原因。这个时候一定要把持住底线，不能退让太多；比如之前在做阅历时涉及到一个曲线图，对于坐标轴的显示问题，开发只能按照平台输出的分段显示，而在用户侧不会关注到很细微的具体时间点，那我们希望坐标轴的显示跨度大一点，后来从我们的角度我们提出通过遮罩的方式，我们不希望显示的分段透明化 ；所以愉快的解决了所谓开发说做不到的问题。
今天就先写这些。后续再补充；打杂的过程虽然没有任何产出，却是保证产品有良好体验必不可少的环节。 恩，吭哧吭哧把腿跑。。。。。
网友评论