用户体验设计（英语：User Experience Design），是以用户为中心的一种设计手段，以用户需求为目标而进行的设计。设计过程注重以用户为中心，用户体验的概念从开发的最早期就开始进入整个流程，并贯穿始终。其目的就是保证：
1、对用户体验有正确的预估
2、认识用户的真实期望和目的
3、在功能核心还能够以低廉成本加以修改的时候对设计进行修正
4、保证功能核心同人机界面之间的协调工作，减少BUG。
前端出现的BUG基本上在测试阶段就能被发现，然后得到更正，实在没发现的，也无法从数据层面捕获，所以前端的很多问题还是难以被发掘，但是造成的损失是–直接在用户层面就损失掉了。虽然是由设计师配色，但是不合理之处，前端页面仔应该提出改正。
其实我们所用的ui框架中也规范了很多操作对应的色彩含义，比如按钮的颜色红色——danger，灰色——info，操作——primary。
红色——热烈、冲动、强有力的色彩，也代表警告、危险等含义橙色——充满生机和活力的颜色，象征着收获、富足和快乐，常用于食物或电商网站黄色——明朗愉快的颜色，饱和度较高，象征着光明、温暖和希望，适合用于亲子相关主题绿色——清爽、平和、安稳的颜色，象征着和平、新鲜和健康，用于生鲜网站，给人一种干净新鲜的感觉蓝色——安静的冷色调颜色，象征着沉稳和智慧，因此一些科技类的企业网站通常会使用蓝色作为主题色紫色——高贵的色彩，象征着高贵、优雅、奢华，在高端化妆品栏目使用黑色——象征着权威、高雅、低调和创意，此外也象征着执着、冷漠和防御，是设计中的百搭颜色白色——象征着纯洁、神圣、善良此外，白色还象征着恐怖和死亡。在设计中，通常用白色作为主题色，配合大范围的留白彰显网站格调在网页设计中，由于同样的颜色会受限于不同的显示设备、操作系统、显卡甚至是不同的浏蓝器，导致配出来的颜色会显得不同，这会严重影响到网站的整体风格，为此人们通过研究，发现并指定了216种Web安全色。当然在现在浏览器版本下应该不会存在问题，除非你做的项目将会在非常低的系统上使用，比如还是用xp系统的政府使用。如果是这样，在考虑网站的配色时，应该尽量使用216种Web安全色彩。
现在的网页首页大部分有多个板块，按照人们的视野捕获及思维方式，肯定是以从上到下的渲染才是正常的，那么首页进来分开调用各个板块的接口必然导致数据渲染时存在先后问题，便成为了不可控的了。解决这种状况我想有两种方案：
（1）Promise.all将所有板块的接口全部成功后时，再去渲染到板块上去，能看到整个的首页都是文字板块显示完成，然后加载图片其他资源。
const getBanners = new Promise() const getArticles = new Promise() Promise.all(getBanners, getArticles) （2）Promise.then保证首页最开始就在视野之内的部分先显示，后面的都在该部分显示完毕再显示。
function getBanners(){ return new Promise() } function getArticles(){ return new Promise() } getBanners() .then(()=> getArticles())在首屏加载资源较多，可能会出现白屏和闪屏的情况。体验不好。盗图一波，小米商城使用骨架屏进行首屏在资源数据还没有加载完成时显示，给很好的体验效果。
网页的文案相当重要，比如：
单位金钱的单位：￥和$；质量单位：g,kg,t；个数单位：个,件,打；长度单位：mm,cm,dm,m,km
长度前端开发必须要想好文案长度变化后可能对布局的影响，到底是换行还是文本超出…，或者是限制长度
前端的交互体验直接决定了产品的成败，如果用户打开你的应用等待了10s没有反应，就一片空白，肯定认为这个已经没有维护了，直接就关闭了。或者在你的应用中太多不合理的操作，卡顿，层级嵌套太深，功能太过隐藏，导致功能完全的无法使用，那么肯定就会走向末路。
如果要加载过长时间，给用户一个反馈，能让用户知道现在系统还在运行，而不是卡主了或者是系统问题。
页面加载时数据加载时下拉数据列表详情提交数据时在提交数据时，如果不做限制，用户可以重复提交，会导致脏数据存在数据库里。
去抖 double 解决短时间内再次提交会被重置掉上次提交，不过会让一次提交也缓慢一段时间
变量控制在异步的的处理时，Promise.finally再改变这个变量，那么这次接口调用未返回时就不能再次提交，加上loading效果，能让用户知道现在在提交数据中，如果接口超时再重置变量
现在的移动端tab栏目基本都是使用滑动tab，由于手机的屏幕越做越大，人们又基本是单手操作，那么很难去点击屏幕上面30%的区域，做成滑动tab能方便用户使用很多。
在接口长时间未响应时，应该中断这次请求，可能是网络问题，路由器信道堵塞之类，刷新一下网络比一直等更有效。所以网页项目还是做上超时限制，当然在预知接下来的操作需要海量数据，耗时巨大时，给用户相应提示，或下面这条：进度提示
如上传、下载资源时，最后就是能显示当前进度，网页上下载文件是基于浏览器的，浏览器自己就有进度提示，但是上传时需要使用一些UI库，或者自己来实现。
用户的删除操作应该有提示信息，询问后如果的确还是要删除，再删除，而且现在数据基本都是逻辑删除，后端也不想承担数据风险。
我曾经用过一个微信小程序，微信授权我也点了，但是它非要我注册，每次点击一个页面就弹出来一次，这就算了，它的注册信息中要采集身份证号，一大片的表单，我表示这样的产品有几个用户受得了。在测试产品时就把自己当成一个小白用户，才能感受到产品的优劣，现在基本上都是做功能测试，性能测试，压力测试，反而忽略了最根本的东西，用户是人，而不是机器。
在开发移动端vuejs项目时，手指触摸时会出现300ms的延迟效果，可以采用better-click对ipone系列的兼容体验优化。
前端埋点主要是为了服务运营人员采集用户行为数据，进行后续的数据分析工作。除此之外也能对产品的改善采集重要数据，像微信小程序就直接有统计每个页面的流量。
日活最能反映某个功能和页面的使用情况，如果是公司主推的业务，日活不好的时候就需要改动了，如果是逐渐没落的功能，也要考虑将其整改还是删除
要想下线某个功能或者板块，没有哪个公司敢直接就下线了，可能结果就是直接失去了粘性用户，甚至会给用户造成严重的经济损失，然后将你们的恶行公布到各个平台渠道。正确的方式应该是以下几步：
（1）、将之前的一个版块，换成从一个图标进去的二级版块，继续观察日活
（2）、推出新的功能争夺份额，既然产品上想剔除之前功能，可见对公司毫无收益，用新功能争取用户
（3）、当日活趋近于0时再下架，切保留以往数据
根据埋点，记录用户日志，能模拟用户行为，测试产品的使用情况。如果大多数用户从某一步骤中断，那么应该去排查了。
前端的错误没在测试那里测出来，基本上就流向到了用户那里，但是由于客户端的多元化，的确会存在很多兼容问题，尤其是移动端，既有分辨率上的差别，还有安卓系统版本上的差别，如果是基于微信环境还好，微信相当于是做了一次的版本限制。那么回收错误信息就是很重要的了，因为一个报错可能失去的是一个用户，像很多app获取一个用户的成本都需要5元。
Vue全局配置 errorHandler可以进行全局错误收集,我们可以根据这个特性对前端异常做这样的处理：业务错误直接写在业务里；代码错误、ajax请求异常等错误可以进行全局捕获然后抛出，不至于前端页面挂掉
import Vue from 'vue' //系统错误捕获 const errorHandler = (error, vm)=>{ console.error('抛出全局异常'); console.error(vm); console.error(error); } Vue.config.errorHandler = errorHandler; Vue.prototype.$throw = (error)=> errorHandler(error,this); 1、代码错误不用手动抛出，全局会捕获到2、如果是ajax异步请求，异常需要通过this.$throw()手动抛出项目内进行的异常判断少之又少，这是很危险的行为，每次接口出现的数据不符合预期都会出现空白页崩的现象。在未来的项目内，异常判断也要加入规范内，是项目很重要的一个组成部分，最起码的全局有异常捕获，其次每个具体的页面内判断字段是否存在，类型是否正确
（1）全局捕获异常 window.onerror = function (errorMessage, scriptURI, lineNo, columnNo, error) { console.log('errorMessage: ' + errorMessage); // 异常信息 console.log('scriptURI: ' + scriptURI); // 异常文件路径 console.log('lineNo: ' + lineNo); // 异常行号 console.log('columnNo: ' + columnNo); // 异常列号 console.log('error: ' + error); // 异常堆栈信息 }; （2）组件捕获异常，react的16版本后新增 componentDidCatch(error, info) { const isNewError = (error.toString() !== this.state.prevError.toString());// should only run once if (isNewError) {//判断两次错误不一致才再次执行，不然一直循环 this.logErrorToMyService(error, info); this.setState({ prevError: error }); } }将错误日志记录到数据库，最好将用户的环境，具体的操作页面能捕获到，才能去解决这个问题。
