设计体系构建法则 | 论B端产品的体系化构建(下)Homepage recommendation
338天前Publish
你的B端产品处于什么生命周期?在这个阶段产品要解决的问题是什么?而在产品发展的过程中,设计体系又应该如何构建?



导读


你的B端产品处于什么生命周期?在这个阶段产品要解决的问题是什么?而在产品发展的过程中,设计体系又应该如何构建?


本文将基于B端产品的发展阶段,带你详细了解设计体系的正确构建方式。



前言


对于产品体量较大、发展周期相对较长的B端产品来说,任何一个设计决策的沉没成本都是巨大的。


若在产品初期就过多制地定规范,就容易限制产品设计的创意性;而在产品框架成熟之后盲目地进行“创意”,则容易造成体验一致性的缺失,以及大量的重复开发工作。


在合适的阶段做正确的事情,能够极大降低产品的设计和开发成本,保证最高的投入产出比。


在产品的不同生命周期中,产品需要解决的问题、工作内容、建设方向是不同的,而对于设计的需求也会存在差异。因此,针对不同的阶段,需要制定不同的策略,才能让设计发挥最大的价值,并逐步构建完整的设计体系。


你的产品处于哪个阶段?在这个阶段中,设计师应该重点做哪些事情,才能逐步构建设计体系呢?




「新生期」确立风格,关注核心场景的最优体验

-


如果你的产品目前处于新生期,那么恭喜你~ 你将有机会从零开始构建一套完整的设计体系。


处于新生期的产品,首先要解决的两个核心问题是:用户是谁?需要解决什么问题?


产品的目标用户群,将决定你的产品风格;而用户需要解决的核心问题,便是产品的核心场景体验。因此,在产品设计上,也将围绕这两个重点来展开。



A.「 确立产品风格 感知性模型的初步构建


首先,我们要为产品创建产品主风格,并以此基础进行延展,构建初步的感知性模型。感知性模型是控制产品外观的一套设计规范,不仅包含产品风格,还包含以主风格为基础制定的组件视觉风格。


影响产品风格的因素很多,但其中最为核心的一定是“人”。


用户是那些人?(用户画像:如性别、用户年龄区间、工作、喜好等)将会决定产品的定位,进而决定产品的调性倾向。


竞品长什么样?我们还需要在前期进行充分的竞品调研,分析目前市场上的产品现状,在设计上保证产品的独特性,让用户能更好地记住产品。


需要注意的是,感知性模型的建立,通常与品牌特征具有强相关性。为了保证品牌调性的一致,设计师需要思考如何在产品中植入这个“感知点”,并恰当地出现在不同的体验场景中,加深用户对于“感知点”的印象。


比如在网易七鱼的所有设计中,为了使所有场景具有统一的品牌调性,在图形风格、配色、界面布局的设计上都采用了一致的延续性。


感知性模型的建立,其实与品牌DNA有异曲同工之妙。优秀而独特的产品风格,可以让用户拥有更好的记忆点和归属感,并成为用户传播的基础



B.「 关注产品的核心体验 


在新生期,产品的核心功能将会是最主要的竞争力。


这一阶段,设计师应该专注于核心功能,将核心场景体验做到最佳。用户使用产品时通常处于什么场景?如何让用户更好地解决问题?流程是否可以更精简?通过不断地思考、尝试、验证,找到最佳的产品设计方案。


而非核心场景的设计,因为业务还在不断发展中,将会伴随大量的试错和调整。所以只需制定基础性的规范即可,否则反而容易限制设计师的发挥,对效率的提升也不明显。


当然,在设计之前,进行广泛的竞品研究也是必要的。竞品是如何解决问题的?我们是否拥有更优的解决方案?我们可以将一些好的、更高效的设计方式结合到产品中。


什么时机进行竞品研究是最佳的?我建议设计师先经过完整的自主思考,并拥有自己的解决方案之后,再开始进行竞品的调研。这样有利于产出更具创意性的方案,而不仅仅只是“比竞品好的方案”。


需要说明的是,这里的体验指综合性的产品体验,包含了产品核心逻辑、交互方式与视觉设计,将会涉及到产品不同的职能。


产品流程决定了用户解决问题的路径。是否能够解决用户核心痛点?是否合理?是都具备通用性?这些都决定了产品未来的用户广度与销售范围;而产品交互则决定最合理的人机交互形式。如何更高效?如何使操作更方便?如何让新用户拥有更低的学习成本,等等……


