“ *** 纵响应”的目标是报告用户 *** 纵的结果、期望、效果或结果。它是用户交互的主要界面。理性反应假设产品战的用户之间可以建立一种优秀的互动，从而帮助用户更好地理解产品战的使用，停止或减少猜疑和故障，促进用户的群体使用体验。
“ *** 控反应”是指产品在使用过程中，系统对用户的 *** 控给出的反应，或者是水果用户的行为引起的变化。这是展示人与机器之间互动的关键场景。反应必须包括两个环节:怀疑信息的输入和战争的输出，两者缺一不可；这里的“输入”主要是指用户的 *** 作。
广义而言，产品想象中的“反应”是指产品对用户行为的即时反应。本文主要总结了B端产品(PC)假设中用户 *** 控和响应假设的战例风格，以及假设中需要注意的成果，希望能为产品相关工作人员，尤其是交互设计师提供必要的帮助。
指出了提醒、移停、告知、功能引导等功能。在那些相似的页面中，更多的是指意象者想要告诉用户或期望用户理解的理解，也是系统对用户理解做出“反应”的一种方法。然而，它们中的大多数并不是作为用户间接 *** 纵的结果而呈现的，它们不具有“立即响应”的特征，因此本文不讨论它们。
1.根据场景分类， *** 纵反应可分为五类。
1. *** 作确认
常见的需要用户停止确认两次的场景有:支付、笼盖、退出、删除、提交、分离、修改、交换...
对于一些“破坏性”或不尽如人意的 *** 作，我们应该在用户 *** 作之前要求用户“再次确认”。除了让用户进行两次确认，更重要的是告知用户当前 *** 控可能带来的“风险”以及对其他模块或未来利用的影响，引导用户对自己的 *** 控进行稳健决策，从而降低用户犯错的可能性。在另一个圈子里，关于一些金融或企业服务产品，也是避免责任的必要方式——防止在用户不小心 *** 纵导致没有好结果的情况下，导致商业行业死亡的冲突或纠葛。
有些用户可以认为“双重确认”会很繁琐甚至“愚蠢”，尤其是那些已经对产品非常熟悉的老用户。而对于与用户财富相关的特殊产品(如理财、企业服务)，防止用户一时的意愿丧失，比“减少一次面攻带来的便利”更重要。另外，其实并不是所有的 *** 纵确认都需要用带遮罩层的模态d窗来实现，有的可以用非模态浮动层，但最好是能显示出 *** 纵触达区域的中间，以免被用户忽略。
在移动端，有一种交互风格，用户可以通过进程滑动吸出“删除”按钮(当前状态)，被打脸后换成“确认删除”按钮。这种情况可以很好地取代d出窗口或浮动层，并且在不对用户造成过多麻烦的情况下，改进了必要的错误预防假设。而在PC的整个产品中，使用d窗或者气泡浮层的情况，可以更符合用户对 *** 控战的认知习惯。
2. *** 纵结果。
常见的场景有:提交、添加、删除、保存、收藏、搜索、查询、下载、上传...
在那些场景中，当用户点击按钮、挖掘和编写表单等时。，并完成终极使命，设计师需要清晰地展现用户使命的结果:失败就是胜利。这可以让用户对自己的 *** 作更有信心，对当前的任务更有“控制感”。
如果只是笼统的告诉用户 *** 纵胜利(比如申请成功、删除胜利、提交胜利……)，建议使用吐司提醒，让用户“理解”一下(一定时间后会主动消失)，用户没必要特别在意战斗和关闭。
但是toast主动消失的特性决定了它不能发起大提醒，否则用户在有限的时间内很容易理解当地的疑惑，会给用户无形的压力。虽然我们提倡案子要简单，但总有一些 *** 纵的结果很好用，说“道不明。”偶尔需要图片来弥补澄清。这时候可以考虑用d出框、浮动层甚至新页面来展示(这在电商app中尤其常见)。
*** 纵结果的一些常见提醒
偶尔在一些巨大的场景中，除了宣布 *** 控的结果，还会要求用户了解 *** 控对产品和其他模块战任务的影响。有的用需求引导用户停止下一个任务。如果是 *** 控失败，同时我们也在上报结果，需要上报用户失败的结果以及如何处理。
除了显示 *** 作结果，还需要向用户报告如何处理它。
当用户进行搜索、查询等 *** 作时，产品应能实时呼应，在页面或搜索框中间接及时报告用户的结果。在这种反应中，搜索框的 *** 纵提醒是一种特殊的提醒。许多远见者提出了一些与 *** 纵响应相关的优秀小技巧来提升用户的搜索体验，比如恍惚搜索、保护关键词、白日做梦、立即回显搜索结果等等。有兴趣的小伙伴可以在网上搜索相关文章，这里就不赘述了。
3.任务历史
常见的场景有:删除、导入、查询、上传、下载、创新、安装、更新、卸载...
在那些场景下，任务不可能马上完成，系统需求有一个卸载、检查、查询或计算的过程。在这个过程中，我们必须使用户的 *** 纵得到适当的响应——设计者需要向用户报告两项工作:
我的 *** 作(提交、下载、安装、...)一般，产品已经或正在一般运行中；
那段旅程需要时间，请耐心等待；
历史绘图:
优秀的响应可以有效减少用户的困惑，减缓用户在等待过程中的急躁情绪。一些有趣的卸载动画，可以让用户感到快乐。有一些只需要简单面签的小游戏，让等待的过程变得非常欢乐，甚至是一种“享受”。
略显隐晦庄重的B端产品，大概是想象过度了，但那个思路值得借鉴:我们可以利用一些简单搞笑的小动画，再配上准确但不生动的案例单。那种情绪化的想象可以让用户更快地“感知”到过程，可以促进用户未来的愉悦感，从而降低他们对产品的好感。
搞笑的过渡动画可以减少焦虑，给用户带来快感。
及时的数据更改:
当列表中正在添加或删除大量数据时，如果用户能够及时看到数据列表的删除，会让用户更加“以此为中心”，对那个过程有一种“等待”的感觉，让用户感觉到任务正在停止，很快就会完成，从而减少用户等待时的焦虑。
点击“远程访问”后，页面中的数据会被及时删除。
4.表单验证:表单、字段输入模式和编号；
用户在挖掘和编写表单后，我们需要在用户点击“保留”或“提交”时停止检查用户输入的内容。除了阻止或减少用户的错误，它还可以规范用户的 *** 作，使存储在系统中的信息可控、标准化和结构化。
我们可以看到，在很多产品中，在检查挖到表单中的内容是否可以打开时，产品战开发者都喜欢使用吐司提醒。至于简单的表单，没什么不好，也比那些用d出窗口来解释细节的产品好，至于稍微大一点的表单，我们有更好的想法。比如在被 *** 纵的工具(如输入框等)周围使用笔墨提醒，方便用户实时快速定位到哪里挖写腐败。).
那么，在用户挖掘和编写表单的过程中，什么时间划分检查比较好呢？根据前后验证，我将表单验证分为“后”和“前”两类。
事后检查:
在B端产品的形式上，开发者似乎更倾向于“设置回”检查，即当用户在第一步点击“提交”或“保留”按钮时，他会根据字段的第二个顺序检查条目是否能满足请求。这样 *** 作初始用户设置的check集合的好处是可以减少之前的命令数量，同时可以减少用户在打字时对服务器的请求数量(一些简单的，比如字段中的几个命令被分割)，从而减轻后台的压力。
事后检查:点击“提交”时，检查必填项是否为空
预检:
那种出发没有错，但据我所知，很多预检其实并没有过度消耗资本；在那种条件下，我甚至提出把检查放在前面，让用户在输入的时候实时检查自己的输入是否准确，而不是挖了十几个字段才检查自己借了什么。
预检查警告提醒所呈现的机会通常是在用户记录或选择目标控件后，目标控件落入空核心时。然后，当用户更正录音(重新取芯)或更改录音内容时，提醒消失；当用户完成构建和更改时再次检查(再次计算内核)。那种验证应该是为了更好的体验的一种假设。
大多数情况下，我甚至提倡使用目的关系的检查提醒，比如输入框中间的浮动层，提醒条，背景下的笔墨，或者背景下的窗体区域，输入框或者背景的拆卸。这样的提醒可以非常方便用户快速定位堕落的地方。
输入框掉落空core后，立即检查输入内容模式是否准确。
5. *** 纵指示/提醒
常见的场景有:煽动控制形式，显示/隐藏功能，逐步显示可疑信息， *** 纵提醒...
至于页面中一些可以交互的元素，除了在视觉上与静态元素区分之外，还要在用户悬停时改变鼠标指针和对应的元素，以此向用户报告当前控件可以通过面击、拖动等方式进行 *** 作。，最简单的就是输入框，鼠标悬停时会变成“脚型”，获取核心时会变亮，以此通知用户可用，输入模式正在进行中。
相反，当一些控件(如输入框、下拉框等。)变成禁用，也可以通过进程把指针改成“禁用”图标来提醒用户，也是简单不雅的评论。
悬停时，会出现“禁用”图标。
由于pages空之间的限制和简单思路的要求，一些图形信息或功能按钮无法在当前区域部分显示。那个时间可以用一种渐进的方式展现出来。当用户将鼠标悬停在目标类别上时，会出现相应的信息、按钮或条目。根据用户行为逐步展示内容的方法，可以给用户很好的“掌控感”，同时也能让我们获得一个更复杂、更新鲜的世界。
当鼠标悬停时，会显示图标按钮的标题。
有一种特殊的 *** 纵反应情况: *** 纵提醒或澄清。一个常见的场景是，用户在点击一个按钮后，系统需要在用户停止 *** 控时提醒用户需要注意的成就和war事项，或者对这件事的步调给出详细的指示。
但需要注意的是，设计者必须确定“提醒”的重要性和必要性，这将影响用户的认知或任务完成的准确选择。否则，提醒(很多都是模态d出)会让用户感到繁琐和鲁莽，体验无疑会很长，而且往往会很蹩脚。
2.根据假定的风格分类:
常见的反应样式有:页面级提醒、d出、浮动层/气泡、吐司、下沉提醒(笔墨、图标、零件发光等。)，动态效果，声音和震动等。
1.页面级提醒
是指被用户 *** 纵后，用户会跳转到一个新的页面，在这里各种 *** 纵反应通过图形信息的过程展现出来。那种页面跳转的缺陷就是会给用户一种断裂感，让用户觉得产品比较大，比较适合展示巨大的 *** 控结果或者澄清。
2.d出窗口
通常有带遮罩层的手印浮动层，包括传统的对话情境和包含墨、笔、脚、画等元素的浮动层。那种情况的反应通常更具“强迫性”和“枢纽性”，只适用于非常重要的提醒和说明，使用时要慎重。一个好的响应假设应该是减少模态d出窗口的使用。
3.漂浮层/气泡
那里指的是无模式的，以 *** 纵工具的接触关系为载体，用笔墨或图片及时提醒用户的浮动层或气泡。那种风格的响应比页面中的d窗更“重”，能间接展现被 *** 纵工具的周围环境，对用户的打扰更大，关系更好。
4.祝酒提醒
各种被流程用户的 *** 纵所触动，并能在一定时间内自动消失的笔墨或图形提醒。吐司提醒会主动移动，不打扰用户，一般用于报告用户的简短和“随便看看”的疑惑，如“提交成功”、“完成”等。在使用toast之前，请确保您阅读了您向用户反映的疑问。如果被用户忽视，会有严重的后果吗？如果是这样，你不应该利用这种情况。
5.下沉提醒
一般来说，它显示了围绕被 *** 纵的工具或被 *** 纵的控件的风格变化。以下文字、图标、输入框、按钮等被禁用。那种变种类型非常适合在有大量字段的表单验证中使用，可以方便用户快速定位到那里挖掘和编写成果。
6.动力效应
用户 *** 作后，将通过动态效果(如过程控件、内容或页面的移动和消失)告知用户当前的形式、进度或 *** 作结果。简单搞笑的动态效果可以非常优雅地报告用户页面的变化，同时也能有效降低用户的焦虑和等待感，从而降低对产品的好感度。
7.声战震撼。
通过进程震撼或者声音情境来回应用户，比如QQ的震撼(去PC的震撼不是设备，实际上是一种动态效果)，迅雷下载时的声音“叮”。震撼之声在移动端使用的好像更多了。因为那种风格的回应过于固执，是在PC全网页的假设下，一般不提倡使用。
如何选择一个想象中的风格？
以下是我总结的。我在思考B端产品(PC端)，并“反应”例子和风格的对应关系。我们可以根据“反应”的功能实例和实际场景来选择开启方式。
3.摘要
“ *** 纵反应”的次要目标是报告用户的 *** 纵所带来(或能够带来)的结果、期望、效果或结果。它是用户交互的主要界面。理性的回应假设可以在产品战的用户之间建立一种优秀的互动，从而帮助用户更好地理解产品战的使用，停止或减少猜疑和使用问题，促进用户的群体使用体验。
我们在想象用户的 *** 控反应时，有两个基本原则:第一，在等待时，一个好的“反应”假设可以减少用户对产品的怀疑，怀疑就会不再担心我的 *** 控；二是要注意，除非特别重要的提醒或者澄清，那种反应不要太固执，打扰用户就好。
像往常一样，想象一个总结，哪里还不够，送上一块砖纠正一下。
本文由@Rindy发布。我已经答应不再重印了。
标题来自unsplash，基于CC0和谈。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）