DevUI是一支兼具设计视角和工程视角的团队，服务于华为云DevCloud平台和华为内部数个中后台系统，服务于设计师和前端工程师。
官方网站：devui.design
Ng组件库：ng-devui（欢迎Star）
官方交流：添加DevUI小助手（devui-official）
DevUIHelper插件：DevUIHelper-LSP（欢迎Star）
引言
一个新版本的上线是否真的对产品体验带来提升？
用户是否真的愿意切换至新版本？
用户是否真的喜欢我们的产品？
现代管理学之父：Peter F. Drucker 有一句名言：
If you can’t measure it, you can’t manage it.
因此我们要对新版本的上线过程进行体验度量，用数据以自证。
我去年有幸参与了一款公司内部产品的新版本封闭开发项目，本篇文章主要从如何更好的制定内测、公测计划，如何用数据证明用户对新旧版本的喜好，用户的转化率等多个维度，就收集数据指标的设置、数据分析的角度等方面分享一些自己的心得体会。
开始
我们在封闭阶段的新版本整体上线过程如下图所示：
我们的第一版本上线经过了大量问题分析讨论和和设计，然后我们的新版本又经历了内测、公测，不断的收集新的反馈，然后不断修正的我们的业务流，最终上到现网环境，收到用户的一致好评。
下面我主要是基于上线流程中我们做的数据分析手段，可以通过收集哪些数据来度量我们的产品体验。
此外新版本的上线过程中，其实还是有额外的收获的，我们的用户画像更加清晰，业务场景的一致性规范越来越明确，还有前端页面的一些基础组件得以沉淀下来。
一、高保真视觉稿输出
在开发新版本之前，我们对当前的老版本做了大量的问题分析和总结，然后深入客户现场，通过和用户的真实面对面访谈和调研，整理了大量的用户诉求和槽点。
然后由产品经理和设计师讲问题进行分类整理之后，输出低保真设计稿。
接着前后端资深开发人员，运营人员，设计师，产品经理等大家一起参与低保真的设计稿讨论，不断修改设计稿的细节：
- 开发人员的参与主要是保证细节的可实现性
- 设计师和产品等人的参与主要是对业务交互层面的把控
- 运营和用户的参与主要是确实当前的痛点问题是否得到缓解和解决
反复讨论和修正低保真设计稿，最终大家取得相对一致结论，这个过程其实非常的难，体验的感受本身就是主观的，谁都可以发表并持有自己的观点。
此时其实需要产品经理力挽狂澜，舍弃细枝末节的无谓争执，在核心诉求得到满足的前提下，输出高保真，开发人员开始实施开发，大胆试错，小心求证。
当时我们的前端开发人员和设计师、产品等人集中坐在一个小屋子里面封闭开发，这样子最直接的好处就是沟通成本的降低。
此外，按照以往，产品说服开发实施一个需求变更，或者开发说服设计师实施一个设计变更，往往会带来一个负面的效果：就是口服心不服。
当别人进入你的专业领域来左右你的想法时，往往是通过威严施压来变现他的思路，这样子带来的可能是被迫的修改，你心里还是不服气的。
大家坐在一起的时候，我们是可以直接通过下游的内测、公测阶段的用户声音来说话，当用户跳起来的时候，“设计、产品、开发”会自觉的识别到错误，甚至都不需要你下发命令，他悄悄的就修改了，心服口服的默默上线。
封闭把新版本上线运作的系统效率提升到了最高。
二、自测试阶段
在新版本开发完成之后，此时的版本肯定存在大量的缺陷和高保真还原度的问题。
开发人员充分自测
此时建议充分发动开发人员进行充分自测试，各业务模块的开发人员，交替测试对方模块，梳理页面的核心逻辑，确定基本流程是否可用，快速响应修复识别到的问题，可以通过wiki的文档协作，备注清楚缺陷的提出人、负责人、复现途径以及严重程度等，严重缺陷尽量做到当天闭环。
设计走读检视
其次联合设计师对页面进行细节走读检视，主要是针对高保真的还原度、一致性等问题进行识别，记录。
产品体验和测试
最后产品经理也要尽快参与到自测试阶段，主要是针对业务主流程的可用性问题、易用性感受等角度做好记录和反馈，设计师和产品的问题与开发自提的问题统一wiki管理，最终根据问题优先级统一走到开发侧修复。
经过自测试阶段的发现问题、修改问题的反复迭代之后，bug的数量和严重程度逐步收敛至可控范围内，此时就可以推进到内测阶段。
三、内测阶段
在内测阶段，我们的目标测试人群要切换到我们的真实用户群体，在真实的用户场景中发现更多的隐藏问题。
此外我们在内测阶段也可以结合我们的热力图和埋点事件，收集用户数据，提前感知下用户在新版本的使用操作流，为后续的公测做好风险评估。
3.1 内测用户群体征集策略
在用户的征集上，我们当时采用的策略是在老版本里面插播一个广告弹框，尽量保证内测的用户群体来自于我们的真实用户群体，且具有老版本的使用习惯。
为了更好地激励用户的积极主动性，最好是设定一定数量的物质激励或者奖金，这样子才能激发用户在使用过程中的反馈动力。
整个内测活动的时间要有期限设置，一般在1-2周左右就差不多了。
此外可以设置单日最佳奖项，和整个活动的前15-20名奖项，基于反馈问题的质量和数量来评定用户的名次，比如反馈100个问题的给予一等奖奖励，奖励信息和排名信息每天定时发到群公告里面，让大家知道自己的排名，也充分激励大家的积极主动性。
用户通过点击广告弹框，了解本次活动的主要目的，有意愿的用户会自发报名，然后由运营人员统一整理好拉群，内测用户群体还是要设置规模限制的，过大的用户量反馈的问题会导致内测阶段无法收敛，要依据团队人力支撑规模来进行制定，比如300、500等。
3.2 内测问题反馈
为了更好的牵引用户反馈自己使用的感受，我们使用的是公司内部的工具类似Github的Issue功能，提前把内测用户拉进创建好的项目里面，默认提供几个类型的标签，如下图所示：
用户在提Issue的时候要选择问题的标签，打上标签的问题十分方便产品经理对收集到的问题进行归类整理。
每一天设置问题反馈的截止时间点，到了时间之后由产品经理确定当日最佳以及把用户反馈的问题标记为是否有效，bug以及需要修改的问题，尽快整理分发的开发侧，快速响应。
由于前期已经引导用户做好了问题标签，此时我们可以根据标签过滤用户喜欢的功能点和不喜欢的功能点，整理分析内测阶段的问题也可以辅助评估内测用户对新版本的体验满意度。
3.3 问卷调查
内测问卷的填写可以作为最终奖励的加分项，从而鼓励内测用户的积极填写。
问卷调查的主要目的是补充之前进行的问题反馈数据，共同完成对内测流程的体验度量。
问题设计可以主要考虑如下几个方面，当然还是要基于团队实际诉求进行充分设计，确保收集的数据可用性。
- 用户画像收集，比如用户当前工作类型，所属部门信息，之前使用的相关工具平台类型，是否使用过老版本，老版本使用时间等之类的问题；
- 新版本的核心优化模块的评价，可以设置新版本核心优化点的单点评价选项；
- 是否会继续使用新版本，是否会主动给朋友推荐新版本等主观意愿的相关收集；
- 待改进的场景点，收集下一步继续优化的业务点；
- ...
3.4 内测总结
在内测阶段通过Issue的问题反馈和问卷数据收集，可以度量出用户对新版本的满意度，喜爱程度，也可以通过词云分析得到对新版本体验评价的热词分布，以及用户对新版本使用和推荐的主观意愿占比等可度量化数据。
通过这些数据可以帮助我们更好的制定下一步公测的计划以及优化当前版本缺陷问题。
最后说一下我们这次活动实际感受，由于激励的存在加上我们的工具本身大家每天就会使用，所以内测用户的积极性非常大，一天会有300个左右的问题反馈，到了真实的用户场景里面确实仍然存在大量的bug和体验性问题，极大的降低了正式上线的冲击。
四、公测阶段
4.1 公测埋点方案设计
公测阶段意味着我们的产品已经满足正式对外使用条件，为了避免对老版本用户使用习惯的过度冲击我们增加了公测阶段。
当时我们是在老版本里面增加了新版本的广告牵引弹框以及快速的访问入口，在牵引入口的点击事件里面我们做了事件埋点，考虑到用户会互相分享链接访问的操作，我们在新版本里面也会识别用户之前的版本是新or旧，如果存在旧切新的操作也会被埋点事件上报上去。
当然也会提供用户从新版本返回老版本的入口和对应的埋点事件，对于一个Web站点交互行为的改动肯定会影响到用户的使用习惯，给用户带来额外的学习成本，因此两个版本之间的切换都要做好埋点事件。
在公测阶段我们使用的主要埋点指标如下：
- 新用户：首次访问某站点的用户；
- 页面访问次数PV：页面加载次数其实就是页面的浏览量；
- 页面访问人数UV：一般是指1天内访问某站点的人数，1天内同一访客的多次访问只计为1个访客；
- 新增用户：某站点访问的新增用户；
- 用户转化率：原来使用的老版本，转而使用新版本的用户，占总用户数的比率；
- 留存率：某一统计时间段内的特定用户群体中，经过一段时间后仍启动使用的用户数占总用户的百分比，分别展示新用户和活跃用户的日留存；
- 跳出率：只访问了一个页面就离开的会话占比；
- 热力图：观察用户的操作热点区域；
4.2 埋点方案自验证
埋点方案可行性自验证非常的重要，一旦公测入口打开，用户的行为就会被上报，而此时如果埋点存在问题，将会丢失最重要的用户数据，第一天的用户自然行为数据是难能可贵的。
针对上述方案的埋点要提前进行测试充分，确保数据上报正常。
建议在相对的独立的自测试环境环境上对相关埋点的设计、数据上报、数据收集等阶段做好演练动作。
4.3 公测数据分析
在现网环境访问新版本的正式入口和运营的预热活动，大量的用户进入到新版本，由于经历了内测阶段的调整，整体用户的反馈主要是交互习惯的冲击。
当然最重要的就是埋点的数据分析了，每一天下班之后产品要及时整理埋点数据做好数据分析，详细记录好每一天的数据变化趋势。
以UV转化率举例，如下图所示可以明显感觉的用户的增长变化趋势，通过数据来佐证新版本对用户的自发式吸引力。
4.4 公测数据分析
在众测阶段我们结合了埋点事件，对整个新版本的上线数据做到了可度量，通过分析汇总的数据可以帮助我们更好的制定新版本的正式上线时间点，以及不断修正众测阶段出现的体验和缺陷问题。
五、总结
体验的感受是主观的，我们很多人都可以对一个产品体验指出大量的问题，之前微信产品张小龙不是也自嘲每天有1亿人教他做产品，我们对体验的追求是无止境的。
上面提到的一些方法只是辅助我们对现有方案设计进行体验度量，说到最后一个产品的体验还是要靠是否真正的方便的帮助用户解决了问题、是否存在满足用户诉求的使用场景才会形成自发的吸引力。
加入我们
我们是DevUI团队，欢迎来这里和我们一起打造优雅高效的人机设计/研发体系。招聘邮箱：muyang2@huawei.com。
文/DevUI 夏天的尾巴
往期文章推荐
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。