需求分析之“试纸测试”

众所周知，产品上线以后，经过一段时间的运营，同时随着战略的调整和需求的逐步明朗，会有许多新的需求和方向产生，此时就不得不进行产品迭代，而任何的新功能和改变背后，都充满了风险和未知，作为产品经理，该如何用最小的代价来验证改变的价值？文章源自玩技e族-https://www.playezu.com/12806.html

今日就和各位聊一聊一种需求验证的小技巧：“试纸测试”。文章源自玩技e族-https://www.playezu.com/12806.html

 文章源自玩技e族-https://www.playezu.com/12806.html

何为“试纸测试”？文章源自玩技e族-https://www.playezu.com/12806.html

　　任何产品或功能的设计价值体现在设计动机，而设计动机的价值就是为了满足需求！文章源自玩技e族-https://www.playezu.com/12806.html

　　而需求之间是存在关联性的，如果假设现有功能是满足需求的，那其周围一定存在着潜在的关联需求等待满足，同时会有很多伪需求伴生，此时就需要去做判断，之所以观主把这种方法称为“试纸测试”，就是寓意“犹如化学实验的试纸一样，用一片小小的试纸附带着现有产品去对未知做判断”！文章源自玩技e族-https://www.playezu.com/12806.html

　　说白了，“试纸测试”的核心理念就在于——文章源自玩技e族-https://www.playezu.com/12806.html

　　依附现有产品，以最小代价，在尽可能少的改变现有产品的前提下，去对未知需求做判断和预演！文章源自玩技e族-https://www.playezu.com/12806.html

　　从而确保在新功能或改变正式上线前，掌握主动，做到进退自如！文章源自玩技e族-https://www.playezu.com/12806.html

ps：任何新功能的上线，都是有代价的，比如开发成本、比如用户接受度的不确定等，不管团队大小、资源多寡，作为一名产品经理，需要学会尽可能的“一击即中”，在低成本下试错！

（市面上每个产品的背后也有自己的故事，所以这里的例子都是经过一定转化的，不具名了，请勿对号入座；另外很多现有的功能做的很好，但是并不代表其在当初上线前就已经能确定上线后的结果，在这里我用“试纸测试”的方法，架空这些功能，做出了一些假设，为大家提供另外一种更稳妥的思路，即“如果有了试纸测试，花很小的代价，可能可以预测结果”。）

　　1.电商平台商品详情页增加“一键下单”功能

　　（任何创新功能在设计时的预期，实际上线后可能根本无人问津，“试纸测试”可以把试错的成本降低，无论是开发成本，还是用户认知的成本）

　　现状：详情页有立即购买功能，点击后进入订单确认页面，确认商品和配送、支付等相关信息后支付，支付成功后流程结束。

　　需求：降低用户操作难度，缩短、简化用户操作流程，使用户从决策到完成支付的过程更紧凑。

　　方案：分析下来，在订单确认环节上，存在很多重复性的输入和操作，而个人消费者的收获、配送、支付等信息可选范围极小，所以希望通过复制上一次（或预设）的订单确认页面输入内容，来去掉这一环节，直接完成支付，所以需要增加“一键下单”功能。

　　正常迭代：直接增加“一键下单”功能。

　　试纸测试：在订单确认页面增加一个按钮“与上次订单相同”，通过对这个按钮的监控来看增加“一键下单”功能的必要性。

　　ps：很多人要问了：正常迭代和试纸测试感觉在功能上差别不大，为什么要多此一举？原因如下——

　　· 首先在订单页面增加按钮和在商品详情页加按钮相比，前者仅仅是对上一次的信息做缓存和读取（自动填充），后者需要开发一套全新的自动化逻辑，明显“试纸测试”的试错成本更小；

　　· 其次在页面的逻辑上，直接增加“一键下单”面临着从商品详情页就把流程做分支，改变了现有的产品和页面逻辑，而“试纸测试”采用的方法，则是不对页面和流程做调整，依然是通过“立即购买”进入订单确认页面，这样的更改对用户来说基本无变化，也不存在认知上的难度。

　　2.B2B平台是否增加采供交流频道？

　　（“试纸测试”除了可以帮助产品经理降低试错成本，也同样可以为产品经理砍去伪需求提供事实依据）