这些工作虽然在视觉设计师工作的范畴以外,但对于产品至关重要。作为产品团队的重要成员,我建议设计师主动去学习并参与到这些环节。


在设计中主动思考,提出自己的看法与建议,这样才能真正的从根本上去提升产品的核心体验,增强产品的竞争力。




「成长期」通过组件库建立“引用”模式,构建团队协作模型

-


产品已经进入成长期,意味着产品的基础形态已经基本形成,并且有了清晰的迭代方向。


如果你的产品在这个时期,设计团队应该及早让产品的”生产流程“标准化。因为产品的页面、模块数量将会开始迅速增加,标准化越早,能够节约的成本也就越高。 


通过组件化建立“引用机制”,可以让产品拥有统一的“零件”标准。之后,再围绕“零件”标准,构建团队的协作模型,使整个产品的“生产线”更加标准化,从而提升产品的效率与品质。



A.「 启动产品组件化,建立“引用机制” 


进入成长期,在产品形态初步稳固之后,就可以开始启动产品组件化了。


组件化,就是将页面拆分成可复用的最小单元。如果将页面比喻成物质,那么组件就类似于“原子”,每个组件独立封装,又可以集中维护,以此来管理和维护整个页面。


组件本身又分为基础组件与复合组件,就像“原子”与“分子”的关系。基础组件可以作为一部分嵌套在复合组件中,这也可以保证复杂组件与基础组件之间的延续性和可控性


与设计规范不同的是,因为组件库包含了封装的前端代码,其统一性在执行上往往比设计规范要彻底得多。


而组件化更长远的价值,在于“引用”机制的建立,以及基于组件库进行的工作模式升级。引用模式可以使所有相同的组件都有共同的控制节点,使整个产品形成可控的逐级链路,对所有末端组件进行集中控制。


在封装的组件库中,我们还可以植入统一的API接口,使所有组件可以进行主题定义。比如整体的配色、圆角度数、间距、模式等等。这样,每个组件将会有非常多样化的配置方式,以此来适应不同场景、不同的风格


是不是很像前文中提到的自然构成算法?基础物质 X 随机变量 X 算法/秩序 = 可控的复杂系统。


任何一个新的产业进入成熟期以后,都会逐渐将某些环节进行标准化,以此来提升效率、降低成本。通过无数个标准化的结合,逐渐形成体系,最终影响整个行业,而数字产品的发展,也必然会经历这个阶段。


通过组件库,不仅可以保证每个组件样式、交互、反馈上的一致性,还能统一对组件进行优化和维护。极大地提升了产品的可控性,降低产品开发成本,也增强了产品的使用体验。


当然,在组件库的创建上有不同的选择,使用开源组件还是自行研发,需要企业根据自身情况计算投入产出比。自研组件库是一个庞大的工程,虽然成本较高,但对于组件的匹配性、易用性、稳定性等方面都会有较强的优势。对于体量较大的B端产品来说,通过组件库节约的开发成本,往往远大于开发成本,而这也是大企业选择自建组件库的重要原因。


从零到一进行组件库的创建,将会经历一个比较长的周期。常规的流程是:产品经理负责组件的定义,之后由交互设计进行单个组件的交互原型、交互规范的设计,在三方评审通过后才会进入视觉设计的阶段。


在组件的视觉设计中,不仅需要考虑单个组件的规范性,还需要考虑整个组件的数值一致性、代码的复用性、复合组件的嵌套关系,以及全局API植入等细节因素。关于组件库的从零到一创建,之后会有单独的文章进行概述。



B.「 团队协作模型的升级 


随着产品模块的逐渐增加,不同模块的产品经理、交互设计师、视觉设计师等也将快速增加。团队较小时,产品的一致性与统一性可以通过小范围沟通去解决,一旦团队规模扩大以后,这种模式便难以解决问题


一方面,组件本身的标准需要符合不同模块的需求。另一方面,不同模块的产品框架、规则需要有一个统一的标准,才能避免产品“混乱度”的不断增加。


因此,在产品的成长期,我们需要一个对组件标准、体验一致性进行管理的团队,可以暂且称之为——产品设计标准委员会


