互联网瞬息万变,在产品不断更迭的过程中,我们经常说要保证产品设计的一致性和质量,提升产研链路的效率。
但现实情况是:产研团队长期面对的是产品越来越复杂,体量越来越大,一个个复杂的产品下包含N个业务线,N个业务团队,甚至还有外部合作的业务,每个迭代都要面对数以百计的功能上线,经常容易出现各种相同但不一致的功能,上线质量参差不齐,执行者也容易陷入日复一日的需求海洋而没有更多精力去挖掘更有价值的事情。
所以如何解决团队效率和产品质量问题?我们的解法是抽象体系化的解决方案:设计模式化和代码化,设计从原子到全局进行统一和优化,并形成系统化的设计指导,由开发进行模式代码化,提供灵活可配置的规则。以此,设计有更系统化的设计原则,整体的统一性和体验有保障,设计和开发周期也可以缩减,甚至大部分日常需求可直接由产品对接开发直接上线。
01 什么是系统化解决方案?
大多数日常需求大多是从单点出发,当点变多变复杂了,就容易出现上述说到的现状问题。
所以解决方案需要基于业务全盘进行设计抽象:从元素——组件——区块——页面——功能流程沉淀设计规则并代码化,来灵活提供拼装N个不同页面的机制,帮助团队更系统化的进行产品设计。从组成内容不难看出,解决方案是需要建立在基础组件基础上,与基础组件、复杂组件、行为模式共同组成设计系统的【功能模式】部分。
02 什么样的团队适合做
解决方案是一套相对稳定的设计机制,所以在产品初期或团队建立初期,产品可能经常会调整的情况下,并不适合做。
初期可以借助成熟的设计系统来减少投入成本。而到成长期可以根据业务的发展梳理基础元素、组件,选择性的建立部分稳定且利用率高的解决方案,并持续发展,保证解决方案可以起到指导和提效的作用。随着产品或团队逐渐成熟,解决方案也应该随着一起成长,相互影响相互作用。
03 如何输出、推进设计解决方案
1. 由大到小地进行信息拆解
- 对产品页面(尤其是重点功能)进行盘点,划分页面类型:比如列表、表单、详情、dashboard
- 对页面中的内容进行区块归类
- 对区块中的信息进行拆解
这三个过程下来,对于问题、规则、规律都会有一定的概念,以一个后台系统为例:
页面大类主要是:
- 列表
- 表单
- 详情
其中列表的内容大致区块分为:
- 页面标题区
- 列表操作
- 列表筛选
- 列表内容
到这个阶段已经可以发现,相同区块位置就存在不稳定,在后台系统中可能影响面不会非常大,但对于内容复杂繁多的工具或C端界面就会容易出现找不到的情况。
不同区块的内容拆解,同样也会发现一些细节问题,比如筛选的样式、规则不一致,列表操作的方式、位置、样式、交互不一致等等。
2. 抽象、重组:从布局—区块—组件—设计规则
从第一步全盘的信息拆解和归纳,已经发现问题,这一阶段主要2点:
思路类似于设计一个界面,首先得有一个布局划分,不同的区块要放哪些内容,再到区块里的细节内容规则,从而抽象出由布局到区块的设计规则和可复用的组件。
以前面说的列表为例:
1)区块主要是4类,明显的问题是区块位置不稳定,所以在布局结构上,需要定义1-2个稳定的可配置的布局框架来适应不同的内容。
2)不同区块梳理组成内容,内容细则。
3)标记出可组件化的内容及规则。
4)提炼整个过程中通用的设计规则,作为全局的指导。如:国际化、排版规则、超限规则、适配规则、文案规则等等。
5)通过布局——区块——组件——设计规则,可以灵活地进行页面拼搭。
3. 落地代码库
区分通用层和业务层,通用层落地到通用模板市场,利用脚手架生产新页面。业务层面的落地则是基于通用库封装具备业务属性(如:业务主题、业务数据、业务拓展方案)的业务库来生产新页面。
目前群核设计团队建立了一套平台通用的解决方案,适用于所有中后台产品。业务属性比较强的产品也基于通用解决方案封装业务层面的解决方案,同样的思路也应用在不同体系的工具场景中。整体实践下来,产研效率提升近50%,甚至完全解放了一条业务线的设计资源。产品体验的一致性、上线质量也有明显的提升。
04 解决方案的管理和发展
解决方案作为设计系统的一部分,与设计系统一同管理,业务设计师使用系统来输出,反馈问题或需求给系统,有系统设计师判断可行性,周期性的管理,及时更新并在内部互通,促进互相成长和发展。
解决方案与设计系统的发展有一点不同的是解决方案有更多业务化的内容,业务团队根据业务迭代维护解决方案。当业务的方案达到通用级别,则列入到通用库。
这些方法和思路也并不限制行业或产品类型,仅是在我们当前服务的产品体系下总结的方法。当然解决方案并不能解决所有问题,只是希望在提供更系统化的设计方法和模式的同时能减少重复工作提升效率,让产研团队有更多的精力和时间投入更有价值的事情。
给作者点赞,鼓励TA抓紧创作!
来源:http://www.woshipm.com/pd/5469983.html
本站部分图文来源于网络,如有侵权请联系删除。