Replies: 1 comment
-
|
提到的点比较多，我尽可能地按照我的理解做下解答吧，如果有遗漏可以再探讨。
Design2Code 的最终产物形式是 Code，它的目标用户不是设计师，也不是产品经理。主要还是面向开发者的 。 关于 D2C 的定位以及适用场景，在这个分享 我们其实已经做过说明了，如果感兴趣可以花时间看一下～。它的定位就是：前端工程师的辅助工具。目标是为了加快前端工程师对照设计稿还原 UI 工作，降低人工写 Render Template 的成本。它的目标从来就不是一步到位，直接从设计稿到一个可部署的产物。
这个每个团队的情况不同，更取决于产品阶段、人力资源情况各种因素，我个人觉得不好一概而论。 事实是，在偏 Sass 类/偏B端的重度应用里，体验/设计质感一直都是很重要的一个指标，Slack，Notion，Figma……非常多 Sass App都依靠优秀的用户体验来推动增长，为重要的 B 端应用平台配备专业的设计资源，在商业公司里是很常见的选择。只是对于内/外部产品而言，侧重点会有所不同。产品体验的好与坏，其实会直接影响用户是否继续使用，B 端产品的体验设计不是可有可无的，不应该否定设计师在里面的作用。 对外部商用的产品，灵活的风格化需求是刚需。例如在 Semi 系的应用场景里，抖音创作平台、剪映、抖音直播、抖音客服…每个不同的业务线，他们都会根据自己的业务特点，选择自己的设计语言表达，这是产品定位决定的，作为一个对外的产品，建立设计风格就如同拥有自己独特的“DNA”，产品风格越明显，客户就越能记住你的品牌。一个样式走天下是行不通的 对内部产品，更看重的是满足开发效率的同时，保证产品体验下限。减少用户的认知负担，使体验更具可预测性，当内部系统的终端用户越来越多，达到数千数万人级别时，其实它已经不仅仅是一个内部工具了，它的产品的体验设计也变得愈发重要，将相同领域的平台以统一的主题设计规范聚合，用户感知到同一主题的同时，能隐型感知到这些平台间的内部联系，同样的表达保证的是同样的操作流程与体验基线 在我们内部，通过 DSM 定制，将 Semi UI -> XX Ui 的情况非常普遍，中大型业务线都有特定的 brand style。一个基座项目/模块，配置不同的主题包后，配合微前端，用于接入不同平台，甚至成熟后，从内部平台转为外部商用售卖，都是非常常见的需求。这也是我们花了非常大的力气，去做了 DSM 设计系统定制，在 Figma 端和 Web 端都做了相应流程覆盖的原因。
Semi 面向中后台（Semi 的主要应用场景），我们姑且称为 B 端场景，（同比的话，类似营销、h5活动这种偏视觉轻交互的场景，我们称为 C端场景）。toB的 D2C 之所以比 toC 难做，是因为对代码的可维护性要求更高。C 端页面可能是周抛、月抛、季抛型的，而B端系统往往生命周期都是以年为单位的。
产品经理的工具主场本身就不是 Figma，程序员也不是。但设计师是，我们所做的一切工作，都是希望通过自动化工具，在不改变角色的原有使用习惯的前提下去提升效率。所以这里关于产品经理用这个工具怎么怎么样的推测，其实前提是不太对的，目标用户找错了 很多疑惑感觉看上去是由于我们面临的困境不同。 但如果你的业务场景里可能不存在设计师这一环节或者参与很少，那么对你的作用肯定不如预期的大，D2C 很可能不是你的 best choice，可能仅需要使用基础 UI库 就能满足了 |
Beta Was this translation helpful? Give feedback.
-
对于设计转码我还是有些疑惑
首先，第一个是关于使用者，设计师？产品经理？
如果是设计师，第一个问题是，B端产品真的还需要设计师吗？大部分就是原型堆砌组件，90%在基础组件能不能实现就可以，大部分场景下毫无问题。而对于剩下10%需要设计的场景，也完全用不了组件库
这也是第二个问题，针对需要设计师的场景，组件库能满足吗？比如app或者h5活动页，90%是素材堆砌，只有少部分才是表单和组件。那么这时候组件库的转码真的作用就不大了
而针对设计师的转码，这条路要有成效就真的很遥远了，100%得需要AI。但这个好像和组件库就没关系了
第三个问题，如果是产品经理用，说实话用设计工具做原型问题也很多，比如交互和逻辑很难表现。当然现实情况实际上是用设计工具不如图形拼的快，比如我们直接用飞书文档的画图就能解决了，之前还得figma然后插入再编辑效率并不高
当然，第三个问题不重要，因为不涉及转码
第四个问题，程序员拿到的码真的能用吗？我们分两种，第一种是素材(用不了组件)设计稿那有用但距离真正实现应该还很久，第二种是组件原型稿，这个你说复杂吗，大部分情况下复制1分钟，改起来10分钟，可能还不如手写的效率高，因为手写的有逻辑连贯性。要真正有用又得上低代码的模式，但是低代码的模式现在也是很不成熟
然后我觉得现在可以快速有成效的做法，比如就是针对b端场景
第一个基础组件库，没问题已经有了
第二个业务组件库，这个我看也有了，就是模板。不过这个因为是设计转码，所以走的是先设计再转码
但对于业务组件来说其实更重要的是『逻辑』，比如支付弹窗的栗子
在设计上其实很简单，但实现上还是需要大量沟通，比如如何切换按钮、折叠、支付方式互斥...，换句话说大部分业务组件更适合设计->开发->分享。还是得这个顺序。当然我也看到了『标记』的功能，但是效率可能有限。
还有一些是简单的布局模板，这个的话，问题在于一般人不会用来纯拼，而是更希望直接用整套后台模板(就是各种什么pro版本)
所以这一块，可能先用最原始的方式处理，就是设计->开发->发布包->使用
第三个针对产品经理，没有转码需求，但有替代设计师的需求
前面说了，b端再加个设计师意义真不大，但产品经理要会设计也很扯，而不会设计呢，前端同学不仅不知道到底要实现成什么样，甚至会放飞自我。
而如果能让产品经理先拼出想要的原型再交付那就比较合理。当然，前面也说了，这个可以用figma先做然后嵌入。这个可以但现在用起来还不是很顺畅
一方面就是小公司很难翻墙也很很难付费用figma, 一方面学figma有点麻烦
解决办法很简单，就是用国内复制品代替figma，比如即时设计，不过飞书不支持嵌入... 这个希望有人可以搞一下
后续想到在补充
Beta Was this translation helpful? Give feedback.
All reactions