深度长文｜如何输出一份让团队满意的交互设计交付物
|
7. 在合理、不违反基本的用户习惯的地方，可以考虑微交互层面的小创新，增加品牌辨识度。交互模式逐渐沉淀成一些通用的规范对这个行业来说是好事也是坏事，好的方面是体验糟糕的产品会越来越少，只要遵循逐渐成型的通用规范就可以相对容易地做到不犯错，但坏的方面是业务类似的产品在交互也趋同的情况下，显得更加没有辨识度了，这就对交互设计师的创新意识提出了更高的要求。同时，对经验足够丰富的交互设计师而言，如果在设计过程中对产品业务层面的创新点有了一些灵感，也可以及时地与PM讨论。 8. 能预估技术成本和风险，详见5.3节。 9. 在把方案提交审查前，进行一次全面的自查，能避免很多审查中被challenge到哑口无言的尴尬场面。 5.3 方案的风险预估 只会画线框图、给PM搬砖的交互很难称得上是优秀的交互设计师，随着经验的成长，对方案风险的预估是很重要的一项能力。其中包括上游产品层面的业务风险和下游开发层面的技术风险。将对风险的预估体现在线框图的具体方案考量和准确的交互说明中，将很大程度上提高团队对你的方案的认可度。 5.3.1 业务风险的预估 对业务模块之间耦合度高的大型B端产品，一个模块的方案有不合理之处时，往往会牵一发而动全身地影响其他模块正常的业务逻辑。单纯为了一个模块的用户体验考虑，很容易导致其他业务流程的复杂度呈几何级数地增加。 举个例子： 在一个项目的巡检模块（巡检简单说就是沿线检查某种设施）中，如果允许用户自行选择签到点的话，无论是签到点的指定错误、遗漏还是延迟，都会导致整个工单的记录出现非常多种异常状况，使得巡检记录的准确性大打折扣，而这恰恰是这一模块存在的意义，也就是模块的业务目标。 所以，最终取消了任何由用户自行选择路线和签到点的功能，前端只记录路径、所有判断由后台完成，大大简化了逻辑和用例的数量，并最终提高了巡检记录的准确性。 再举个简单的例子： 这个例子在另一篇文章《B端产品的角色与场景分析：以会议申请功能的设计为例》中详细讲过，这里简单提一下。 某办公管理系统APP的会议申请模块中，最终的设计方案中，已申请的会议（室）不允许修改任何信息，如果一定要修改必须取消后再重新申请。这样可以通过牺牲一定用户体验（便捷地修改申请单），更好地有助于达到产品的短期目标（提高用户申请会议的决策成本）和长期目标（教育员工养成对自己的会议申请负责的习惯）。 那篇文章中也提到过一个问题： 交互设计师到底是应该优先站在用户体验角度考虑问题、把业务风险交由PM判断，还是应该替PM将产品目标和业务风险的问题考虑进自己提出的方案内？ 其实说到底，就是业务风险是否要由交互设计师预估的问题。最近请教过Saga前辈和尤文文前辈。他们比较一致地认为后者更有利于团队效率和个人成长。从团队效率上来讲，交互设计师进行风险预判可以减少方案提出后的撕逼和返工。 从个人成长上讲，避免被“纯粹的交互设计师”这个立场框住自己，学着既能做具体方案、又会替PM从产品目标和商业角度通盘考虑业务风险，这样的设计师是很容易成长为leader的，这也是我在后面工作中的努力方向：） 5.3.2 技术风险的预估 在学有余力的条件下，交互设计师拥有一些基本的CSS、JS功底是很好的一件事，虽然不一定自己去写，但知道自己提出的哪些交互需求容易做、哪些很难做甚至做不了，可以一方面为团队提前预估技术成本和可能存在的问题。 另一方面也帮助设计师对前端同学“这个做不了”、“这个太花时间”的答复心里更有数：是真的做不了，还是他只是想早点下班呢。 在出于技术成本的考虑做出设计方案的妥协时，可以写在交互说明中。 一方面帮助大家理解你的苦衷； 另一方，比较nice的前端同学在评审时看到这些备注时，如果他有能力做到更好的方案，或许会主动告诉你他可以实现呢~ 如果没有代码方面的基础，也可以通过不断与开发同学协商可行性，或者从每次评审中逐渐积累”哪些能做哪些不能做“的概念，来帮助自己的方案减少技术方面的撕逼。 当然，对于这个问题，Saga前辈的建议是，交互可以把上游（产品）的问题在做方案时就考虑进自己的方案，而对下游（开发）的问题，不要过早地妥协。先按最有利于用户体验的方案提出，再交由开发自己去判断实现的可行性。所以实际工作中视自己和开发同学的默契程度，是自行预估、交由开发判断、还是不断保持协商，选择适合自己团队的方式才是最好的。 动效设计大概是最典型的一类容易牵扯到技术风险的问题。包括我在内的很多交互设计师都是动效控，在符合用户心智模型的基础上，带给用户惊喜的微交互能一两拨千金地提升用户对产品的好感度。 例如，还是刚才说的巡检功能的例子： 巡检模块是项目的核心模块，本质上有点类似运动APP的计步模块，相比其他页面单调的表单和列表操作，是一个比较容易通过动效进行情感化设计、让产品的精致程度上一个档次的地方。因此在做方案时，在一些记录状态的切换、地图/表单页的转场切换中，曾经构思过不少动效。 但在方案提交前的自查中，我自己去了解了一下通过animation和canvas实现这些动效的难度系数，发现如果让开发同学自己造轮子的话开发成本会相当高，看似简单的动效在需要考虑H5页面的多机型适配时，调试难度相当大。我也在Codepen和一些成套的第三方动效库里找过有没有合适的轮子可用，但效果不尽理想。 因此最终至少在一期阶段我放弃了这些有趣的动效，先让开发同学在有限的时间内集中精力保证功能的实现，后续在有余力的情况下再进行动效上的完善。 再举个和开发保持沟通，及时调整方案的例子： （编辑：源码网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
