APP 的描述就好比是在给自己的 APP 写一份求职简历，APP 的版本控制必须在最开始就要做，push 是最基础的 APP 运营形式，需要持续优化。
继续关于移动产品设计的话题。
本来之前我是写了一个「移动产品设计概要」的纲要的，这个纲要囊括从一个 idea 开始到具体上线再到持续迭代的所有环节。后来觉得，还是信笔随写吧，这样比较自由自在的，即使哪天不想写了，也没什么遗憾。
今天这个题目有点怪，当然，这个概念也是我自己造出来的。会简要写几个部分的话题：APP 的版本控制、APP 的名称及描述、APP的 Push 消息。为什么是简要写呢？因为展开太累，同时本身这系列的文章就是我自己在梳理思路，所以，点到为止。
APP 的版本控制，是必须从 APP 最开始就要考虑进行，就要执行的事情。这直接关系着你后续推出的功能能到达多少用户。
对于网页产品，到达用户的路径非常短，因为几乎所有的用户都是在一个版本号下面使用的，直接升级，所有人刷新页面，就看到最新版本了。但是，APP 是以安装包的形式达到用户的，也就意味着，如果用户不愿意升级，那么，你的新功能直接到达不了，到达不了，后续的都是白扯了。
按照我个人的思路，开始做一个 APP 的时候，第一件事情就是把版本的升级策略定下来。提示升级、强制升级分别在什么时候出现，线上允许运行的最低版本是多少。
伴随着版本升级的另外一个问题需要提前考虑的就是版本的升级节奏。更新太频繁，用户会觉得烦；更新太慢，不能在 Appstore 里露脸，会被遗忘；特殊的日子一定要发版本凑热闹。
同时，每个版本一定有一个「特色」功能，即使没有，也要包装一个出来，不然的话，单纯升级版本号是没有太大意义的。
举个例子，春节假期是每个 APP 都不能错过的一场盛宴。一线城市的用户向二三线城市转移，会直接促进大家使用 APP 的交流；假期中基本闲在家里，对手机的使用会变的频繁。所以，必须在这个时候出版本来吸引用户眼球，至于怎么吸引，自己想。
不是一个 APP 一旦被审核通过，就立刻向全部用户 push 升级的，这会存在很大的风险。按照我个人的方式，APP 一旦审核通过，先升级某一个小渠道，观察是否存在致命性的 BUG，比如闪退等。如果存在，立刻撤下来，如果不存在，开始推送升级，如果时间还能恰好赶在周末，那实在是太好了。
说到，APP 升级，我注意观察了蛮多 APP 的名称、描述、升级描述。这些部分的内容，基本都没有经过「设计」。
先说名字，有的APP 的名字跟自身的功能很贴近，不需要太多的设计，不过，有的 APP 则不是。在 Appstore 里进行搜索，名字的权重相对较高的。
举个例子，最早的时候快捷酒店管家在Appstore 里的名字就叫快捷酒店管家。这个 APP 主要是预订如家、汉庭、7天等等快捷酒店的，从名字到具体做的业务还是有点差距，不少人不太容易理解「快捷酒店」的含义。后来，我把他修改成为「快捷酒店管家- 会员价预订7天、如家、汉庭、莫泰、锦江之星、格林豪泰、速8、布丁、易佰旅馆等经济连锁酒店」，这个名称经过设计之后，有2个变化，一是用户可以通过搜索如家等品牌酒店的名称进来，二是很明确的把产品特色表达出来了。
升级描述的「设计」则更重要，因为这个部分的内容会频繁的被用户看到，直接决定了用户对版本的好感。
我们看到很多的升级描述直接是「修复了 Bug」、「优化了性能」，甚至很多 APP 的描述直接就是研发复制了跟 PM 的聊天记录，连名字都没去掉…..
把APP 的名称、描述、升级描述抽象到另外一个事情上，这就好比你在给你的 APP 写一份「求职简历」。APP 的名称就是你的一句话自我介绍，APP 的描述就是你的能力概述、APP 的升级描述则是你每一次的工作经历能带来的提升。我很喜欢求职者的简历里出现具体的描述，比如「活跃用户提高5%」要远比「较大的提高了活跃用户比例」更让人觉得这个人靠谱。
当然，我们也看到很多人在过渡的优化自己的 APP 说明和名称，这完全是在自己砸自己的脚。用一个优雅顺畅的说法，把你的 APP 跟某些跟你业务相关联的热门关键词组合起来，这才是王道。
最后说说 push。有个做内容型 APP 的人问我，我的 APP 发出去了，但是用户的活跃度不高，怎么办？ push，是 APP 最基础的运营，尤其是内容型的 APP。
当然，因为很多 APP 的 push 也是没经过「设计」的，所以，大家都超级反感了。不过，如果你留意会发现，大家不是反感 push 本身，而是反感没有技术含量的骚扰性 push。
结合产品自身的特点去 push；设计好 push 到达用户的时间点，想象一下他在什么时间什么场景下接到你的 push；对用户进行分级，针对不同的用户 push 不同的内容，采用不同的频度；对 push 的类型做区分，气泡还是弹窗，纯文字还是带点符号什么的，用什么文案？
