首页

量化设计价值(三) 如何创建体系化的监控系统

seo达人



随着用户体验设计的发展,我们已经过了仅依赖需求和直觉就可以完成产品设计决策的阶段了。数据对用户体验设计师的价值可以总结为两点:1. 数据可以在「产品设计决策阶段」提供了更多元的参考意见;2. 数据可以在「产品设计复盘阶段」提供更客观的评价标准。

 

数据使用的场景

无论所处哪一种设计阶段,总的来说设计师的数据需求主要可以分为两大类:

图片

 

1.探索事物间关系的“内因/外因”:

是什么东西影响了用户的购买决策 ?我的新版网站首页的改版是否为产品提升了注册的转化率 ?这类需求的本质是探究一种事物间的欢喜和因果性,常用「推论性统计」、「相关&非参数校验」进行分析。对于这类需求,往往会有专业的数据分析师,用户研究设计师,数据产品经理承接。

 

2.发现数据中的“模式/异常”:

在一天之中随着时间的变化,用户的访问量有什么规律 ?这类需求的本质是在对已经发生的事物规律做一种总结 ,使用的统计方法更多的是「描述性统计」。对于绝大多数设计师而言,能够做到发现数据中的 “模式/异常” 基本可以覆盖绝大多数日常工作的需求。

本文主要关注解决设计师的第二类使用场景——发现数据中的“模式/异常”。目前各大互联网企业内部都会提供自研或者第三方的BI工具,因此笔者建议设计师可以通过建立一个包含关键的体验指标的数据看板系统,对自己负责的业务进行系统的总结和复盘。

以我曾经的工作内容为例,我们的产品是服务商家进行“前后端对接生产”的订单审核系统。【效率】是制造业至关重要的关注面,在一个企业用户的付费决策中也起到了相当重要的分量,客户使用我们的工具进行订单审核和流转的效率是整个用户体验模型中的重要部分。

因此我们需要构建一系列合理的指标来判断订单系统的处理效率。除【效率】外,【用户行为】【用户特征】等都是设计师关系的信息。以【效率】为起点,最终我们构建了一个笼统的包含设计师所有要监测的信息看板系统

图片

 

关键概念

本质上互联网产品中的看板(kanban)与自然科学领域研究人员的用 R 或者 Seaborn绘制的精美图表没有本质上的区别,差异点可能在于看板更加关注时效性,同时更加具备可交互性。

随着仪表盘工具和各种BI软件产品在人群中的普及,人们对仪表盘,指标(Metric)和关键绩效指标(KPI)的组成有不同的理解。为了确保我们都说相同的语言,我将定义一组术语,这些术语将构成我们讨论的基础:

  • 度量(Measure):度量是一段数字上可量化的数据。销售额、利润、留存率,都是具体衡量的例子。
  • 维度(Dimension):维度表示给定指标的不同方面属性。例如,时间通常被用作分析不同度量的维度。其他一些常见的维度包括地区、产品、部门、细分市场等。
  • 层次结构(Hierarchy):维度可以进一步分解为层次结构。例如,时间维度还可以形成层次结构,例如 年>季度>月>日。
  • 粒度(Grain):层次结构中的每个级别都称为维度的粒度。例如,年 > 季度 > 月 > 日 ,中的“年”是一个特定的粒度。
  • 指标(Metric):指标是我们经常在仪表板中显示的数据类型,它表示一个度量Measure)的数据段与一个或多个特定维度(Dimension)和相关粒度(Grain)的关系。

图片

上图是在Tableau中一个标准的指标示例-“每周销售总额” 的构建方式。在这个指标中,我们需要量化的“”是美元——即总销售额,用来观察量化数据的“维度”— 即时间,而时间维度可以被进一步分解为“年>季度>周”的层级结构“每周销售总额”需要关联的维度中的特定“粒度 ——即周。

  • 看板(Cards or KanBan): 观察一个或多个指标(Metric)运行情况的图表
  • 仪表板(Dashboard): 仪表板是多个图形,图表,量表或其他直观表示的集合。多个看板可组成一个仪表板
  • 报告(Report): 报告可以是对应图表和其他可视化的表示,也可以是可能直接相关或不直接相关的大量图表和可视化。多个仪表盘可组成一个报告。

图片

“实时、受众群体、流量获取、行为……” 上图为Google Analytics 中提供的多种类型的数据分析报告,报告可以非常广泛地涵盖广泛的相关信息。每一种特定报告内包含了若干个回答特定问题的dashboard,一个dashboard内可以包含多个相互关联的指标的看板。

一个可分析、可追踪的数据系统中,最原子的构成单位理解成一个“看板”。如何从0-1构建一个客观有效的数据看板系统?我们可以类比【一个人学习做菜】的过程,做菜的过程可以总结为三个阶段:

  1. 学习菜谱&列一个采购清单
  2. 采购食材&烹饪食材
  3. 摆盘料理&品尝美食

对应到数据看板系统的创建,我们亦可以总结为三个阶段:

  1. 了解数据的特性、明确自己需要哪些数据
  2. 通过技术手段获取数据、将粗数据加工成意义明确的指标
  3. 将指标数据可视化,观察数据并尝试分析现象

图片

 

度量Measure & 维度Dimension

“ Data is more than numbers, and to visualize it, you must know what it represents. ”

数据不仅仅是数字,数字、数组、表格、都可以被称之为数据。要将数据形象化,你必须知道它代表什么。为了构建有效的效率指标,第一步是:明确为了解决当前的问题,要观察的【度量】是哪些,以及这些度量又需要从哪些【维度】进行观察。

 

了解数据类型

一个线上的项目每天都在收集成百上千种数据,怎样确定自己需要什么数据作为 度量(Measure)呢?首先值得注意的是,不是所有类型的数据都适合作为度量Measure)被加工成指标。
不同学科,不同课程,不同领域,对于数据类型的定义基本一样,但称呼并不完全一样。统计学中,数据类型分为四种:定类,定序,定距,和定比。这四种类型是从低到高的递进关系,高级的类型可以用低级类型的分析方法来分析,而反过来却不行。

图片

定性数据与定量数据

 

从宏观角度分析,数据类型分为 定性 和 定量 两种。一个通俗的例子,以自身为例:例如衣服的颜色,头发的类型和鼻子的形状这些标识标识的是定性数据;例如身高,体重,年龄和鞋子的尺码,这些可测量的是定量数据。

1.定量数据

定量数据是统计数据,通常具有自然结构性意味着它更加严格和明确,可再细分为连续/离散两种。此类数据使用数字和值进行测量,这使其更适合进行数据分析。可以通过以下方式获取定量数据:

  • 测量
  • 实验
  • 调查
  • 市场报告
  • ……

2.定性数据

定性数据是非统计数据,本质上通常是非结构化或半结构化的。定性数据可以用来问“为什么”的问题。它是调查性的,在进行进一步研究之前通常是开放性的。从定性研究中生成的数据用于理论化,解释,发展假设和初步理解。可以通过以下方法获取定性数据:

  • 文字和文件
  • 音频和视频记录
  • 图片和符号
  • 访谈笔录和焦点小组
  • ……

想要了解订单流转的效率是怎样,最简单的方法是通过和我们的客户进行面聊一下使用情况并记录一下反馈,但这样的产物并不方便进行统计分析和展示。尽管有一些对定性数据“结构化”的方法,比如对定类数据进行的非参数校验,但实施起来成本较高。定量数据因为本身结构化的特点更适合分析,因此在这里建议设计师在构建自己的dashboard系统时,需要跟踪分析的数据尽量选择定量数据

 

确定需要观察的度量&维度

明确需要观察的度量有哪些,首先需要从要解决的问题出发。但是没有一个整体的分析模型,往往会导致我们的分析遗漏很多信息和细节,导致数据分析师无法理解彼此的需求,最终导致最后产出的看板难产或答非所问:

使用的问题分析工具—— KPI wheel

在这里介绍一种名为KPI Wheel的简单工具,可用于收集将用于定义和可视化指标的前期必备信息。您可以将 KPI wheel 的图片打印在纸上,然后开始尝试依次思考这四个方面:

  1. “ 要解决的问题是什么”
  2. “谁在关心这个问题?”
  3. “我需要去哪里获取这些数据?”
  4. “为什么这个数据很重要?”

在解答的上述的几个问题的过程中随手记录:

(1)可能引发什么进一步的疑问

(2)使用此信息可以采取什么行动或决定。

不断的提出问题并进行进一步分析,这么做的目的是让用户不断分解问题,直到他们有足够的信息来采取行动或做出决定。经过几轮完整的分析后,用户就可以大致确定指标的「度量」和 所需要的「维度」。

图片

以我曾经的工作内容为例:我们的产品是服务商家进行“前后端对接生产”的订单审核系统,我们需要构建一系列合理的指标来判断订单系统的处理效率。以下是与产品经理讨论过程中的具体流程:

 

第一轮 KPI Wheel ——

1.Answer KPI Wheel:“ WHAT?WHO? WHERE? WHY? 

  • what:我们需要一种途径了解用户进行订单审核的效率如何

针对这个问题我们联想到:

1.想要了解订单处理效率,首先需要定义什么叫订单的效率;在行业中有一种叫做「订单生命周期」的专有名词来表示订单从创建到结束的时长,是一个可借鉴的概念

2.针对我们的业务,一个工单的生命周期经历了从创建-流转&审核-通过,一个工单从创建到通过所经历的时间是我们需要记录的【度量】

 

  • who:产品/运营/设计 三个业务方都关注订单的效率

针对这个问题我们联想到:

1.对于不同的角色,在检测数据的时候都关注哪些维度?

2.订单类型分审核单&生产单这两种,两种类型的订单,订单类型是一个必要维度

3.时间是上述三个相关方都需要关注的维度,一个订单在通过审核时的时间,是一种重要的分析维度;而“时间”维度,我们可以继续拆分为: 年-月-周-日 的层次结构

4.对于运营,了解不同行业的商家的订单效率对进行深入运营是必要的。而”行业”维度根据分类方式的不同,又可以归类为一级行业(软装设计/板式家具/…),二级行业(整木定制/办公家具定制/暖通/地板/瓷砖……)

4.对于产品,为了更好的维护客情,对于特定的大客户的数据需要重点关注。因此商家账号的ID,也是重要的分析维度。

 

  • where:我们需要的数据要在哪里获取?

针对这个问题我们联想到:

1.与一般的用户行为数据不同,订单的数据都储存在后台的操作日志中

2.需要的”行业”维度,可以复用其它团队已经制定好的标签

 

  • why:效率是企业的生命,制造业中存在各种效率指标,如“人效”/“屏效”等。糟糕的使用效率会造成我们的产品在根本上是不可接受的,因此效率指标非常重要

针对这个问题我们联想到:

1.通过【订单生命周期】统计的时间,可以在整体上评估订单系统的流转效率。但是仅仅依靠一个这样的指标,缺少一些更细致的视角。可以增加对方案(订单的载体)的停留时长的统计,来计算审核在整个生命周期中所耗时间的占比。

2.The Rising Questions & Action:“ 根据问题1的答案,这还会引发什么其他问题,或者您将采取什么行动?”

 

