网站消息提醒 设计 第1篇
提示信息是为了给用户在使用产品中提供引导和解决用户在使用产品中的问题而设计，想要达到的这样的目的，首先应该做到在提示信息中“把话说清楚”，即在提示信息中应该明确告诉用户当前问题是什么，为什么发生，如何处理。
如上图，在用户填写完表单提交数据时，系统校验数据不合法时，提示信息为“数据保存失败”，用户通过这样的提示信息，无法了解错误的原因，也就无法快速定位问题并纠正问题，从而影响用户维护数据的效率和使用体验。对比图中第二个提示信息，在提示信息中说明错误的原因，用户就可以基于提示信息，了解到问题什么时，要如何解决。
网站消息提醒 设计 第2篇
公司的业务系统中，存在大量批量维护业务数据的的场景，在此场景下，当用户提交的信息不合法，系统给出的提示信息为：“XXXXX不可为空/错误”，用户在获取到这样的提示信息后，需要自己的在表单中一行一行的定位问题，这样的体验流程显然是即不友好也不高效的，所以针对此类场景，除了要做到把话说清楚之外，还应该给提示信息一个定位，即告诉用户问题在哪在对公司业务系统提示信息进行优化时，针对此类场景通过“定位+问题+原因+解决方案”结构的提示信息，在告诉用户问题、原因及解决方案的同时，告诉用户问题在哪一行，帮助用户快速定位到问题问题并纠正，示例：第[n]行的，某某字段输入不正确，请检查。
网站消息提醒 设计 第3篇
主动些，是对提示时机的思考，大部分的提示信息是针对用户的行为结果进行提示，从防止用户错误行为的角度考虑，在设计提示信息时，可以关注事前、事中对用户进行引导。
问题：在公司业务系统中，几乎90%的场景都是如流程上所示，系统都是在相对滞后的环节（用户提交数据后）根据数据校验结果给出提示。用户在获取到到错误信息后，需要重新在界面中定位问题-纠正问题-重新提交，这样的流程对用户、系统而言都没有做到效用最大化。
优化：在文本框获取焦点时，利用提示信息对用户进入事前教育； 在文本框失焦后调接口校验，如用户输入的账号或密码不合法，利用提示信息告诉用户错误信息和解决方案； 这种处理方案，或许代码工作量相对会大些，但是可以对用户的事前、事中行为起到很好的引导作用，对用户体验和效率的提升是可想而知的。
7.用户需要怎么做
问题：公司业务主要面向B端用户，系统中会维护一份标准的业务数据，销售在开展业务过程中，可以基于不同客户的要求，获取公司的标准数据并在规定范围内进行调整。 所以在销售获取标准数据时，如标准数据并不存在，系统会提示“XXXXX在标准XX不存在”，这样的错误提示，虽然明确告诉了用户问题是什么，但是没有给出问题解决方案和途径，大部分用户在获取到错误信息，都会再咨询其它销售同事或产品负责人来解决问题。
图中案例是同一场景下，不同的提示信息设计：提示1：只告诉了用户，问题是什么提示2：在告诉用户问题的同时，告知了用户如何解决问题提示3：在提示1和提示2的基础上，为用户提供了解决问题的途径对比来看，提示3是帮助用户解决问题的最有效的
此案例想要表达的核心是：在设计做错误提示时，除了告诉用户问题是什么，最好为用户提供问题的解决方案和途径
反思：
这一波系统提示信息的优化，从用户的反馈来看效果是不错的。那么，为什么之前的系统提示信息会那么“差”，原因可能是：
以上内容为我在对公司业务系统的提示信息进行优化时的一些思考，希望对你们有帮助，欢迎交流！
网站消息提醒 设计 第4篇
无论是对外、对内或是toC或toB的产品，产品的用户群体一定会存在文化背景的差异，因此，在进行提示信息的设计时，需要充分考虑不同区域用户的语言、文化、宗教等因素的差异，不要让感觉到困难、被歧视、自卑、距离等不好的感受。
例如：axure是一个面向全球用户的产品，有一次在浏览其官网，不小心进入了一个错误页面，错误页面的提示信息是全英文，虽然我知道这是错误页面，但是到底出了什么问题，我借用翻译工具才弄明白。如果你负责的产品是面向全球用户时，提示信息设计一定要区别对待，针对设计。在公司业务系统中的错误提示，并没有出现此类问题，此部分内容为在执行优化工作中的拓展思考。
网站消息提醒 设计 第5篇
第一个提示，出现了系统语言“主键ID”，“主键ID ”这样的词语，对于普通用户来说，是无法理解的。第二个提示信息中，出现了用户无法理解的“错误代码”，面对这样的提示信息可能需要用户联系客服咨询或自行查询错误代码提示录，才能明白其中所指。
这两个提示犯了同一个错误，即“没有对用户说人话”，类似于这样的提示提示信息，既不能助用户快速定位、解决问题，反而会增加用户解决的问题成本。
提示信息是用户而设计，用户有专业与非专业之分，所以在提示信息的设计中，对关键问题的描述用户用词，要禁止使用错误代码、系统语意（如主键ID）,避免使用过于专业的术述，需符合用户的业务认知、常规认知。
网站消息提醒 设计 第6篇
出于信息持续性的考虑，触达渠道之间有部分关联关系在制定消息触达渠道时需要注意，如：
通知的内容需要满足简明易懂的同时，还要让用户能够快速处理。根据大量经验总结，通知内容的撰写可使用一个通用撰写公式：
在应用撰写公式写内容时，需注意以下要点：
除了以上通用注意事项，由于渠道本身的特征差异，还需注意以下渠道相关的要点：
在完成通知内容以及操作反馈的梳理后，对消息梳理表格进行更新，补充相关信息：
自此，消息项的盘点已经完成，后续可基于该表格与产品、研发沟通。当业务出现变更时，也需要对表格内容进行同步更新。
消息通知的触达渠道中，电话、短信、push 推送的呈现由系统决定。但是若产品有独立 App，往往需要消息中心去承载全量的消息列表。本章会介绍如何设计消息中心。
不同应用的消息中心处理方式受产品定位、应用框架等因素影响，设计差异化较大。但是可以通过按路径分割去简化设计：消息中心的入口、消息列表的组织方式、消息卡片的样式、消息的设置等几个部分。
主要有底部 tab、个人中心附近的图标入口、个人中心的菜单项等三种入口形式：
△ 消息中心的三种入口