委员会可以是虚拟的项目组,也可以是一个群,在有需要的时候进行讨论,并进行文档的沉淀。当遇到有可能跨模块的内容,或者能够复用于其他模块的通用方案时,都要通过委员会进行评审。同时,委员会可以定期对产品内容进行排查,查看在产品中是否含有可统一、可标准化的内容。 


比如在七鱼工作台中,抽屉式内容是每个模块都会出现的。但是,因为不同模块是由不同产品经理负责,所以内容模块的标准就会存在差异,比如模块的布局、信息展示的排版、甚至ICON都不一致。


这就会造成两方面问题。一方面,用户在切换模块后,需要重新对信息格式进行适应,甚至无法关联相同的信息,导致学习成本增加。另一方面,当一个模块需要接入另一个模块的抽屉内容时,内容标准与样式的差异性,也为大大增加开发和维护成本


这种全局的统一设计标准,单独一个模块的设计师或者产品,都是很难推动的。必须拥有一个标准审核的机制,使不同模块的同类内容具有相同的设计标准,才能使产品在发展中始终保持有序发展,避免产品走向混乱,最终导致产品“失控”


团队协作模型的建立,将会逐渐沉淀出一系列的“跨模块设计标准”,而这些标准将会成为逐渐整合为“规范体系”,最终构建成为完整“模式语言”。



C.「 设计中台化 


在产品的成长期,随着设计团队的人数的增加,设计团队的中台化也是需要考虑的事情。特别是随着Figma以及其他云端协作软件的出现,也使团队设计文档管理与协作的方式更简单了。


对于设计团队来说,设计中台的建立主要有以下几个优势:


  • 标准文档管理:设计中台将会作为所有设计标准的来源,让所有设计师可以进行调用。比如组件库设计稿的存放与维护、ICON绘制规范、全局Banner规范、框架规范等。

  • 资源共享:将一些通用的、质量好的设计元素进行共享,提升利用率和统一性。

  • 项目协作:大型项目的多设计师协作

  • 资产沉淀:随着项目的进行,我们会积累大量的设计资源。设计中台不仅是设计稿的存放库,也可以将优质的设计资源进行分类,形成团队资产,方便设计师进行学习与调用。


设计中台的建立,能够引导标准的统一,降低团队的沟通和协作成本,是推动设计体系建设的重要因素。




「成熟期」构建模式语言,整合功能性模型+协作模型

-


在经历成熟的的快速扩张之后,产品形态将最终进入一个相对稳定的阶段。其模块数量、页面数量已经足够巨大,虽然可能还伴随着一些功能的增加或完善,但这座“大楼”已经基本成型了,“楼层”已经基本确定,剩下的可能是基于“楼层”建立更多的房间等等。


在这个阶段,设计团队需要将前期积累的“标准框架”构建为统一的功能性模型,并整合功能性模型(组件库)和协作模型,形成真正的设计体系。



A.「 逐步建立模式语言,构建产品搭建模型 


随着协作模型的建立,不同模块在进行设计时,都会进行标准的统一。在成熟期之前,因为产品形态还在扩张,这个标准都是比较零碎的。当产品进入成熟期后,设计团队就需要将这些零碎的规范进行梳理,形成规范体系


比如下图的产品构建框架规范,便是产品搭建的标准之一。比如一二级菜单的出现位置,页面中标题、操作区、列表应如何布局等等…


以及在具体的功能页面中,不同页面的细则规范、应用切换方式,页面的预加载样式如何统一等。 


最终,我们会将所有的全局规范、框架规范、信息架构,都整合为完整的模式语言(规范体系),以此来指导设计师/产品经理进行产品的统一设计。



B.「 功能性模型+模式语言 产品快速构建


完成模式语言(规范体系)的构建后,结合我们的功能性模型(组件库),就可以初步形成了产品的快速搭建能力——即一些常规的页面,产品经理可以在没有设计时参与的情况下,自主进行快速搭建。设计师只需要在搭建完成后,针对页面进行走查即可。


整个搭建过程类似于乐高积木,通过单个组件进行框架搭建,然后遵循页面的结构进行组件填充,之后形成产品的功能模块,再更进一步,将多个功能模块再搭建成业务系统。


通过“样式组件化”+“规范体系化”,再配合逐步完善的协作模型,整个产品团队最终将形成了完善的设计体系。