在回答上面的4W的过程中,会引发其它衍生问题,例如 “订单审核周期的时间的最小单位是什么?”  等等。针对上述的其中衍生问题,可以再进行一轮kpi wheel的自问自答。比较简单的衍生问题,不需要4个方面都进行问题分析。

 

最终 

在多次重复上述的两个过程后,最终我们确定了要在产品中量化哪些 度量(Measure),以及这些度量需要哪些分析维度,并将所有需要的度量和相关的维度都用表格的形式记录下来。

例如,‘订单从创建到最终通过的时长(h)’,是一个需要被量化的度量。它需要关联的维度(Dimension)有时间、商家ID、一级行业、二级行业。

图片

 

指标Metric

研究完成菜谱,记录采购清单后,接下来的带班过程就是准备食材并进行烹饪。当你已经明确了要观察的 度量(Measure)、和需要关联的维度(Dimension),下一步就是通过数据建设获取这些度量,然后将度量加工成指标。

 

建设埋点

获取度量的过程就是取数’的过程。想要创建看板,数据分析师需要通过各种方式获取一张包含所有你需要的信息的宽表。如何获得这张包含一切关键信息的表格?我们需要借助埋点获取数据。

所谓埋点就是在应用中特定的流程收集一些信息,用来跟踪应用使用的状况。您可以把用户在与您的网站或应用互动时触发交互行为理解为一个 “ 事件 ”,一个时间存在一个触发的条件,当达到这个触发条件后就会上传请求,请求中会携带需要的 “ 参数 ”。

例如“用户点击按钮将商品加购到购物车”这个行为,每次用户触发这个行为后都会发送一个请求,而这个请求中会记录:1.加购商品的金额/2.加购商品的类型/3.加购商品的商品ID…等信息。这些结构化的信息构成了我们需要的度量(Measure)与 维度(Dimension)。

在完成了最基础的埋点后,我们就获得了最基础的数据。

图片

 

如何建立有效指标建议

“指标”是量化衡量标准,未经加工的数据不具备可观察的价值。通过埋点,我们单纯只是得到了若干张包含所有用户信息的巨型表格,我们是分析不出什么有用信息的。为了更有效的去观察和分析作为度量Measure)的数据,就需要对埋点数据进行一定的加工,变得更加易于理解和表达。

当一个度量Measure)的数据段与一个或多个特定维度(Dimension)之间互相联系了起来,度量就成为了指标。例如,同样的一份关于【访问用户人数】这一度量,可以根据关联的时间维度的不同,创建 DUV 和 MUV 等多个不同的指标。

如何创建一个有效的指标,结合笔者的工作经验,下面给出三点建议:

 

(1)为一个指标设想一个高级概念:

  • 首先指标的名称需要客观,要让人乍一听就能大概会意,例如:「加购商品操作每日点击次数」。而如果您定义的是类似:“软件上手度”,这种概念比较晦涩、在业内又没有约定俗成的定义的指标,可能需要重新考虑概念是否恰当。
  • 每周访问站点的用户总数/ 每日访问站点的用户数/ 每日访问站点的新手用户数…,这些指标即相互独立,但反应的又是同一件事的客观熟悉的时候,我们可以把这些详细的指标统一用一个高级的指标概念来做一个归纳,例如“站点访问用户数”

图片

 

(2)检查并确定定义指标的细节:

  • 确定了指标的基础概念后,需要检查一遍指标的细节。
  • 例如,“订单生命周期”这个指标的定义中,生命周期是指一个订单从创建到最后通过审核耗时,而与其关联的维度有时间,订单类型等。需要强调的是,一个订单可能会存在:创建时间、通过时间,这两种不同的时间戳。而在“订单生命周期”这个指标我们需要关联的时间维度是【通过时间】。如果关联是【创建时间】,则会得到另外一种完全不同的生命周期计算方式。

图片

 

(3)将测量到的度量数据,通过计算总结为一个指标:

  • 通过埋点收集到的是大量的数据,是一个巨大的整体,而指标则是描述总体特性的参数。而把原始数据组织并总结成更易处理的形式的技术叫做描述性统计,一种最常见的方法是通过计算平均数的方法总结一组数据。
  • 这些描述总体特性的参数中又存在不同的用途,有的用来描述频数分布,有的用来描述集中趋势:平均数,众数、中位数,有的用来描述变异性:四分卫距、方差。我们需要根据自己的用途选择合适的统计方式来构建指标。

图片

 

根据统计方法的不同,常见的指标类型有以下几种,他们拥有不同的分布类型和方差的计算公式

  • 【 计数 Count 】
  • 【 概率 Probability 
  • 【 平均数 Average 】
  • 【 中位数(或其它位数)Percentile
  • 【 比率 Rate 】
  • 【 一般比例 Ratio 】

图片

 

可视化 Visualize

烹饪好食材之后,接下来的工作就是摆盘与上菜。优秀的摆盘可以让料理更加精致和高级,优秀的数据可视化可以帮助我们更好的观察与分析数据,反之糟糕的数据可视化可能会让我们丢失很多重要信息。

 

Why visual ?

为什么一定要使用看板(图表)来观察和分析数据?仅关注几个关键指标的数据是否就已经足够?

使用看板对指标进行观察和分析的意义在于:相比单纯的数字,图表可以携带更多的展示维度(大小、长度、颜色、面积…),能帮助我们多维度的观察数据、避免疏漏。

例如,安斯库姆四重奏(Anscombe’s quartet)是四组基本的统计特性一致的数据,但由它们绘制出的图表则截然不同。如果仅依靠基本的统计特性来观察数据,我们很容易忽略一些重要信息。

图片

 

选择合适的图表类型

BI工具中支持多种图表类型,比如展示浏览路径的“桑基图”、展示转化率的“漏斗图”,甘特图、散点图等。如何选择合适的图表来展示并分析你的数据可以参考下图:

图片

图表种类繁多,但只要掌握其中的一小部分就能满足绝大多数需求。对于大部分设计师,以下3种最基础的图表类型是最常用的:

  1. 条形图:是最常用的图表类型。条形图易于阅读,我们用眼睛比较条形图的末端,很容易快速得出结论:哪一类最大、哪一类最小以及类别之间的增减区别。
  2. 线图:最常用于绘制连续的数据。因为线连接了点,这就暗示了点与点之 间存在着离散数据(一系列数据分隔成不同的类别)间没有的联系。通常,连续性数据都以时间为单位:天、月、季度和年度。
  3. 饼图:在总量间各部分的占比时比较高效

最后,当我们创建了许多看板后如何进行归纳?我们可以将关注相同的问题的看板归纳在一起,就形成了一个关注同一类问题的Dashboard;对不同的 Dashboard 提取共性,将同一个业务的不同Dashboard组织起来,就形成了一个Report。一个Report内可以笼统的包含当前业务需要关注的所有信息。

图片

例如:【订单生命周期】关注的是企业的订单效率问题,但并不是唯一关注效率的指标。另外还有诸如:“审单员平均审核时长”这样的人效指标的看板,这些看板同样反馈的是订单的效率。我们将关注相同的问题的看板归纳在一起,就形成了一个Dashboard,Dashboard内的看板与指标都有关注同样的问题—效率。

除了效率,身为设计师的我们还需要关注很多其他的问题:比如使用的用户的特征、流量的来源、用户发起的行为等等,这些问题都可以拥有自己独立的Dashboard。最后这些Dashboard组织在一起,就成为了一个支持系统的观察分析当前业务的体验指标的完整报告。

 

观察与分析数据

“ 我们需要的不是数据 , 而是数据告诉我们的实事 ”。通过建立一个系统的监测体系的目的主要是为了从数据中探索:模式/ 异常。不管图表的形式是什么,我们都需要留心观察这两者。

 

1.何为「模式」:

模式即数据中的某项规律。比如机场每月的旅客人数,虽然随着时间推移变化不定,但是通过几年的数据对比,我们可能发现旅客人数存在着季节性或周期性的变化,某些月份的旅客数量一致偏低/某些月份则一直偏高。

图片

根据数据画像我们可得知某个产品的成熟期用户占绝对多数的现状,

了解了这个「模式」就可以更好的制定符合绝大多数用户心智的设计策略

 

2.何为「异常」:

异常即问题数据。异常数据并非是错误数据,也有可能是设备记录或人工录入数据时,出现的问题。我们通过异常异常分析,一方面可以分析异常原因;一方面可以发现现有系统的漏洞。

图片

苹果公司通过监控异常值、发现了位于深圳的AppleCare灰色产业,

进而改善了AppleCare的产品策略,避免了巨大的损失

最后在观察分析数据的过程中,有三个需要特别关注的数据的特性不要忘记:

  • (1) 数据具有可变性(VARIABILITY)

数据的可变性这一重要的特性让我们可以从数据中获取规律和关系。如果您构建的指标本身并不具备可变性了,那您很可能需要尝试其他指标进行跟踪和分析。

  • (2)数据具有不确定性(UNCERTAINTY )

很多数据都是只能提供一个估计而不是绝对准确的数量。例如:分析人员通常会通过样本的数据,进而对整体的数据分布进行进行猜测。

  • (3)数据需要联系上下文( CONTEXT )

数据分析离不开情境。我们知道,数据的产生必然是有其情境的,不过统计数据时,我们通常都要剥离情境;而当我们进一步分析数据时,又必须回到具体的情境中去。

例如:某个羽绒服经销商发现某一年冬季的销售额产生了明显的下降,这本应该是一个异常的信号,但我们不能简单粗暴的定义这是一个糟糕的数据。因为实际上,销售额下滑的哪一年是一个暖冬,且和同类的竞品相比自己的产品销售额下滑趋势的更低。结合情景分析数据,往往能得到意想不到的结论。

 

本文参考文献:

文章:Dashboard Design: Key Performance Indicators and Metrics —— Thomas Gonzalez文章:【统计学】区分定类、定序、定距、定比变量——YYIverson书籍:Tableau:数据可视化之极速BI —— 沈浩书籍:Which chart or graph is right for you?——Tableau图表白皮书

书籍:Data Points:Visualization That Means Something  —— Nathan Yau

书籍:Storytelling With Data —— Cole Nussbaumer Knaflic

 

原文链接:酷家乐用户体验设计(公众号)

作者:晓虎

转载请注明:学UI网》量化设计价值(三) 如何创建体系化的监控系统

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png



分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

详解|组件库可以替代 B 端设计师么?

seo达人


有很多同学跟我说,自从 Ant Design 的组件变得越来越完善,自己也越来越不知道 B 端设计师的工作意义和价值是什么了。其实除了 Ant Design,还有很多常见的、优秀的组件库,都为 B 端设计和开发的工作提供了便利。那么使用组件库真的可以替代 B 端设计师么?当然不能。B 端设计师有其存在的独特价值,本文就跟你聊聊组件和设计师之间的关系

 

图片

 

1 . 组件是「效率」工具

组件是工具,用来为设计师和开发提升工作效率。上文中所提到的 Ant Design 的初衷也并不是要做一款替代设计师的组件库,其根本目的之一也是提高整个团队的工作效率。使用组件可以从两个方面提效:

