这期我来给大家说说「设计中」的工作流程和方法。话不多说，上图~
「设计中」的三个环节：
交互方案设计、设计评审、技术评审。
之所以把设计评审和技术评审也算进来，因为评审也是完善设计方案的重要环节。
1、交互方案设计
什么是交互方案设计？
我理解的交互方案设计不是照搬竞品UI，或者按照PRD中描述的内容做单纯的信息展示，而是要收集有价值信息然后进行思考和决策，最终转化成能创造用户价值的最高投入产出比的解决方案。 一个完整而合理的交互方案通常具备哪些特征？我总结了以下几个方面：
满足核心用户故事，具备所有MVP功能
明确不同场景和状态下的UI样式，配有详细而条理清晰的交互说明
设计决策基于前期的调研、测试获得的有价值信息，而不是基于设计者的凭空猜想、主观判断
遵循现有的设计系统和设计语言
具备技术可行性
能在规定时间节点内完成，并有较高的投入产出比
（欢迎大家补充更多~）
在进行交互方案设计的时候，思考的重要性远远高于画图。前期的需求调研、竞品分析等过程，已经是思考的开始；后期的画图阶段，只是把前期思考的结果进行可视化呈现。注意呈现的过程要符合现有的设计语言。有时间的话，建议在方案完成后进行可用性测试，进一步确认是否符合用户预期。
B端和C端有什么不同？
（1）设计方法不同
B端和C端大部分的设计方法是相通的，但也有些不太一样的地方：
C端通常以目标为导向进行设计，从一个目标拆解到可能提升目标的所有场景，再到具体功能和页面，设计师由点及面发散开来，从全链路寻找设计发力点。其设计重点放在引导方式、交互细节、视觉样式等方面。
比如一个C端金融类产品，目标是引导用户发生投资转化，那么我们可以梳理用户从接触产品到离开产品，整个过程中有哪些场景可能发生投资转化。每种场景下，如何引导和刺激用户才能让其更容易发生转化。这就是由一个目标发散到多种场景，场景挖掘得越多，提升目标的可能性越大。
B端大多从解决用户实际问题出发，功能范围和需求边界更加明确，设计更聚焦。比如用户需要一个定时发送日报周报的功能，你只需要围绕这个功能进行设计就可以了。
B端更注重组件化设计思维，通过原子组件来搭建功能模块，这样不仅能提升设计效率，降低开发成本，还能保证产品体验的一致性。对于产品还不成熟的公司，在组件库上的创新能带来的收益微乎其微，B端设计师可以把更多精力放在提升整体体验，关注流程上的、全局性的设计策略。
近年来很多B端产品越来越C化，那么C端的设计方法也可以灵活运用到B端。
（2）设计语言不同
C端设计重运营重体验，设计师可以加入更多的想法和创意，通过情感化设计、氛围感来感染用户，引导其发生转化，C端设计语言是感性而冲动的。B端大多为工具类产品，设计目标是提升效率，运营需求较弱，B端设计语言是理性而严谨的。
（3）B端的一些特点
B端服务的是企业，是组织，而不是独立的个体，因此设计时需要有更大而完整的思考框架，支撑更复杂的业务场景。
比如不同用户角色需求有哪些、痛点如何解决、角色之间如何协作；新功能涉及到的数据权限、功能权限、资源权限如何分配和管理；功能与功能、系统与系统之间是否有依赖关系；考虑客户的行业特征、企业差异化需求，方案能否覆盖各类客户的使用场景；明确产品价值和用户价值，哪些优先做哪些后做；考虑各种安全性问题和加载性能的问题……
我在做【图表的创建流程优化】时，将所有类型的图表整合到了一个页面来管理（之前是每类图表单独管理），从功能上方便用户对所有图表进行全局查找，从交互上缩短了图表创建路径，从数据层面更方便存储和管理数据，针对此方案我还做了可用性测试。
原以为大功告成，但实际评审时，却发现了以下问题：
GIO平台中不同类型图表权限是分开管理的，每个用户角色拥有不同权限，如果将所有类型的图表整合到一起，就需要针对每个角色的不同权限情况分别做处理，给予提示和限制；另外，所有图表放在一起管理，数据量级增大，查询性能也受到影响，数据加载慢对用户体验的损伤很大。经过和研发、产品同学讨论后，我对方案又做了一些调整和完善。由此可见B端设计师需要考虑得更多。
给B端设计师的建议
（1）搭建设计系统，熟悉组件规范
设计系统是一系列可重复使用的组件和它们的使用指导文档，使用这些组件能够快速地开发不同平台的产品。设计系统让设计能够扩大规模，提供一种设计标准供不同的设计师参考。如果公司有长期开发的产品和多个设计师，建议搭建一套自己的设计系统，解放设计生产力。当然搭建设计系统也有成本和弊端，可以根据自身情况来选择。
此外，熟悉组件规范是设计师的基本功，了解每个组件的状态及样式、适用场景、组件的可控参数，以便在设计方案时更灵活地应用，避免乱用组件，减少不符合规范的设计。
（2）及时和研发同步设计进展
多和研发同学同步和沟通设计进展，了解技术实现的边界，对于不可行的设计策略及时调整，降低设计返工的风险。
在【可视化图表优化】项目中，使用第三方图库开发比自行开发成本更低、性能更稳定，但可视化呈现效果也会受到图库能力的限制。
由于对图库底层能力不了解，我在设计过程中多次向研发同学请教。图表有哪些参数可以改，哪些样式可以自定义；哪类图表由图库实现，哪类图库无法支持；哪些功能做到图库里，哪些功能留到应用侧去写，这些细节都要做到心中有数，并在图表设计规范中去定义和约束。设计细节依赖于技术框架，缺少了技术的支撑，设计寸步难行。设计师多了解一些技术知识能事半功倍。
（3）多设计师协作时做好同步工作
不同设计师负责不同模块，但是模块间难免有重叠和相互依赖的部分，这时候做好同步工作，保证设计的一致性很有必要。
我负责分析模型的设计，KPI分析单独由另一个设计师负责。KPI分析也属于分析模型，与其他分析模型有重复的功能，我们在设计时却没有统一。这不仅增加了开发成本，还给用户带来了困惑。由此可见，同步工作多么重要。
2、设计评审
什么是设计评审？
我来介绍下我们团队的设计评审制度。
主设计师邀请组内同学参与评审，会上大家针对方案进行讨论，各自发表建议和反馈。意见分歧时，主设计师拥有最终决策权。 我很喜欢我们公司开放、包容的团队文化，鼓励每个设计师都发言，不用担心被嘲笑，大家会耐心倾听，尊重每个人的发言。Leader和组内成员拥有平等的发言权，谁有道理听谁的。
B端和C端有什么不同？
（1）评审流程不同
C端的评审流程比较简单，让设计Leader、产品经理过一遍方案，或者有经验的设计师自己来定就可以了。
相比之下，B端的评审流程更复杂，也更重要。设计评审是组内同学一起参与，一方面由于B端项目复杂，需要考虑的问题多，多个设计师能献智献策；另一方面，不同模块之间有依赖关系，功能重叠性高，设计师们也可以同步信息，保证设计的一致性。有必要的时候，还会邀请有经验的行业专家进行评审。
（2）评审侧重点不同
C端评审重点在于是否能助力产品达成目标，交互是否合理，能不能更优。B端评审重点在于能否实现用户价值，产品功能是否完整，组件是否符合规范。
给B端设计师的建议
（1）善于利用动态原型演示方案
设计方案很重要，讲解方案也很重要。评审时多利用动态原型来实操演示，让大家更清晰地理解设计细节，更直观地看到产品实现效果。
在设计看板共享功能时，三类角色会高频使用这个功能。基于这三种角色我建立了三个Persona（用户画像），通过讲故事的方式描述了每个角色的使用场景，分别演示了他们设置共享的操作流程。这个过程不仅展示了完整的交互细节，还把大家带入到用户故事中去，让大家更好地理解用户场景和产品价值。
（2）做好评审记录
设计评审不仅仅停留在口头，还应落实到文档。设计评审表就是一种比较好的记录方式。评审表中可以记录项目信息、设计目标和评审反馈，主设计师填写好项目信息和设计目标，参与评审的同学把问题记录到评审反馈，后期由主设计师进行回应和跟进。另外，Figma中的Comment评论功能也很好用哦。
（飞哥整理了一份好用的设计评审表模板，有需要的朋友可以私信~）
3、技术评审
什么是技术评审？
技术评审会上产品经理讲解PRD，设计师展示完整的设计方案，大家针对需求和方案的合理性展开讨论，设计师收集反馈重新调整方案。研发团队评估技术可行性和开发周期，并为下一步技术方案设计做准备。
技术评审产品经理、主设计师、研发团队都会参加，必要时还会邀请产研Leader、系统架构师等人员。
B端和C端有什么不同？
（1）B端更注重技术评审
C端技术对接，需要给研发同学讲清楚设计方案，一般来说竞品有的功能，技术基本上都能实现。B端就不同了，竞品能做的，自身的系统架构、底层技术框架不一定支持，因此受技术侧的限制更大一些。很多时候设计师不得不因为技术限制而妥协，通过设计方案的调整来解决技术上无法攻克的难题。
给B端设计师的建议
（1）多了解技术实现原理
在实际工作中，处理好和研发同学的关系，多请教多提问。积极参加公司的技术分享会、技术方案设计评审会，了解产品的技术实现原理。有时间也可以自己去学习前端后端知识。相信你在了解这些知识后，做设计会更有底气，方案评审也能更轻松“通关”。
（2）注意沟通方式，以理服人
以开放的心态来面对评审。不要害怕暴露问题，发现问题是好事，知道哪里不足才能进一步提升。如果方案被质疑，首先要保持情绪稳定，不要着急反驳，耐心听取对方的建议和反馈。如果不认可对方的观点，就摆出前期调研和测试的“证据”，给对方讲解设计演进的过程，平和友善的沟通态度和有理有据地回应，能让你更有说服力。
小结
从「设计中」的流程可以看出，设计的过程不仅由设计师一个人来完成，还要和其他不同专业领域的人一起交流、探讨、思维碰撞，合力打磨出一个最优的解决方案。好的设计师善于收集信息、协调沟通、权衡利弊，并最终将方案细节呈现出来。在产品研发过程中，设计师起着非常重要的作用。