快速搭建体系的建立,可以创造更高效的资源分配模式


一方面,对于产品来说,这意味着大量的资源可以从简单、重复性高的工作中脱离出来。通过快速搭建体系,标准化和简单的设计任务就无需设计师参与,可由经过培训的产品经理直接进行搭建,而前端开发因为组件化与设计标准的统一,代码复用率也大大提升,节约了大量的开发资源。


另一方面,因为“生产原料”与“生产流程”的统一,使得产品的设计一致性得到极大的提升



C.「 提供高质量的用户体验 


在产品进入成熟期后,产品通常已经具备了庞大的用户量。而在B端产品竞争日趋激烈的今天,用户体验将会越来越成为产品的核心竞争力之一。因此,提供高质量的用户体验,将会成为非常有价值的事情。


特别是在产品快速发展的成长期,为了配合版本迭代,而忽略的大量体验问题,都要在这个阶段有针对性的进行解决。


而设计体系的建立,使得设计师拥有更多的时间专注于关键场景的体验升级


产品设计团队可以定期针对产品进行体验评估扫描目前产品出现的问题。确定列表后与各相关方确定优先级,之后根据优先级进行排期,并跟踪结果,最终验证体验问题的解决成果。


比如为了解决页面在加载中的卡顿问题,设计团队为七鱼的主要页面设计了一套页面预加载模式。提升页面流畅性,尽量减少用户等待中的焦虑感,也对模块的结构有一个预期。

undefined


为了解决不同屏幕的最佳适配问题,我们与前端开发一起设计了一套多段式自适应适配方案,让屏幕适配不那么生硬,同时提升屏幕的使用效率。

undefined


以及在网易七鱼的产品中,会伴随着大量的筛选任务,经常会占用巨大的屏幕空间。为了解决这个问题,设计团队打造了可收缩式的“自适应超级筛选”。使客服人员在保证精准筛选的前提下,最大限度地提升屏幕使用效率。

undefined


而在使用场景最多、占比最高的表单组件中,我们制定了层级式表单规则,根据不同类型的字段,赋予合适的宽度,最大化地提升了屏幕的使用效率

undefined


这些产品体验的优化任务,大多都由设计团队进行推动,取得了非常良好的效果。这使得我们的产品在大的维度拥有极高一致性的同时,在不同的场景也具备高品质的设计体验。




「生态扩张」基于设计体系,快速创建新产品

-


一套成熟的设计体系建立,意味着产品的“基础零件”和“生产流程”都已经成熟。这种模式一旦落地,企业不仅可以快速生产新的B端产品,还可以基于这个模型对老的B端产品进行改造,最终构建完整B端产品生态。



A.「 快速创造全新的产品 


通过分析B端产品的构建方式,我们可以发现:不同B端产品的构成方式是相同的,区别仅在于产品的风格(感知性模型)和模式语言(产品的框架规范)的差异。而产品的组件库、协作模型以及快速搭建流程,都是可以在不同的产品中进行复制粘贴的


因为组件API的存在,我们可以将同一个组件适配不同的产品风格,并且基于改造后的组件库,构建产品的整体框架规范。比如下图中的三个产品,虽然他们的风格不同,但都是使用FishDesign组件库进行API定义的。

undefined


同时,当协作模型在一个产品中运转成熟后,我们可以将这种协作方式快速复制到新的团队中。之后,随着新产品逐渐进入成长期,我们可以同样按照上文所讲的方式为产品构建整体的框架规范(模式语言),并应用相同的快速搭建系统等等。


我们可以发现,当拥有一套成熟的设计体系之后,构建一个新产品的成本将大大降低


基于这种模式,所有的组件仍然引用自同一个组件“源”,也就是说,企业仍旧可以通过组件库保证所有产品的可控性。我们仍旧只需要维护一个组件库即可,而这也将为企业节约大量的开发资源。



B.「 产品融合,打通企业服务全流程 


一个B端产品,通常是为了解决“某一类”问题而诞生的。而B端企业的最终目标,一定是为企业解决“一系列”的问题,甚至是“全流程”的问题。因此,在一个大型B端企业中,当所有的子产品都逐渐成熟以后,产品的整合通常会成为下一个目标。