(1)工作内容上:可以将不必要的、重复性劳动的时间节省出来

(2)工作流程上:便于设计师与前端开发做交接和协作,节省沟通成本

 

2 . 组件是「质量」保障

使用组件,可以在一定程度上保证设计工作的质量。组件规范了前端和设计师的工作方法,建立相对底层的系统,设定了设计和开发的质量底线。

图片

基于组件规范,设计和开发的产品更容易具备:

(1)一致性:具备相对一致的表现样式,设计风格和交互体验上均可保持统一

(2)可用性:对于用户操作,可以保证最基本的可理解性和可操作性

(3)审美性:符合基本审美标准,虽不会很亮眼,但也不会很难看

 

3 . 设计师要「沉淀」业务组件

B 端设计师可以尝试沉淀有针对性的业务组件。很多业务领域有其独特性,比如金融类组件和政务类的产品页面列表内容就有很大区别。单一的元素组件在应用的过程中是可以被再次组合和沉淀的。

举个例子,我在做业务需求设计时,相比于 Ant Design,其实更常用的是 TechUI —— 它是建立在 Ant Design 基础上的、由我们蚂蚁的设计师通过对业务需求的提炼、组合和封装,做成的一套于蚂蚁自己的【业务组件】

二者的区别是:

  • Ant Design:是所有人的,是通用的,是单一的原子级别的(比如一个输入框)组件。
  • TechUI:是蚂蚁自己的,是私有的,是组合的区块级别的(比如一整个表单)组件,更具备蚂蚁集团自己的业务属性。

图片

针对你公司不同业务类型,沉淀出不同种类的区块级别的组件,这类组件使用起来也会更加得心应手、加倍提效。这也是 B 端设计师可以去学习和精进的一点。

 

4 . 设计师要「洞察」业务诉求

使用组件,可以让设计师把节约出来的时间和精力放到更多有价值的工作上去。作为 Ant Design 的设计师之一,坦白的说,即使你的设计稿全部使用了 Ant Design 的组件搭建,最终的页面效果也仍不完善,在用户体验上始终可以更进一步

B 端设计师应该更多去关注对用户需求和业务逻辑的深入挖掘,不仅仅是在界面细节的表现手法上下功夫,还要学会站在全局,用系统性思维看待每一个项目,为整个产品的系统流程做优化,做更全面的产品体验升级。

 

5 . 设计师要「放眼」B 端未来

随着技术的发展和迭代,B 端产品的发展也呈现出多元化趋势。我列举以下几个方面,用于思考和拓展设计师的边界:

(1)承载媒介:多端化设计需求增多

B 端产品的应用领域日渐广泛,各类终端设备普及,设计师需要更多的探索设备的应用场景。如点餐系统、收银系统、AR、VR 应用等等,最近鸿蒙系统中演示的多端联动,也可能是未来的趋势之一。

图片

 

(2)工作流程:中台策略 / 组件化设计

它是一种提效的工作方法。中台策略适用于公司层面,我们上文提到的组件化设计更适用于团队。

图片

 

(3)用户体验:重视用户个性化和体验

B 端设计越来越重视用户体验,提供个性化的配置方式,并考虑无障碍设计领域。很多 B 端的应用和业务也在逐步开放给 C 端。 例如企业微信在 2019 年打通了个人微信和企业微信的壁垒,钉钉从 2020 年也开始在 C 端发力。

图片

 

(4)视觉表现:数据可视化设计

需求多来源于政府、企业的定制化需求,更偏向于对数据呈现效果的打磨和优化,能够展示和分析数据中的关键内容,形式与内容需要高度一致,才会达到良好的展示效果。

图片

 

原文链接:长弓小子(公众号)

作者:元尧

转载请注明:学UI网》组件库可以替代 B 端设计师么?

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png



分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务



库存领域的业务——库存模块

雪涛

导语:近期公司需要把一个事业部的发货及库存相关业务实现线上化,在我们部门内部进行业务调研及充分讨论后,库存中心的产品规划方案基本确定,本文把我们实战过程中的方案分享给大家,期望能够为读者在设计库存模块时提供些许思路。


01 场景说明

XX事业部主要业务以化工贸易为主,在市场上对部分产品处于核心地位。XX事业部自己不进行产品生产,主要提供营销服务,仓库、物流均以整合社会资源为客户提供服务为主。整体的业务流程如下:

  1. 客户自己在平台下单,或业务员代客户下单,提交订单时需要判断发货仓是否有足够的货物发出。
  2. 内勤确认订单无误后,进行发货操作,业务要求后期需要进行自动发若客户有特殊需求则需要指定具体批次货物进行发货。
  3. 根据发货单,由仓库人员处理出库,并进行实际的库存扣减。
  4. 物流人员根据发货单中的收发货信息安排承运商进行配送,并回收配送相关状态。
  5. 在客户需求变更或配送的货物发生异常情况时能够进行售后申请,把货物进行相应处理。
  6. 对于库存管理人员要求能够定时进行库存盘点,能够及时发现库存货物由于一些管理上的异常情况而导致货物数量异常的情况。
  7. 货物需要定期进行存货核算以及仓储费用结算。

在整体的业务模式中主要可分为以下三种货物供应模式:

  1. 计划性的向供应商采购货物后进行备货,再销售给客户。
  2. 在客户下单时若除常规备货的商品外还有其它货物需求,可由销售反馈给采购后进行零采。
  3. 向兄弟公司调货销售给客户(具体可分为对方公司直接发货给客户和由销售公司发货给客户两种方式)。

在库存管理的业务中,事业部相关人员要求需要及时知道有多少货能够进行销售,其中有多少是已经在仓库可以随时发货,有多少可能是已经采购但货还在配送过程中,还有一些可能是产品管理人员能够预测未来会到货的货物数量。

02 业务分析

通过对上述场景进行分析后,我们能够把和库存配送相关的业务进行如下分类:发货业务、出库业务、到货计划、入库业务、库存管理业务、调拨业务、售后处理、其它出入库业务。

整体的业务架构图如下:

产品设计:库存模块

在整体的业务架构中,各个部分具体的使用角色以及所需要负责的业务具体如下:

发货:一般由销售助理/内勤人员完成,其主要任务是执行销售订单,在客户没有特定要求下,可以设置为系统自动生成,按先进先出的规则进行批次匹配,在客户对批次有特殊要求下需要人工干预,选择对应批次的货物发给客户。

注:在化工行业不同批次货物其性质会有所差异,故客户会有一些特殊要求。而发货单也是事业部对接仓库、承运商的单据,仓库根据发货单进行货物分拣并以发货单与提货司机进行匹配,防止货物错发,同时物流调度人员也会把发货单分配给具体的承运商,承运商下的司机根据发货单到对应的仓库进行提货,并配送到对应的收货地址。

出库:公司以出库单为依据影响库存,同时也根据出库单生成实际发生的应收。主要分为销售出库、退货出库、调拨出库、其它出库。销售出库主要为根据发货的实际情况进行库存扣减,是记录货物从真实的从对应的仓库中已经发出的凭证;退货出库主要为记录售后需要进行退货处理的记录凭证,把退货业务放在出库单中进行记录有一个好处就是能够直接通过负数的单据关联原有单据进行冲销,而根据出库单生成应收后也能直接进行应收冲销,由此不会改变财务核算的逻辑;调拨出主要记录跨组织调拨、转库调拨等情况,能够记录清楚该出库时由哪家公司发起调拨而产生的,最终能够反映在内部结算上;其它出则包含了盘亏出、报损出等不同的情况。

退货质检:主要记录在客户把货物发回到指定地点后到货物再次入库之间的业务信息。能够在该单据上记录货物异常的情况以及责任所属。

到货计划:主要用于记录计划性采购订单货物接收计划,能对在途可售库存进行管理。到货计划需要记录货物是否可售,到货具体的时间、数量、位置等信息。

入库:入库单能够直接影响库存,同时能够根据入库单生成实际发生的应付;主要分为采购入库、退货入库、调拨入库和其它入库,具体逻辑和出库类似。

库存逻辑:主要分为库存设置、明细、库存量和库存报表。库存量的定义和具体逻辑是该部分最为复杂的业务,在讨论库存量前我们需要明确几个定义:

  • 现存量:指仓库(可以是虚拟仓)中实际存放的货物数量,理论上能够进行实际出库的货物数量,有些文档中也称之为物理库存、账面库存。
  • 在途可售:指货物未在仓库,当时也能够销售的库存,支持外部采购在途、内部调拨在途。
  • 待发货量:指已经下单需要进行发货的货物数量,支持销售待发、调拨待发。

以上三个库存量均有实际单据进行对应,由于我们需要管控到批次基本,所以我们需要同时在SKU和批次两个维度进行库存量的记录,在途可售不需要在批次维度进行记录。

基于此我们通过计算得出我们能够用于销售的可售量,再通过一些库存分配策略我们就能实现很好的库存管理,例如:可设置预留量20%,各个渠道设置不同的数量,各个渠道可售数量之和可以大于总库存,但每个渠道的库存则不能大于最大可售量。我们也能够设置相应的库存预警机制,在库存低于一定比例是能够进行预警或者是限售。

03 功能设计

通过对具体的业务进行分析后,我们即可对产品功能进行详细设计,根据业务的实际情况,整体的功能结构如下图:

产品设计:库存模块

从业务分析中我们可发现主要涉及两个领域的业务:物流配送领域和库存领域,物流配送领域我们暂且不做具体的功能设计说明,对库存中心整体分为四个大的模块:出库管理、入库管理、库存管理、其它管理。

出库管理主要满足库存扣减相关的业务场景,例如:销售出库、调拨出库或其他出库,但有一种特殊情况就是售后退货也是放在出库模块,主要是出于财务核算逻辑考虑,如果公司财务核算是应收和收款核销,应付和付款核销,没有应收和应付核销的模式,那么售后退货就应该用出库模块解决,如果公司由应收和应付核销的模式则也可以把售后退货放在入库模块;但第二种模式会增加财务核算的难度,同时在进行库存统计是也会造成入库数据虚高,实际出库不足,主要还是看具体业务的模式。

由于我们服务的事业部暂没有做应收和应付核销的模式所以我们就采用了第一种方式,而对于出库单之前是否一定需要有发货单也是要根据具体业务进行规划,如果仓库管理、物流配送都是自己公司内部完成,也可以使用出库单+配送单的模式进行处理。

由于我们的业务是物流配送和仓库管理都是外包给第三方所以对外是以发货单为标准单据进行管理,所以出库单只是发货单的具体执行情况的记录。

入库管理主要满足库存增加的相关业务场景,例如:采购入库、调拨入库和其它入库,同出库一样在采购发生退货时也是以入库单的形式进行处理,如此设计的理由和销售侧是一样的。

对于库存管理,则属于库存中心最为核心的业务模块,根据业务分析中的相关概念,我们把单据对库存的影响整理一张图:

产品设计:库存模块

上图中有一个核心公式:可用量=现存量+在途可售-待发货量,由于化工行业的产品有分批次的特性故需要考虑SKU级的库存结构设计和SKU+批次级的库存结构,批次级的现存量合计一定要等于SKU级的现存量,而待发货量则不一定相等;在提交订单时(提交或支付)以SKU级的库存(不考虑库存分配规则)进行校验即可,在进行发货时则需要同时满足订单上的可发货量和SKU+批次及的可用量以防止超发或者超卖。

