搞定异常的七字真言增删改查显算传.docx

搞定异常的七字真言增删改查显算传.docx

《搞定异常的七字真言增删改查显算传.docx》由会员分享，可在线阅读，更多相关《搞定异常的七字真言增删改查显算传.docx（14页珍藏版）》请在冰豆网上搜索。

搞定异常的七字真言增删改查显算传

异常是大多数

1.什么是异常

是程序运行中，因外部因素（设备错误、输入错误等）导致的程序异常。

逻辑层的程序异常，通常是产品经理的责任。

2.粗略判断异常是否完整

一个带有输入、输出、传输、运算的完整功能模块，产品经理出的原型图中，如果异常情况的页面没有占到70%，那就需要继续完善。

3.举例——昵称为必填，且不能重复

只有结合产品、用户、场景，才能做出合理的异常情况。

举例仅供参考。

（1）昵称输入有误

然后在Axure中对应元件上写说明内容，如下图：

（2）昵称被占用

同理，在对应元件上写说明内容，如果是移动端原型，可在旁边放便签描述（另一篇《完美“登录”，从去掉“注册”开始》中有附图）。

以上提示，只是局部提示。

根据场景不同，还会有关联性异常情况。

比如在填写时，昵称尚未被占用，填写其他内容过程中，刚好被占用导致最后一步无法保存，也需要处理。

如果涉及到翻页情况，又会产生保存时机的问题。

是点下一步就保存，还是最后提交时统一保存资料。

如果点下一步就保存，那在第二步未填完就退出页面，又该如何处理。

因此，需要根据实际情况来处理异常情况。

排查异常的七字真言

七字真言：

增、删、改、查、显、算、传

1.增：

新增、创建、添加

开篇的输入昵称，就属于增。

另外，还包括注册账号、上传图片等。

做【新增】功能时，从以下三个角度考虑：

（1）上下限/建议值/默认值

∙字数输入的上下限、图片/视频大小，前后端都做限制校验。

（例：

昵称限制4~10个字，前端需要校验，不在范围内不让提交。

但是后端也不能相信前端，还需要自己再做校验，防止一些技术手段绕过前端给后端提交非法昵称。

）

∙图片/视频尺寸、图片/视频比例，给建议值。

（例：

下图头像项的图片要求）

∙一些低频选项，可以给默认值，无需每次都操作。

（例：

性别默认男，城市默认当前定位点）

（2）类型校验/格式校验

∙例如：

输入类型的全角和半角，可做自动转换提高体验。

∙导入表格的功能，那就限制只能上传Excel格式的文件。

另外，.apk、.exe等可执行文件，需要特殊处理，微信会加后缀，来降低风险。

（3）容错机制/关联变化

∙手机号已被其他账号绑定，需让用户可做更换绑定、合并账号等操作。

∙昵称被占用，给多个建议昵称，让用户手动选择。

∙自动保存为草稿、编辑状态下阻止浏览器关闭等。

∙自动生成编号、排序方式，关联出现的状态，及页面变化。

以上，有些限制是出于产品体验考虑，例如图片过大，会导致浏览时加载慢影响体验；有些限制则是出于安全考虑，例如不能上传可执行文件。

一些低频问题，尽量静默处理，例如：

∙非网盘类应用，自动压缩太大的图片。

∙邮件发送APK、EXE类可执行文件，无需加后缀。

∙及时通讯软件发送则加后缀，但能通过安全扫描的也可以不加。

∙手机端选择年月日时，给合理的默认项，比如1990-06-15，6月是月份中的中位数，能快速定位到1到12月任意月份。

15日同样是中位数，能快速定位到1~

总之，一切围绕用户体验去考虑，使用体验、安全体验、设备体验等等。

小思考：

假如你是支付宝产品经理，在PC端做人脸识别认证的时候，你会怎么做？

如何考虑？

2.删：

删除

删除操作比新增操作风险大，但逻辑相对简单，有以下四种情况：

（1）删除是否可逆

∙需求上可逆、需求上不可逆

∙逻辑上可逆、逻辑上不可逆

（2）是否批量删除

（3）是否涉及权限

（4）逻辑删除or物理删除

∙逻辑删除是通常说的假删除，给一条数据做了个标记，其实这条数据还在数据库里；

∙而物理删除是指从数据库里真实删除了某条数据，常规意义上是不可恢复的。

如上图：

1.弹窗一，单个删除操作，逻辑上可逆，但用户体验上不可逆，所以需要二次确认。

2.弹窗二，既属于批量操作，也属于权限操作，需要高级别权限人员扫码确认。

扫码后，手机端的确认页面上，需要展示一些重要信息，方便高权限人员做决定。

3.二次确认方式：

弹窗确认、弹窗扫码确认、弹窗密码确认、弹窗验证码确认、弹窗指纹确认等。

如上图：

在重要的删除操作时，增加【影响范围】，说明当前删除操作可能会影响到的地方，如果这种影响是需要手动解决的，就需要去逐一排查。