　　现状：某化工平台提供的交易模式为询盘交易（撮合交易）和现货交易（类库存交易），采购商只能向某一家或多家同时进行采购意向的提交，而现货交易由于品类的限制，可能存在现货与采购需求有细微出入的问题。

　　需求：公司高层以及业务线认为，需要通过类似交流社区或频道的功能，帮助采购商把需求给扩散，在提升采购效率和反馈率的情况下，又能吸引有潜在供货能力的供应商参与到平台交易中。

　　方案：在原有的主线交易流程外，增加一个单独的二级子频道“采供交流区”，功能类似于简化的“58同城”这类的。

　　正常迭代：直接增加二级子频道，需要做很多开发，包括一整套新的逻辑：从浏览到发布到接触到初步达成意向后的关闭。

　　试纸测试：直接在现有的商品，无论询盘或者现货的“询盘/购买”按钮边上增加两个按钮“我也能供货”和“这不是我要的，让平台帮我找更多供应商”，统一跳转一个简单的采供信息提交表单（包含联系方式），而在用户端后台中只增加一个记录该次提交的跟踪模块，通过运营人员的介入来帮采供双方完成：其原本通过采供频道可能达到的预期效果，即如果是采购商发布采购信息无非是要供应商应答，这个找供应商的过程前期就用人工来完成。

　　ps：如此做的原因如下：

　　· 通过“试纸测试”降低了开发成本是其一，同时避免了在需求未验证前，盲目进新版块上线所带来的流量切分和意外跳出；

　　· 这里的核心思路是“先证明对错，再完善功能”，原有的需求需要进行一定的转化，表面是要做一个新频道，实际需求不是非要这个频道不可，而是需要一条帮助采供双方在原有交易线外，把潜在需求给释放的路径，所以“试纸测试”通过简化和运营人工介入，就是为了证明这个点。

　　· 产品经理要学会砍需求，这是老生常谈，观主平均要砍掉全公司（包含老板）的80%需求，这个“砍”不仅仅是不做，有时候是双方互相让步后简化着做，而“试纸测试”很大的一个作用就是为你提供“砍需求”的理由。

　　3．电商平台增加新的品类前的试纸测试

　　（“试纸测试”不仅适用于产品设计和开发，还能用于运营场景）

　　现状：某珠宝B2B平台，80%的商品为黄金类珠宝首饰，而在品类上也是以这个为基础，但是珠宝首饰的品类其实极其丰富，同时延伸的周边产品，如加工用具、包装盒等也极多，但是客观的说该行业为非标定制行业，又是柔性手工生产业，所以在信息化的难度上不小，很难做到全品类的普适（意味着每增加一个品类，起码商品管理和展示、下订上要多一套新模板）。

　　需求：业务团队需要在现有品类上增加很多其它品类，逐步转化成全品类平台。

　　方案：原平台从展示、搜索到下订，以及后台的结构都需要从适用于黄金品类转化为全品类，如黄金是没颜色的，而新增的K金有双色和三色，同时颜色不同工费等都不同，原模板需要更改。

　　正常迭代：直接分析每个品类后设计开发，从上传到展示，从搜索到下订，几乎全流程需要翻一遍。

　　试纸测试：不做任何更改，将一些已经谈好的供应商的非黄金（即新品类）类商品，通过现有的商品体系上传，很多关键信息无法很好展示，但是起码采购商可以看到图片、名称和备注，这些粗浅的显示无法帮助采购商做购买决策，通过人工介入来完成这一步需求的验证。

　　ps：原理如下：

　　· 当时我评估的开发量很大，而且不确定性太多，于是就试图用冗长的开发周期吓退业务团队；

　　· 原先的产品结构，仅仅是不适合全品类，但是不代表完全无法进行初步信息的展示和沟通，人工的介入很好的弥补了这一缺陷，所以何不先不做改变，通过运营来做些尝试呢？如果用户真的对这些品类存在需求，再开发新模板也不迟。

　　· 我的经验就是：很多时候你没推出某个功能或商品前，用户满口说好，但是实际上线后，会不会买或者用，还是两说，做产品的童鞋们严谨些。