在SKU级的可用量的基础上我们可以根据具体的业务设计库存分配策略,库存策略以可分为预留和可售,预留则表示不对外进行销售,可售又可按渠道、活动级其它逻辑进行分配,各个方式之间的总和可超总可售量,但每种方式不可超总可售量,通过如此设计我们可以最大限度利用库存,而避免出现超卖现象。

库存的核心计算逻辑主要在图示蓝色部分,基本上把各种单据对库存的影响都罗列进去了,但以上的整体逻辑还是基于有货(或在途)的情况下开展的,但还有一种特殊情况是该逻辑不能覆盖的即预售/期货模式,预售/期货模式是以销定采的模式,是在确定了销量的情况下再去进行集中采购;所以对于预售/期货模式 我们需要单独设计一个虚拟库存的模块,而该模块根据实际经营可以轻量级的方式在商品中心进行实现,最终在进行货物交付的时候在通过出库单进行管理即可。

在库存中心还有库存预警、盘点、期初处理等功能,在此不一一展开说明,大家可根据自己的实际情况进行产品功能设计。

04 总结

库存领域的业务是一个相对比较专业和复杂的领域,市场上也有十分之多的传统软件或SaaS,在很多企业认为通过采购的方式去部署一套软件性价比会比自建库存中心要高。

但笔者认为在数字化转型的浪潮之下,通过数字化的工具提升供应链的效率、降低供应链管理的成本一定是一个十分之重要的目的之一,营销测的数字化转型大多数企业已经通过消费互联网认识到了其价值,我想供应链测的数字化转型在接下来的这几年也一定会逐渐显现其宝贵的价值。

传统的库存管理软件不管其架构还是对业务的实现都有其弊端,很难实现和营销侧的互联网架构的系统进行完美对接;所以自建基于互联网架构的库存中心,并培养懂库存业务知识的互联网人员是大多数要做数字化转型或产业互联网的企业必须要完成的任务之一。


蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png


文章来源:人人都是产品经理   作者:不可分类者

分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务






CentOS7 升级PHP到7.2

前端达人

写在前面

CentOS7下安装PHP默认是5.4的,但是有些框架要求PHP的版本得在5.4以上,这就需要我们把PHP升级一下了。

yum provides php 
  • 1

开始升级PHP:

rpm -Uvh https://mirror.webtatic.com/yum/el7/epel-release.rpm #更新源
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
yum remove php-common -y  #移除系统自带的php-common
yum install -y php72w php72w-opcache php72w-xml php72w-mcrypt php72w-gd php72w-devel php72w-mysql php72w-intl php72w-mbstring  #安装依赖包 
  • 1
  • 2
  • 3
  • 4

查看版本

php -v 
  • 1

PHP 7.2.8 (cli) (built: Jul 20 2018 15:20:01) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.8, Copyright (c) 1999-2018, by Zend Technologies

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png


转自:csdn 作者:Peithon

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

centos7重启php环境

前端达人

apache
启动
systemctl start httpd
停止
systemctl stop httpd
重启
systemctl restart httpd
或者

service httpd stop

service httpd start

service httpd restart


mysql
启动
systemctl start mysqld
停止
systemctl stop mysqld
重启
systemctl restart mysqld

或者

service mysqld stop

service mysqld start

service mysqld restart



php-fpm
启动
systemctl start php-fpm
停止
systemctl stop php-fpm
重启
systemctl restart php-fpm


nginx
启动
systemctl start nginx
停止
systemctl stop nginx
重启
systemctl restart nginx

或者

service nginx stop
service nginx start
service nginx restart

开机自启

chkconfig httpd on

chkconfig mysqld on
 

 

一、MySQL启动方式

1

2

3

4

5

1、使用 service 启动:service mysqld start

 

2、使用 mysqld 脚本启动:/etc/init.d/mysqld start

 

3、使用 safe_mysqld 启动:safe_mysqld&

二、MySQL停止

1

2

3

4

5

1、使用 service 启动:   service mysqld stop

 

2、使用 mysqld 脚本启动:/etc/init.d/mysqld stop

 

3、mysqladmin shutdown

三、MySQL重启

1

2

3

1、使用 service 启动:service mysqld restart

 

2、使用 mysqld 脚本启动:/etc/init.d/mysqld restart

四、强制关闭

以上方法都无效的时候,可以通过强行命令:“killall mysql”来关闭MySQL,但是不建议用这样的方式,因为这种野蛮的方法会强行终止MySQL数据库服务,有可能导致表损坏……所以自己掂量着用。

Windows下重启MySQL服务,对于没装mysql图形管理端的用户来说启动和停止mysql服务:
…\…\bin>net stop mysql
…\…\bin>net start mysql

 

 

卸载PHP

yum remove php
yum remove php*
yum remove php-*
yum remove php7
yum remove php70
yum remove php7.0
yum remove php-common
这才是苦大仇深卸载个干干净净= w

 

 

Centos下Yum安装PHP5.5,5.6,7.0

默认的版本太低了,手动安装有一些麻烦,想采用Yum安装的可以使用下面的方案:

1.检查当前安装的PHP包

yum list installed | grep php

如果有安装的PHP包,先删除他们

 yum remove php.x86_64 php-cli.x86_64 php-common.x86_64 php-gd.x86_64 php-ldap.x86_64 php-mbstring.x86_64 php-mcrypt.x86_64 php-mysql.x86_64 php-pdo.x86_64

2.Centos 5.X

  rpm -Uvh http://mirror.webtatic.com/yum/el5/latest.rpm
  CentOs 6.x
  rpm -Uvh http://mirror.webtatic.com/yum/el6/latest.rpm
  CentOs 7.X
rpm -Uvh https://mirror.webtatic.com/yum/el7/epel-release.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

如果想删除上面安装的包,重新安装
rpm -qa | grep webstatic
rpm -e  上面搜索到的包即可

3.运行yum install

  yum install php55w.x86_64 php55w-cli.x86_64 php55w-common.x86_64 php55w-gd.x86_64 php55w-ldap.x86_64 php55w-mbstring.x86_64 php55w-mcrypt.x86_64 php55w-mysql.x86_64 php55w-pdo.x86_64
 

yum install php56w.x86_64 php56w-cli.x86_64 php56w-common.x86_64 php56w-gd.x86_64 php56w-ldap.x86_64 php56w-mbstring.x86_64 php56w-mcrypt.x86_64 php56w-mysql.x86_64 php56w-pdo.x86_64


注:如果想升级到5.6把上面的55w换成56w就可以了。

yum install php70w.x86_64 php70w-cli.x86_64 php70w-common.x86_64 php70w-gd.x86_64 php70w-ldap.x86_64 php70w-mbstring.x86_64 php70w-mcrypt.x86_64 php70w-mysql.x86_64 php70w-pdo.x86_64
4.安装PHP FPM

yum install php55w-fpm 
yum install php56w-fpm 
yum install php70w-fpm
注:如果想升级到5.6把上面的55w换成56w就可以了。

nginx重启不了



蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png


转自:csdn 作者:锅巴胸

分享此文一切功德,皆悉回向给文章原作者及众读者.

免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务


HarmonyOS Sans - 华为把鸿蒙系统自带的字体开放给全社会免费商用了

雪涛

最近华为发布了鸿蒙系统并且开源了代码,成为了科技圈的热闻。不过我注意到了,系统内置的字体也是开放免费商用的。



关于 HarmonyOS Sans

华为鸿蒙字体 (HarmonyOS Sans) 是华为和汉仪字库合作定制,专门为鸿蒙操作系统设计打造,设计上聚焦于功能性、普适性,字形和之前介绍过的谷歌思源黑体阿里巴巴普惠体以及 OPPO 手机公司的 OPPO SANS 等免费商用字体有点类似,是一款适合阅读的多字重中性字体。

HarmonyOS 字体特性

  • 5种字重粗细调节。HarmonyOS Sans 支持可变特性,让用户选择他们喜欢的字体粗细来进行文本的显示。

  • 支持等宽与变宽两种样式。变宽数字在阅读文本段落中能让阅读体验更加连贯。而等宽数字在强调数值以及数据需要经常变化的表格、时钟数字的 UI 界面使用时,效果会更好。

  • 支持多国语言。HarmonyOS Sans 支持简体中文、繁体中文、拉丁、西里尔、希腊、阿拉伯等5大书写系统,105种语言全球化覆盖。

  • 通用性极佳,中英文混排效果优秀。鸿蒙系统是一款面向全场景的分布式操作系统,无论在手持设备、电视大屏幕还是手表的小屏上, HarmonyOS Sans 鸿蒙字体都具备极强的通用性和协调性。无论是粗体还是细体均需拥有出色的一致性。

undefined
harmonyos-sans 5种字重

字形特点

在保障字体体验的功能性前提下,HarmonyOS Sans 在人文和现代中找到新的平衡。在短笔画时保持横平竖直,简约无装饰,撇捺弯钩长笔画中融入书法的笔势美学,带来全新的视觉感受。

undefined
harmony-sans 字形特点
undefined
harmonyos-sans 笔画特点

在排版设计中常见的“字体不协调”问题之一就是中英文混合的排版,鸿蒙字体对此做出了针对性的优化,把西文字体设计得更显大更显宽,与中文对齐的匹配度更高,细看起来更加和谐。

undefined
harmony-sans 英文字形

一张图对比其他同类字体字形:

undefined
和其他类似字体比较

字体应用效果

undefined
harmonyos-sans 应用例子
undefined
harmonyos-sans 应用例子

使用场景和用途

HarmonyOS Sans 易读性强,字型简约富有科技感,在各种不同尺寸的屏幕上都能获得清晰的显示效果,既适合用于设计制作、平面印刷,也可用于阅读,显示大量文字也依然干净清爽。拥有5种字重,用在正文阅读通透流畅,粗细结合的标题也更醒目。

而对于移动 UI 界面设计来说,HarmonyOS Sans 本身优化了显示效果和协调性,特别是对数字的优化(比如时钟显示的冒号,往往需要手动调整),使得对 UI 作品整体气质有所提升,因此也可以用在效果图或作品集中。

当然了,你也可以设置为日常的办公文档字体,也可以下载用来替换自己手机设备的默认字体,即使没有华为设备,也能体验一下鸿蒙系统的文字显示效果。鸿蒙字体的格式为 .ttf,可以在 Android、WindowsmacOSLinux 等系统上使用。

免费商用说明

华为鸿蒙字体 (HarmonyOS Sans) 是随鸿蒙系统发布的中西文字体,有华为联合汉仪字库专为鸿蒙系统设计,现在华为将其公开发布,任何个人和公司都可以免费下载使用,包括商用。

需要注意的是,windows 系统内置的微软雅黑字体以及 macOS 内置的平方字体都是不能商用的,用在设计或者印刷上会面临侵权风险。喜欢这一类中性字体的,除了思源黑体阿里巴巴普惠体,现在又多了一款鸿蒙系统字体可以选择了。




蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png


