当前位置:首页 >  国际设计 > 正文

前文我们提到了流程优化给我们的设计工作都带来了哪些直观影响;本文将深入细节从多角度去解析组件化的概念,帮助我们理解、构建组件库。


 

设计组件化的概念本身是从程序的开发模式中演变而来;开发中的工程化思维是不是也可以帮助我们高效的管理设计稿呢?产品的快速迭代中,原本固化的工作模式越来越不适应环境的变化;而研究各种工具、优化设计流程、开放设计思维可以让设计师有更多时间去优化体验、寻求设计价值。


 

关于组件化可以对团队产生多大的影响,可以去我的上篇《起点读书改版实战》查看,组件化管理对于设计师来说,迭代效率得到显著提升,设计团队能够主导产出的优化结果增多。


 

我们日常使用的 Sketch 之所以能成为目前最主流的产品设计工具之一,我个人认为在于它的每一次更新,都可以多多少少解决目前设计过程中的某些痛点,而科学的使用这些功能会将设计师的能力最大限度发挥出来。那么如何将项目组件化?本文将从起点读书的组件化案例中吸取核心内容与大家分享。


 

理解产品结构

业务属性的不同,对于产品整体布局的影响也存在差异,读书、社交、电商、新闻、视频等品类App都有自己独有的组件结构;而相同品类下的产品结构基本大同小异,以读书类产品为例,横向对比,大部分的阅读页、精选页、书详情页结构基本相似,唯一不同的是业务各有不同,模块位置等有所差异,但是从组件复用性上看都存在极大相似度。


 

并不是各类产品厂商不想做差异化,而是本身的业务属性对于大部分用户来说已经形成一条比较成熟的数据排版结构,较大的改变会招致用户的反感,虽然可博得部分用户的追捧,但这样的「创新」对于一个成熟产品而言却是不利的,因此我们往往会把更多的差异放在组件细节上;所以理解产品的结构可以帮助我们快速构建组件库的基本框架,在此框架基础上可以对组件大致做下分类和优先级排序。


 

组件归类

对自己负责的产品结构有所认知后,我们就需要对产品结构进行程度上的解构、分类;组件 (UI层面上的) 的归类通常分为四种:原生组件、扩展组件、自定义组件、封装组件。


 


 

原生组件,顾名思义就是系统本身自带的组件类型,例如按钮、导航、弹窗等等。

扩展组件,是基于原有组件基础,进行功能扩展,例如在导航栏上加下拉操作,在弹窗中加操作项等等。

自定义组件,所谓自定义组件就是原本系统中没有,我们根据产品特点创造出来的特有组件。

封装组件,是指对产品中经常出现的一系列场景页面进行组合封装的复杂组件。



这四个概念中,原生组件和扩展组件都属于系统(Android & iOS官方规范)导向的类型,所以我们暂且统称为基础组件;这类组件存在于大部分App中,例如导航栏、工具栏、弹窗、toast、按钮等就是基础组件。


 

自定义组件和封装组件,具有较强的产品功能导向,因此称为属性组件。这类组件跟产品功能有较强的关联性,比如效率管理App中常用的日历组件,视频App常用的播放器组件,读书App内的推书列表组件、金融App内的行情趋势组件等。


 

做这样的区分,可以让我们对组件有更加充分的理解,两个类别的组件在构建时也存在较大的差异,区别对待可以帮助我们更好的理解、构建和调用;有了明确的定义,我们在构建组件库时就能明确类型,合理规划,有效的进行搭建的前期工作。


 

颗粒化管理

与传统穷举法区别

穷举法顾名思义就是将产品中使用的所有组件全部列举出来,好处在于比较直观,没有复杂的组合逻辑、方便交接,坏处是比较难以管理、拓展性小,文件冗余、牵一发动全身等。


 

颗粒化管理是将组件进行模块拆分再拆分,充分提高细小组件的的复用率;具体是就是将组件先拆分为具有复用性的模块,进一步再对复用性的模块进行模块拆分,以此类推,通常拆分到图标、文字等单一元素时已经是最小颗粒了;如果需要调整其中某一模块时,只需进行独立调整,就可让全局随之响应,而其他模块不会受其影响。这种管理方式的优点诸多不一一赘述,缺点在于这样的组件拥有一定的复杂度,理解需要花费一点精力。


 

最新图文

相关文章

图1
图3

热门排行