至于图标的话我就更不用多说了，大家肯定都记得那些非常基础的绘制图标的法则。个人认为图标也不太需要放一个单独的篇幅去展示，除非它有一些新奇有趣的亮点。

界面框架，只是框架而已吗？

在之前的文章中有写过，匹配产品定位的界面框架一旦输出，对整个 APP 之后的迭代与功能设计都有很直接的影响。定义整体的UX 框架方案，是实践设计目标与策略的过程，基本围绕着这 3 个出发点：匹配产品定位、满足业务拓展性、符合舒适度美学 。

1. 定义整体框架

首先我们从宏观角度分析，一方面产品的业务线处于什么情况，是相对独立的业务主线产品（举例：拉勾）？还是平台级产品（里面包含了许多垂直的业务线，举例淘宝）？如果是平台级产品在整体框架设计时就需要考虑跨端跨业务的框架拓展型。

举个例子，就是在定义平台框架的时候要考虑这个框架与容器是不是同时适用于底下的子业务线，同时当这个框架到了 H5、小程序、PC 的时候需要做哪些适配调整，是否都可以很好地进行兼容适配。

另一方面，整体框架设计的类型是否符合设计目标。举个例子，无框式超大留白的框架设计虽然看上去很厉害，但在大部分商业产品中它的实用性却非常低的。假设说我们今天需要做一个电商类的 app，设计目标是希望能够提升业务转化以及购买效率，那么展示效率与功能分区就显得尤为重要，它就更适合一个相对紧凑的卡片式为主的框架设计。

其次从微观的角度来说，遍地就都是细节了。舒适度美学这一说，其实难免有些抽象，我们把它转为相对合理一些的落地原理就会清晰很多，像大家熟知的间距 4 倍数原理、对齐原则等等。但是这些微观的内容不建议大家放到方案展示里，因为它并没有针对单个方案的特殊性，更像一种大众共识。

2. 具体容器解析

我们特地把单独的容器部分拿出来解析，是因为自定义容器是展示核心业务最主要思考呈现，同时还可以配合运营做很多提升业务效率的配置。在做具体设计的时候，我们需要区分「端上固定」模块和「运营配置」模块之间的差别。

「端上固定」模块

顾名思义就是开发端上需要写死的模块。写死的模块意味着，无论一个配图还是一句文案，也只有开发童鞋修改后通过发版才能实现内容变更。一般适用于相对固定的产品功能以及 UGC 用户生产内容。比如：拉勾上传简历功能、斗鱼的直播间列表。

「运营配置」模块

相对「端上固定」，「运营配置」就不需要跟着发版，可以随时后台上传替换模块内的内容，适用于需要 PGC 生产的内容。说到这里很多童鞋可能马上就联想到 banner，弹窗的运营位了，但其实除了这些之外还有很多容器模块是需要灵活配置为「运营配置」模块才能更有效地提升运营业务价值。

我们可以这样来区分「运营配置」模块类型。

一种是纯运营配置模块，即设计与开发输出框架、定好配置字段限制之后，运营可以独立完成后台配置的。比如：资讯 app 0-1 前期的资讯列表内容。

另一种是运营设计配合模块，即需要设计配合运营输出一定的设计图才可以进行后台配置的。比如：常见的 banner、弹窗、热门推荐专题等。

在 0-1 的设计方案中，更推荐大家展示「运营配置」模块的内容与解析，因为 0-1 是个以拉新为主的阶段，运营显得尤为重要，所以我们的设计需要侧重考虑整体的运营效率与转化。

如何展示亮点设计？

在我们概述完大部分的整体思考路径与设计方案后，我们需要由面到点，从全局提炼细节，突出自己的设计方案亮点。

而如何提炼这个亮点呢？是挑一个我设计的最好看的界面呢？还是直接放最复杂的那个流程？以下是推荐选择的亮点设计：

1. 完成理论实践，并可以量化价值的设计case

大家应该都了解，一些和设计息息相关的数据 UV/PV/GMV/ 相关业务指标等，以及一系列在实践中很好应用来解释设计方案的理论支撑比如 5W1H、GSM 与五度分析……这些数据和理论是支撑我们设计更饱满更有说服力的重要支点。

虽然在 0-1 的项目里，我们基本不太用得上优化数据比对（因为产品初期用户数量少，产品体验路径也是一直处于不断试错阶段），但是我们还是可以借用上文所述的一些方法论或者 A/B test 来完成我们的方案思考过程展示。

2. 影响上中下游环节的设计case

除了对业务提升价值的项目外，我们有时候也需要注意对品牌设计、产品、运营、技术等上中下游造成影响力的设计项目。通常这类设计大部分也都是设计自驱发起的，能起到提升各方人效和业务效率的作用。

举例的话，我能马上联想到的就是多方协作的大型线上组件库，可以参考阿里的 Ant design、滴滴的魔方，在之后的版本拓展中甚至可以延展成功能更加强大的多方协作 ux 设计资源中心。

遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://www.uisdc.com/thinking-of-design-scheme#