文章来源:站酷   作者:weyman_me

分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务





太强了!这些Dribbble顶尖插画大神的作品,是我学习的源泉

seo达人

今天彩云跟大家分享的是Dribbble上,我非常喜欢的插画设计大佬们。优秀的太多,这里仅放10位我觉得最值得看的,可谓是精选中的精选,所以我建议你一定要收藏学习。(彩云花了3个多小时艰难选择出的10位,太难取舍了,最后入选的标准是一些更具风格特点插画大佬们)

 

1、Mikael Gustafsson

https://dribbble.com/MikaelGustafsson

首先推荐的这位大佬是我超喜欢的插画师,他在dribbble上发的作品不算多,但不发则已,一发惊人。每一张作品中,不论是画面构图、场景、配色都非常优秀而且还把插画做成了动态(其实是在Unreal引擎中落地的游戏场景动画),细节做到了极致。尤其喜欢他作品中的配色,我经常参考他的作品找配色的感觉,推荐你一定要去看看。

图片

图片

 

2、Beresnev

https://dribbble.com/Beresnev

这位大佬也是我在Dribbble上关注比较早的插画师,他的作品大多数都是动态的,其实发现他的动态也是做到了极致。插画的风格偏简洁矢量,很有自己的个人风格。可以从他的作品中学到很多动画动态细节,画面的动态速度、动作曲线、转场,极简的配色等等。他发布的作品量也不算大,但每一个都值得学习。

图片

图片

图片

 

3、Jenny Yu

https://dribbble.com/jennyyu

这位小姐姐很擅长在画面中运用光影关系打造意境,效果超喜欢,而且每一张图都能让看的人感受到一个故事,富有情感。画风比较轻盈,喜欢在画面中添加一些彩色的噪点,像是水彩撒上去的感觉,值得学习。

图片

图片
图片
图片

图片

 

4、Andrey Prokopenko

https://dribbble.com/Pro_Art

这位插画大佬擅长在结合图形本身构成的不规则暗色框里作画,从几年前就开始流行这种风格的画法。大概在5年前,彩云也画了不少类似这种风格的插画,当时跟这位大佬还经常互动,每次他发作品我会点赞,我发作品他也会给我点赞。只是他现在还在坚持更新这种风格图,我已经好久没画了,惭愧。总之,学习他的构图,细节,配色都是非常不错的,值得关注。

图片

图片
图片

图片

 

5、MBE

https://dribbble.com/Madebyelvis

Mbe插画风格应该很多人都已经熟知了,而他就是引流这股趋势的创始人。这种风格技法上较为简单,应用范围较广,曾经有段时间,各大厂的应用在空状态页,启动页面等等都进行了跟进。从这位大佬的作品中可以学习他的构图,配色细节,尤其是可以学习他对于可爱风格的表达。

图片

图片
图片

图片

 

6、Burnt Toast ®

https://dribbble.com/BurntToast

这位大佬在Google,Facebook,Samsung,Microsoft都工作过,跳遍国外大厂啊。他的插画具有很明显的个人风格:明亮的色彩,简单平滑的曲线描边,清新有趣可爱。我很早就关注了他,非常喜欢他的风格,给了我很多的灵感。他发布的作品量挺多的,很多都比较适合用到UI领域,推荐关注学习。

图片

图片
图片

图片

 

7、Brian Edward Miller

https://dribbble.com/bemocs

他是美国科罗拉多州的一位独立插画师,作品风格偏古典,擅长使用噪点笔触给画面增加细节。画面细节较为厚重,在一些风景,场景的表达上,比较适合参考。相比较于前面的一些插画风格,这位大佬的作品算是比较特别的,推荐给大家。

图片

图片
图片

图片

 

8、Canopy

https://dribbble.com/canopy

这是一家在纽约的插画工作室,他们的作品以矢量插画为主。我很喜欢他们画的这种图形规则的矢量风格,对于不擅长画插画的同学比较友好,很适合来临摹学习,也能用到一些UI项目中。他们对于颜色的不同明暗过渡运用的非常好,值得学习。

图片

图片

图片

 

9、Matt Carlson

https://dribbble.com/matt-carlson

这位大佬的插画作品,风格较为多变,擅长画一些风景画,尤其是对于树的表达有自己的特点。也是我关注的比较早的一位插画师,功底很好,值得关注。

图片

图片
图片

图片

 

10、Ana Miminoshvili

https://dribbble.com/Anano

最后推荐的是一位自由插画师,她的作品喜欢加一些噪点,并结合一些特别的图形外框,用出界的构图方式营造立体感,增强了视觉表现力。她的小插画,也很适合用到UI和运营里。在她的作品中从图形上,构图上,能看出是一位功底深厚的插画师,值得学习。

图片

图片
图片
图片
图片

总结

文章中列出来的这些是我从关注列表中再三筛选出来的比较有代表性的顶尖插画大神,在我的工作学习过程中,他们给了我很多的灵感。当然,这份推荐名单只是我自己的个人喜好,无关粉丝数量,排名也不分先后。

这篇分享,一定是值得收藏的,不论是找灵感,还是临摹学习,不用到处找,这10位大佬的作品就足够你研究了。当然,插画能力的提升离不开大量的练习,可以把这篇文章中分享的作品收藏起来(彩云挑选出的比较有代表性的作品),慢慢临摹学习都是极好的。

 

原文地址:彩云译设计(公众号)

作者:彩云Sky


转载请注明:学UI网 » 太强了!这些Dribbble顶尖插画大神的作品,是我学习的源泉


蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png



分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务



如何建立完善的设计验收机制

seo达人



在日常工作中,设计师经常会有这样的烦恼:上线的产品和原先设计的不一样,不是这个交互提示没有显示,就是那个图标大小显示错了。更有甚者,产品功能的交互逻辑就有问题。用户在使用过程中体验大打折扣。导致这个问题的原因很可能是在产品开发链路中,设计师完成对设计稿的交付后就认为这个任务告一段落,开始着手下一个任务。而后续环节中的队友对设计意图、设计细节理解不足或产生误解,将关注度仅集中在主要功能的提供上。解决这个问题,设计师们需要设立设计验收环节,进行设计输出和产品实现的比对和检测。

而在传统的瀑布式开发流程中,由于产品实现周期较久,产品上线前设计师可以安排充足的时间进行验收;但是在敏捷开发过程中,每个迭代的任务多、时间紧,设计验收往往草草收场,以至于问题不断累积,影响产品整体用户体验。本文将会结合酷家乐工具型产品-酷大师在敏捷开发过程中的实践经验说明如何搭建设计验收体系,在设计师与队友们的高效沟通的前提下,保障产品高品质在线。

 

搭建设计验收框架

很多设计师反馈:产品上线前验收过,有些小问题没法立即解决;上线后会发现一些新问题;随着产品功能的增加,问题越来越多,通常呈现分散式、零星式的特点,有些防不胜防的感觉。

实际上,这是因为大多数设计师认为设计验收就是上线前的事情,结束了就完成了,没有建立系统验收框架,缺少全生命周期去跟进设计实现的概念。

由于酷大师项目是我从0到1一直跟进的项目,在启动初期就做好了搭建设计验收框架的准备,按照单一功能验收、部分模块功能验收、全局功能验收、阶段性整体复查这样的顺序,网格状、系统性、地毯式进行验收。验收阶段贯穿上线前、上线后,形成点、线、面、体相结合的布局。

图片

单一功能验收阶段——模块验收阶段——全局验收阶段——周期性复查阶段

 

一.单一功能验收阶段

大多数项目进行敏捷开发时,一个sprint结束后会上线该sprint研发的功能,此时可以进行该sprint中开发的功能的验收。在酷大师敏捷开发过程中,一个sprint往往会完成1个复杂功能或多个独立的简单功能,我通常会给每个功能建立设计验收文档,逐个进行验收。这个阶段的验收往往比较细致,会关注每个功能的设计输出中涉及的所有细节点。

这样一轮精细化验收结束后,往往能够发现产品实现中90%以上的问题。我称这个阶段为点状验收

 

二.模块验收阶段

有些功能比较复杂,会拆解为多个子功能,花费多个sprint进行研发。比如说酷大师中的渲染功能,先实现构图外景等能力,再实现阳光调节能力。

所以会先进行构图场景和阳光调节的单一功能验收,当这些能力研发完成,渲染功能比较完整时,再进行整个模块功能验收。此时的验收既是对单一功能的复查,也是对模块功能的检测。我称这个阶段为线状验收

 

三.全局验收阶段

通常我会在一个相对具体的时间节点,比如半年、一年或者大版本更新迭代时,去查看整个产品功能迭代情况。这样的时间节点就很适合进行一场全局性的功能验收。

平日的验收结束后陆续会进行优化,但是由于优化时间点不一定是即时的,也有很多情况下是问题优先级较低,很久才修复。全局功能验收就能从全局角度了解半年或一年进展情况,查漏补缺。

由于酷家乐体系下,半年会对产品做一次回顾,所以我会在1个季度结束后进行一轮全局验收,检查出的问题可以下一个季度进行优化,保证每半年回顾时整体状态可控。我称这个阶段为面状验收

 

四.周期性复查阶段

前面三个环节结束后其实会沉淀下数量客观的验收问题,一部分在上线前会解决掉,一部分上线前不容易解决的会在上线后短期内解决,还有一部分问题可能涉及资源、产品方向等短期难以解决的问题,会留档,等待合适的时机进行解决。

为了防止短期内没有解决的问题被时间所遗忘,我会安排周期性复查,比如在半年的节点上,复查这半年的验收文档,对问题进行跟踪整理,适合近期进行优化的推进优化解决,短期内还是没法解决的再进行备注说明。

这样体系化的全生命周期的验收,就可以保证产品稳定的质量呈现。

 

明确基础验收流程

图片

建立验收文档——验收问题录入——同步&沟通验收问题【确定问题优先级&跟进机制】——过程中跟进调整情况———上线前复查

 

一.建立验收文档

有些团队内部协作习惯于直接口头沟通,面对简单且量少的问题时比较快速,但是也存在信息遗漏、沟通误差等问题。所以建议每次设计验收时先建立验收文档。

如果团队共同使用线上协同工具,那么验收记录留档和信息同步都能及时有效进行;如果没有团队协作工具,可以自己使用在线或本地文档工具,比如石墨、语雀、Pages等。建立文档时也需要按照一定规则,方便后续查找,比如命名按照功能、模块、时间顺序等。

随着文档的增加,为了方便进行管理,可以建立一张验收文档管理表,记录单个文档的基础情况。有些团队分工较细,交互设计师和视觉设计师会分别建立验收文档,在我们的团队协作中发现共同维护一份文档比较高效,只需要在问题类型中进行交互、视觉的分类即可。

 

二.验收问题录入

设计师在对最初的设计输出和设计实现进行比对时,往往会发现与最初设计意图有出入的地方,建议将差异点都作为验收问题进行录入,在后续沟通跟进弄清缘由的情况下,再去判断是否列入验收问题。

验收问题录入的过程,实际也是对功能的二次思考,在这过程中真切验证原先规划的操作路径是否真的易用。有时也会在录入过程中,发现需要增加延展的能力,那么也是可以录入并备注,为未来的体验优化积累突破点。

