电子商务网站设计的书,中国商标免费查询平台,wordpress网页自适应屏幕大小,库尔勒网站建设前言“前台重体验#xff0c;后台重逻辑”#xff0c;B端谈 UX 有没有价值#xff1f;一切电子化的今天#xff0c;运营、审核、电销、账务……无数岗位依赖中后台系统来完成他们的日常工作#xff0c;好的 UX 确实可以直接为这些产能提效当中后台的工程师们花费了巨大精力…前言“前台重体验后台重逻辑”B端谈 UX 有没有价值一切电子化的今天运营、审核、电销、账务……无数岗位依赖中后台系统来完成他们的日常工作好的 UX 确实可以直接为这些产能提效当中后台的工程师们花费了巨大精力沉淀出的一些技术产品最终落地到业务上的时候得到的是终端用户“XX系统简直就是狗屎”的抱怨这就是一种极大的资源浪费前端工程师的产出是直接对接终端用户的前端工程师应该是人机交互的专家UX是User experience的缩写即用户体验其核心是用户体验指用户在使用产品以及与产品发生交互时出现的主观感受和需求满足。其中最重要的概念就是以用户为中心去思考人机交互一些设计思路实用先于视觉通常情况下好看与实用并不会产生冲突但有一些情况下也需要取舍上图在视觉上看起来没有任何问题符合对齐原则。但如果这个筛选器的宽度是自适应的实际应用中就会存在一些问题。当用户使用较大分辨率的显示器时筛选器的宽度会被撑开此时候项目名称和日期的左右对齐布局就会出现距离过远的问题。当用户需要在若干候选项中筛选数据时视觉焦点需要频繁的左右横移造成视觉疲劳。倘若是使用看起来“不那么和谐”的跟随布局就不会有这样的尴尬以业务逻辑为准交互逻辑的设计需要契合业务逻辑在某些不能确定的交互场景下不妨从业务角度去思考一个典型的场景是表单默认值比如一些必填项或单选项是否需要给默认值给哪个默认值需要考虑终端用户的实际使用场景如果某个默认值是绝大多数场景下的最佳选择默认选择该选项可以减少用户的重复操作提升表单效率如果是是长串文本如备注而用户的大多数文本类似只有少数关键字不同就可以考虑填充用户上一次的备注内容甚至保存用户的常用文本作为模板而如果是不可逆的操作则宁可不设默认值每次都让用户手动选择确认以避免出错。源自网络侵删可视化优先相比数字和文本人的大脑更容易接受图像除了常见的图表之外对于一些有逻辑相关性的数据我们也可以使用可视化的方式来表达比如中后台系统的页面上往往充斥大量的table页面在某些字段有业务逻辑关联的情况下就可以使用可视化的方式来表达既节省了字段空间又增加了数据的易读性费茨定律费茨定律指的是使用指点设备到达一个目标的时间同以下两个因素有关设备当前位置和目标位置的距离越长所用时间越长目标的大小目标越大所用时间越短将列表的操作区域收束在尽可能靠近的地方且给每个独立的操作区域划分合理的间隔有效减少鼠标的来回移动提升阅读信息与操作的效率对比以下图片顺流而行用户在执行一些需要集中注意力的任务时会进入心流状态在此状态时不愿被打扰我们给用户提供交互时应该思考一个问题什么情况下应该顺应用户的心流什么情况下有必要打断比如一些不那么重要或不那么复杂的扩展操作应尽量避免使用遮罩弹窗遮罩弹窗不但会打断用户的心流而且增加用户的移动成本一些行内编辑的场景也应尽可能避免进入编辑状态时出现行、列宽高的抖动打扰用户心流一些弹出式的输入可以直接帮助用户提前获取好控件的焦点并提供快捷键方式的确认减少用户的低效操作而一些重要的、影响较大的、不可逆的操作则需要有意打断用户当前心流将用户的注意力转移到重要的确认事项上明确、及时反馈反馈的重要性不用多说现在的UI库基本也自带各种反馈机制在什么时候使用哪种程度的反馈是我们需要学习的一种典型的反馈场景是长时等待通常是某些后端接口需要响应较长的时间需要用户等待一段时间根据需要等待的时长反馈的设计也不一样4s内的反馈一般是一个简单的loading就可以了而超过4s的反馈就需要有更加明确的反馈机制了目的是让用户确信不是程序出了问题也要让用户知道自己还需要等待多久一般可以使用进度条也可以是文本如果是较长时间的等待可以考虑让用户可以去做其他事无需在界面上等待在后台完成处理后再给用户一个延迟的反馈好的反馈机制可以减少用户的迷惑在下图的流程编辑器里当连线被拉出后会将可连入的节点高亮并给出连入点即使第一次使用的用户也能知道下一步该做什么除了长时等待之外一些独立的小编辑项可以使用弱反馈不打扰常见的痛点场景条件缓存在带有条件查询的页面上将查询条件通过url的get参数保存下来以便将当前的查询条件保存在浏览器书签或进行分享在页面意外关闭或刷新后也可以第一时间回复在服务端渲染的时代这是常规操作但在普遍使用SPA的当下经常被忽略。宽表如果是表格的字段太多可以参考《交互设计四策略》中的“组织”、“隐藏”和“转移”策略可以是固定部分字段剩余字段收起通过滚动展示缺点是windows客户端下使用鼠标的用户体验很差需要鼠标拖动横向滚动条的操作很反人类尤其是小屏下查看超过一屏的数据简直令人崩溃可以提供快捷键来改善但需要让用户知道有快捷键会提升用户培训成本。另一种方式是让用户自定义列头或是将部分字段收纳起来作为二级信息展示也可以通过合理的组织整理提升cell的利用空间通常越是庞大的数据表格留白越少也越需要border来加以区分参考Excel以上几种方案各有利弊也可以结合使用需要权衡业务场景来定夺查询字段查询表单是中后台系统最常见的页面前面说的字段太多引申出另一个问题是搜索选项与字段数量成正比导致随着功能的增加搜索选项也不断增加丧失易用性通常的做法是收起一些不常用的搜索项需要时再展开另一种更为讨巧的方法是将搜索条件直接放置于对应的表头上可以节省很大一部分字段不管使用哪种查询设计方式都建议将当前的搜索条件直接平铺给用户并提供清除功能详情页不同的业务对详情页的需求天差地别无法一概而论单从展示层面来说详情页本质上需要解决的也是有限空间下的复杂信息展示首先是需要对功能区域进行合理划分其次是对多个大块信息的处理通常会选择使用tabs来处理但个人建议使用平铺锚点的方式来代替tabs主要是以下几点tab数量过多时tabs本身就需要翻页增加无用操作查看相邻数据时滚轮查看比移动点击效率更高当用户需要搜索某个关键字时平铺的内容可以通过浏览器的搜索直接定位到而tabs无法做到从交互层面来说一般详情页都有返回上级页面的需要而由于详情页本身的复杂性可能内部还存在路由跳转、锚点跳转等情况无法依赖浏览器的回退来返回可以将详情页以抽屉组件的形式直接在列表页上滑出也可以将上级页面数据、返回入口以快捷方式的形式带入详情页方便直接在详情页内做切换长表单过长的表单可以让用户分步填写如果要在一屏内展示则最好控制住容器的max-height这是为了让确认按钮组在页面上随时可见且不会距离表单项太远。让用户通过滚轮查看和填写表单将视觉热区缩小在一片固定的区域内可以减少用户的阅读疲劳感。有限空间下的复杂信息展示如上图所示在保证布局合理性的前提下尽可能减少不必要的空间占用这点是细节在业务迭代任务较重的情况下最容易被忽略。狭窄的场景需要放一些较大文本内容表单的需要给用于显而易见的提示确认按钮到底放在左边还是右边一个有趣的实验是无论确认按钮放在哪边用户的出错率都相差无几但如果一个系统中确认按钮的位置前后不统一就会大大提升用户的操作失误率。所以我们要确保的是系统内的设计规范的统一这一点在多人协作项目时最容易被忽略。总结UX 设计有很多法则但在实际应用中我们不应该盲目遵循很多时候我们需要从技术、业务、终端多个角度去做权衡将自己代入到实际的用户中去审视。当然在知道系统的构造之后很难再去模拟一个小白用户所以如果有机会还是应该尽量观察终端用户的实际使用场景。除此之外也要对UX设计的结果进行追踪和验证可以借助埋点也可以对终端用户进行抽样调查。碎碎念一个应用和一堆功能页面的区别在于功能页只关心你的数据查出来没有而应用会关心你查数据快不快看数据爽不爽数据查出来之后要干嘛使用中后台完成日常工作的用户工作中通常会伴随着大量重复性的操作并且通常没得选。由此即使是一丁点体验上的不便在无数次的重复下也可能会使用户崩溃得出这系统不行的结论。前端工程师向业务方负责的同时能用也有义务向系统的终端用户负责好用。
