在规模较大的互联网公司里，用户体验设计师通常同时从属于两类团队，纵向的专业 UED 团队和横向的包括运营、PD（此文都指代产品经理）、开发等职能在内的项目团队。在校招求职的过程中，我一度对专业的大型 UED 团队非常向往，觉得这样能在专业能力上得到最充分的学习和锻炼；但现在我觉得，一个靠谱的 UED 团队固然非常重要，也能让人成长很多，但好的项目团队带给新人的成长却其实一点都不输前者，尤其是从 0到 1 再从 1 到 10 保持稳定迭代、而非上线一个 App 不久就解散的那种产品项目团队。无论是运营、PD 还是开发，他们都有很多值得我们这些初级 UED 去学习的地方，这些素质可以帮我们打破纯设计师思维的局限性，从更多维的方向来分析思考，看待问题和设计提案能更深刻和触及本质，推动体验优化的落地也会更到位。
运营
1. 对业务与用户的了解
在我的感受中，运营更常接触到第一线的业务和用户，而他们对业务与用户的了解程度也非常深。对 PD/UED 确认的各种需求细节，他们能一一解答清楚完整的来龙去脉，并在产品设计方案初步成型后补充一些 PD/UED 考虑不到的用户场景和业务规则对设计方案的限制；对于一些 B 端产品，作为设计师接触和访谈真实用户的机会相对有限，而运营则和他们有更直接的接触和更频繁的沟通，能以较好的同理心感受到目标用户的使用场景和真实痛点，并将其描述还原出来。作为设计师的我们同时跟多个项目算是家常便饭，如果节奏稍微紧张一点，有时就会减少对于了解业务和用户的时间投入，急着开始想具体的解决方案，这样出来的设计，有时不但解决不了问题，还造成了更多的时间浪费。
2. 多角度分析数据本质
数据是指导产品设计迭代的重要一环，但是仅仅凭借一些表面数据的提升，并不能真正判断出设计方案的好坏。影响数据表现的因素有很多，在判断产品设计方案优化对数据提升的真实影响之前，需要先剔除到非设计因素的干扰；如果只看到短期数据涨了就归纳为设计改版的成功，一方面并不能真正令人信服，还有被数据蒙蔽导致产品设计方向误入歧途而不知返的风险。
而运营对影响数据的不同角度因素变化了解更清楚全面，能比我们更准确地分析出问题本质所在。数据下降了不一定能说明新的设计方案不好，也许是因为这段时间有偶然事件发生导致基数发生较大变化，导致整体数据被拉低；数据上升了也不一定是产品设计的功劳，也可能恰好是这段时间运营推广力度较大、竞争对手爆发公关危机等缘故。
3. 良好的文案功底
文案的好坏对用户体验其实也有着不小的影响，欠缺推敲的文案小则引发用户迷惑，大则让用户误解为是在挑衅嘲讽而发怒、甚至酿成公关事件。我自觉写作功能不算太差，但却会经常为界面上看似简单的文案而头疼，陷入啰嗦而又词不达意的困境；在这方面，运营通常能给出更准确、更简练、更好调动用户参与的文案，也是值得我们学习的地方。
PD
1. 讲故事说服他人
说来惭愧，我在本科课堂上就被教育过讲故事是设计师非常重要的一项能力，但在实践中却觉得自己这一点不如项目组的 PD 们太多。PD 们精于运用各种类比法，让听众可以快速通过一个现实中的熟悉事物来形成对陌生新业务的概念印象；会绘制包含各种角色、形象生动的业务流程图，从线上到线下的完整流程闭环清晰易读、代入方便；PD 们的表达能力、协调能力、面对质疑挑战的抗压能力，都是值得作为设计师的我学习的地方。
2. 决断与执行
设计师会为了一个像素的偏差、一个微交互细节的还原不到位而纠结上大半天，但紧张的项目周期却往往不允许我们在每一个细节都纠结到完美，而且其中一些纠结事后来看还基本可以说意义不大（比如相关模块很快就被迭代掉了）。
PD 会更有决断魄力，能更好把握住事情的优先级，及时终止设计师在一些性价比不高甚至无意义地方的过度「纠结」。在决策完成后，能坚定地推动其执行到底，面对阻力想尽办法软硬兼施，而不是轻易放弃。
不要让头衔束缚讨论
我在的项目组有一点很好，就是大家不会在讨论时拘泥在自己的头衔范围之内，也会思考和参与到其他职能范围之内的事情，PD 会思考运营方案线上化怎么做，设计会思考产品层面如何优化，开发会指出交互体验上存在的问题……大家各有各专业擅长的地方，但没有泾渭分明的感觉，不会因为觉得这一块是别人的事我就完全不管，也不会因别人「侵犯」自己的专业领域就轻易产生防御心理。Title is just a title，不要因为它限制了自己的视野与全局思考能力。
网友评论