验收文档的撰写标准将在后文具体说明。

 

三.同步&沟通验收问题

验收问题常常会涉及多个岗位团队成员,比如前端、后端、运营等,如果是团队使用在线协作工具,在问题录入的同时设计师可以先做好原因预判,立即@相关队友,在正式进行沟通之前,能够给相关队友预留一些排查原因的时间。

在一次设计验收完成后,可以依据整个验收文档,与相关队友共同沟通验收问题。可以召集相关几位队友直接沟通,或者召开会议。在沟通的过程中,通常需要复现问题,判断原因,以及确定跟进优化的负责人。

同时会根据问题的影响程度、调整难易程度、资源配比程度,综合判断各个问题的优先级,再根据优先级进行排期调整。设计师在排定优先级时需要遵循体验原则,尽量保证新功能上线时以较好的效果呈现。这样用户初次接触功能时,在首因效应影响下,会对该功能体验抱有好感,对产品整体体验也会给到好评。

 

四.调整跟进

验收问题调整的过程中,对于复杂问题往往需要进行频繁的沟通,工程师需要在过程中与设计师确认方向正确性,防止偏差导致的再次误差。

此时设计师应给予充足的支持,比如详细解释设计意图,比如帮助工程师寻找类似场景的实现效果,比如相关组件资源等。既是团队协作共同解决难题,同时也在解决问题的过程中了解底层原因,为预防后续遇到类似问题积累经验。

 

五.上线前复查

体验问题调整结束,依据体验文档,再次验证修复情况。在这个时期,如果还遇到其他问题,也是可以进行问题录入和优化。

 

制订验收文档标准

图片

标明序号——定位问题范围——定位问题分类——问题清晰说明——差异截图对比——原因与解决方案——定位负责人——记录优先级———跟进记录

 

一.标明序号

验收文档支持以多种形式呈现,比如word、excel、ppt等,尝试过多种形式后,选择使用excel表格。对问题属性、范围、负责人等进行说明时可以单独呈现,很容易最终进行分类整理。

比如复查时,可以拉取一段时间的验收文档,整理后可以知道视觉问题占比10%,那么视觉还原程度还是不错的。比如渲染模块问题占比20%,那么说明这个模块下还需要集中进行优化调整。

确定呈现形式后,可以在文档中标明序号,方便后期整理。

 

二.定位问题范围

验收问题影响范围往往并不相同,比如影响当前功能、多个功能、当前模块,也有些问题涉及产品全局,甚至还有些问题会涉及公司其他产品线,此时需要说明清楚。

工程师在修改问题时就可以针对该范围进行问题解决,防止解决问题覆盖面太小,产生遗漏。而涉及到公司跨业务线的问题时,可以@对应负责人,进行沟通解决。

 

三.定位问题分类

在酷大师验收过程中,通常遇到的问题分类为:交互类问题、视觉类问题、运营类问题、技术类问题、产品方向类问题等。相关人员通常会直接关注对应问题,帮助高效处理。

 

四.问题清晰说明

清晰描述问题,尽量具体,避免类似于“不符合”、“不好看”、“与设计稿不一致”等主观笼统的概括;提出问题的同时尽量说明解决方案,当然有些方案设计师能够直接给予,而有些涉及其他岗位时就可以@队友进行解决方案的描述。

 

五.差异截图对比

将设计稿与开发界面进行截图对比,标注出差异问题点,帮助相关队友快速直观理解问题。有些情况下截图不能说明清楚操作过程中的问题,也可以采取录制gif的方式,演示操作行为。

 

六.原因与解决方案

通常问题涉及的相关人员会在这个区域进行跟进说明,比如造成当前问题的原因、解决方案、排期等。

 

七.定位负责人

记录当前跟进的跟进入。

 

八.记录优先级

优先级的评定可以有多种维度。通常可以直接做判断的维度有两个,易于调整的问题优先级较高,对完成功能影响大的问题优先级高。其他维度可以根据具体产品,与团队共同进行分析,总结其中的规律。

 

九.跟进状态记录

主要集中于对问题解决情况的跟进,通常分为已解决、跟进中。

 

其他思考

为了实现产品高品质在线,除了在研发实现后落地系统的验收机制以外,设计师可以在很多环节发挥作用:

1.设计稿本身的高标准输出,考虑清楚开发成本和可实现性;

2.交互评审环节尽量解释详尽,与相关工程师达到理解上的一致;

3.开发过程中参与沟通,帮助工程师先做一波问题的排除;

4.出现问题帮助促成解决,包括跨团队资源的收集、组件支持之类;

5.明确产品设计还原度对于用户体验的重要性;

6.以多种方式邀请合作伙伴参与到验收环节中,比如bugbush、专家走查、可用性测试。

 

原文链接:酷家乐用户体验设计(公众号)

作者:怀瑾

转载请注明:学UI网》如何建立完善的设计验收机制


蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png



分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

 


复杂系统如何设计 | 论B端产品的体系化构建(上)

分享达人

导读


为什么B端产品总是容易“失控”?B端产品设计与C端有何差异?如何在不断复杂的系统中,权衡效率、成本、体验之间的关系? 


本文将带你从B端产品的本质出发,了解产品发展过程中容易出现的问题,并从复杂系统的角度去探讨设计体系的构建方式。



目录


一、「 困局 」容易“失控”的B端产品

A .「 关注重点的差异性 」

B .「 微小差异的不断叠加 」

C .「 产品发展进入恶性循环 」

D .「 进入效率拐点,产品失控 」


二、「 启发 」从复杂科学的角度思考设计

A.「 自然算法 」

B.「 物质的构成原理 」


三、「 探究 」什么是产品设计体系?

A.「 定义 」

B .「 组成部分 」

C .「团队能力要求 」

D .「 构建方向 」


四、「 剖析 」B端产品的生命周期

「 产品生命周期概述 」

A .「 初创期 」解决核心问题,产生价值

B .「 成长期 」能力完善,产品扩张

C .「 成熟期 」效率提升,快速增长

D .「 暮年期 」商业价值降低,发展逐渐停滞


NEXT、「 下期预告 」设计体系的构建法则




前言


随着产业互联网时代的到来,市场对B端产品的重视程度逐渐提升。然而,谈及B端产品,特别是SaaS产品,大多数设计师对此并不是特别感兴趣。一来,SaaS更注重功能层面,似乎本身对设计的要求并不高;二来,SaaS产品的最终实现效果总是不尽人意,就算设计得再好看,实现出来也难以出彩。


确实,若设计师仅仅只是关注视觉层面本身,那么B端产品确实不像C端那么吸引人。但是,若你能以整个产品构建的角度去思考B端产品设计,那么设计师能够在其中发挥的空间是巨大的。


假如把C端产品比作精致的小房子,那B端产品就是一幢巨大的高层建筑。建造小房子,你可以尽情地发挥创意,追逐潮流,大不了推倒重来。而建造大房子,则需要设计师考虑更多的维度,因为这是一个长期而复杂的工程。


建筑的外观不仅需要好看,更需要足够耐看、稳定;为了适应更多人的需求,你不仅要考虑房子的软装,还要考虑户型的合理性、通用性;而为了降低成本,你还需要考虑家具、硬装的标准化、房间的兼容性等等…


“你是否有信心建造一个宏伟的高楼大厦?” 


这是我在B端设计中,反复强调体系化思维的原因之一。想要建造一个大型建筑,没有体系化思维、没有更完善的多职能协作流程,那么这座高楼一定会在建设过程中埋下隐患。而当问题一旦出现,涉及到的沉没成本也将会非常巨大。


当然,对于C端产品来说,体系化也愈发重要了。随着互联网时代的持续发展,一些C端产品的复杂性也堪比B端。我在之前的文章中提到过一个观点:“C端B化,B端C化”。在未来的数字产品设计中,B端产品将会逐渐开始重视产品的外观与体验,因为触达的人群更年轻化、对体验要求更高了。而C端产品也会更注重体系化建设,因为产品体量越来越大,需要寻求效率与成本之间的平衡点。


产品设计体系,本质上是一套更科学的复杂性数字产品的设计方法与工作流程。因此,不管是B端产品还是C端产品,设计体系能够在提升设计品质的同时,让产品更“可控”,提升效能,降低成本。


这套设计方法论,是我在工作中不断实践与完善的一些经验与方法。希望能借此分享一些自己浅薄的经验,也探讨一下数字产品设计未来的形态。




一、「 困局 」容易“失控”的B端产品

-


作为较为复杂的数字产品,B端产品在快速发展的过程中,总是容易出现一些问题。特别是当产品体量到达一定阶段后,问题就会逐渐暴露出来,比如:


1. 产品丑、设计质量低;

2. 组件样式繁多,操作习惯不一致;

3. 新老系统差异大,不同模块体验差异大;

4. 页面结构混乱。


等等…


很多问题大家都能明显地意识到,但往往因为“不影响售卖”、“价值不高”、“新功能优先”等理由被搁置。


随着问题逐渐积累,产品的优化成本也变得越来越高,最终使整个产品已经积重难返。若只是多部分页面/组件进行优化,小修小补,虽然成本低,但成效甚微;若是进行大修大补,那么优化成本将远大于研发新功能的成本。


这种普遍的B端产品现象,被称为“产品失控”,即——团队已经对整个产品的形态失去控制力。


那么,为什么B端产品特别容易出现这种问题呢?



A .「 关注重点的差异性 


首先,产品的本质决定了其关注重点的差异性。


与C端产品不同的是,B端产品往往更看重“能力”(为企业用户解决问题),而产品的销售方式与付费模式,也决定了产品体验并非首要关注的对象。由于B端产品通常针对企业用户,需要更长的研发过程,产品的体量和复杂性也相对较高。因此,除了产品解决问题的“能力”之外,产品还需要关注研发的效率及成本。


因此,在产品的发展初期,企业通常对效率最为关注,其次是成本,最后才是体验(能用就行)。绝大多数B端企业,只有在产品跑通商业逻辑,并具备一定用户与盈利预期之后,才会对产品的体验逐渐重视起来。



B .「 微小差异的不断叠加 


任何微小的差异,在无数次的叠加之后,都会被快速放大。特别是当团队的人员逐渐增多后,放大速度将会呈指数级上升。


为了配合产品的快速发展,产品往往会采用“堆量”的研发模式。增加研发效率,最简单直接的方法便是投入更多的资源。随着产品不断增加模块、功能、页面,团队人员也在不断地扩充。


但是,人类不是机器,并非简单的1+1=2。团队数量的上升虽然会带来效率的短期提升,但同样也会增加团队的管理成本。不同的产品经理、设计师、研发人员,对于产品的认知是不同的。随着团队人员的不断增加,“个体差异性”将会被不断地叠加与放大。


就像“传话筒”的游戏一样,同一个事物,不同的人理解总是不同的,经过多次的“传话”以后,往往与原本的意思已经大相径庭了。


这种情况表现在产品设计中,则会出现:当相同的组件由不同的人做时,总是会在基本样式、实现原理、交互细节等不同的维度出现差异。比如上图中的导航菜单组件,不同的模块在开发时总是会存在差异,最后差异越来越大,形成了五花八门的导航菜单形式。