　　4．常旅客积分管理app，增加优惠券功能后的反思

　　（“试纸测试”的有趣之处在于替代，把从开始到结果的每个步骤，尽可能的用比较小代价的行为去做替代，从而做到“不大动干戈”而完成尝试）

　　现状：一款常旅客（整天上天入地飞飞飞，各种酒店嗯嗯嗯的物种）专用app，包含社区、信息交流和各大航空酒店集团的会员积分管理功能，同时附带着教你如何“薅（HAO）羊毛”以及推送精准的优惠信息。

　　需求：业务团队（又是万恶的业务团队）需要增加一个优惠券的功能，无非是与现有可绑定会员卡的集团进行谈判后，拿一些甜头给用户，三方互利互惠，优惠券用于够用户在预定酒店或者飞机时使用。

　　方案：根据需求，当时需要做的最低要求也不简单，起码包含三块：优惠券前台入口（查看和领取），个人中心中的优惠券查看功能（包含优惠券的使用状态同步等），以及app运营后台的优惠券录入和管理模块。

　　正常迭代：把app折腾翻一遍，再把后台翻一遍，同时还可能需要和不同酒店航空集团做后台技术对接（取决于给券的合作方），整个开发周期各位童鞋应该也初步有概念了，我们当时的开发配置（2ios，2安卓，2java，1测试）需要折腾半个月。

　　试纸测试：（首先要说，这是个曾经失败的功能，做好后没人用，原因多样，包括比较二的是合作方不提供优惠券，今天拿出来说也是一些反思后的结果）现在想想完全可以简化，app是以手机号注册的，每个用户的手机号都有，app优惠券前台也不需要做那么复杂，直接给个点击领取的功能，点击后新页面也不跳，直接提示成功与否，成功就下发短信把优惠券推到手机，然后，个人中心也不做优惠券的查看和管理，前期反正券少，先借用用户手机的短信功能对优惠券做管理和状态查看，app端可以少改动就少改动，可以不动就不动。

　　ps：来说说这个“试纸测试”的思路：

　　· 分解需求后无非是几点需要证明：用户在看到优惠券后是否会点击领取，领取后是否需要一个管理的功能，领取后实际是否会去用。

　　· 根据分解的点用“试纸测试”的思路做替代：核心点在于把整个领取后的优惠券代码查看和管理这块，借用手机自带的短信管理功能来做替代实现，省掉了app两个界面“优惠券领取后详情页”和“已领取优惠券列表页”。

　　· 还是“试纸测试”的核心思路，尽量“不大动干戈”的去做些低成本试错，先验证这个优惠券的出发点和结果是用户认可的再去完善功能。

相关的例子数不胜数，观主就不一一道来了，各位可以结合自己做过的产品，来看看从“试纸测试”的思路上，是否有新的破局方法。

“试纸测试”是一种新的解题思路，是我根据自己的产品经历总结提炼的方法论，可能各位都有用过类似方法，但是希望通过这次提炼可以帮大家更体系化的去思考和应对产品需求，在实际场景中使用“试纸测试”时需要注意以下几个要点：

　　· “试纸测试”的核心是以小博大，用小代价去预测大方向。

　　· 有时候别人说的需求是需要经过转化的，“试纸测试”就是教你如何用小而美的方案去做替代法，然后把别人的实际需求给低成本的进行试错。

　　· 如果一项新功能或者改动对原来的产品影响不大，那其实可以不用“试纸测试”，切勿陷入非用不可的泥潭，这是笨办法和无奈之举。

　　· “试纸测试”的大前提是保护现有产品，但是也切勿忘记要试错的目的，有时候过于简化，可能达不到试错的目的。

　　· “试纸测试”是一个平衡的技巧，是一种双方理解下的妥协，需求方如果很坚定的认为要做，产品经理非不做时，你得明确告诉需求方，我们需要通过“试纸测试”，更有目的、更低成本的做着看看。

　　· 最后再重复一下，“试纸测试”的代价如果很大，需要谨慎是否有必要了！

　　以上只是我对过去的思考和沉淀，希望对诸位有所帮助，换一种思路，一起在产品的道路上走的更远。

图文来源网络如有侵权联系删除