设计思维5:数据在设计中的运用
我们平时工作中可能会有这种感受,最开始的时候你有可能都不清楚自己的用户在哪。
如上图参照1,通过挖掘,我们可以把关键信息比作是红色的圆球,但是关键信息出来了以后,可能你的老板、上司常常要求多加一些功能以便覆盖更广泛的人群,那么多加的功能往往给核心功能造成很多干扰,影响用户对信息的解读。这种现象是很常见的,我们如何解决呢?参照2,我们在梳理出核心信息后,剩下的三类信息做淡化处理。不过这并不很理想,非核心信息还是占据了核心信息的空间,我们可以参照3进一步弱化非主要信息,这样核心信息进一步凸显。可能这样做我们无法覆盖所有的用户,但是抓住最主要的80%的用户就可以了。
我们以上图为例,假定A用户喜欢红色的信息,B用户喜欢绿色的信息,那么现实情况就是绿色信息对A用户是干扰,红色信息对B用户是干扰。遇到这样的情况,我们应该怎么在界面上设计红绿信息呢?那么我们要覆盖更多的商业利益,我们就要用大数据来解决这个问题。
我认为真正的大数据应该是“来自未来的信息”。所谓来自未来的信息就是提取过去的信息和今天信息,进行综合分析得到展示未来的信息。我们举一个具体的商业例子来说明什么是未来的信息。
我曾经在一家电商公司做产品经理的时候,做过一个关于商场的项目,目的是通过收集商场内用户的购买停留时间,来做精准广告推送这么一个事情。
建立一个场景:一个20岁的女大学生经常去徐家汇的某个商场的耐克打折店闲逛,看到打折的商品可能会购买,我们的手机APP可以记录了她的停留时间,得出她到耐克打折店的停留时间最长,那么当她再一次来商场的时候,APP就可能根据之前的信息进行准确的推荐,所以说这个推荐是基于一连串有关联性的数据得出的,这就是来自未来的信息。
有了数据,我们就可以根据数据去进行设计,我们来看一下盒饭和果汁的例子:
在全家便利店有这么一个现象,在一张购物单里往往会出现盒饭和果汁两种商品,经过分析发现这些购物单多数来自午饭和晚饭时间,人物分析后认为可能是吃饭含有盐份,容易导致口渴,同时盒饭不能满足维生素的补充,喝果汁有利于补充维生素。于是全家便利店决定把盒饭和果汁摆放在一起,取得了极大的成功。这是一个正面的例子,如果我们这样做行不行呢?
建立一个场景,购买了盒饭,在结账的时候向购买了盒饭的用户推荐果汁或是向购买果汁的用户推荐盒饭,这就是一个很糟糕的体验,虽然盒饭与果汁依然具有关联性,但是这种行为对消费者造成了干扰。
所以结合今天的设计来看的话,很多设计都是如上面左图所示,不管是淘宝还是京东都是如此。用户在购买东西或浏览信息时下面有一些相关的推荐,我们称之为“跟随型信息推荐”,采用跟随型的方式处理大数据设计的原因在于不足于一半的可能性、选择权交给用户、数据不够精确等。
另一种设计我们称之为“打断型信息推荐”,形象地说就是用户在浏览购物车时忽然弹出您可能喜欢的信息。我认为凡是敢做成打断型推荐的信息必须满足以下条件:100%的可能性、承受全部责任、数据绝对精准。所以我千万不要把本应是跟随型信息推荐做成了打断型信息推荐。
今天我们做设计时应力求做到以下三点:一是像打靶一样精准瞄准用户的需求信息,放弃撒网捕鱼式的大而空的设计;二是将信息和需求明确主次,主次混沌一团是不受欢迎的;三是结合媒介进行信息的设计,我们不能所有的终端都用同样的设计。针对大数据来说呢,只想重点强调一点,尽量采用跟随型信息,谨慎使用打断型信息。
(集创堂)
1、常见数据库设计方法是比较简单的。
2、一主多从冗余读库带来的副作用:读写有延时,可能不一致;写仍然是单点,不能保证写高可用。
3、主库冗余存在数据不一致问题。
4、数据读取速度。
5、利用缓存来实现。
相信大家都看过这样一篇新闻:谷歌搜索结果页上的链接颜色,是通过一个严密的实验,用数据来最终决定的。他们测试了整整 41 种蓝色,最终选出了那个表现指标最好的蓝色。选用这种蓝色要比其他的蓝色每年多为谷歌带来两亿美元的利润。
案例二:13年以前淘宝网的购物车是蓝色的,后面改成了现在的颜色也是产品设计部门在做产品迭代的时候发现,不同的按钮颜色会对转化率有细微的影响。目前购物车和立刻购买的颜色是转化率最好的。也许对小公司来说千分之几的影响可以忽略,但对淘宝这的大公司来说千分之一就是十几亿。
那么这些给产品设计师带来哪些启示呢?
作为设计师一直都在做产品优化设计,但到底是否真的是有改进呢。
若有A/B两种方案,各有利弊,到底哪个方案才更好呢。
这个时候就需要数据来支撑你的设计方向。数据是客观的设计方案上线后通过正确的分析就能看出好坏,好设计的价值能很直观的表现和被衡量;
关注数据指标,不仅仅是产品经理或运营的“专利”,作为交互和UI设计师也需要掌握这方面的技能,帮助产出更贴近用户行为的设计。
下面我们聊一聊产品设计师需要了解的数据知识:
PV 页面访问量 (Page View)
用户每 1 次对网站中的每个网页访问(成功访问/进入)均被记录 1 次。用户对同一页面的多次访问,访问量累计。在一定统计周期内用户每次刷新网页 1 次也被计算 1 次。
理论上 PV 与来访者数量成正比,但是它不能精准决定页面的真实访问数,比如同一个 IP 地址通过不断地刷新页面,也可以制造出非常高的 PV。
比如你一天打开网站30次,算30个 PV。
UV 独立访客人数(Unique Visitor)
访问网站的一台电脑客户端为一个访客。00:00~24:00 内相同的客户端只被计算一次。
使用独立用户作为统计量,可以更加精准地了解一个时间段内,实际上有多少个访问者来到了相应的页面。
PV、UV有什么区别?
比如你上午打开了,访问了四个页面并关闭网页。下午又打开了,访问了12个页面。则当日统计结果为:PV=16、UV=1。
PV: 页面浏览量 次数 不去重
UV:独立访问数 按人计算 去重
VV 用户的访问次数(Visit View)
用以记录所有访客用户1天内访问了产品的页面多少次。当用户完成所有的浏览并最终关掉该产品的所有页面时便完成了一次访问,同一用户1天内可能有多次访问行为,访问次数累计。
DAU/MAU 日活用户与月活用户(Daily active user / Monthly active user)
DAU(Daily active user)指的是日活跃用户数量。通常统计一日之内登录或使用产品的总用户数(需去重)。与流量统计工具里的UV概念相似。
日活跃用户数与月活跃用户数相比,日活跃用户数不稳定,容易受到活动,节日的影响。但可以用来评估活动和节日用户活跃的影响。
MAU(Monthly active users)指月活跃用户人数。MAU是用户数量统计名词,指网站、App等月活跃用户数量(需去重)。月活跃用户数是一个月内活跃的用户数。数值越大,说明产品用户越多越活跃。因为样本时间足够长,数据相对稳定。属于用户资产里的核心指标。
数据用途:衡量产品使用的活跃度。方便了解产品的每日用户情况,了解产品的用户增长或者减少趋势。
注:一个用户一天通过一个渠道3次进入产品,则DAU只算一个。
MAU不等于DAU之和,必须要去重才有意义。
新增用户:
DNU:Daily New User(日新增用户数);
WNU:Weekly New User(周新增用户数);
MNU:Monthly New User(月新增用户数)。
新增用户:即安装应用后,首次成功启动产品的用户。
留存用户数:
用户在某段时间内开始使用该应用,经过一段时间以后依然继续使用该应用的用户,被认作是留存用户。是衡量产品的用户粘度和产品的留存用户的一个规模。
留存率:
率留存率=留存用户/新增用户*100%。通常重点关注次日、3日、7日、30日即可,并观察留存率的衰减程度。
常见的指标有次日留存率,七日留存率,次周留存率。留存率常用来评估某一功能效果。比如:某个时间内,获取的新用户的次日留存率常用来衡量拉新的效果。
用户增长就是获取新用户,留存下来的过程。做好留存,促进活跃,才能保证活跃用户的增长。
次日留存率:即某一统计时段新增用户在第二天再次成功启动应用的比例。
7日(周)留存率:即某一统计时段新增用户在第 7 天再次成功启动该应用的比例。
30日(月)留存率:即某一统计时段新增用户在第 30 天再次成功启动该应用的比例。
数据用途:用来衡量用户使用粘性和忠诚度,也可以用来作为产品改版后的重要指标,产品体验越好,越符合用户需求,则留存率越高。
人均点击次数
定义:点击PV/点击UV
举例说明:例如首页,1月16这天有10万人点击提问,其中一共点击了12万次,那么人均点击次数为12/10=1.2次
数据用途:用于衡量产品/页面/功能中的内容对用户的吸引度,对比同页面的不同功能。
平均访问时长
指在特定统计时间段内,浏览网站的一个页面或整个网站时,用户所停留的总时间除以该页面或整个网站的访问次数的比例。
如用户在网站特定时间内总停留时间为 1000 秒,在这段时间内,总的访问次数是 100 次,那么这个页面或网站的平均访问时长就是 1000秒/100=10秒。
该数据是分析用户粘性的重要指标之一,也可以侧面反映出网站的用户体验。平均访问时长越短,说明网站对用户的吸引力越差,可用内容信息越少。
平均停留时长
定义:所有用户的停留时长和/用户数
举例说明:例如首页所有用户的停留时长为100万小时,一共在首页停留的用户有200万,则平均停留时长为0.5小时。
数据用途:用来衡量页面吸引度,一般来说,停留时间越长,用户粘性越强。
人均使用时长
定义:用户平均每天停留在产品的时间。
举例说明:例如2月20日有100万个用户一共在产品上使用了50万个小时,则2月20日的人均使用时长为0.5个小时。
数据用途:用来衡量用户使用产品的深度,判断用户使用产品的粘性和依赖度。
说明:用户对产品的使用时长越高,说明对产品越依赖,商业化价值也越高。
CTR 点击率( Click-Through-Rate)
图片广告;文字广告;关键词广告;排名广告;视频广告等的点击到达率,即点击量除以浏览量(PV)
CPC 每次点击费率 (Cost Per Click)
为广告投放的重要参考数据,是广告的一种常见定价形式。
CPM 每千人成本 (Cost Per Mille)
是一种按照千次曝光进行计算收费的方式,假设收费方式为10元/CPM,那么每一千个人看见推广广告,你就需要给推广商支付10元。这是目前比较流行的推广方式之一,可以有效增加曝光率。
ARPPU 平均每付费用户收入(Average Revenue Pper Paying User)
在统计时间内,付费用户产生的平均收入,一般以月计算
产品设计师更多的关注产品数据可以将用户的行为可视化,以便更清晰地了解用户行为,经过一段时间的数据对比,设计师和产品经理可以共同验证并规划后面迭代的方案,预测产品的走向与趋势。并且通过数据分析,可以量化交互方案的效果,作为一名解决产品问题的设计师,帮助设计师更了解产品与用户,且对自己职业的成长更有帮助。
数据库的设计过程大致可分为以下六个阶段:
1. 需求分析阶段
需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。
2. 概念结构设计阶段
通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。
3. 逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型(例如关系模型),并对其进行优化。
4. 数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。
5. 数据库实施阶段
运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C),根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。
6. 数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
那么我们要做到什么程度才是对的呢?下面就说说数据库设计的原则:
1、数据库设计最起码要占用整个项目开发的40%以上的时间
数据库是需求的直观反应和表现,因此设计时必须要切实符合用户的需求,要多次与用户沟通交流来细化需求,将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确,就要分析不确定的因素,设计表时就要事先预留出可变通的字段,正所谓“有备无患”。
2、数据库设计不仅仅停留于页面demo的表面
页面内容所需要的字段,在数据库设计中只是一部分,还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段,因此数据库设计绝对不是简单的基本数据存储,还有逻辑数据存储。
3、数据库设计完成后,项目80%的设计开发在你脑海中就已经完成了
每个字段的设计都是有他必要的意义的,你在设计每一个字段的同时,就应该已经想清楚程序中如何去运用这些字段,多张表的联系在程序中是如何体现的。换句话说,你完成数据库设计后,程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度,那当进入编码阶段后,才发现要运用的技术或实现的方式数据库无法支持,这时再改动数据库就会很麻烦,会造成一系列不可预测的问题。
4、数据库设计时就要考虑到效率和优化问题
一开始就要分析哪些表会存储较多的数据量,对于数据量较大的表的设计往往是粗粒度的,也会冗余一些必要的字段,已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时,一般都会对主键建立聚集索引,含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时,还要考虑是否有必要采用存储过程。
5、添加必要的(冗余)字段
像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求(如统计)的字段等,在每张表中必须都要有,不是说只有系统中用到的数据才会存到数据库中,一些冗余字段是为了便于日后维护、分析、拓展而添加的,这点是非常重要的,比如黑客攻击,篡改了数据,我们便就可以根据修改时间和操作用户IP来查找定位。
6、设计合理的表关联
若多张表之间的关系复杂,建议采用第三张映射表来关联维护两张表之间的关系,以降低表之间的直接耦合度。若多张表涉及到大数据量的问题,表结构尽量简单,关联也要尽可能避免。
7、设计表时不加主外键等约束性关联,系统编码阶段完成后再添加约束性关联
这样做的目的是有利于团队并行开发,减少编码时所遇到的问题,表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。
8、选择合适的主键生成策略
采用E-R方法进行数据库的概念设计,可以分成三步进行:首先设计局部E-R图;然后合并各局部E-R图,并解决可能存在的冲突,得到初步E-R图;最后修改和重构初步E-R图,消除其中的冗余部分,得到最终的全局E-R图,即概念模式。扩展资料
在需求分析和逻辑设计之间增加概念设计阶段,使设计人员仅从用户角度看待数据及处理要求和约束,产生一个反映用户观点的概念模式。这样做有三个好处:
(1) 数据库设计各阶段的任务相对单一化,设计复杂程度得到降低,便于组织管理。
(2) 概念模式不受特定DBMS限制,也独立于存储安排,因而比逻辑设计得到的模式更为稳定。
(3) 概念模式不含具体的DBMS所附加的技术细节,更容易为用户所理解,因而能准确反映用户的.信息需求。
在初步E—R图中,可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据,冗余的联系是指可由其他联系导出的联系。冗余的数据和冗余联系容易破坏数据库的完整性,为数据库的维护增加困难,应当予以消除。消除了冗余后的初步E—R图称为基本E—R图。
但并不是所有的冗余数据与冗余联系都必须加以消除,有时为了提高效率,不得不以冗余信息作为代价。因此在设计数据库概念结构时,那些冗余信息必须消除,那些冗余信息允许存在,需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据,则应把数据字典中数据关联的说明作为完整性约束条件。
数据库设计包括两个方面的设计内容:概念设计和逻辑设计。
数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。
数据库设计的设计内容包括:需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护。
数据库设计(Database Design)是指根据用户的需求,在某一具体的数据库管理系统上,设计数据库的结构和建立数据库的过程。数据库系统需要操作系统的支持。
数据库设计是建立数据库及其应用系统的技术,是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性,为了支持相关程序运行,数据库设计就变得异常复杂,因此最佳设计不可能一蹴而就,而只能是一种“反复探寻,逐步求精”的过程,也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。
调查和分析用户的业务活动和数据的使用情况,弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况,确定用户对数据库系统的使用要求和各种约束条件等,形成用户需求规约。
需求分析是在用户调查的基础上,通过分析,逐步明确用户对系统的需求,包括数据需求和围绕这些数据的业务处理需求。在需求分析中,通过自顶向下,逐步分解的方法分析系统,分析的结果采用数据流程图(DFD)进行图形化的描述。