网站内容更新提醒(书写文案的时候，尽量用1,2,3,4)

　　网站内容更新提醒(书写文案的时候，尽量用1,2,3,4)

　　这句话与需求文档中的需求点或迭代计划中的任务非常相似。一是用户不理解这句话的意思，二是根本没有一点可以吸引用户的意思。如果你想吸引用户，你必须告诉你你的新功能给用户带来了什么好处，或者帮助用户解决问题。所以如果你按照这个想法把刚才的副本改成：

　　“您可以使用短信与您的朋友分享商业信息”

　　这样，用户不仅可以了解这个功能，还能知道这个功能给自己带来的好处。

　　写文案的时候，如果想从实现模型转变为心智模型，可以尝试从一开始的主题入手，比如多用：

　　你可以... 你可以解决...的问题

　　少用：

　　添加... 支持...

　　虽然搜狗FM和微信都能理解新功能是什么，但从文字情感的角度来看，我觉得还是不够完善。

　　3）有条理

　　写更新文案时，一定要有条理，不要把所有的描述都混成一大段；因为用户在看更新文案的时候基本都是扫一扫，在文中找到有用的信息；所以在写文案的时候，尽量用“1,2,3,4”来分隔信息，比如我4）适当修饰

　　经常看到一些应用程序使用五角星，爱情符号作为分隔符，或者不要忘记在最后添加一个笑脸。有些人可能认为这是不必要的，但实际上，这样做不仅会在整个更新列表中突出您的产品，还会给用户带来活泼和热情的感觉。

　　（Hive更新文案不完美，但比别人好）

　　补充一下，有朋友说他们更新的副本是运营人员写的。我强烈建议把这个副本交给交互设计或者PM，因为他们往往最先知道这个功能的初衷是什么。了解这个新功能给用户带来了什么样的满足感，或者解决了什么样的痛点。如果UE或者PM文字功底不好，可以先写个草稿，再让专业人士处理~

　　2. 应用内弹窗提醒

　　应用内弹窗提醒是指在打开应用程序时，通过弹窗的方式直接告诉用户有新版本可用。这样做的好处是用户在使用产品时可以看到，而且有针对性。不利的一面可能是用户的操作突然被阻塞，给用户带来不舒服的体验。所以，做这种提醒是有风险的。必须满足几个原则：

　　1）必要性

　　与商店更新文案不同，由于是应用内交互，可以自行灵活处理，无需每次更新版本提示。因为这个提示会阻塞用户的操作，让用户不舒服，所以要保证这个版本只在需要提醒用户的时候弹出。一些纯bug修复版本可以提交到商店，但不需要弹出窗口。

　　2）只说要点

　　与商店不同的是，弹窗显示的文字较少，也没有办法一一列出新功能。所以它应该只解释要点，精简文本，或者只解释最重要的新版本特性之一。比如你想像上面一样更新微信的弹窗，你可以设计成：

　　3）需要强制更新

　　不知道你们的产品有没有强制更新机制。如果是有经验的PM，应用必须有强制更新机制。强制更新是为了防止出现意外情况，发布一个会造成重大事故的版本，或者新旧版本之间的严重冲突。所以在某些情况下，你需要考虑一个需要所有用户都更新的场景，否则旧版本无法再使用。这个机制必须在产品的第一个版本中考虑到，否则以后出现问题将无法弥补。

　　因为没有所谓的通过商店更新强制更新，只能通过弹窗提醒。强制更新的弹窗往往只有一个选项，更新，否则关闭应用程序。

　　4）允许用户忽略

　　通常弹窗提醒是很烦人的，很多设计都是在应用程序打开的时候就提醒一次，所以如果不能忽略的话，会让用户感觉不舒服。有两种方法可以让用户忽略提醒。一个是只有第一次输入新版本时才会弹出弹窗提醒，另一个是在弹窗上增加了“忽略此版本”的选项，版本将不再点击。提醒。

　　这样，用户就可以明确表达“我知道，但我不想更新”的需求。

　　三、推送提醒

　　很少会通过发送推送来提醒用户更新版本，因为推送只是一瞬间，点击后无法直接跳转到AppStore。但是，推送的使用可以非常灵活。通过推送，激活久未使用、久未更新的用户依然有效。大概意思是：返回搜狐，查看更多