忙了1个多月，终于活动模块的东西基本成型了
虽然开发评审又被一泡喷。。。。
总结一下，这次产品设计中遇到的问题
需要满足四个需求功能
新用户立减、满额立减、满额立送、限时抢购
活动促销系统的设计，重点在对活动需求的拆解与角色权限的归类
不过，产品设计，归根到底页都是对功能、权限、角色的分类，然后把所有分类通过算法、交互进行串联；
产品经理就是个分类控。。。。
这次的难点主要在三个功能
活动类型的归类
权限的归属
结算模块的信息展示
分类说下
活动类型的归类
活动的角色对象主要是用户、店家、运营四方在扯皮；
用户的操作是遵守规则，进行购买
店家的操作是遵守运营设定的规则，在运营制订的大规则下设计小规则，并进行添加商品、设定价格
运营则是设定大的活动类型，并提供给店家进行操作
而自己遇到的问题就在大规则与小规则的嵌套中，如何界定大规则与小规则的边界——功能的主题应该放在哪边的问题
从自身平台业务出发，运营的控制力越大越好，从这一点出发，商家只需要选择商品与价格即可，不需要再设定任何的小规则
但是经过与开发的扯皮，发现两个问题，活动归结到底，商家没有任何规则的设定权力活动也玩不转，形式太单一；而运营，堆叠了所有的条件反而使得系统变得无比复杂，界面交互对于小白运营完全无从下手
所以针对这个问题，先对活动进行拆解，对活动条件做减法，区分出了店铺全场活动与店铺部分商品活动两种活动类型，拆解掉涉及到店铺条件筛选与商品条件筛选的店铺部分商品活动类型，只保留全场活动这一种类型；
在界面规则交互上做调整，根据梳理完成的活动类型进行固化条件，设定活动规则的边界，根据平台与店铺利益划分活动时间设定权限的操作角色
对于活动需求的归类，一类是需要用户区分的活动，一类是只在结算进行计算的活动，一类是时间类的活动，用户区分的活动高于结算型活动，时间类活动与之并行
最后的结算对账模块还没开始理，回头研究下，到底对账那边是什么东西在一直挨喷
需求分析
角色归类
边界设定
规则设定
流程设定
交互界面设计
开发沟通
优化
进入开发
9步走，暂时总结，以后补充
