「解决问题」是很多人对设计的定义归纳，具体到产品/交互设计领域，深入理解业务并提出合适的解决方案也是一项很基础、重要的要求。但对于用户体验/交互设计师来说，「理解业务」和「解决问题」本身都并不足以构成核心竞争力，论理解业务，常常多线切换接需求的我们很难追上专注深耕某一业务线的运营和 PD 们；论解决问题，其实运营、PD 甚至开发都会有自己的想法，有时也能够解决问题，只是方式相对简单粗暴、思维不够细腻深入。交互设计并不只是针对某个具体业务去理解和提出解决方案就行了，作为交互设计师的我们，还应该思考得更深远一点，让自己体现出更多的价值。


求本：数据化设计与短视焦虑
在不少大公司里，数据化设计的概念备受追捧，各种 XX 率和 KPI 关系紧密，也是衡量设计师是否拿到结果的权威指标。但若盲目于追求数据指标本身的欣欣向荣、甚至为之不择手段，看似业务方和设计师都拿到了结果，解决了「提升 XX 率到 XX 百分比」的业务目标，却可能伤害到用户、引发更大的体验危机、损害更多商业利益。之前在知乎上看到过一个吐槽某打车软件客服体验的答案，提到超时自动断开人工客服、导致需要重新排队等待、重复输入内容的糟糕体验；但有人却觉得这是一个精妙的设计，因为它提高了投诉门槛、降低了客户的投诉率。从平台数据指标的角度来看确实是在朝业务期望的方向走，但我们要解决的问题是「降低客户投诉率」吗？合理安抚客户情绪、提升客户对平台的满意和忠诚度才是更本质的目标吧，掩耳盗铃式的数据导向设计看似解决了业务方的诉求，却在让我们和用户的距离渐行渐远。反思自己，也曾经在设计文档里把「设计目标」环节简单地写成「提升 XX 率到 XX 百分比」过，而没有更深入地思考和阐述背后的真实场景、问题本质，虽然最终解决了表象的业务诉求，但却可能只是治标不治本罢了。


匠心：把设计产出做出品牌感
在设计产出物的品质感上，交互设计师相比视觉设计师有吃亏的地方，Dribbble/Behance 等网站上也较少看到交互设计师的表现。但即使是重逻辑、流程的中间产出物，也同样应该追求专业极致的设计过程、产出和落地，把自己当成一个品牌一样去产出有美感的东西，这样能帮助我们在专业性上得到更多认可，有精美过程故事推导阐述的方案也更容易被接受。在需求的轮番轰炸下能保持精益求精的态度并不是很容易的事情，

延展：比业务方再多思考一步
被业务的短期目标牵着鼻子走是我们不愿看到的事情，那么在做设计满足业务方的基础需求时，就要更主动一点去思考用户完成这个基础场景后的下一步、再下一步应该是什么，思考解决方案的延展面。但在真实业务场景中，用户还会有下一步的线下推动工作，但产品里却没有提供触发的行动点。在团队里大家很鼓励「设计驱动业务」，但这是一件说起来容易做起来难的事情。但有时不得不承认这就是常态，「设计驱动业务」并不一定是说要完全由设计主导发起一个项目，这对经验和威信都欠缺的初级设计师来说尤为困难；而配合既有业务需求，做更多微创新的延展，结合设计师自己的思考落地成综合解决方案，相对来说要更容易落地和拿结果，也能帮设计师在更短期的时间内建立起成就感和自信。


思维：建立跨界通用思维框架
交互设计师对业务的理解很重要，但在持续深入理解业务之余，也要有意识地去建立独立于业务的通用跨界思维、框架和方法论，我们不能满足于逐一解决单一、孤立的业务问题。这一点是交互设计师区分于产品经理（业务经理）的地方，产品经理和业务的关系更紧密，细分出了商业产品经理、技术产品经理、数据产品经理等支线，有些产品经理甚至十年如一日地在某个细分业务领域耕耘，如果单拼对业务的理解能力，我们是很难拼过他们的，这或许也是有些人觉得交互设计师在产品经理面前有很强的可替代性的原因之一。在观察有总监、主管级设计师参加的评审时，会发现他们对于各类业务背景下的设计方案，都能基于手下设计师阐述的背景信息快速理解和给出建议，不存在对业务接触了解不够就不知道发什么言好的情况。高级交互设计师无论被扔去接触怎样的业务，都能以一个较快的速度去沟通、理解、适应业务背景和推动设计工作执行，在设计咨询公司里这一点更为突出。交互设计师应该学会在项目历练中建立起一套属于自己、不断迭代完善的通用设计思维、框架和方法论，换一个业务线也可以复用，与此同时，锻炼快速学习理解事物的能力也很重要。相比深入理解业务，这对于交互设计师来说才是更重要的价值体现。交互设计应该有更强的通用和跨界能力，一个交互设计师深入理解某一业务是好事，但如果只有在这个业务领域才能发挥，那并不是一个合格的交互设计师。

本文由职坐标整理并发布，了解更多内容，请关注职坐标设计创作交互设计频道！