比如删除之后，榜单是不是空了、满减活动是不是凑不够满减额度了、轮播图上展示的还是已删除的商品、定时推送发出去的链接打开却告知商品不存在，等等。

总之，删除有风险，设计需谨慎。

不删可以，就别做删除功能。

后台产品，可在筛选区域或系统设置中加个【展示已删除xxx】的复选框，勾选之后，才在页面内展示已删除的信息。

至于能否恢复就是另外一套流程和逻辑了。

3.改：

修改、编辑

参考【新增】的一些规则，很多页面可以复用【新增】的页面。

但新增员工类涉及密码的，复用时需去掉密码输入框。

需要注意两点：

（1）能否修改

∙用户ID不可修改。

∙用户状态，需要有权限的人才能修改。

（2）保存机制

∙定时保存。

∙失去焦点时保存。

∙其他条件触发，比如网络变化等。

4.查：

查询、搜索

两种：

（1）查询

∙实时查询，用于小数据量场景。

∙定时任务查询，用于数据量大，关联表多的情况。

历史数据直接读取已经查出来的数据，避免每次查询都是多表联查，可提高查询速度，降低服务器压力。

∙查询频率，多长时间查一次，根据情况定义。

∙查询速度，查询速度慢的，需要优化。

（2）筛选/搜索

∙多条件组合筛选

∙模糊搜索、精确搜索

∙可搜可选

举例解释（后台）：

A实时查询：

柱状图显示今日新增用户，直接查询即可，每访问一次或刷新一次页面，就查询一次数据库。

B定时任务：

表格内展示今年新增用户数量，并展示对应的订单状态、物流信息、会员信息、标签信息、活跃情况等等。

查询时需要跨数据表联查，比如先在用户表查出今年新增的用户的ID，然后分别用用户ID去订单表、物流表、会员表、用户标签表中，查出对应信息，然后用表格呈现出来。

这种情况，就不能用实时查询了，服务器一次性跑不来一年的数据。

所以就用定时任务查询，定时（如每天查前一天的上述数据）查一遍，并记录下来，当有人访问该表格时，无需联表查询，直接读取已经记录下来的数据并展示即可。

C多条件组合筛选：

比如筛选性别为男/分类为老年人/2019年已体检的人员列表。

D模糊搜索/精确搜索：

如字面意思。

E可搜可选：

比如有个下拉选择框，里面是城市列表。

在使用时，有时你是知道城市名，可以直接下拉展开鼠标点选。

有时你不知道城市名，或者太多一时找不着，那可以在下拉框里直接打字输入，下面就会展示对应城市，回车或鼠标点选即可。

因此，当开发皱着眉跟你说，这个表格字段太多，查询会卡死服务器，你就说：

跑个定时吧，亲~

作为一个产品，写涉技术文章，我好难啊…我知道的就这么多了…

5.显：

显示

其他六字都服务于【显】字，是七字真言的舵手。

【增删改查算传】都通过【显】与用户互动。

用户对所使用的产品的一切感受，也都是通过【显】感受到的。

甚至可以说，【显】就是产品经理的一切。

用户在使用的过程中，出现误解、不会操作等情况时，产品经理没法去解释去帮助，所以在交付给用户之前，就要尽量把所有异常都做处理。

简单总结几个重点：

（1）可读/易用

消除歧义

∙例1：

是否确定取消？

确定/取消

∙例2：

是否删除？

（换行写删除的内容名称及影响范围）删除/不删除

文案有温度

∙现在发生了什么，你需要怎么做，这样做的后果是什么，做了之后还能不能反悔修改。

∙根据用户和场景，决定文案的语气、字数多少、字号大小、按钮大小、是否语音播报、颜色等等。

需要有代入感才能写出有温度的文案。

化繁为简

∙界面简单：

典型的说起来简单做起来难~

∙文案简洁：

产品内部评审的时候，让大家去自己读，看有没有不同的理解，如有则改。

∙操作简便：

尽量减少点击次数，但敏感操作又会故意设计复杂操作。

∙精简流程：

比较难，太精简了会导致耦合度高，太分散了会导致操作体验差。

（2）一致性

用一致性消除歧义：

用词一致、icon一致、交互一致、色彩一致。

∙共识性一致：

比如红色用于警告类，绿色用于引导操作。

∙产品内一致：

同一模块，避免出现既有实心icon，又有线条icon，等等。

用一致性提高易用性：

产品的所有弹窗中，确认按钮在左侧，取消按钮在右侧，等等。

检验方法：

找一个不知道前置条件和行业背景的人，看你原型的文案、模块布局、操作顺序，是否有误会的地方。

（3）消除焦虑——一切尽在掌控

常规加载时，坚决消灭所有空白页，包括返回数据为空的异常情况。

先显示骨架图→再模块化显示数据。

loading和进度条，文件过大导致必须等待时使用。

让用户有个心理预期，根据其使用场景，合理决策继续等待或者退出。

（4）反馈系统——凡操作，必有反馈

正常反馈

∙页面有明显变化的，无需额外的反馈，页面变化本身就是一种反馈。

比如：

发朋友圈，发完就能看到，那就无需提示发送成功。