C .「 产品发展进入恶性循环 


令人遗憾的是,虽然问题很明显。但是在不断的“成本考量”中,产品团队往往优先关注新功能的开发,而忽略底层问题的优化。


随着产品的快速发展,产品的优化/迭代成本将会逐渐大于研发新功能的成本。要么背负巨大的成本进行整体重构;要么降低标准,继续以这种模式不断叠加新功能。


在这种情况下,大部分B端产品往往会选择后者。于是,产品的发展将会进入一个“恶性循环”


  • 产品快速发展,功能不断叠加;

  • 各模块由不同的产品、不同的开发研发,导致各模块之间差异增加;

  • 产品丑、体验不统一,但老系统优化成本过高。综合衡量,优先进行新功能研发;

  • 所有模块标准不统一,产品迭代效率持续降低,维护成本持续增加。



D .「 进入效率拐点,产品失控 


产品的发展犹如一辆快速奔驰的巨型列车,一旦加速便难以停止。


随着问题的反复出现,以及在一次次的“利益权衡”中选择性的忽略,产品的恶性循环不断重复,而问题也逐渐叠加、沉积下来。


当这个问题已经大到我们无法回避时,我们才发现:产品的单位迭代/优化成本,已经远远大于新功能的研发成本。而新功能带来的增量,已经无法抵消现有模块的迭代成本——产品迎来了效率拐点。


就像一个庞大而复杂的机器,虽然依旧可以运行,但整体效率已经很低了,而与之对应的维修成本则非常巨大。小修小补根本无法解决问题,而大修大补则很有可能会带来更大的亏损。


最终,产品逐渐在“失控”中难以自拔,竞争力逐渐降低,但整个团队对此却无能为力,严重影响了企业的发展。


那么,在产品发展中,我们应该如何避免这种情况呢?换而言之,一个高度复杂的数字产品,我们应该如何设计,才能避免其逐步走向混乱? 




二、「 启发 」从复杂科学的角度思考设计

-


如果我们将B端产品看作是一个复杂系统,那么产品“失控”的本质即——在不断复杂化的形态中,缺乏有效的控制机制,最终导致整个系统失去控制。 


但是,在大自然面前,B端产品这种复杂程度显然不值得一提。


像大自然这样的复杂系统,是如何构成的?所有的物体都由原子所构成,为什么简单的一百多种原子,能够构成如此复杂的世界?生命又是如何在无机物的世界中诞生,并逐步进化成如此复杂的个体的?



A.「 自然算法 


道生一、一生二、二生三、三生万物...无论是老子的《道德经》,还是《深奥的简洁》、《万物皆数》、《复杂》这些现代的书籍中都阐述了这样一个观点:


任何看似复杂而又可控的系统,一定存在着精简的“算法”,通过不断的叠加从而形成复杂系统。


就像爱因斯坦说的:“宇宙最不可理解之处,就是它居然是可以被理解。”


在大自然中,有很多的花纹与图案的形状都存在相同的规律。比如上图中的羊齿草分形图案,这种图案在森林当中到处可见,我们看到很多树的形状跟叶子的形状是一致的,这就是一种分形图案。而这种分形的图案本质上是一个公式,通过不断地自我引用进行迭代,这便是分形。


科赫曲线(Koch curve)就是一种分形。其形态似雪花,又称科赫雪花(Koch snowflake)、科赫星(Koch star)、科赫岛(Koch island)或雪花曲线(Snowflake curve)。


它最早出现在瑞典数学家海里格·冯·科赫的论文中。我们将一根直线分成四段,然后向中间挤压形成等边的倒V形状;接着再将每个倒V的边进行相同的操作,不断地重复之后,我们发现:第一步是倒V型、第二步变成了大卫星,第三部变成了枫叶,第四步… 经过无数步以后,最终成了越来越复杂的“雪花”形态。


科赫曲线便是“自然算法”的一种。海岸线虽然很复杂,但是却有一个重要的特性——自相似性。从不同比例尺的地形图上,我们可以看出海岸线的形状大体相同,其曲折、复杂程度也很相似,换句话说,任意一段海岸线就像是整个海岸线按比例缩小的结果。而海岸线的构成原理就是这种科赫曲线,它是通过天然的演化,不断折叠最终形成了这种形状。


可以发现,他们都是由 基础物质 x 简单算法 x 随机变量,经过无数次叠加后,最终形成了一个复杂而多变的整体。



B.「 物质的构成原理 


宇宙中还有其他各种惊人的“巧合”。爱因斯坦的相对论揭示了宏观世界的规律性,普朗克和海森堡的量子力学揭示了微观物质世界的规律。当我们从微观世界到天文学会发现——原子核的构成方式居然与天体的构成非常相似。粒子围绕原子核的运动方式,就好像行星围绕太阳运动一样。


不管是整个宇宙,还是生命体,将其置于复杂科学的研究框架中,那些基本定律最终也会变得极其简单


在宇宙中所知最为复杂的形态,便是如同我们自身的生物。这些复杂体由已知存在于银河系中最普通的物质所构成。但是,通过氨基酸的形态,这些基本原料竟能自然地将自己组合成一个自组织系统。


混沌中隐藏的算法,使宇宙成为极有秩序的地方。而在秩序中隐藏的随机数,又使得宇宙成为极为丰富的世界。


也正是因为算法的精简,一切物质的创造才能具备复制性、延续性、进化性


那么,我们反过来思考——想要使复杂的系统简单可控,是否就需要一套简洁、有效的“算法”?通过“算法”,将基础的“物质”不断地“有序叠加”,形成一个可控的复杂体系。


因此,对于复杂的SaaS系统设计,我开始引入“设计体系”这一概念,希望能够找到未来SaaS产品设计的发展方向。只有设计体系的建立,才能保证产品可控性,才能在不断复杂系统中,保证效率、成本、体验之间的平衡。




三、「 探究 」什么是产品设计体系?

-


产品设计体系,在国内仍旧是较为陌生的词汇。什么是设计体系?


A.「 定义 


一个成熟的数字产品,需要有一个稳定、且持续迭代的形态。创造这个形态的过程,我们称之为广义上的产品设计(这里指产品的整个策划和设计过程,包含策划、交互、视觉及部分前端开发)。而负责控制和维护这个形态的这套系统,便是产品设计体系。


我们接触到的更多是设计系统(Design System),比如平台级的设计体系,Apple、Google、Microsoft等系统级的设计系统,及其设计开发套件、应用生态。公司级的设计系统,如Airbnb设计系统、IBM的Carbon设计系统、蚂蚁金服的Alipay Design等。


但是,在一个企业内部,想要Design System能够系统性地运转,还需要基于这套标准建立的团队协作机制。只有设计标准与团队协作标准完美融合,才能建立真正的设计体系。



B .「 组成部分 


如果将数字产品比作复杂的“生命体”,产品的发展比作竞争中“自我进化”,那么设计体系便是产品的DNA。它既是产品形态的控制源,又是不断自我迭代的进化源,它的作用是:


  • 控制产品外观——感知性模型(视觉风格/规范)

  • 制造基础构件——功能性模型(基础/复合组件)

  • 模块的构建规则——模式语言(产品框架规范)

  • 产品标准定义、生产方式制定——协作模型(高度协同的工作流程)


它不仅能控制产品的“生产结果”,提升产品质量;还能规范产品的“生产过程”,形成一套完整的多职能协作流程,提升产品的生产、迭代和维护效率。 


从宏观来看,设计体系像是一个“规范的复合体”,它是各职能之间规范的有效整合,产品框架、交互规范、视觉规范、前端规则,同时也是基于整合规范所创造的一套创新的工作模式。



C .「团队能力要求 


设计体系的建立,需要整个产品团队拥有一致的目标,并为之通力协作才能完成。这就需要整个团队拥有较高的平均素质与契合度


同时,体系化的建立和推动,也需要团队中有人牵头去推动。设计师作为“产品-开发”的中间环节,是非常有条件成为推动者的角色的。


当然,这就要求设计师拥有更丰富的横向能力。


一方面,设计师需要将自身的能力边界进行拓展,与上下游的职能保持密切的沟通,并解他们的诉求。只有当设计体系满足各方利益时,体系化才有推动的空间。


另一方面,对于产品侧与开发侧人员,设计团队也可以通过培训来提升他们的能力边界。比如针对产品的交互培训、针对开发人员的基础审美培训等。这样才能提升产品的下限与上限,增强产品的综合竞争力。



D .「 构建方向 


设计体系并非超脱于产品之上,而是根植于产品的成长过程中。


想要推动体系化的建立,必须充分了解产品发展的基本规律。产品处于不同的生命周期,所要解决的问题是不同的。在正确的时间做正确的事情,并对未来的形态进行规划,才能逐步让设计体系根植于产品、融合于产品。


因此,在下一章,我们首先来了解一下B端产品的生命周期。




四、「 剖析 」B端产品的生命周期

-


对于设计师来说,首先要更宏观地了解产品所处的生命阶段,才能知道设计需要解决的问题是什么,并以此有针对性制定不同的设计策略,最终帮助产品构建完善设计体系。


本章更多的是对B端产品的发展阶段做一个剖析,而不同阶段具体的实施策略,会在后面讲解。



「 产品生命周期概述  


类似于人的成长历程,一个新的B端产品从诞生到逐步扩大,通常都会经历几个不同的生命阶段。


B端产品研发是一个漫长而系统化的过程。这个过程通常伴随着商业业务发展与商业战略模式的不断调整。


B端产品从立项到下线,产品会处于几个典型的不同状态中,这就是产品的生命周期。通常来看,大多数产品都会经历以下几个生命周期。初创期-成长期-成熟期,直至最终进入暮年期。


而产品的商业价值,也会伴随着产品的发展而变化。在通常情况下,伴随着产品的逐渐成长,其商业价值也会随之增长,并在成熟期进入黄金的商业价值期。而当商业价值出现大幅、持续性的降低时,则基本算是进入了暮年期。


那么,不同的生命周期中,产品将会遇到哪些问题?而为了保证产品的持续发展,产品团队又需要做哪些事情呢?



A .「 初创期 」解决核心问题,产生价值


初创期,即产品已经从构思到研发,并成为了初步的产品。这个时期,产品虽然还不能覆盖完整业务,但已经能够顺利运行


从构思到创意,再到实践落地。B端产品的诞生,通常源于在行业内深耕多年的资深玩家。在不断地实践中,通过创意与实践,找到了一条能够帮助行业解决问题、提升效率的路径。


在这个时期,产品需要解决以下几个问题: 


1)用户是谁?


B端业务的本质,就是“向组织销售服务来获得盈利”。哪些企业最需要你的产品?哪一类用户的问题最需要通过这种方式得到解决的?这些都是需要在早期非常明确的。


站在普罗大众的角度去规划产品固然是好的,但成功的产品都始于一小部分早期用户;B端产品的用户通常来自某一垂直领域,首先让他们喜欢上你的产品,然后慢慢向外拓展至更大的人群当中。


想想看,最初一千名喜欢你产品的种子用户可能是哪些人?


2)产品能够解决什么问题?


