购物车里面我们参考了部分竞品的分栏方式，并且转化成我们自己的分栏方式，这里尤其要提的是购物车里面的逻辑较为复杂，除了文案、提示语的变化，以及达到目标值之后的商品状态变化，按钮样式变化以外，比较无语的是在和技术沟通的过程中，发现了很多历史遗留的逻辑问题，以及与其他系统对接留下来的未解决问题。

　　在这个需求中，我们的购物车无法同时存在两条相同的商品数据，并且无法存在多个免费商品数据，这些购物车规则牵扯到的方面较多，优化成本很高，这就导致了我们必须想出一些折中方案，尽量让用户体验不那么糟糕或者造成相当大的困惑，(事实证明在对国外同事做体验测试的时候在极端情况下是存在一些困惑问题，不过这些问题出现频次较少，可以交代客服人员在客户询问的时候进行解释。)

　　后台原型出图

　　后台制作中首先要注意在活动功能管理板块下预留其他活动的扩展空间，并且注意前后端的数据交互标注清晰，提前设计好表结构和字段方便开发建表，理清楚业务操作逻辑后，便可出图啦,这里我就贴操作逻辑以及最后的成品展示，后台操作逻辑以及关键节点解释如下：

　　表单部分截图如下：(部分字段)

　　添加加购商品如下：(部分字段)

　　如何判断我们的功能达到目的？

　　我们回过头看看我们之前的需求分析，运营希望加快清仓产品的清仓速度，提高清仓产品的曝光，那这只是业务场景，对于我们这个功能来说，清仓产品只是一种产品类型，那么如何判断我们这个功能是否有效？我们根据实际条件下(我们无法拿到页面点击数据)可以取到的数据制订以下实验：

　　我们采取独立样本T检验对功能效果进行评测，总共10个清仓产品，产品转化率近似，20个热销产品，转化率同样近似。

　　分三组制作三个专题：

　　第一个专题为普通专题，将10个清仓产品与20个热销产品混合放置即可；第二个专题为加价购专属专题，设定活动方式为满减，将10个清仓产品作为20个热销产品的加购商品；第三个专题也为加价购专属专题，设定活动方式为满赠，将10个清仓产品作为20个热销产品的赠品；

　　然后针对三个专题每一个专题抽取30个独立用户分组，用户群的用户基数近似相等，用户群转化率相似，采用相同的推广渠道，由于无法精确确定用户数量，我们只需告知推广保证每日每个专题划分的每一个群组的流量保证在一个特定数量XXXX左右，持续两周，最终得出每个用户分组的以下数据：从这个专题页落地的用户所下的订单中，同时包含清仓产品与热销产品的订单数/所有订单数，我们给它起个名字叫近似加购率（因为即使在加价购专题里清仓产品和热销产品在一起也不一定就是参加加购活动加购的）。用图表展现就是这样：

　　得出数据后做两两独立样本T检验，最终判断实验结果，这个网站可以根据你的数据样本辅助你完成此类实验：

　　（对于T检验的方法和适用范围感兴趣的读者可以回顾下大学知识或者谷歌一下，这里笔者就暂不列出实验具体步骤了，后期笔者会计划专门写一篇这类实验的完整过程，这篇文章就只讲一下笔者的实验思路。）

　　需求评审

　　这一环节其实并不一定只在这一阶段做一次，就像我上面说的，笔者出了第一版方案后拉几个团队成员进行初稿评审，理出许多问题，然后再进行修改，针对一些短期无法实现或者成本较高的功能点进行排期或者删减，有时候也可能会出现二审，三审的可能性咯~如果到三审还有很多问题那就相当的揪心了，所以一般都是团队中过两遍，然后拉上BOSS们再终审一遍基本就OK了。终审是最需要用心的时候，一定要注意自己的表达能力和情绪感染力，让Boss能明白并且认同你们的方案。在会议上面对别人的提问要及时给出有理有据的答复，这一点在终审上是要尤其注意的，良好的演说能力也能为你的需求过审少很多麻烦。

　　设计开发