ios|APP底部弹出控件( 四 ) 用户|客服|微信|腾讯|链接|弹窗

如果有两种用法，你发现它们的使用边界比较模糊，证明其中一个是可以被合并、或者直接删掉的。分类越集中，越有利于保持一致。
2. 分类框架因地制宜“底部弹出控件”同时包含了原生和自定义的用法，且落到不同产品中，自定义的归类方式会存在较大差异。这里以美港股券商为例，以下是我的分类框架。

文章插图
“基于原生”，指的是直接调取系统原生控件，在交互上没有进行自定义改造的基础用法。它们可能在视觉上有着区别于原生风格的再设计，但是底层仍可清晰对应至某个原生控件。
“自定义”用法在上文中已详细阐述，以美港股券商为例，目前还没有遇到“并行”的用法，未来如果出现了对应需求，再补充至文档中即可。
“关联功能”相当于这份文档的落地指引。在完成以上全部用法的编写后，以筛选、货币兑换、日期选择为具体案例，来说明这份文档如何使用、以及使用后可以带来哪些收益。
【 ios|APP底部弹出控件】同时还可以为这些功能的体验换新，提前做好方案上的储备。
3. 保持一致保持一致的重要性无需赘述，它是保证一个产品体验质量的基石。尤其在编写控件规则的过程中，每一步都需要反复确认“一致性”的问题，直到没必要的分叉一个个消失，全局的整体性才会逐渐浮现。
四、Q&A1.“操作确认”类对话框需要从Alert整体调整为底部弹出控件吗？
从体验差别上来说，必要性不大。我目前调研到的产品，应该只有豆瓣、脉脉做了全局上的规划和调整。而这样的改动，落地成本通常较高，投入产出比较低，不建议盲目推进。
2. 如何让这类横向规则文档，被真正的使用起来，而不是束之高阁？
非0-1的产品，想依照文档对老旧设施进行重建、改造，需要等待大改版这样的顺风车时机。除此之外，我们还可以从两个角度入手，小步推进。
一是在文档确认、发布后接到的需求，从设计内部的输出环节开始，使用最新的规则设计需求；
二是在接到已上线功能的需求，发现其涉及到文档中内容，可尝试与研发、产品、测试同学进行沟通，如排期、风险可控，可借此机会解决一个单点问题。
本文由 @cony的小书包原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议