果真，非常流程才是考验产品经理基本功的试金石。趁着年底，我也参与一下这场对产品的试炼，总结一下我目前对非常流程的认知，希望对同样低级阶段的你有帮助。
非常流程每每千奇百怪，这里我尽可能地通过抽离共性进行总结，倾向于产品设计中根本层级的非常流程。
一、空状态初始状态。一样平常为首次进入系统时。无结果。输入查询条件后无匹配的结果。内容被打消。提醒、关照被一键打消等场景。网络问题。无网或超时。无权限。一样平常没有权限查看时须要缺省页面。
例如用户在表单填写时未保存或提交就切换其他菜单，此时须要考虑自动保存或保存确认弹窗。
三、上游环节/信息的缺失落
对付这一类问题我目前碰着两种详细场景：
一是历史数据的缺失落。例如之前我们为一个能耗监管系统（to G）设计了一个根据上年能耗数据给出预测和决策建议的模块，但是在产研主管那里被PASS了。
缘故原由是政府用户最初利用系统的一年中，这个模块都无法利用，由于没有历史数据可以做打算（当然实在站在我个人的角度，我会以为如果没有更好的替代方案，实在这个设计也可以保留，只是在没有历史数据时须要给用户一定的缺省提示）。
二是配置环节的缺失落。例如，在能碳系统里有一个碳核算的功能，碳排放=排放因子活动数据（活动数据即能源花费量），活动数据由用户自行输入，排放因子是由我们配置的。
同时部分排放因子区分行业或地域，只管我们的数据库覆盖了我们主流用户所属的行业和地域，但后端提出仍有极小的可能性接入的企业没有相匹配的排放因子。这时候我们考虑三种做法：
供应默认排放因子进入页面报错，奉告其缘故原由并提示其联系管理员从源头上限定对这个页面的查看此外，这种高下游配置由于某一环节的缺失落导致的非常流程，可能我们第一想法是在上游配置环节就进行限定，不做好配置就无法进入下一环节。但在实际事情中我创造，这种高下游每每不是单一的线性，而是多页面多任务协同，以是发生非常的概率还是很大的。
四、信息输入中的边界和限定
想必这条大家该当都不陌生，一样平常在入门学习prd撰写的时候险些所有的履历贴都会提醒新人把稳这条。但由于涉及的类型浩瀚，在实际事情中可能难免会有漏网之鱼。
我指的“信息输入”泛指统统往系统中输入信息的过程、组件，不止输入框组件，还有选择、导入等。
是否必填是否有默认值。如有，值为多少。支持单选或多选。如多选，是否在可选性数量上有限定，如“最多可选3项”，或支持全部可选。边界。在这里我紧张分为两类，一是数值的边界，包括数值范围、字符长度限定等，处理时可以通过限定输入（如“文本框仅支持输入>0且<100的整数”），或者点击【保存/确定】按钮时校验，校验不通过标红并提示等；二是按钮等交互组件的边界，如新增多少行后【新增】按钮禁用。数据类型。一样平常在表单中也可以通过限定输入的办法处理。排重。一样平常在填写“XX名称”时常见，比如“设备名称在租户下具有唯一性”。韶光。一是可选多远的韶光，对历史年份/未来年份是否有限定；二是能选多宽的韶光，即韶光跨度，如“最多跨选7天”。上传附件。支持的附件类型和大小等。写到这里溘然以为把这部分列到非常流程里不太合理，由于本部分是正向流程里的根本。但由于本部分确实繁琐，很随意马虎遗漏。
此外，再提醒一点，与其等事后校验让用户“改正缺点”，不如提前奉告用户填写规则，减少缺点。
五、不影响主线的非常流程
写下这个小标题，略显敷衍，让我以为些许羞愧。有一类非常可能是由于多次迭代等缘故原由造成的，积重难返。如果涌现了一些不影响主线、优先级较低的非常，我们有一个下下策的处理办法：奉告用户连续操作会发生的非常问题，其他的随他去吧……
请把稳，这已经是下下策了。产品设计每每牵一发而动全身，越今后越明显，这也提醒我们迭代前应从整体出发，对本次迭代的全局影响和联动进行充分考虑。
囿于个人履历和笔力，本篇只对产品设计中相对共性的非常流程进行了剖析。这部分相对根本，实在只要做到对各种把稳事变心中有数，每每就能避免。
但事实上对非常流程来说最难的正好是无法抽离出共性的那部分，一样平常在业务层面，这部分可以说是真正的千人千面，在社区中也看过一些履历贴，终极办理办法总结起来仿佛只有一条——“穷尽”，穷尽各种业务场景。
一人之力每每有限，在产品设计中我们须要和开拓、测试多多沟通，尤其是测试，他们的测试用例也是尽可能地覆盖各种场景，对非常流程的设计很有助益。
末了，对非常流程，送给大家也送给自己一句《盗墓条记》里的话：前走三，后走四。意为干事之前至少考虑三步，干事之后至少考虑四步。
那么，下一篇再见啦！
本文由 @工凡 原创发布于大家都是产品经理。未经容许，禁止转载
题图来自Unsplash，基于CC0协议
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。
