背景概述

微信公众号平台提供了个性化菜单的接口，第三方开发者可以直接调取使用，可以根据关注者的标签、性别、地区、系统语言等条件自动匹配显示不同的菜单，以达到让公众号上不同的用户群体看到不一样的自定义菜单，实现精准的个性化营销。比如我是一位男生用户，显示的菜单与女生用户的会不一样。

我们的产品同学想要在司内产品接入这项能力，在进行UI设计时，发现产品同学提供的原型设计思路（下面的方案A）在可用性和使用场景上存在一些欠妥的地方，大家双方对个性化菜单上也产生了不一样的理解，于是重新换了种思路设计了方案B与产品同学再沟通。

方案分歧与验证

下面是基于两种个性化菜单模型展开分析，虽然在UI设计层面上体现出的差异很少，但在功能的设计思路、数据结构都是不一样的思路。

方案A存在好几个问题，也正是这几个问题决定了这个方案不太可能继续往下走，主要是由于功能设计的拓展性差和对实际使用场景考虑的不周到。下面通过对两个方案的模型进行分析来两个方案的差异和优缺点。

方案A

modal1

分析维度	说明
模型结构	个性化菜单是一项独立的主菜单（如图中菜单3、菜单2…所示）每项个性化菜单都设定匹配规则「matchrule」，匹配替换的时候是以默认菜单为基础，从左起第一项主菜单开始逐项替换。
替换规则	1. 将个性化菜单按最近创建时间排序排序； 2. 检测个性化菜单中的「菜单3」的「matchrule」是否与用户的相关属性或标签匹配； 3. 匹配和替换菜单。如果「matchrule」符合，即把默认菜单中的第一项菜单A替换成「菜单3」；如果不符合，再检测「菜单2」的匹配规则是否符合用户，符合即替换，不符合即继续检测下一项，直到成功匹配并替换默认菜单的第一项； 4. 默认菜单中的第一项菜单被匹配替换成功后，按照上面的规则继续匹配和替换默认菜单中的第二项菜单； 5. 直至把默认菜单的所有项都替换完成，即终止剩余个性化菜单的匹配替换；如果剩余的个性化菜单都与用户不匹配，也终止个性化菜单的匹配替换
问题	1.替换顺序每次都必须要遵循从左到右依次替换，这种规则容易出现被替换的主菜单并不是业务真实想替换的那一项，这种替换方式较难符合实际场景的使用预期； 2.最小替换单元是一项主菜单，公众号的关注用户每次进入都要检测匹配，容易给服务器增加不必要的访问压力； 3.该模型无法设定菜单的个数，系统设置的默认菜单有几项主菜单，个性化菜单最多就有几项

经过分析，方案A中个性化菜单的替换逻辑过于局限且不符合实际的使用场景，比如无法控制个性化菜单上的菜单数量，也无法控制具体替换哪一项菜单。

方案B

modal2

分析维度	说明
模型结构	个性化菜单是一整个菜单按钮组（如图中m1、m2、m3…mn所示），每一组个性化菜单里的菜单按钮（如菜单a1）可以设置子菜单，与默认菜单一样。
替换规则	1. 个性化菜单按最近创建时间排序，最新创建的排在最前面，优先匹配； 2. 检测第一组个性化菜单中的「matchrule」与用户的相关属性或标签是否匹配，如果匹配则替换掉原来的默认菜单，剩余的个性化菜单不再匹配； 3. 如果不符合，再检测第二组，符合即替换，如此循环到最后一组。
优势	1. 以一整个菜单组为最小单元进行匹配和替换，在软件设计和处理上可以把个性花菜单看成是带有匹配条件的菜单按钮组，结构与默认菜单一致； 2. 能够避免方案A中局限且不合实际使用场景的替换逻辑，可以完全控制菜单项的数量、内容、和排放顺序，做到真正意义上的个性化。

验证

为了验证方案B的设计思路是否可行和完整性，进行了多次模拟个性化菜单相关的增删操作和设计相关的关键页面。同时为了说服负责这项功能的产品同学，也查看了微信公众号平台开发文档的相关内容，从代码示例中即验证了这种猜想。

创建个性化菜单的示例代码片段如下所示，有两个主要参数「Button」和「sub_button」，分别对应的是一级菜单和子级菜单。从代码示例中可以看出，个性化菜单与默认菜单的基本结构实际上是一样的，唯一的不同点是个性化菜单增加了匹配规则(Matchrule)，符合规则的订阅者会展示个性化菜单。

参数	说明	示例
button	一级菜单数组，个数为1～3个	今日歌曲
sub_button	二级菜单数组，个数为1～5个	搜索、wxa、赞我一下
matchrule	菜单数组的匹配规则

