## disclaimer 我一直嫌弃在非toC的专业向软件产品里，产品经理画线框图，再交给设计team画图的模式。但是我无法提出更合理的模式。在 AIGC 爆发之后，我似乎看到了新的可能，但是不够确定。直到我看到有国内外企业的近似案例，我打算还是写一下。不过时间太短，这些企业的尝试目前还不能说成功或失败。 但是，在打草稿一样乱写的时候，我发现我在混杂着多个细分行业里的情况，导致了论证不清。但是如果不混杂多个细分行业地写的，是明显不够全面地。也就是说，我目前暂时下这样的结论： （1）在IT行业的某些公司里，其实是可以适当地对产品经理、UI设计师等设计性质团队进行合并同类项的。就看决策者的决心和劳动者的能力。 （2）但不同类型的企业，因为目标用户或客户的差异，which is can’t be changed，必须保留不少单纯从产品设计角度看“非有益”但是在项目总体看“非有害”的职能。 ## 不成功的正文 软件行业的产品设计的“模”基本都是由产品经理设计的，交互UIUX等设计师会在PRD里的线稿的基础上绘图、美化、制作交互和动效等。 ### 历史上的分工的延续 这样的分工，如果追一下历史，是能理解的。在 figma 等可协作的交互工具出现之前，photoshop 等美术专业工具和 Axure 等产品设计工具之间是有大山阻隔的。现在，在一些领域，一些环节上，我认为交互设计师等设计师应该把产品设计师一大部分工作合并走。 ### 分工后新问题 我对工业设计不够了解，工业设计里应该也有类似的工作划分。设计师可能绘制了原型图，然后和工程研发团体开样、测试。设计图纸如果粗暴分为工程图纸和其它偏美术类的图纸，那么显然设计师是需要自己盯着工程图纸的，偏美术类的图纸被“外包”给其它团队或者外部团队的可能性更大。大型工程，如建筑业，对设计图纸的要求显然高于当前“作坊式”的IT软件行业。得了吧，很多“大型”IT项目的设计图纸可能也就和一个别墅装修项目的量差不多。更有可能，这样的图纸都不存在。 换句话说，绝大部分软件产品的设计环节里，是有一些冗余的人员设置的，而这种冗余居然是有害的冗余。产品经理花时间绘制的UI线稿，是不可能带着成熟的设计师的经验的。UX团体从产品手里拿到了被产品经理处理过的二次需求，在用户体验上开始带着镣铐跳舞。只需要使用美观的 UI 实现 PRD 里的简单的逻辑，且确保在人机工程上不出一些可笑的低级错误（也就是不会被领导和用户嘲笑的哪些），即可完成工作。 It works fine for most of the time. 两三年后，再来看这样的产品，看似井然有序，实则功能堆砌。远看功能丰富，近看一片乱，overrall 的用户体验（即用户单一或综合目标的实现能力）上可以说是“草色遥看近却无”。小公司的产品，因为人少，团队研发速度慢，等多个原因，可能用户体验居然好过大肠出品。（大肠出品，我打错了，感觉可以不改）要是你公司刚好买了一个这样的软件，自求多福吧。说不定可以体验到包装精美但是杯子质量一碰就碎的购物体验。 当然，还是有不少优秀的作品的。我也相信有不少公司里有人设法解决过这个问题。但是，从结果看，还是有提升的空间。 ### 我的想法 我有一个想法，就是产品设计的工作，现在可以让负责用户体验的团队多多承担了。 用户体验型的设计团队，为什么一直无法在中小型企业里出现？正是因为他们在需求讨论上的话语权太低了，他们几乎不参与需求价值的评估，只是一个单纯的劳务型角色。一旦他们提出改正用户体验的想法，此时多少已经处于病入膏肓的时候，大修成本太大，manage team 肯定会以成本优先的方式对待，小修小补能上路不被继续骂就行。体验一般？“苦一苦用户，骂名产品经理来担”。反正你我都是在这公司工作几年而已，让老板和后面的人想办法吧。 如果用户体验型的设计师，能直接参与到和需求方的沟通上。同样一个功能，他们可能可以给出更多的设计方案，更重要的是，他们的潜意识可以综合所有的用户需求，提炼到更一手的经验，设计的方案也能在更高一层面上提升 overall 的用户体验。那些小痛小痒的问题，在设计阶段可能就被发现和处理了。 那么，需求的沟通，没了产品经理，会不会有问题呢？会！但是我们不是要消灭产品经理，而是让更靠近业务环节的产品经理不再负责细节上的功能设计，这样他们有更多的时间来“把握价值”，花更多时间去和一线的业务团队磨，更多时间直接去面对外部客户，直接负责项目管理，消除项目经理传声筒。 那么，项目经理消失了，和客户沟通的事情是不是会不够顺畅。我猜目前有一些项目经理也做一些商务的事情吧。如果业务侧的产品经理直接接过了项目管理的部分角色，那么对外沟通环节就少了一次信息损耗。 那么，设计团队没有产品经理那样对技术的了解，会不会造成和研发沟通的问题呢？这种问题在及格线达到的team里不应该存在！ 那么，当技术方案和需求目标之间存在 gap，会不会导致项目不成功呢？技术负责人应该是要评估需求可靠性和技术方案的可行性的吧。如果需求目标是极具业务价值和经济效益的，你是做还是不做？这是技术管理上的问题。我个人认为技术负责人是要参与需求价值评估的，不然一个高级技术经理，又不参与实际开发，又不参与新技术研发，难道做一个橡皮图章，循环式地开会汇报，一到具体问题，让下面给方案，不管好不好，先做了再说，做好了分钱，做砸了跑路？ 那么，设计师时间在沟通上多花了一些，会不会导致没时间做设计？我对具体的设计工作不是足够了解。我猜测如果有设计规范，有完整的设计组件库，有完整的设计流程，一个新需求，或者新功能，即在“边际”上的设计投入应该是不高的。也就是说，你的设计团队存在潮汐一样的空档！在最初的环节，他们要把几乎所有的大问题（规范、组件库、核心理念等）都设计好，后面稍微修改，在大版本的时候大迭代。在 AIGC 的时代里，素材的迭代速度可以提升，毕竟不少素材本身就是“日抛型”，70 分能用，就没必要做 80 分。把时间用在核心的事情上。