映月城与电子姬污染值是什么污染值如何去除，

为何游戏总改不好，聊聊游戏制作过程中的调优调研做法

本文首发知乎：https://zhuanlan.zhihu.com/p/621289774

最近看到一些产品的失败都被归咎于逼氪、太肝、得出的结论过于笼统，如果一个游戏都是如此归因，那岂不是做不肝、不氪的游戏就能成功呢？

为何用户与设计师之间存在着如此不可调和的矛盾，更有甚者用户之间的反馈也会互相冲突。所以在产品的设计/调优过程中一直存在一些声音的干扰这时候要如何的兼顾做取舍，不被用户牵着走从而听到正确的声音成为设计师/运营的命题，所以有了以下的一些经验方法可以分享出来。

一、听取用户的声音（访谈+社群+问卷）

用户的话要听吗，答曰肯定是要听，用户是大家的衣食父母，那怎么听，用什么来听，才是大家最关心的事情，以下是一些常用的调研方式。

a.用户访谈

用户直接访谈1V1（电话、面访），是了解用户对产品感受最深度的方式，所面对的用户越核心，给出的反馈越精准，故而一般都会进行多组用户的深度访谈，以追求到控制变量。访谈中分为两类：访谈就更深挖一些玩家个人观点，ce测试是观察玩家、追问为主。

在访谈的时候，除非是从业者（专家），对玩法评价时会表达出较为笼统的、主观的感受，如不好玩，不喜欢等，需要我们引导感受去往某个设计归因，让用户能从面——线——点更深入的评价 。

集体对一个设计产生评价时，如果集体的统一性够强，就说明设计的方向问题可能性大，但如果无法统一，则需要去了解因为什么发生了变量，如：用户的游戏习惯不同，用户的生活习惯不同等因素导致。

众口难调，曾经在原神出的时候，曾面对过一个塞尔达用户，对原神充满偏见，觉得美术是抄的、玩法不好玩，但其实没仔细体验过原神/非手游用户，你就算变出个塞尔达手游来也不能满足他们的需求，在这种情况下，往往会划定用户圈层，并且为圈层用户中进行一定的权重加成。

比如在最近刚上的星穹铁道中，发现不喜欢回合制的用户除非把核心改动改掉，否则很难满足他们的游戏诉求，所以还是需要先划定圈层对用户反馈进行采样、控制变量，以提取核心信息，所以找对用户是用户调研的前提。

阴阳师用户圈层

我们就得到了一个用户主观感受表述，问题集中度较高则需要引起重视，但很可能会遇到如下问题：用户由于过于害羞/过于激进无法在人面前展示对游戏真实的评价，用户的数量有限导致样本偏差，如在某个地区的拉到的访谈玩家会具有某个地区的共有属性。

定性CE访谈报告

b.社群反馈

最直接接触到用户的渠道是社群：包括TapTap，b站评论等形式，这一层普遍能反应核心用户的感受，通过用户单当面输出的反馈形式来。

在这一个方式上，能反应出客观事故：如战双的黑卡事件反应出运营问题、也能反映出主观感受：如某2游NTR事件反映出文案问题 。

用户主要也是通过这个渠道来了解游戏发生的状况，社群运营好了也是游戏生态的一部分，变成更热爱游戏玩家衍生出众多二创，给游戏带来额外的生命力，甚至会成为用户留存的重要原因。

但也容易被带节奏，如出现的某个小BUG，游戏的类似贴图被煽动，导致一定程度上的所谓“带节奏”。

需要自己沉下心去分辨哪些模块是真的有问题哪些模块是没问题的，越表层的设计如文案、美术、运营事故越能直观表现，越需要引起重视，越底层的越需要分辨，这就是所谓调优没这么容易的原因。

举个例子：映月城与电子姬，针对网友对手游的的吐槽，该游戏破天荒的做出了无限体力，免费月卡等形式吸收玩家，但实际的运营效果并不理想，说明更深层的内容要更要慎重考虑意见。

c.问卷调研

为了倾听到更多用户，需要进行用研问卷设计，并不是所有的用户都会在社群里发表自己的感受，故而会在游戏里发放用研问卷让用户填写。

在面对设计时，若所有玩家对某个设计反馈不好集中度高，并且连内部体感上都有问题，越浅层意见，越可视觉化的的设计问题真实性越明显，就越需要优先修改，修改优先级为：美术>交互>文案>战斗>关卡>系统>商业化>数值，如：忘川风华录一开始版本升星操作繁琐，但是涉及到越深层的就越需要谨慎。

在面对玩家对修改意见不一致的，可以通过交叉分析，获得各个R级/各个活跃层架/各个游戏进度（后台数据取），以辨别系统面对的用户感受是如何。

比如：付费弹窗设计，小R甚至零氪，极少在这种性价比上花费金钱，但是大R却是很喜欢这个系统的他们会认为很划算——衍生出了不同用户对不同系统的评价不同，需要适当调整分层的权重来获得真实面对用户的评价，进一步进行取舍

AFK弹窗设计

游戏中用研问卷对游戏设计部分的评价，往往是主观感受，但是涉及到数值模块，大家都会不约而同的选择——奖励给的不够多。

但如果因为奖励不够多而给多，把玩家的下一步数值目标给填满，反而玩家轻易获得当前目标，一大段时间内即进入了能力比挑战强的状态，心流上趋近无聊，进而玩家上线没动力，导致玩家流失反而是得不偿失的。所以在数值设计上的模块设计师需要非常谨慎，因为这是牵一发而动全身的，这也是为什么有些问题玩家一直喷但是设计师不改的一个影射。

