发布时间：2021-8-30 分类： 行业资讯
对于跨端产品，一些设计人员将专注于C端的设计，而B端的内容配置部分则更为轻蔑。当C-end用户看到凌乱的内容时，他认为这不是B端用户的底池。它只会使产品的设计不合理。作为一名跨产品设计师，它应该是一个完整的全链接体验。对...负责任。
对于许多内容产品，C端用户看到的相当一部分界面不是直接来自设计师，而是B端商家和运营商配置的结果，以及B端用户的内容配置不合理。规范性约束，指导和审查，如果它们可以自由发挥，C侧的最终渲染效果将完全无法控制，影响产品的整体视觉印象和体验。
我目前负责的业务在这方面存在严重问题。该业务的主要模式是商家和运营部门在B方面发布付费任务，C-end用户申请并完成任务以获得补偿。目前，服务的B端任务配置几乎没有任何限制。例如，在信息显示区域，B端用户随机找到第三方编辑器编写HTML内容然后将其抛入配置表单，并直接将其呈现给C.最终用户，所以各种奇怪出现了字体大小，颜色匹配，对齐等问题。除了C端的失控显示外，B端编辑的代码阈值（需要一定的HTML和JSON基础）以及将大量数据编辑到主题中的效率低下也是不友好的。 B端用户自己，影响了B端的未来。开放更多外部业务的可行性。
在这样一个问题的背景下，当我们重新设计B端的整体任务发布过程时，我们专注于优化任务配置的关键组件（包括信息显示和主题），基于组件化的设计思想，并完全走了通过。现有和潜在的业务用例，抽象可视组件/模块，可针对各种业务场景灵活组装和组装，并将最终映射限制为C端样式规范，以降低B端配置阈值和规范C端渲染效果的两个主要设计目标。由于存在许多业务场景和跨PC /移动平台，因此它们背后的逻辑也非常复杂。在调整业务场景时，必须考虑兼容性和技术可行性。该设计经历了一波碰撞，即将完成。以下是我在内容配置方案下在组件设计过程中遇到的挑战和注意事项的详细讨论。
完整的用例演练和分层抽象归纳
复杂多样的业务场景是组件设计面临的最大挑战之一。出于这个原因，我们花了一些时间在C方面体验各种类型的在线任务，收集用户反馈的屏幕截图等，并在前端和操作的帮助下进行整理。除了业务方面已经学习的扩展后计划之外，还开发了一个相对完整的用例列表，并包含了尚未开发的潜在新业务方案。此过程需要一定的时间，但这是预组件设计过程中非常必要的一步，它直接影响组件的覆盖范围和可扩展性。
在一定程度上收集业务用例后，内容维度从上到下汇总，抽象出各种显示/主题组件，以及不同组件的组成，样式和附加逻辑（有点类似于HTML，CSS和JS） 。关系），清楚地了解信息结构。
在根据B侧配置页面的布局框架整理出不同维度的内容级别之后，此过程从未聚焦的优先级（例如表单中的组合，样式和逻辑相关配置）进行配置步骤。项目，低频逻辑配置操作出现在预加重位置）变为自上而下层逐行（激活帧 - 添加组件 - 插入组件 - 更改样式 - 设置附加逻辑），关联信息配置的联动映射更清楚。
基于精梳组件样式类型和逻辑配置项，可以进一步定义映射到C端组件的可视和交互规范，并且B端用户只能基于规范的现有内容进行有限的选择（对于例如，定义某段文本属于“标题样式”或“体型”），不能自定义控件样式（如自由更改字体大小，颜色）等。
提高了大量数据的编辑效率
当我梳理前面的内容级别时，组件被分成常量（手动输入的数据）和变量（本地上传的数据），并且变量概念的引入与大规模的业务场景密切相关（1K +， 1W +）数据导入。 。
例如，如果B端用户希望通过任务收集1000个不同的语音读取数据文本，如果没有变量的概念（本地上传的数据），则意味着他需要手动选择或复制1000个文本 - 读取组件。每次更改时，只会大声朗读对象的一个字段。但是，如果您选择在本地导入1000个文本的表数据并将其命名为变量文本，则在编辑读取对象时插入名为text的变量，然后只需要编辑文本读取组件一次，系统将基于变量的值。该号码自动生成1000个任务并分发给C-end用户，大大提高了任务配置效率。
这里的挑战是如何使选择和插入变量的过程更直观和易于使用。在产品之前的配置过程中，通过让用户输入诸如$ content.image或{{text}}之类的字符串来实现变量插入。此过程具有一定的学习成本（为了区分常见的输入文本，字符）。字符串的格式通常需要设计得更复杂和特殊），对用户来说不够直观;市场上的其他竞争产品提供了一个下拉选择框供用户选择导入的变量名称，这需要用户记住导入它。什么是每个变量的具体值及其对应的值（变量的内容无法预览），并且它不能满足常量和变量的灵活组合的业务需求（例如插入字段“品牌名称：阿迪达斯” ，品牌名称不变，阿迪达斯是变量。）。
我们的最终解决方案是在编辑文本或其他多媒体内容时提供插入变量的条目，单击以显示导入变量的列表，预览变量的第一个值的内容，并插入带有标签的变量一串。它在编辑区域中的显示方式，您可以进一步配置样式和其他逻辑。此过程完全是可视化的，预先预览内容，并满足将手动输入的文本常量和插入的文本变量灵活组合到段落中的需要。
平衡B端/C端，PC /移动查看和读取编辑模式
为了进一步提高配置过程的直观性并降低B端用户学习配置的成本，我们介绍了设计配置表时所看到的概念，并探索了各种不同的设计模式。这里的主要挑战是多端，多平台平衡，考虑到B端配置的效率和C端的直观显示，以及一套适应PC /移动配置的解决方案任务。
第一个解决方案是类似于下图的预览视图+表单。它也是一种非常常见的移动组件配置界面设计模式。在编辑表单的过程中，考虑到编辑效率和直观性，可以实时预览组件在C侧的最终渲染效果。 。
第二种解决方案是集成编辑和预览功能，以与C侧显示相同的方式将组件拖放到预览视图中，并直接编辑当前视图中C端可见的组件字段，以及在C侧不能直接看到的一些配置（如果添加选项，包括变量插入等，则在侧栏中完成。方案2在直观性方面比方案1更有利，但样式配置是与逻辑配置和变量插入操作区分开（侧边栏不是全部低频操作），编辑效率较差。
解决方案1和选项2是设计的早期两个版本，但它们都有一个缺陷，即我们的产品C是跨平台的，任务的一部分是移动视图，而另一部分任务是到PC端，有些任务可以跨越两个平台。对于PC端任务的配置，方案1的解决方案不合适，需要重新设计设计。第二种方案还需要设计两个预览视图，开发人员不愿意做另一组PC端任务。配置计划，然后重新考虑新设计。
在第二种解决方案的基础上改进了最终的解决方案。实际上，在设计第二种解决方案时，我们陷入了一种思维陷阱，即直观地感受到组件在C端的影响。编辑后的视图需要与C端完全相同。实际上，只需要B端用户知道用户在C侧配置的内容的大致位置顺序。上面未配置文本内容。出现以下说明：“请阅读以下（实际上是上述）文字”足够;而C侧组件在PC /移动显示器中有不同的样式（例如标题左侧和中间，带点和按钮的选项），但结构顺序是相同的（例如选择组件是标题 - 描述 - 选项），你只需要在B侧设计一组具有相同结构顺序的表格，就可以映射到PC并同时移动。
设计方案2的第二个思路是将C侧的可见信息与不可见信息的配置完全分开，这样可以更好地让B端用户进入C侧视图来感受显示效果。内容由他自己配置。但是，B端用户的操作区域是分开的。如果操作区域是从B端用户的角度设计的，则根据高频操作/低频操作划分更合理。
意识到这一点，我们将一些C侧不可见但高频的配置项（例如插入数据）移动到页面中心的编辑视图区域，并在激活编辑视图时显示，焦点是隐;一些C侧可见但低频配置项（例如图像上载的数量限制描述）被移动到页面右侧的附加操作区域。编辑视图中仅显示高频关键信息，最终C端效果不同，但不会因为这些差异影响用户配置的过程和结果。并且如果用户想要在C端完全预览效果，那么提供额外的预览测试条目，除了样式之外还可以体验问题之间的跳转逻辑。为了平衡配置的效率和直观性，最终效果类似于下图（直接放设计草案不方便，找到问卷网络的类似截图）：
考虑兼容性
最后，我想提一下兼容性问题，因为之前内容显示区域完全未经组件化，并且HTML插入方法是由第三方编辑器编写的。在设计组件化解决方案时，我们还必须考虑与先前现有生产线的兼容性。在任务显示上，然后逐步完成迁移。
基于兼容性考虑，相对完整的组件化配置方案的第一个版本得到了改进，即选择了文本/图片/视频等组件然后进行组装，并引入了丰富的文本框（当然，可选的样式是严格的限制，不能随意调整字体大小等），插入组件在富文本框中受支持，而旧版本的任务通过富文本框代码模式兼容。
总结
对于跨端产品，一些设计人员将重点放在C端的设计上，而B端的内容配置部分则更加轻蔑，甚至让产品经理完成B端的设计。然而，尽管B侧的内容配置看起来不起眼并且用户量有时受限，但是不合理的配置直接影响C侧的许多页面的最终体验。我们不能指望所有B用户都像他们一样。具有某种美学和模糊的细节，或者依赖于非限制性的配置文档。当C-end用户看到凌乱的内容时，他认为这不是B端用户的底池。它只会使产品的设计不合理。作为一名跨产品设计师，它应该是一个完整的全链接体验。对...负责任。
本文由大家撰写，产品经理专栏作家@鸿影（微信公众号：红鹰设计思维书）原创发布。未经许可，禁止复制。
该地图来自Pexels，基于CC0协议
