首先说下我们的团队配置：2个运营、1个产品兼测试兼部份交互、1个前端1个后端、1个设计兼部份交互。这个配置在1个以运营主导的公司里也算正常，而且需求方和技术方不在1起，沟通也不是很方便。但是，作为1个产品狗，弄好和技术部小火伴之间的关系是必备技能，这可不能马虎。
我们依照常规套路来从头到尾讲1下这个需求的实现进程，大体就分以下几步：
公司不1样流程也有小差别，比如英气正规的公司可能还会有灰度发布阶段，固然这也得看发布的需求值不值得这样做，其中触及的细节步骤暂未列出，只是写了个大体框架，（你在原型出图后到需求评审进程中，会有屡次低保真模型流程测试，根据需求评审会其他小火伴的意见进行原型修改等进程）并且由于本次只是针对单个需求的制作进程，所以这个流程根据实际情况也会有些许不同。
搜集需求
当运营的BOSS首先跟我提这个需求的时候，他是这样说的：
“我需要我们这个站做1个加价购功能，大概就是买产品到达1定条件后可以用少许价格换购另外的产品，类似与这个网站的功能（因而便取出1个台湾的网站给我看）。”
明显当他这样跟我们说的需求我们是不可能回1声“哦”然后屁颠屁颠跑去开始弄加价购，我们需要问清需求背景，需求目的，期望应用到的需求场景，和是不是有后续计划（斟酌到功能拓展性）。
理解并分析需求
由于目标客户群体和欧美文化因素等缘由，面向这类用户的跨境电商服装垂直站点1直保持着简约，低调的风格，即便卖几美金的货，网站逼格也必须看起来跟国际大牌站点风格没甚么两样，正是由于这个缘由，大部份这类网站并没有多少促销活动，最多的两种促销手段是Coupon赠送和直减打折，剩下的打折手段实在是少之又少，相比于我们国内满目琳琅的促销手段，跨境垂直B2C站点这块俨然荒芜之地。
经过我1番穷追猛打的追问后，并且由于之前自己做过1段时间运营的背景，便了解到了以下情况：
- 现阶段网站库存积存较多，常规清仓打折活动效果其实不明显，并且推行入口单1（推行人员只单纯的推清仓集合页，量也不大），清仓产品在很多流量入口没有暴光，需要与关联性热卖品进行搭配销售，并且顺便利用热卖品的流量暴光清仓产品，加快清仓速度；
- 运营这边希望在有限的流量情况下提高客单价，由于加价购的门坎条件，当活动功能覆盖的流量范围大并且功能应用公道的情况下，是会对网站整体客单价产生1定影响；
- 当前运营活动手段单1，常规活动功能效果不明显，运营手段有限，需要新增活动功能；
- 未来运营还希望能增加积分功能，满赠功能等等其他活动功能（触及后续功能扩大，不属于这次需求以内，但是也要斟酌）。
至此我们明白了运营提加价购的背景，缘由和目的，这个需求的运营真实需求是：以加价购为基础，搭建1个活动功能体系，能够有效的进行商品清仓，并且可以用运营手段影响客单价，增加运营的活动运营手段。
在理解了运营的需求后，我们需要对用户需求进行分析，如何平衡用户需求和商业需求？这个是需要我们斟酌的，我们希望用户接受并且顺畅使用我们的功能，那末从用户角度来讲，我们需要注意甚么？
我们站的定位是年龄段在20⑶5岁的年轻女性，目标国家则是主要集中的欧美国家，商品价格偏低，物美价廉，以服装类目为主搀杂其他附属品类。
所以这要是想做面对面的用户调研是10分困难的，但是根据以往的数据分析和行业经验，我们可以知道这个客户群是对打折促销非常感兴趣的群体，也就是对价格敏感，更直白的从人性来讲就是爱占小便宜。那末用户的使用处景又是如何呢？
我们需要从：
- 用户装备；
- 用户使用时段；
- 用户着陆页页面场景；
这几点进行分析，终究得出契适用户使用处景的解决方案。所以我们需要在功能制作中需要注意在适合的场景下凸显价格差异，满足用户对价格敏感的特点，刺激下单。固然了，你还可以根据其他的分析模型去更加具体的分析1下，经常使用的分析模型有马斯诺，人性7宗罪，从用户动机动身，摹拟用户对需求进行验证等。
需求挑选及优先级排序
好不容易接到个需求咱就别给他在挑选和排序了。（PS：这样做是不对的！这里我们要区分需求优先级排序和需求功能点优先级排序，二者所处的阶段不1样）
制定迭代计划
此需求暂不触及大的版本迭代计划，但是对此需求的小版本迭代计划，则需要在第1次评审后根据技术，运营等小火伴的建议，评估具体功能点的实现难度，实现周期和摹拟运营方案落后行排期迭代。
转化需求
在转化需求前我们首先要知道我们首先面临的几个问题：
- 类似加价购活动在国外站点基本没有，最少在我调查的近40个不管大型综合类电商还是小型垂直电商站基本没有发现（暂时发现台湾的两个网站有，但是否是我们的目标客户群），所以，我们面临着比较高的用户教育本钱，并且需要选用适当的文案让用户理解并且参加活动；
- 此类活动即便在国内也没有哪家网站是让服装类商品参与的，基本只有小零食，快消品等通用性较强的商品。服装类商品触及到尺码，色彩，款式等个性化较高的属性，用户不太会草率加购这类产品，并且服装类商品如果尺码，款式问题触及的退换货较多，如果主商品退货，加购商品退不退就很为难，类似这类情况触及的纠纷也相对较多；
- 由于公司业务缘由，GA页面事件埋点暂时不可用，也就是说具体的页面点击事件数据暂时不可用，我们只能根据粗糙的用户行动数据,业务指标数据和用户反馈来尽可能公道的评估活动功能效果；
了解面临的问题后我们开始转化需求。
明确需求的关键节点：
我们根据用户使用处景来明确这个需求的前台关键节点：
竞品分析
肯定关键节点后，我们有针对性的进行竞品分析，调研主流网站对关键节点的处理的优劣，由于国外没有网站可以参考，在经过量方挑选后，选取了国内站点两个综合类并且流量较大，活动体系完备的网站，京东和1号店；（在此我只是论述下竞品分析的1些套路，具体分析内容由于篇幅和本文主题就不论述了）
1般我们竞品分析分为两种，1种是完全的竞品分析，我们需要进入1个新市场，或开1条新产品线，那末我们要完完全整的从战略，产品架构，产品功能点，产品界面设计等等层面去解构，这也就是我们在各大网站上最多见的竞品分析报告；但是从实际工作中来看，这类分析报告确切不怎样经常使用（但是这类分析1般用来锻炼1下自己的产品思惟是有帮助的）；我们经常使用的是针对功能点或模块的针对性竞品分析，而这类分析又分为两种：
- 带着目的去拆解，优化自己产品已有的功能；
- 功能整体分析评价，新增或借(chao)鉴(xi)相应的模块或功能。
而我们这次应当采取第2种方法，对竞品的功能进行整体分析评价，从而新增我们的活动体系。
竞品分析进程中….（此处省略几千字和N张图）
根据我们对京东和1号店的活动体系进行分析，得出以下关键结论：
1般的加购类活动类型包括以下几个：
而这么多活动规则如何有序的在购物车进行聚合展现呢？除每一个网站固有的分级策略外，1般的活动优先级展现是这样的：
至于为何是这么个顺序，有兴趣可以自行去研究下，笔者在此就暂不论述啦，除以上关键路径外，我们还对关键节点页面的活动展现，交互方式，规则说明等做了详细的研究和参考。在分析的进程中我们发现1个很严重的问题，这么复杂的活动，翻译成英语的话，还真没几个人能懂。。。打个比方，”加价购”怎样翻译？我专程问过好几个国外同事，也没人能简洁的描写出来的，没有1个词来形容这个词，他们乃至没有听过这类活动。
所以，如果直接依照国内的加价购，完完全整的展现出来的话，那末我的1版本草稿业务逻辑方案是这样事儿的：
这仅仅只是1个满额减的完全的流程，里面还触及到阶梯满减的概念，那末除满额减，还有满额赠，满量增，满量减，满额折，满量折，每个都这么来1遍？中国人都绕晕了吧，何况还得翻译成英文，还得通俗易懂短小精悍，即便不斟酌技术本钱，如果这个作为第1个版本就这么个推出，基本就GG了。
所以，在功能框架1定的情况下，如果照搬国内的设计并且直接推出全套版本明显不能满足我们的需求，我们要另辟蹊径，站在国外友人的脑海里去斟酌问题，去斟酌他们的思考方式和语言特点，虽然我们要重新教育用户，但是要尽量的将用户理解本钱降至最低。
因此终究此功能的初版大致方案框架是这样事儿的：
暂时舍去阶梯概念，舍去满折方式，以1个Icon为节点，包括满额，满量两种活动方式，我们需要教育客户1看到这个Icon就知道这是类似于加价购的活动，不再在标识上辨别满额，满量概念，在用户的购物动线上，从Icon，文案1步步引导用户，完成对活动的理解和参与，全部进程是个很自然的引导进程，不用再去让用户纠结规则，也不再去设置长篇大论的活动引导页。
到了这里，我们就不再出现加价购这个名词了，我们称之为APA活动体系，去养成用户对APA活动的认知和使用习惯。
原型出图
前台原型出图
这个需求在原型制作环节全部页面展现虽然简单，但是触及到多规则，后台设计多流程。前端页面动态数据较多，特别注意规则说明和异常说明详细无遗漏，否则到时候做完了测试的时候就不可避免的开怼。并且与用户的交互也比较多，所以我采取了低保真交互原型，并且把交互方式录成GIF放在原型包里面，（必须要特地去提示开发和设计某些按钮是可以点的！！！）具体的原型这里就不放了（不要打我，我1般做低保真交互模型的原则是做出特定的交互方式，对界面元素只是标注下信息层级关系，不会去加色采和按钮样式引诱设计师，每一个人都有每一个人的原型写法，如果有感兴趣的同学可以跟笔者交换下），在跟设计和开发反复沟通交换和后两次评审会以后，我们的初版前端成品是这样的：
商品列表页Icon展现：
由于之前设计规范的缺失，在商品列表页我们补充并且制定了活动功能的Icon规范，采取红底白字的Icon方式展现活动，这为后续的其他活动功能留下扩大空间，鼠标移入会有简短说明。
商品详情页活动规则和选购商品展现：
商品详情页首先展现的是1段引导性文案，我们不会上来就告知用户活动详细规则，由于第1英文解释起来实在太麻烦，2来过于繁琐的文案也会造成页面混乱。我们把既定的规则放入展开模块当中。这个页面触及到的程序规则就是页面展现的相应文案，根据后台配置的活动类型不同而变化，比如满减活动，这里就会提示 “You have a chance to get this following fashion items in a low price:”
如果后台配置的是满赠活动，这里就会提示”You have a chance to get this items for free”,同时按钮文案也会变成 “See the free items”,里面的规则说明也会相应变化。
这个链接会引导客户去1个专门为APA活动定做的专题落地页当中，可供用户选择更多APA商品，固然这个专题落地页模板的制作也又是1个比较好玩的事情了，直接上部份设计稿吧（Low-price items里面的图标文案超越图标范围是由于我在截图的时候只是缩小了页面，但是文案是用html写的，不是图片，所以字体缩小不了）
商品专题页页面截图（部份）
购物车页展现：
购物车里面我们参考了部份竞品的分栏方式，并且转化成我们自己的分栏方式，这里特别要提的是购物车里面的逻辑较为复杂，除文案、提示语的变化，和到达目标值以后的商品状态变化，按钮样式变化之外，比较无语的是在和技术沟通的进程中，发现了很多历史遗留的逻辑问题，和与其他系统对接留下来的未解决问题。
在这个需求中，我们的购物车没法同时存在两条相同的商品数据，并且没法存在多个免费商品数据，这些购物车规则牵扯到的方面较多，优化本钱很高，这就致使了我们必须想出1些折衷方案，尽可能让用户体验不那末糟或造成相当大的困惑，(事实证明在对国外同事做体验测试的时候在极端情况下是存在1些困惑问题，不过这些问题出现频次较少，可以交代客服人员在客户询问的时候进行解释。)
后台原型出图
后台制作中首先要注意在活动功能管理板块下预留其他活动的扩大空间，并且注意前后真个数据交互标注清晰，提早设计好表结构和字段方便开发建表，理清楚业务操作逻辑后，即可出图啦,这里我就贴操作逻辑和最后的成品展现，后台操作逻辑和关键节点解释以下：
如何判断我们的功能到达目的？
我们回过头看看我们之前的需求分析，运营希望加快清仓产品的清仓速度，提高清仓产品的暴光，那这只是业务场景，对我们这个功能来讲，清仓产品只是1种产品类型，那末如何判断我们这个功能是不是有效？我们根据实际条件下(我们没法拿到页面点击数据)可以取到的数据制定以下实验：
我们采取独立样本T检验对功能效果进行评测，总共10个清仓产品，产品转化率近似，20个热销产品，转化率一样近似。
分3组制作3个专题：
- 第1个专题为普通专题，将10个清仓产品与20个热销产品混合放置便可；
- 第2个专题为加价购专属专题，设定活动方式为满减，将10个清仓产品作为20个热销产品的加购商品；
- 第3个专题也为加价购专属专题，设定活动方式为满赠，将10个清仓产品作为20个热销产品的赠品；
然后针对3个专题每个专题抽取30个独立用户分组，用户群的用户基数近似相等，用户群转化率类似，采取相同的推行渠道，由于没法精确肯定用户数量，我们只需告知推行保证逐日每一个专题划分的每个群组的流量保证在1个特定数量XXXX左右，延续两周，终究得出每一个用户分组的以下数据：从这个专题页落地的用户所下的定单中，同时包括清仓产品与热销产品的定单数/所有定单数，我们给它起个名字叫近似加购率（由于即便在加价购专题里清仓产品和热销产品在1起也不1定就是参加加购活动加购的）。用图表展现就是这样：
得出数据后做两两独立样本T检验，终究判断实验结果，这个网站可以根据你的数据样本辅助你完成此类实验：http://www.evanmiller.org/ab-testing/t-test.html
（对T检验的方法和适用范围感兴趣的读者可以回顾下大学知识或谷歌1下，这里笔者就暂不列出实验具体步骤了，后期笔者会计划专门写1篇这类实验的完全进程，这篇文章就只讲1下笔者的实验思路。）
需求评审
这1环节其实其实不1定只在这1阶段做1次，就像我上面说的，笔者出了初版方案后拉几个团队成员进行初稿评审，理出许多问题，然后再进行修改，针对1些短时间没法实现或本钱较高的功能点进行排期或删减，有时候也可能会出现2审，3审的可能性咯~如果到3审还有很多问题那就相当的揪心了，所以1般都是团队中过两遍，然后拉上BOSS们再终审1遍基本就OK了。终审是最需要用心的时候，1定要注意自己的表达能力和情绪感染力，让Boss能明白并且认同你们的方案。在会议上面对他人的发问要及时给出有理有据的答复，这1点在终审上是要特别注意的，良好的演说能力也能为你的需求过审少很多麻烦。
设计开发
设计开发中要随时与团队成员保持联系，特别是与设计沟通更加频繁，你们要商讨具体的交互细节和页面细节，切记不可用特定的言语干扰设计思路。
比如说，有些产品会要求设计某个按钮用甚么甚么色彩，某个元素大1点，小1点，这都是不可取的。你只需要肯定好信息层级，告知设计师由于业务需求，哪些元素需要强调，哪些需要弱化便可，设计师会根据设计规范和自己的设计思路进行设计，否则就会和设计师怼的没完没了了；至于与开发的沟通，主要是在逻辑层面的交换会更多些，而且笔者认为最好能懂些技术知识，即便1点不懂你也要分清楚哪一个开发是做哪1块的，遇到问题找谁，跟他应当怎样沟通，如果存在沟通障碍，那末程序员1般的反应都是—>生闷气，不理你，哈哈，你要知道，大部份程序员还是很可爱的。当你的需求提上去后，甚么时候测试，甚么时候上线，这块的进度1般都由项目经理掌控，固然，自己的心里也要有谱，有自己的项目进度表。
测试
测试确切是个心累的活儿，如果你们公司的测试人员较为专业，会为你省下很多麻烦和时间，你只需要负责上线前每个阶段的验收便可。否则，你就得自己写测试用例，测试反馈，直到上线，这里每一个公司的流程不1样，这里也就不过量论述，免得产生误导。
上线视察，数据反馈
在此之前需要跟运营人员和推行人员打好招呼依照事前设计的实验方案进行实验，在上线以后逐日监控数据变动情况，每组数据的流量是不是有异常，专题商品库存情况，下架情况，等等，总之需要控制变量，确保实验依照时间顺利完成，最后拉取实验数据进行数据分析，根据分析结果肯定此功能的可用性，得出分析报告反馈给团队成员和BOSS。
版本迭代
这1部我并没有写到最开始的那个流程图当中，对1个完全的产品有大的版本迭代，对1个功能一样也会有相应的版本迭代。在这个需求中，我们前面根据12期需求评审以后和后续根据运营人员的实际情况进行功能扩大，针对此功能大致得出以下迭代计划：
固然，这个迭代计划只是作为产品人员自己的计划。具体每阶段是不是上线还需要根据每阶段的数据反馈和公司具体的运营需求和运营策略的变化（在1个运营主导的公司就是这样咯~）进行调剂，总之，用心对待自己做出来的东西，不单单是生孩子，养孩子的责任你一样也逃不了。
至此，这个需求从初始到上线的1个流程就基本结束了。虽然仅仅只是通过1个需求来回顾了1下需求从开始到结束的全部框架，不知不觉也有了近7000字，对里面的细节部份请谅解我没有在本文中全部写出来，文中还有许多的不足请各位读者给予指正，私信评论都可，哈哈，欢迎拍砖。
作者：白子
来源：人人都是产品经理