小结：用户研究能帮助我们完成基础的问题发现，未来期望的方向与主观感性的感受，。

但实际落地时候需要考虑到的是改动成本与性价比，并且用户与用户之间可能发生冲突，需要把信息重要程度梳理。

用户是主导我们发现问题的钥匙，但不能被用户牵着走丧失了设计本心

调研模型

二、看用户的行为（数据分析）

游戏不同于互联网产品的是，游戏里面涉及到经济、人文、数学模型等较为深度的设计，故而并不是用户层就可以明显感知到的，需要额外的手段来辅助我们验证设计更深层次的东西，故而需要结合数据分析来看：

A.游戏基础运营数据分析

用户的留存、LTV、活跃、ARPU等常见运营数据是一系列设计后汇总的核心指标，目前手游市场已经非常发达，对各个品类/竞品的核心指标都会有标准，故而在外层往往更注重这些数据，一般超过了预期就需要做用户行为的基础分析即可。

所以才会有为什么某个设计玩家在喷，游戏依然坚持这个设计——因为在收入等关键数据上有所提升，或决策层短视等原因抛弃了这群会退坑的玩家，选择服务沉默的付费玩家。

但基础运营数据如果出现了问题，如果第N天的留存折损比较强，则需要更细一步具体梳理用户行为。

游戏基本通用指标

B.用户数分行为分析

此处是游戏内部用户的具体行为分析，相对于用研分析可以看到用户的客观行为，比如用户数值养成饱和度、用户的商业化行为，用户的关卡滞留率、通关速度等在用户主观反馈上采样不到的数据。

比如某个系统被设计出来但是参与率异常低，我们故而能知道系统设计可能出现了问题，但是还有以下可能：

1. 系统规则本身不合理导致用户主观不喜欢这个系统，从用研反馈上能明显收集到较多；
2. 系统本身投放的养成资源已经溢出/.产出性价比分配性价比低，玩家在数值上对这个系统没有追求；
3. 系统的界面层级较深、导致用户找不到/不符合系统定位层级；
4. 日常的任务系统不设置该系统引导；
5. 该系统本身是一个边缘系统，需要对游戏系统定位，产销、性价比有一定的的了解感知等等等等。

我们在面对数据时，做到了发现数据——部分归因——但是做不到建议，

在很多数据分析上上看到的仅是潦草的几个：建议调整系统，建议改善卡点，优化留存等隔靴搔痒的建议。

但准确定位问题找到原因，并且提供更有方向/更落地的建议能够更好的服务于项目就需要进行竞品调研，对同类型游戏有深度了解，避免闭门造车的情况。

PS：如果数据过于灾难，建议调整产品方向而不是调优这么简单了

三、看同行的做法（产品拆解）

有时产品质量过关了，但是在市面上出现了比较先进的设计方式而导致玩家差评/玩家数据表现不佳，在设计时没考虑到，就比如：三国志幻想大陆的全局加速。

有时候是出现产品基本的设计存在明显改良空间，通过一系列产品拆解对比，可以找到自身产品的问题。

如新手节奏打点，成长节奏等，也可以通过系统比对找到可能的归因，并且得出一定的优化方向（需要有一定的游戏拆解能力）。

曾经在面对回合制的自动挂机系统中，用户的评价呈现极端的两面性：部分玩家觉得挂机刷怪没什么，但是部分玩家觉得为什么还要持续的挂机，仔细拆分来看会发现大有不同。

习惯了挂机系统的玩家回合制游戏的经验较为丰富，而不习惯挂机的玩家游戏经历比较泛，熟悉魔灵的设计师就知道在这套框架下不适用于改动挂机获取装备的形式，因为魔灵自身的养成扁平，策略度深，数值目标需要自我寻找搭建，故而需要这么一个强数值压力，要求稳定阵容的玩法来迫使玩家认识魔灵。但从表层感受去否定一个深层设计，容易造成游戏无法构成闭环，从而导致玩家流失。

魔灵挂机

在反拆竞品时，受有几种方法可以验证竞品是否比我们更好/有效果：

1. 主观拆解，用自己的设计经验、体验经验去感受设计好坏；
2. 运营数据分析，若竞品在某个版本上了某个系统，起到了较好的活跃作用，则改系统推测是有效（从第三方数据平台可以捕捉到）；
3. 数据分析对比，这涉及到较为机密的公司机密，一般需要有比较丰富的数据库来做benchmark（大厂积累的优势也在这）；
4. 人脉打听，如果有相关认识的人，不如当面问问某个设计点是怎么想的，为什么这么做，效果如何。

系统横向比对

四、规划与总结

1. 用研更能反馈主观意见与感受，可以在发现问题之外定位到更近准的感受，但缺点是对问题的发现度上不够客观 ，容易被部分用户带节奏，研发需要保证自己的主见；
2. 运营数据是游戏的命脉,先看分数再分析原因，数据分能更客观真实的记录用户的行为，但比较难反应用户的主观感受；
3. 拆解可以获得更多先进的产品，避免闭门造车，最好通过多种渠道去反推设计、设计效果来获得方向启发；

最后根据排期与人力梳理优先级，可以利用kano模型、游戏设计阶段与重要性（表层的设计一般影响前期留存、而底层设计影响后期留存），去解决优先级高的问题。