主次原则
主次原则很好理解，就是重要的和不重要的要区分开，分清主次，就像你去参加一个宴席，要分宾主落座，不能喧宾夺主。在产品设计上主要是利用颜色、文字来进行区分，后端系统是面向业务的，界面也更加丰富，有展示数据指标的、有录入表单的，这时就要从下到下，从左到右，按照浏览习惯进行布局，重要图表或字段要通过颜色进行标识或加粗。
次要信息可以收缩，由用户选择展开，关键指标的明细通过链接方式以弹出页面或新页签方式浏览，重要信息尽量在一页显示，在信息过多时采用左右或上页划动时，重要部分要锁定。
直接原则
所谓直接原则就是，在产品设计时要简单直接，能一步操作的别分成两步，能在一个界面完成的工作不要用弹窗或浮层。在相关操作的文案术语上也要简短直接。
用尽量少的信息让用户以极少的成本就能完成操作，别把用户绕迷糊了。
统一原则
这个更容易理解，在画原型图时，都会使用统一的组件库，PRD都有标准的模板，在系统编码时都有统一的编码规则，源码都统一管理，接口都采用标准协议等等。
在后端系统设计时，我们可能会更注重于业务逻辑的的实现，对于界面都不太关注，在同一系统中可能是多个人开发的，元件大小、排列、命名等都不统一。
界面是给用户的第一感觉，专业与否也能体现出来，所以要统一相关标准，沟通时使用统一的术语，设计使用统一的模板，统一的样式。保持统一，降低用户的认知难度，避免出现几种不同样式，增加用户操作成本。
少做原则
少即是多，互联网业务变化太快，虽然后端系统相对稳定，但是也会伴随着业务调整持续开发，否则大家996都在忙什么呢？
快速迭代，快速上线，AB测试，目的是降低试错成本，最大限度的满足业务需求，所以产品设计时要遵循MVP原则，产品和研发都应该学习如何把握用户的心理预期，揣摩用户的心智模型，进而实现用户的心理预期。
项目管理中有一个镀金，说白了就是画蛇添足，尽量用最少的时间，最少的资源实现最大的价值，这才是目标。
在以前接触的很多项目需求，业务这也要那也要，产品也难以取舍，研发就照着PRD设计，最终做了很多工作，却没有达到用户预期，这是普遍存在的问题。
做多，做复杂容易，做少，做简单难!
反馈原则
前端系统的操作时的提示、反馈给用户的信息非常得要，这是用户体验的关键。
后端系统在查询时虽然借助于分页、缓存等技术速度有所提升，有时还会有大量的结果返回，用户还要等待；在单据保存、审核等操作时，后端处理逻辑比较复杂，有时成功有时失败。对于这些都需要实现功能与用户的交互反馈。
所以在设计时要尽量对每个操作能做到人机交互反馈，让用户清楚知道目前在做什么，处理什么样的状态，减少疑问。
反馈的文案一定要通俗易懂，千万不要将代码错误返回，这样会大大降低用户体验，不是问题也是问题了；技术查错要依赖于系统日志，而不是前端的界面错误提示；当然可以定义一些标准错误代码便于解决问题。可以学习Oracle，它们的错误代码ORA-XXXXXX，知道错误代码，就可以基本定位问题，这个在系统开发时值得借鉴。
对称原则
人是对称的，中国的很多建筑也是讲究对称的。关于对称，我的理解是在产品设计时有时要从整体上考虑，有时要从局部考虑。
像一些常用的展开与收缩也是一种对称，它们有依存关系；所以对称不单指元件的布局，操作上有时也是对称的。
单一原则
这个是面像对像设计时非常重要的原则，在产品设计上也同样适用。系统功能模块设计时不能眉毛胡子一把抓，不要期望在一个功能功界面上满足用户的所有需求，要根据业务原则、操作场景进行切分，每一步操作可以与下一步关联，引导用户操作。
总结
在产品与系统设计时可以尽量考虑这些原则，当然代码编码时有很多标准、原则，UML建模、设计模式……
在实际工作中是否真的可以做到，能做到多少，这些也是值得深思的，复杂问题简单化、简单问题复杂化属于二律背反规律，还是要寻找一个平衡点。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>在上一篇文章里，我们分析了游戏中用户的分享行为：用户的分享动机主要来源于炫耀需求和游戏资源需求；分享诱因可以提示用户完成分享行为；分享反馈有助于强化用户分享行为。
在这篇文章里，我希望和大家讨论一下落地的事情：分享系统。什么是分享系统？什么是好的分享系统？分享系统包含着怎样的要素？相信看完这篇文章，你会有所启发。
分享系统
什么是分享系统
分享系统，顾名思义，就是保证用户完成分享动作的系统。分享系统除了承载了游戏内分享的功能之外，也包含分享功能的展示策略及确保用户完成分享动作的一系列机制。
设计分享系统的意义在于最大限度地利用用户分享的能力，为游戏设计者获取回流和新增用户。
具体来说，就是深刻把握用户心理，利用用户的分享动机，提供分享触发器，让用户顺利完成分享动作，并提供反馈强化用户分享行为。
分享系统需要依附于用户本身的游戏路径，制定分享展示策略规划不同场景的展示，并利用机制让用户完成分享动作。
比如说，moba游戏战报分享这一板块，设计时就需要判定用户当前游戏的状态，根据不同的状态提供不同强度的分享提示。用户输了，那最好没有分享提示；用户赢了，分享弱提示；用户获得胜方MVP，分享强提示。提示中包含提供给用户的资源奖励，用户完成分享动作后，系统立刻将奖励发放给用户，强化用户的分享行为。
什么是好的分享系统
设计分享系统的目的是为了保证用户分享动作，因此，分享转化率越高，证明分享系统的设计越成功。
用户对分享系统的感知强度，会直接影响用户的分享转化率。但是二者不是简单的线性关系，而是随着用户对分享系统的感知强度增加，用户的分享转化率先逐渐升高，再逐渐降低。
直观来理解，就是分享系统“骚扰”用户的强度，强度到达一个阈值之前，用户只是当作提示，强度越强用户越容易被促使进行分享行为；达到阈值之后，用户便会觉得厌烦，强度越强用户的厌恶心理越强，越抵触进行分享行为。
用户分享转化率的最高点，会随着用户分享的心理成本大小，以及动机强弱而动态变化。
用户分享的心理成本越高，这个点越偏左，即用户在更弱的刺激下就会拒绝分享了。
以拼多多的分享砍价举例，都市丽人将砍价分享到微信群的心理成本肯定远远大于小镇大妈，因此，在同样的分享场景下，小镇大妈会疯狂拉人头砍价，而都市丽人会直接放弃。
用户分享动机越强，这个点越偏右，即用户能接受更强的刺激。
比如一局游戏中，用户赢了肯定比输了分享动机更强，这时候即使强硬地弹出弹窗让用户分享，用户更有可能欣而分享而不是愤而关掉弹窗。
好的分享系统，应该区分不同的分享场景，识别用户的心理成本和动机强度，控制不同的分享感知强度，以达到更高的分享转化率。
分享系统要素
设计分享系统有三个要素，分别是分享点、分享触点和分享反馈。
分享点
分享点，即用户在游戏的整个体验中，可以进行分享的时机或者场合。分享点需要具备两个条件：用户的游戏节奏放缓，且用户有意外的体验。
用户的游戏节奏放缓，指的是用户并没有进行密集的游戏操作，或者游戏目前阶段允许用户进行休息。比如常见的每一局游戏结束的战报时间，以及用户在游戏里闲逛的时间，都算是游戏节奏放缓。
游戏节奏放缓允许用户将注意力从游戏操作本身解脱出来，转移到自己获得的游戏体验上，也允许用户跳出游戏进行分享动作。
用户有意外的体验，指的是用户在某个时刻遇到了和自己以往或者和他人不同的体验。只有用户意想不到的体验，才能引起用户的注意，从而形成分享动机。试想一下，平平无奇、一如既往的事件，根本不会让我们有分享的想法。
就像你每天都在楼下同一个摊位买同一种馅的包子，每天的口感口味都一模一样，那你肯定不会有分享的想法；但假如有一天这个包子突然肉变多了，你就会想发一条朋友圈表示自己的意外。
完成分享行为，需要用户有分享的动机，同时也需要有适合分享的环境。上文阐述的两个条件，意外的体验正是为用户提供了分享动机，而用户游戏节奏放缓则给用户营造了分享环境。
分享触点
分享触点指的是分享点上用户感知到的内容，分享触点引起用户分享动机。
正如上文提到的，分享触点需要让用户感到意外，可以是表现了一个意外事件，比如战报页展示用户在上一局中的超神五杀；或者创造了意外体验，比如玩家在游戏中穿过一片丛林突然看到了日落的美丽景观。
让用户感到意外，就首先需要让用户觉察到。分享触点的意义在于，将无形的事件转化为有形的内容，从感官上刺激用户，让用户形成具体的分享路径。
卡牌游戏中，用户每次抽卡的概率是未知的，而大部分时间用户的运气都是不好不坏的。当用户欧气爆棚时，用户一定会感到意外。
在食物语中，如果用户抽卡的手气很好，开卡之后就会弹出一个额外的页面“少主，您的手气太棒了”，吸引用户进行分享。
在这个分享触点，表现了玩家”手气很好“这一意外事件。另外，手气好究竟如何定义呢？用户自己可能有一些标准，可能也不是很清楚。当系统提示用户”你手气很好“的时候，相当于将用户的好手气具象化了，进而刺激用户完成分享行为。
分享反馈
分享反馈，即用户完成分享行为后， 系统给予的一系列正向反馈。
在上一篇《游戏分享行为》中有讨论过，当用户完成一个行为时，立刻给他一个奖励，也就是正反馈，让用户的行为受到强化，用户下次也更倾向于完成这个动作。
在分享系统中也是如此。用户成功分享回到游戏后，如果有即时的反馈，用户感知到反馈后下一次会更倾向于分享。
用户感受到的分享反馈，主要体现在用户收到奖励时。当用户感知到他受到的奖赏是有用且份量不小的时候，之前的分享行为会被强化。
要保证用户可以感知到奖励对自己的好处，就需要做到以下两点：奖励的设置上，要保证对用户有用；奖励的发放上，要通过各种方式告知用户奖励的价值。我们来分别对这两点进行阐述。
有用的奖励
除了一些剧情为主的游戏之外，用户来玩游戏，一般是为了满足社交需求和自我实现需求，即“更强”和“更好看”。因此，能够服务于游戏主要养成系统，或者服务于用户的外观的奖励，是对用户最有用的。
服务于游戏养成系统的奖励，可以设置为金币、抽卡券、武器技能升级材料等，服务于外观的奖励，可以设置为皮肤体验券、皮肤碎片等。
告知价值
奖赏发放的方式能够影响用户对奖赏的感知程度，同样是发放一定量的金币，图文并茂的弹窗提示一定比纯文字的toast提示更能吸引用户的注意力，更容易让用户形成记忆，从而强化分享行为。
同一个游戏界面toast提示和弹窗提示对比。
分享系统在游戏中一般比较脱离游戏主线玩法，也缺少成熟的方法论。很多人设计游戏分享系统的时候，总是东看看，西看看，找一些竞品来拼凑。
其实，从用户的心理出发，思索系统需要包含的板块，再完成系统框架的搭建，也同样适用于游戏分享系统的设计。
这有助于我们对自己设计的东西更有把握，评估和修改的时候，更容易发现哪里出了问题。
希望本文可以对你有启发。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>我认为所b端系统的设计都围绕一个原则：以满足业务的需求为准，用系统减轻业务实际操作的负担，提升工作效率。
所以对于发票管理系统来说，其设计也都是围绕业务的实际操作来进行的，发票系统主要是为了服务于税务同学，因而不可避免的也会涉及到一部分的税务知识，对刚上手的同学来说可能不是特别友好，我专业是学计算机的，刚开始接触发票系统时，完全不清楚红票、蓝票，抬头、税额等这些发票里的门门道道，所以前期走了一些弯路，也花了时间去适应，这次我通过结合发票的基本知识、发票系统的基本设计思路以及我在熟悉系统中遇到的坑来对系统设计进行分析，希望会给你带来帮助。
01
首先我们了解一下什么是发票？
发票,过去称之为“发货票”，是表示钱已经收到，货已经发出的一个手续，其实在晚清时期就有发票的雏形，当时买卖双方很希望有一种能证明交易过程的真实性的证据：商家销售货物所开具的一份“发货单”，也是买卖双方进行交易的商品清单，当时的这种凭证其实很类似于收据，后来随着朝代的更替、结合交易场景发票被逐步优化，就有了现在的发票。
度娘说：发票是指一切单位和个人在购销商品、提供或接受服务以及从事其他经营活动中，所开具和收取的业务凭证，是会计核算的原始依据，也是审计机关、税务机关执法检查的重要依据。收据才是收付款凭证，发票只能证明业务发生了，不能证明款项是否收付。
简而言之，发票就是发生的成本、费用或收入的原始凭证，正因为发票是唯一凭证，所以每张发票都会有一个特定的发票号码。
其实我们实际生活中涉及到发票的场景非常多：吃饭、住宿需要找店家开张发票，线上购物找商家开发票….对于商家来说，发票主要是公司做账的依据，同时也是缴税的费用凭证，而对于消费者来说，发票主要是用来报销的。生活中会出现一种场景，商家反馈本月度票用完了，承诺给消费者下个月开票。这是因为公司会定期从税务机关购买发票，如当月票已被用完的话，一般都会下月补开。
发票分为普通发票和增值税专用发票。增值税专用发票能用于抵扣，增值税普通发票只能做记账凭证。目前专票只支持纸质发票，而普通发票电子、纸质票都支持。
知道了发票类型、形式还不够，还需要知道一张真正的发票长什么样子，有哪些字段。
附一张滴滴的发票：
我们可以看到，一张发票中会包含发票抬头、发票税率、发票号码、开*公司等信息。
设计发票系统需要从以下几个维度去考虑：
02
发票数据的基本操作
开具发票：需要输入哪些发票信息，提交信息后如何开票
对于抬头信息、电子邮箱或者邮寄地址是需要用户来录入的，像税率、纳税人识别号、开票人信息等都是公司自己配置好的，自动带入即可。当信息填写完成后，大部分中小型公司都是会通过调用第三方系统进行开票，当开票成功后，就如上文所说，生成一个特定的发票号码。
查询发票：查询条件有哪些，支持哪些数据的展示。
要明确的是，查询项的主要目的是用于定位数据。除了最基础的一些查询项，如发票申请时间、开票成功的时间，还要根据业务日常的操作诉求进行设计，比如是否需要根据提交人进行查询、是否需要通过交易订单号查询等等
查看发票：除了发票本身信息以外，还支持查看哪些信息。
查看发票详情里的字段一般是包含了查询项以及提交项的内容，除此之外集合实际业务场景考虑是否增设其他信息，还如自动带入的配置信息、订单信息、商品信息等
修改发票：发票中哪些信息支持修改。
修改的功能主要会涉及到安全问题，所以这里要考虑功能的权限配置，同时还要给出修改规则，即哪些字段可以修改，哪些不能，如用户自己提交的信息基本都是可以修改的，而像系统自动带出的字段都是不允许修改的。
03
发票数据状态的流转
“用户提交一条数据 –发票系统生成一条数据–提交三方系统开票–返回开票结果”。
这是一张发票在系统的正向流转过程。简单来说就是未开始-进行中-已完成/失败，我们可以发现，这里其实有涉及到数据的状态变更，同时还用考虑在对应不同的状态下，会有不同相关联的操作，比如说对于已成功开具的发票，我们可以对此进行红冲，红冲后，我们就会得到一张“红票”，未红冲的开成功的票即“蓝票”（这里要说明的是，虽然“红票”是基于对“蓝票”进行红冲后生成的，但实际上这属于两张发票。有各自不同的发票号码。）再比如，开票失败以后我们可以再次开票等等。
04
与不同系统之间的关联。
我们上文说过，发票是发生的成本、费用或收入的原始凭证，是有一个前置动作的，所以对于发票系统来说，他不会是一个完全独立的系统，他要从订单系统、退费系统、商品系统中获取信息，从而对发票信息进行判断。如在开发票时，发票系统需要去订单系统抓取订单状态进行判断，当订单状态为“已付款”或“已收货”（具体状态因业务场景而定）时才能发起，像京东这样的电商平台，会自动抓取订单“已签收”状态进行自动开电子票。同时发票系统也要去判断当前订单是否重复开票；同理，当订单状态为“已退费”时，发票系统也需要对之前开过的票进行红冲。所以熟悉发票系统的前提下，也要求对其他系统有一定熟悉。
05
最后的思考
不管从功能支持来说，还是从界面设计来说，不同业务下不同公司的发票系统设计的肯定不一样，但是本质还是围绕发票本身的性质结合业务诉求进行设计，这篇文章主要提供一种系统设计思路。上文的这些内容其实都是一些很基础、但是一不注意就会被忽视的思考点。其实在我看来，一个好的产品经理需具备的必不可少的能力就是踏实的落地能力。从知道这个事怎么做，到最后把这件事做好，这其中如果不细细思考，得出的结论也大多是些泛泛之空谈。从单纯的处理某个功能，到最后站在一个比较高的角度去看系统的整体设计，最后输出你对系统的思考，试着输出你认为还需要优化的点，这都是你的一种成长。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>