∙页面无明显变化的，用吐司类轻提示反馈。

比如：

操作成功、已添加。

∙没有反馈也是一种反馈。

异常反馈

∙操作失败、网络异常、获取数据失败、触发安全机制等。

∙错误反馈文案由两部分组成：

①用户能看懂的，②开发能定位到问题的。

（5）用户安全——让用户掌握主动权

上限

∙短信通知、推送通知、注册/登录短信、邮件、都需要设置上限。

∙系统bug导致短信轰炸用户的情况时有发生。

几千条短信发过来，只能拆SIM卡…

中止及撤回

∙短信、通知、邮件，分批推送，且后台能进行中止发送和撤回操作。

∙把测试推送内容发到正式环境的，更是屡屡发生。

​比如腾讯视频8月21日的推送：

“台风利奇马已致山东全省人死亡…”，算得上特别重大的安全事故了。

隐私数据

∙涉及身份证号码的页面，要做数据权限处理，通常设置为少数人才能批量看到身份证信息。

防止被拍照或截屏。

∙在移动端，通常是用户通讯录、摄像头调用、MIC调用、定位等。

看了一堆文字，该换换口味了，图来：

1）上图一详解

∙标题简短，瞟一眼即可，无需阅读。

∙正文第一段，描述是哪个SKU。

当然，能配图更好。

∙正文第二段，根据实际场景，给一些标签，做最后的参考决策，避免误删。

∙两个按钮是同级的，不做任何引导。

∙操作按钮直接用动词命名，尽量避免使用【是、否】【确认、取消】类文案。

2）上图二详解

∙文案难以理解，虽然是用户自己点击的‘取消关注’按钮，但仍然是个失败的文案。

∙更难受的是，这时候我会怀疑上一步是否误触了其他人，会关掉弹窗重新点一遍取消。

∙最难受的是，文案和按钮关联会出现更大的歧义，我该点【确定】还是【取消】？

∙最后，敏感操作尽量别带色彩去引导。

如支付、删除等。

∙具体记不太清是取消关注，或是取消收藏什么的了；但文案非杜撰，至今仍对“是否确定取消”记忆尤新…

还想继续上图来着，发现其他内容不配图也能理解，于是，图不出来了。

你们有想法可以留言，我酌情酌能力补图。

七字中，其他六字，除了其本身的异常，更多的是和【显】碰撞出来的异常。

【显】又面向用户，因此，处理异常的时候，要用同理心，去体会用户的感受。

∙这里稍微扩展一下我对同理心的理解：

感同身受，是比换位思考更深层次的一种情绪和感受。

∙举例：

记得以前给某共享单车提过建议，别在早晨上班前弹启动广告和开屏广告。

∙设计这个功能时，应该去体会这样的场景：

“卧槽，要迟到了，哪有单车哪有出租车”，心急如焚的时候，发现一辆单车，一个饿虎扑食来到了救命单车前，掏手机开App，5秒的启动广告导致心急如焚**2，探手去点【跳过】，被故意设计的点击区域小于视觉区域的【跳过】套路，进入了广告，广告连续跳转了N次链接，点三五次无法返回单车App界面，点的急了，又点多了导致退出了App…各种迟到后的心情…简直是条条大路粉转黑。

还有一些不常见的情况，比如虚拟运营商出了新号段，军人没有身份证，等等。

6.算：

算法、计算

算法：

是指用系统的方法描述解决问题的策略机制。

其能对一定规范的输入，在有限时间内获得所要求的输出。

根据算法的定义，产品角度通常涉及到：

（1）规则

∙个性化推荐

∙风控

∙打标签

∙积分体系

∙会员体系

∙用户ID

∙订单编号

（2）算法

∙图片压缩

∙搜索查询

∙产品经理需要简单了解一下算法逻辑，推荐【AIgorithms】App，能可视化的了解各种算法的运算逻辑。

（划重点：

AIgorithms App）

7.传：

数据传输

最近5G话题火热，大部分人对5G的印象是速度快。

其实，5G的应用亮点是低时延和高带宽，速度快反而是其次。

上面这段话，提到了【传】的三个点：

时延、带宽、速度。

出需求时，要传输的这三个点，都属于用户的场景，是必须要考虑的。

比如手机直播和短视频，在4G普及之后才可能诞生。

所以，从用户角度，主要有两点：

（1）传输安全，结合【显】字，可分为：

∙用户可感知类：

脱敏传输并脱敏显示、可执行文件加后缀等

∙用户不可感知类：

加密传输、接口安全、服务器隔离（敏感服务器不直接面向用户）。

（2）传输速度

压缩：

比如微信发送图片，不勾选原图，图片就会被压缩传输。

预加载：

比如阅读类App，用户看第一章，他就会预加载第二章。

用户读起来就不会有等待加载的过程，不会打断爽感。

异步加载：

∙偏移动端：

按模块加载并显示给用户，不要等整屏内容都加载完再呈现，避免让用户焦虑。

∙偏PC端：

尽量避免整个页面刷新，减少服务器压力，和用户等待时长。