我们要为用户解决什么问题?“用户的问题”可能是一个需求、一个困扰或是一个机遇。他们的需求是否真的是痛点?


这个时期,团队需要拜访大量的目标用户,通过交流获取痛点。我们必须验证这个需求的真实性,以及我们的解决方案是否具备一定的可实施性


我们可以通过更具象的UI或流程,初步展示想法,不断优化。最终形成一个可验证的初步产品Demo,并通过Demo进一步与潜在用户进行沟通。


3)这个问题是否普遍?是否具备标准化的可能?


不同企业的需求是有差异的,如何将个性化的需求抽象成共性的解决方案?如何权衡范围与成本之间的关系?我们要将不同企业的需求进行抽象,形成标准化的解决路径。


这个阶段,我们需要为种子用户创建方向聚焦的MVP。MVP必须是名副其实的最小化可行产品,要为种子用户带来端到端的精准体验。如果他们不理解产品功能,不知道如何或为什么使用,或是发现其性能低劣、bug 太多,无法达到“可行”的程度,那么你的假设就难以得到有效验证。


4)是否能够形成完整的商业闭环?


用户是否真的会为这个产品买单?换句话说,产品是否能赚钱并且养活整个团队?


B端产品在初创期,最重要的是快速验证产品与业务的亲密性,能否完成既定的商业战略。产品团队需要通过磨合业务,快速调整业务解决方案和产品架构。


不仅是产品的打磨,整个团队也要形成完整的闭环。工作流程、产品的商业运转机制也要初步跑起来。产品的售前、解决方案、产品研发、实施、客户成功,我们需要真实地完成这一套闭环的操作,并基于此做团队毛利模型的测算。 


解决问题,带来价值,并且能够将价值转化为收益,这才是产品可持续发展的关键。只有跑通完整的商业模式,拥有长期的盈利预期,产品才能顺利进入下一个阶段。



B .「 成长期 」能力完善,产品扩张


成长期,即产品形态初具完善,并具备完整商业闭环之后,处于快速成长的时期。这个时期,产品将进行快速的迭代,覆盖的业务一天比一天完整,能满足的业务需求越来越多,而产品为业务带来的价值越来越大。


与新生期的区别在于,新生期时的迭代方向还未完全明确,迭代更多的是尝试,磨合业务与产品。而在成长期时,产品的迭代方向已经是非常清晰了的


1)更多用户,更多真实需求


产品在真正投入运营之后,所遇到的情况一定与MVP时期有所区别。随着产品的不断售卖,我们将会接触到越来越多的真实用户,以及更多的真实需求。而这些用户与他们的诉求,将会成为产品发展的指引。


2)解决更多问题,业务范围扩张


经过长期的打磨,产品的形态和可用性已经初步成熟了,商业模式也已经初步跑通。随着更多的真实需求,产品将会选择有价值的方向扩张业务范围,从“解决一个问题”逐渐走向“解决一系列问题”


3)功能完善,产品体量快速增加


伴随产品的快速迭代,产品的基础功能会逐渐完善,同时也会基于核心功能去搭建更为丰富的功能矩阵。更多的能力、产品模块、页面,最终逐渐叠加为一个完整的大型产品。


4)组织逐渐完善,人员专业化


随着业务扩张,组织架构逐渐完善。为了提高专业性与效率,团队人员从“多面手”逐渐转化为专业化方向。与之对应的是,团队成员的数量也会在这个时期快速增加。售前、解决方案、产品研发、实施、客户成功,这一套完整的团队模型在各模块中不断地复制。



C .「 成熟期 」效率提升,快速增长


成熟期,即产品的形态已经稳定,并能够创造持续的商业价值。处于成熟期的产品,肯定是已经进行商业化运行的。反之,没有达到预期的商业价值的产品,不能算成熟期。


进入这个阶段时,产品已经实现了产品-市场匹配。但是,我们需要对整个产品、以及团队进行一系列的调和与优化,才能让整个产品的形态与运作方式更加合理,以便将产品推向更广阔的市场


1)产品效率、组织效能提升


经过一系列的快速发展,产品体量通常都会比较大,而团队成员也快速扩张。随着一致性成本、沟通成本增加,势必会造成研发效率、组织效能会下降。因此,如何降低产品的单位研发成本?如何让整个团队的组织效能达到最佳状态?是需要解决的问题。特别是当产品具备一定的客户数量以后,单位研发成本的降低将会极大提升产品整体的利润率


2)产品设计-研发标准化,构建完整链路


通过产品设计-研发标准化、数据架构标准化,打通不同模块的壁垒,提升模块化与灵活性。将单点之间的竞争力相互配合,形成“场域”竞争力


产品的单点也许不能保证都有最佳的竞争力,但如果我们能够提供一系列的、高质量、无缝衔接的配套服务形成闭环,将会形成强大的整体竞争优势。同时,产品设计-研发标准化,能够增加产品售卖的灵活性,通过灵活的组合方式吸引不同的用户,提升销售灵活性与成单率


3)提供高质量的用户体验


产品最终是给人用的,用户体验也会在将来逐渐成为B端产品的核心竞争力。随着竞争的加剧,以及用户群体的逐渐年轻化,用户体验将成为企业在选择产品时的重要考量因素,也是口碑传播的重要途径。


由于在“产品-市场匹配”阶段需要尽快地推出产品,所以在设计开发过程中可能遗留诸多问题,需要进一步打磨优化。产品设计需要与开发具备高度的一致性,视觉交互是否合理,前端代码是否准确合理,操作反馈是否高效等问题,都需要这个阶段来进行调和。


4)教育市场,卖给更多的人


当产品逐渐成熟并具备一定体量之后,单靠销售跑单是远远达不到发展要求。这个阶段,需要市场部人员对市场进行教育,聚焦不同的行业领域,从“点式营销”转变为“面式营销”,并配合销售人员进行产品的售卖。因此,在这个阶段,产品的品牌力、核心能力的传播将至关重要



D .「 暮年期 」商业价值降低,发展逐渐停滞


暮年期,即产品发展停滞甚至倒退,逐渐失去商业价值的产品。


B端产品进入暮年期的原因,主要有两个。一是,伴随着业务的发展,产品已经很难满足业务需求。且翻新产品的投入产出比较低。二是,伴随产品的使用时长,产品将变得臃肿和迟钝,逐渐难以敏捷地满足业务需求。


很多时候,商业环境的快速发展、技术的更新迭代都有可能成为产品进入暮年期的原因。对于暮年期的产品,根据商业战略,产品经理既有可能要延长产品的寿命,也有可能持续保障产品完成顺利换代。当然,更多暮年期的B端产品,由于业务的调整,最终迎来生命的终结。


需要注意的是,很多产品因为在成长期、发展期无法建立有效的产品控制机制,导致产品过早的进入臃肿阶段。也就是前文中所讲的“产品失控”,非常有可能加速产品暮年期的到来。


因此,是否能在前三个阶段建立健康、完善的设计体系,是产品能够获得更长生命力、更多价值的关键。




NEXT

「 下期预告 」设计体系的构建法则  

-


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


设计体系的建设并非一蹴而就,通常是伴随着产品的而发展逐步建立的。在下一篇文章中,我们将基于B端产品的发展阶段,带你详细了解设计体系的正确构建方式


蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png


文章来源:站酷   作者:Jady13_剑杰

分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务


如何设计友好易用的表单

分享达人

表单对于用户和产品同样重要。当我们需要收集数据时,表单是我们最常采取的方式(也许是由于在互联网普及之前,表单就已经长期应用于我们日常生活中 )。因此,将表单设计得友好易用是提高用户信息填写完成率的关键。


表单拆解

表单的样式会根据业务目标、内容的不同而发生变化,但是有一些基础的组成部分能帮助用户快速顺利地完成表单的填写。


1.类别标题:类别标题能够帮助用户浏览表单并同时解释整个表单的大致内容是什么。当你需要把被收集的信息分类为多个部分时,比如个人信息、职业信息和财务状况,这时类别标题就可以派上用场。


2.文本标签: 文本标签能够提示用户在每个输入框中应该填写什么样的信息。


3.提示文字:文本标签的附加说明。


4.错误信息提示:向用户反馈为什么输入框中输入的信息有误。


5.重要行为召唤按钮:表单末尾的按钮,用来提交表单上输入的内容。



表单状态


在用户使用表单时,有三种最基本的状态能够帮助用户完成操作。


1.默认状态:默认状态是用户未进行任何操作时的状态。


2.激活状态:当用户点击输入框后,输入框就变成激活状态并通过样式的变化强调显示。如果用户视线离开了屏幕一小会儿,这个状态可以帮助用户快速浏览定位。


3.反馈状态:此状态一般在完成一个信息的填写,并进行下一个字段输入的时候出现,让用户了解输入的信息是否正确。对于一些无法立即验证的信息可以在用户提交表单的时候进行反馈。



设计原则


1.保持简单:将表单设计得短且简单。只收集必要的信息,避免让用户分开填写姓氏和名字(分开填写姓氏和名字一般只存在于外国网站)。允许用户查看已输入的密码,而不要让用户填写两次密码去确认。


2.使用内嵌提示:当用户输入信息有误时要给出错误提示,同时要将错误原因注明在相应的输入框旁。


3.组合相关项:将有相关性的填写项组合在一起,然后将它们以合理的顺序整理,这可以帮助用户不必花费太多认知成本去填写必要的内容, 这个过程不仅轻松而且只需要用户很短的专注时间。


4.使用左对齐的文本标签:始终在输入字段上方放置文本标签。不要用文本标签替换提示文字,不然用户在提交表单之前很难检查他们输入的信息,会浪费较多的时间。请把标签放在输入字段上方并且左对齐。


5.根据输入信息的格式设计输入框:简单来说,确保输入框的格式与输入信息的格式协调。比如说,地址的输入框应该比手机号码的输入框更长。


6.CTA按钮(行为召唤按钮)

一般表单的后面会有一个或多个按钮,比如“提交”、“下一步”之类的。在按钮有多个的情况下,最重要、或者是最想要用户点击的按钮应该要突出,而其他按钮弱化处理。

当使用模态视图状态下的表单时,有时会有一个关闭按钮用于关闭模态视图。另一种设计方式是使用叉号图标并将其放置在顶部的右侧边缘,它可以代替关闭按钮,如图所示。


7.搜索字段:当网站内容比较多的时候,把搜索字段做的明显些,方便用户对网站内容进行筛选。同样的,在用户使用了搜索功能获取到结果后,不要清除搜索框内的搜索关键字,因为用户可能会查看最初他们搜索了什么。


8.清晰:向用户清晰地表达信息,不要出现含糊不清的词。用户可能不愿意填写表单,所以尽可能清晰简单。如下图的绿色按钮文字使用“提现”而不要使用“确定”。


原文:https://blog.prototypr.io/creating-user-friendly-forms-46e3f7f4eef2

作者:Momoh Silm

译者:Ballen贝林、春风似蛋挞

本文翻译已获得作者的正式授权

授权截图

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png


文章来源:站酷   作者:Ballen成明

分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

日历

链接

个人资料

蓝蓝 http://www.lanlanwork.com

存档