在传统的B端企业中,产品整合通常会是一个非常大的问题。因为不同的产品可能采用不同的前端框架、不同的风格、不同的操作行为等等。可以说,产品整合的成本约等于重新开发一个产品。


但是,如果所有的产品都采用同一套设计体系,那么产品整合将会容易很多

undefined


因为所有产品都是基于同一套设计体系进行构建的,不同产品的区别仅在于框架规范(模式语言)以及核心场景操作方式的差异。所以,我们只需要对这些产品的整体框架规范进行统一,就能逐步打通不同产品

undefined


最终,通过产品设计体系+一致的产品框架规范,我们将几个不同的B端产品整合成了一个大型的B端平台。在这个平台中,原先所有子产品的能力都在其中,同时我们也可以将所有的能力在同一个平台中串联起来,形成完整的解决方案。


而对于我们服务的企业来说,我们不仅拥有众多可单独购买的“多样化服务”,也拥有一系列全流程的“大型服务能力”。我们既能解决小问题,也能解决大问题,产品的竞争力将会大大提升,我们所能服务的客服范围也将越来越大




「未来前瞻」B端产品设计的发展局势

-


随着B端产业的快速发展,在未来一定会出现更多的创新的设计趋势。在文章的最后,结合自己浅显的认知,跟大家来聊一聊未来的新趋势吧~



A.「 设计“算法”化,框架智能化 


即便是目前基于组件库的UI设计,产品模块的“拼装”上,更多的还是依靠个人感官,以及设计师的配合。虽然存在栅格系统,但显然在设计与前端层面并没有形成完整的融合。


因此,在未来的B端设计中,UI设计中部分“感知性”的模型,将会逐渐转化为“算法”


比如在所有的UI界面设计中,我们可以将4间距设定成一个代数值U(U=4px)。以此为基础,我们将模块内元素的间距设定为2U,模块间的间距设定为4U。通过这种方式,我们可以将所有的间距、层级以U进行表示。将所有的设计稿、前端开发都使用同一个代数U进行设定之后,所有UI的间距就实现了“代码化”。


以这种方式,全局的UI间距可以转化为“算法”,让机器自动生成间距。同时,当我们的界面在不同场景需要调整疏密感时,直接调整U的数值,配合栅格系统,就能实现全局等比调整



B.「 能力交叉,新型岗位诞生 


在职能的细分上,一个很明显的趋势是,不同职能的能力范围将逐渐蔓延。在成熟的产品中,不管是产品经理还是设计师,他们的能力都会越来越向两端扩展,并趋于融合。


比如产品经理更懂交互了,视觉设计师也更懂交互,并且一部分成为了体验设计师。这就导致部分交互设计岗位会减少,产品经理将会承担部分交互工作,而另一部分则由体验设计师完成。比如为了让产品还原度更高,一部分设计师将会开始研究前端代码,而一部分前端则会拥有更高的设计与审美素养。


因为各职能之间的“交叉面”增加了,所以产品的“下限”更高了,而产品的整体品质也得到了提升


而在设计软件未来的发展中,这个趋势也将得到加强。产品设计师(产品经理+体验设计师)将能够在软件上完成从产品策划-UI设计-Demo演示-开发对接的全流程


另一个趋势是新型岗位的诞生。随着B端产品的逐渐成熟,一些大型的、成熟产品将会对各方面提出更高的要求。而未来可能将会出现以下两种职位:


数字体验工程师:


在未来,越来越多的体验将在虚拟场景、或者虚拟现实场景进行。产品体验的提升很大程度上将会依赖技术与设计的结合。因此,在一些大型的互联网公司,很可能会出现同时精通产品体验与前端技术的“数字体验设计师”。


产品架构设计师:


在大型的B端产品中,各产品经理往往负责不同的业务线,专注于本模块的架构。而设计师虽然制定规范,却难以推行至产品框架层面。导致了产品的顶层框架-产品UI规范-产品前端框架,这三者通常是分离的状态,二者将带来非常巨大的弥合成本


产品架构设计师的出现,将会以 [产品+设计师+前端架构师] 的角色,统筹所有的产品线,制定 [产品-UI-前端] 一体式的整体架构,让整个产品的标准完美兼容所有的模块,使整体架构更精简、更可控



C.「 跨端模块化,兼容性框架,全平台融合 


随着移动互联网、物联网的加速,数字产品将会逐渐延伸至更多的场景。而多端的兼容性、一致性、成本也逐渐纳入到未来的思考之中