{
    "button": [
        {
            "type": "click", 
            "name": "今日歌曲", 
            "key": "V1001_TODAY_MUSIC"
        }, 
        {
            "name": "菜单", 
            "sub_button": [
                {
                    "type": "view", 
                    "name": "搜索", 
                    "url": "http://www.soso.com/"
                }, 
                {
                    "type": "miniprogram", 
                    "name": "wxa", 
                    "url": "http://mp.weixin.qq.com", 
                    "appid": "wx286b93c14bbf93aa", 
                    "pagepath": "pages/lunar/index"
                }, 
                {
                    "type": "click", 
                    "name": "赞一下我们", 
                    "key": "V1001_GOOD"
                }
            ]
        }
    ], 
    "matchrule": {
    "tag_id": "2", 
    "sex": "1", 
    "country": "中国", 
    "province": "广东", 
    "city": "广州", 
    "client_platform_type": "2", 
    "language": "zh_CN"
  }
}

思考和启发

🙋🏻 在产品设计过程中，上面这类问题的发生不是偶然，主要原因是对功能的应用场景考虑不到位，以致在方案设计上显得比较局限。

那设计上如何避免这类问题？我一般使用下面的方法：

1.抽象化功能，总结规律和模式

当我们在接受需求信息的时候，我们的大脑已经在开始有意识地组织需求信息，寻找规律，搭建业务结构架和流程模型 — 在大脑里形成一定的概念认知。如果只是一味地只是接受信息，不做任何的加工处理，信息最后也只是成为一个简单的记忆符号，很难再有更多的价值。

特别是我们进行功能设计的时候，一边吸收需求，一边把具体的需求抽象化成某些普适的规律和模式，再把它应用到我们的设计中。

举个例子，偶数 [2, 4, 6] 之于数学公式 2n，[2, 4, 6]是很具体的偶数，但2n能代表所有偶数，有着普适的规律和适用性，可以用来求出其它的偶数。这就是抽象化和模型的魅力和好处。

如果以后再遇到类似的替换覆盖的操作时，是直接在菜单内部单个元素替换还是采取整体替换的方案，这时候就可以想到我们这次个性化菜单的的两种模型。

2.抽象化在产品功能设计中的作用：

能更多地思考顶层业务，主干流程，避免过渡地思考细节，过渡地考虑细节经常带来的问题是主次不分；
把现象或问题总结成规律和模式，遇到类似的问题可以根据情况适当套用；
跳出已有的思维模式，切换其它角度看问题，容易寻找创新点和改进点；

3.优先业务数据建模

数据建模是指根据业务特点，总结归纳和设计业务数据对象之间关系的过程。虽然数据建模通常用在数据库设计里，但它实质上也是一个抽象化的过程，所以在产品设计过程中可以把它作为抽象化业务、归纳和设计规则的一种方法。

在B端的产品设计里，有很多的功能需要业务数据建模，比如账号体系、权限(RBAC相关的模型)，还有上面提到的公众号个性化菜单。在进入产品细节方案设计的时候，我们都会经常忽略基本的业务数据建模，直接着手每个页面的具体功能和交互设计，因为基础的底层数据关系没有梳理清楚，导至最后陷入了痛苦的混乱逻辑当中，我们的方案A就是典行没有做好数据建模。理想的做法是，先进行业务数据建模，然后再梳理流程和确认页面如何流转，最后才是每个页面的细节设计。

做数据建模还有一个好处是团队成员对业务功能的理解比较容易达成一致共识。当我们在设计或者描述一个业务功能的时候，不同的人大脑里对它的理解经常会不一样，有时甚至是截然相反的想法。出现这一点的原因是我们每个人大脑对业务功能的解析不一样，通过借助一些建模工具，比如建模语言UML、ER图，可以让自己梳理清晰流程、对象的关系和状态。模型是非常客观的，其他人在理解上不会容易出现理解偏移。

下面两个类图分别是方案A和方案B中默认菜单与个性化菜单之间的关系模型。我们也能通过这些模型去分析方案自身的做给缺点，也有助于其它对接人员比如开发人员查看和理解。

演推和预判

演推和预判是设计师自己检验设计方案、发现问题的一种好方法。下面是一些常用的演推思考维度：

使用场景是否能满足
流程是否完整闭环
交互是否清晰高效
用户在使用的时候可能会发生哪些问题

在设计方案的过程中，带着这些维度反复在大脑中串连和思考各个场景环节，思考设计这么做会有哪些优缺点，还有没有更好的交互，是否还有其它的应用场景，能不能找到更简单的逻辑去实现同样的功能等等。通过这种方法往往可以发现更多问题，反推着换思路重新思考已有的设计方案。

背景概述
方案分歧与验证
思考和启发