◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。
实际工作中,各种各样的页面需求也接踵而来,不论每种需求承载的底层逻辑是复杂还是简单,都逃不了【需求设计–>交互设计–>视觉设计–>开发–>测试–>上线–>数据提取–>数据分析】这个完整的链路。
那么,在资源有限的前提下,就衍生出了页面快速搭建的需求
,以解决交互设计、开发、测试、数据提取与分析等多个环境的资源消耗。
接下来,开始产品的设计前准备
。
可以看到,在体量足够大的情况下,这件事是有价值的。
接下来
我们拿出市面上的各种页面进行调研,会发现,基本上一个页面的构成,无外乎以下几种米素:
如果大家拿出天猫、淘宝、京东、豆瓣、蚂蚁的页面出来调研一下,会发现,不同业务属性的页面搭建,风格是完全不同的。从框架搭建和产品设计阶段开始,就需要确认工具主要服务于哪些业务场景,并针对性地进行设计。
基于SKU的电商业务场景页面搭建,是相对标准化的。商品作为页面的核心米素,页面的布局会对商品的属性产生较强的依赖,比如:
页面需要进行分层级设计,第一层级,用于设计具体正常排序的模块;第二层级,用于设计特殊布局的模块,在第一层级之上。可以理解为,两个模块垂直叠加。这点很重要
。
然后,我们要做模块的抽象,核心是可以通过各种模块的堆叠,完成一个页面的搭建。有两种产品设计的方向:第一种,设计纯粹抽象的模块;第二种,设计相对具象的模块。
如何理解纯粹抽象的模块呢?
即可以任意设置内容的不同样式,然后根据不同的布局米素属性,不同导航米素容器,进行组合。这是纯抽象的,扩展性非常强,但是学习成本较高。这个留个悬念,大家可以选思考下。
我们用相对具象的模块来进行设计,这种方式,会更加容易理解。
包含的模块为:Banner、IMG、Hot Pot、商品、各类导航、宫格等。
针对模块细节,颗粒度定义,功能设计,就不展开描述了,我们就整体产品规划
从能力上,不同公司的业务场景下,对模块的抽象程度不同,抽象出来的模块也可能包含部分业务含义,拿在做的结构及模块输出举例,对内的产品模型如下:
对外的商业模式及产品模型,这边简单描述下:
其中,每一个节点均很考验产品设计能力,底层模块对应的数据结构及图形化配置界面(落数据)、以json文件的形式生成还是接口提供(性能和能力考量)、前端获取json后解析的方式、渲染能力、CDN、多场景支持等等。不一一展开来讲了。
最后再提一下,作为工具类产品,不可避免地会面临诸多业务需求,千万不能通过简单的线性叠加需求来进行需求设计,否则几个版本下来,产品会不堪重负,并且失去灵活性和扩展性。在进行业务需求沟通和需求拆解的过程中,要注重需求的抽象,尽量减少与业务系统的耦合,
保持产品的独立性
。
独立性、易用性、稳定性、灵活性、可扩展、可追溯,是工具类产品的核心。
如果有一天,作为工具类的设计者,有一天看到用户(运营或其他)通过自己的产品,搭建出的页面非常华丽,不看配置或者代码都不知道是使用什么模块组合而来的,这种成就感,是无价之宝。
要做好一个完整的产品,需要在细节把控到位,针对性的有如下tips:
◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。