因此,跨端模块化、全平台融合将会是未来的趋势。随着Google的Flutter、华为的Harmony OS,都正朝着这个方向发展,而苹果也在尝试iOS、iPadOS、MacOS的三端融合。


很显然,对于产品体量巨大的B端产品来说,多端开发的成本是非常高昂的。而且,高昂成本带来的,却仍然是大量的体验不一致、版本难以管理等,而跨端的模块化,将是这一系列问题的答案。


比如网易会议在产品设计之初,移动端就直接采用了Flutter进行跨端开发,而桌面端(Windows、Mac端)则采用了兼容性框架。同时,为了使未来全端融合可以实现,我们对很多场景与组件都进行跨端的模块话设计,不管是设计稿还是前端数值,都实现了1:1的跨端统一。 


可以预见,在未来的系统架构中,一定会以跨端模代码统一、全平台融合作为目标,而产品的设计也会逐渐往这个趋势发展,带来更多的可能性。


最后,希望华为的Harmonys能够成为第一个真正意义上的全场景融合系统,也希望中国所有的科技公司一起加油~




「末」写在最后的序

-


各位读者好久不见~ 我还是那个爱写序的作者,为了看起来正经一些,我这次选择将序放在了后边。


相比上次发表,又经历了大半年。我的芬达还是只会握手,汽水配了两次种,都以暴打公猫而失败(配种费也退不回来了…)。疫情以后出国计划泡汤,终于在4月底去了一趟海边,这次带着女票和弟弟妹妹们,虽然很操心,但也非常欢乐,希望能够带给他们一个美好的回忆~


至于工作,这段时间的变化也挺大的,经历了公司内的组织变革、拆分,伴随着离别、重组、成长、新生。心态上确实又成长了许多,也看开了很多事情。没有任何事情是一成不变的,你的安全感来能力和内心的强大。只是做好随时应对变化的准备,才能坦然的活在暂时的稳定中。


从整个宇宙的尺度来看,变化是永恒的。所有的物质都处于大爆炸的余晖中不断膨胀,就连时间也是如此。


熵增是宇宙的基调,而生命以负熵为生。生命就是要在不断克服变化,在变化中寻找平衡。努力与舒适、工作与生活、做人与做事,任何事情都是相对的,平衡是事物长期发展的关键。


随着年纪的逐渐增长,好像突然能够读懂一些“老书”了。不管是孔孟老庄,还是伟人的《毛泽东选集》,对于自然、社会、人的认识反思,都比我们要深刻的多。智能并不等于智慧,抖音和头条看再多,都比不上认真完整的去读一本书。


孔子曰:“子温而厉,威而不猛,恭而安。”


王蒙老师对此的解释很通俗:做人时刻做到面面俱到,是不容易的。从长远看,也就是求几个方面的平衡、均衡。温和很好,失去了坚定性与原则性就不好了,所以还要补上厉。威严是必要的,太凶猛莽撞了就伤人害人,提醒您悠着点,别那么猛恐怕是必要的。恭敬小心,如果变得哆里哆嗦,进退失据,闹心乱意,当然也是走向了反面,您还得安详踏实些。这三条乃是做人的辩证法。


希望大家能在工作之余,多看一些好书,多一些学习成长。


感谢大家的观看,下次再见~



推荐阅读书籍/文章:

《智能商业》—— 曾鸣;《设计的思考》——周陟;《设计体系》—— [英] 阿拉·霍尔马托娃;《深奥的简洁》—— [英] 约翰·格里宾;《机械宇宙》—— [美] 爱德华·多尼克;《万物皆数》—— 米尔埃卡·洛奈;《产品从0到1的4个发展阶段》;《B端产品生命周期》;《复杂》——梅拉尼·米歇尔

原文链接:https://mp.weixin.qq.com/s/e6WXObaBaqJhNJwmcz0NCw
353
Statement: all the content and comments made by netizens in ZCOOL only represent themselves, and do not reflect any opinions and opinions of ZCOOL.
Report
Share
Collect
in to comment
Add emoji
喜欢TA的作品吗?喜欢就快来夸夸TA吧!
All Comments0
杭州 | UX设计师
Article information
文章标签
收录收藏夹
更多收录此文章的收藏夹