首页

前端登录流程

前端达人

前端登录流程

初次登录的时候,前端调后调的登录接口,发送用户名和密码,后端收到请求,验证用户名和密码,验证成功,就给前端返回一个token,和一个用户信息的值,前端拿到token,将token储存到Vuex中,然后从Vuex中把token的值存入浏览器Cookies中。把用户信息存到Vuex然后再存储到LocalStroage中
Cookies
在这里插入图片描述
LocalStroage
在这里插入图片描述
在这里插入图片描述
然后跳转到下一个页面,根据后端接口的要求,只要不登录就不能访问的页面需要在前端每次跳转页面师判断Cookies中是否有token,没有就跳转到登录页,有就跳转到相应的页面,我们应该再每次发送post/get请求的时候应该加入token,常用方法再项目utils/service.js中添加全局拦截器,将token的值放入请求头中
在这里插入图片描述
后端判断请求头中有无token,有token,就拿到token并验证token是否过期,在这里过期会返回无效的token然后有个跳回登录页面重新登录并且清楚本地用户的信息在这里插入图片描述

再全局拦截器中加代码在这里插入图片描述

转自:csdn 作者:mslmhl

app界面赏析 ——— 北京蓝蓝设计 移动端UI设计资源分享(二十一)

前端达人

移动互联网的迅速崛起,让移动网页,移动客户端越来越重要,客户端的页面设计也是一门很大的学问。科技迅速发展的今手机屏幕的尺寸越来越放大化,但却始终 很有限,因此,在APP的界面设计中,精简是一贯的准则。这里所说的精简并不是内容上尽可能的少量,而是要注重重点的表达。在视觉上也要遵循用户的视觉逻 辑,用户看着顺眼了,才会真正的喜欢。


接下来为大家分享精美的app UI设计案例:


jhk-1620273584169.jpgjhk-1620273585641.jpgjhk-1620273589355.jpgjhk-1620273592714.jpgjhk-1620273594998.jpgjhk-1620273606526.jpg



--手机appUI设计--

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服



  更多精彩文章:

      手机appUI界面设计赏析(一)

       手机appUI界面设计赏析(二)

       手机appUI界面设计赏析(三)

       手机appUI界面设计赏析(四)

       手机appUI界面设计赏析(五)

       手机appUI界面设计赏析(六)

       手机appUI界面设计赏析(七)

       手机appUI界面设计赏析(八)

       手机appUI界面设计赏析(九)

        手机appUI界面设计赏析(十)

       手机appUI界面设计赏析(十一)

      手机appUI界面设计赏析(十二)

      手机appUI界面设计赏析(十三)

      手机appUI界面设计赏析(十四)

      手机appUI界面设计赏析(十五)

      手机appUI界面设计赏析(十六)

      手机appUI界面设计赏析(十七)

      手机appUI界面设计赏析(十八)

      手机appUI界面设计赏析(十九)

      手机appUI界面设计赏析(二十)



从B站用户反馈出发,谈一谈产品的开放性

涛涛

编辑导语:随着互联网的不断发展,用户在各种产品上能体验到的功能越来越多,并且如今的产品设计在很大一部分都会考虑到用户的想法,产品的开放性也随之提高;本文作者分享了关于从B站用户反馈出发,谈一谈产品的开放性的思考,我们一起来了解一下。


最近在B站看番时,不小心翻到了用户反馈论坛,去看了一些用户反馈。

以下是其中一些反馈:

  • 建议加个重置口味功能,首页给我推送的都是些什么玩意儿。
  • 请增加字号调节选项,字太小看着不舒服。
  • 发视频能不能添加设置私密功能。
  • 我想收藏评论。
  • 对已关注的up,可以自行选择是否接受动态推送。
  • PC首页的“热门”变成了有针对性的推荐了,感觉找不到自己想不到的视频了,很痛苦
  • 看到了新增了一个“互动弹幕”,能否给它加一个开关来决定我要不要开启这个互动弹幕。

看的反馈越多,三个字越是清晰:控制权,用户希望控制跟自己相关的事物。

而这个控制权,一般是掌握在产品设计者手中的,这就引出了本篇的话题:开放性。

布里利(1967)对开放性的定义是:一个系统是开放的,不仅仅因为其与环境间的相互交换关系,还因为这种相互交换关系是变化的关键因素。

一、Web2.0:产销一体化

Web2.0是一个古老的概念了,但仍鲜少见到真正应用这个概念的产品设计。

在《社区化》一文中,我根据生产者与消费者的边界变化提出了三个时代:

  • 第一时代:严格的质量管理体系,专业人员进行生产与筛选,生产与服务分离;
  • 第二时代:提供工具及平台,消费者同时也是生产者;认为UGC(用户产生内容)就是Web2.0的核心是一种错误的认识,Web2.0强调生产者(一种角色)向消费者(另一种角色)的全面开放,用户生产内容只是其内容生产的开放;
  • 第三时代:各种角色的边界完全消失,生产者、消费者与服务者完全融合。

在各大长视频应用中,仅有B站使用了web2.0的概念,且较为初级,主要使用的是UGC+SNS这两类形态。

从用户反馈中可以得知近期B站做了一个改进,将首页的热门推荐改为了个性化推荐;

无论是热门推荐(中心化设计)与个性化推荐(去中心化设计)都是web1.0思想的设计,因为用户在其中只能被动获取,从这个角度来看,无论怎么改,都没有改变其专业生产内容(PGC)的本质。

从开放性的角度来看,有三个改进的方向,分别对应了三类设计:

1)赋予用户选择权:允许用户选择热门推荐还是个性化推荐,这可以称为尊重用户,但不能称为开放。微信的改进中越来越侧重用户知情权、选择权和控制权,比如点击链接跳转时必须经过用户同意。

2)允许用户参与到个性化推荐的优化进程中,比如知乎的不感兴趣、设置屏蔽词。

从B站用户反馈出发,谈一谈产品的开放性

3)将个性化推荐的控制权交给用户,将隐藏于后端的对用户的个性理解开放,让用户参与到个性化推荐的演化进程中,这是一种由内向外的开放。

在《社区化》一文中描述了产品的开放性的两个类型:

产品的开放性指产品从通用性设计与固定功能走向个性化设计与模块化功能,从完成的、封闭的结构走向未完成的(留有空间)、开放的,从被动开放(接受反馈与建议)到主动开放,从部分开放走向全面开放。

结构开放:在设计阶段开展共同设计或是在设计后留有参与空间,通过将产品分为多个单独的要素或模块,允许参与者在一定范围内对结构进行拆分、重排或其他再组合设计;汽车生产中使用定制化的柔性策略一方面避免了落后的市场调查,使生产直接面对真实客户的真实需求,另一方面多样化的需求也有助于改进了解潜在需求改进通用型设计,比如将大量需求的个性化设计成为通用型的基本设计。

使用开放:允许使用者发挥想象力创造性的使用产品,创造新的用法、用途或使用场景,以增强产品使用的外延,延伸产品的功能,增强产品的生命力;游戏开发商越来越重视玩家贡献给游戏玩法带来的丰富性,在设计游戏时,即考虑了开放性的设计,提供编辑器使玩家能够用独特性的视角来完成独特性的内容。

二、参与式设计

美国教育学家 Banathy 在1991年发表的《谁应当是设计者? 》中认为, 在过去的40年间, 人类的活动系统经历了四代设计方法的演进:

  • 第一代设计是规定性设计,深受系统工程方法的影响,常通过立法实施及自上而下推行;
  • 第二代设计是权威性设计,引进顾问和专家,研究某个特定的系统问题,进行需求分析,并向决策者提供问题的解决方案;
  • 第三代设计是参与式设计,其设计过程是设计者和决策者通过实际讨论而展开的;
  • 第四代设计是使用者设计,其提出人类活动系统必须由那些身处其中的人,利用这些系统的人以及这些系统所服务的人共同来设计。未来具有开放性的特点, 其走向如何, 取决于人们的目的导向和设计实践。其口号是: 设计未来是我们自身的责任, 我们理应对开创自己的未来负责。

将其简化一下,根据设计的主体,分为三类:

  • 为使用者设计(design for user):设计主体是权威与专业人士。
  • 和使用者一起设计(design with user):设计主体也是专业人士与使用者。
  • 使用者设计(user design):设计主体是使用者。

我见到的产品一般处于权威设计向参与式设计转化的进程中,参与式设计注重为参与而设计,在设计中注重留下参与空间,也就是“消费者空间”。

B站首页右侧,有一个可以控制分区位置的设计,允许使用者根据自己的意愿控制各个分区的位置:

从B站用户反馈出发,谈一谈产品的开放性

在微信内,允许使用者选择发现页内显示的模块:

从B站用户反馈出发,谈一谈产品的开放性

在网易云音乐中,给使用者留下大量可参与的空间,比如歌词翻译:

从B站用户反馈出发,谈一谈产品的开放性

参与式设计的典型方法是模块化设计,模块化设计是指在对一定范围内的不同功能或相同功能不同性能、不同规格的产品进行功能分析的基础上,划分并设计出一系列功能模块,通过模块的选择和组合可以构成不同的产品,以满足市场的不同需求的设计方法。

仍以B站首页的分区为例,将每个分区设计为一个模块,交给使用者进行再设计,这样,使用者不仅可以调整分区的顺序,还可以选择是否显示某个模块。

参与者设计的反向使用者不仅不提供空间,还会挤占参与者空间,比如Youku首页的专辑推荐,这应该是留给参与者的空间,这是内容的再组织的一环。

从B站用户反馈出发,谈一谈产品的开放性

三、使用者设计

在B站反馈中,看到了一些令我震惊的建议,比如:我想收藏评论。

对这个建议进行分析,会发现收藏对象的多样性,从这个角度出发,可以针对收藏的范围进行系统设计。

在v2ex社区中,也见过类似的建议,比如:比起同好,我更想知道同恶。

同好是有相似兴趣的人,同恶是有相似反感对象的人;这是基于正向情感与反向情感的设计,这种设计思路,单凭设计者,是很难空想出来的。

《失控》中戴维·艾克利描述了生命演化:想要得到和生命真正类似的行为,不是设法创造出真正复杂的生物,而是给简单的生物提供一个极其丰饶的变异环境。

在系统思维中,有两个概念,跟开放性息息相关:自组织与涌现。

自组织:组织是指系统内的有序结构或这种有序结构的形成过程,以组织力的来源划分,分为自组织与他组织,如果组织力来自外部指令就是他组织,如果不存在外部指令,系统按照某种规则,各尽其责、协同而自动的形成有序结构就是自组织。

在《从设计为大众到大众参与设计》一文中提出了一个有益的思想:设计设计的过程,一种面向创造与再创造的设计;

后现代主义时代,结果已不再是主要目的,结果是充满流变性的,而过程却是决定结果流变性的主要因素,什么样的过程方式和实施原则是创作主体的主要任务,也可以说过程即是目的。

在这一观念思维下,设计过程不再是私密的个人性行为,也不再是潜藏在设计成果背后的那种工作室行为,而是可以拿到前台,成为设计作品本身。

设计的目的也不再是结果的唯一性了,过程的方法如何和过程的交互价值都会成为设计的直接目的,设计的创作就是在创作一种过程,一种思考过程或者体验过程。

四、竞争的方向

在马斯洛的需求层次理论中,将需求层次分为五个基本层次:生理需求、安全需求、社交需求、尊重需求、自我实现的需求。

在Kano需求分级模型中,将需求分为三个基本层级:基本需求、期望需求、兴奋需求。

从这些对需求的分级上,可以看出两个方向:

1)激励的方向:对用户的激励,应该从低级需求向高级需求,在满足低级需求后,逐步向归属感及自我实现的需求发展;应该意识到,在低级需求得到满足后,将逐渐失去激励作用。

2)竞争的方向:在基本需求层次的竞争是一种低层次的竞争。目前几大长视频网站的主要的广告及VIP收入等建立在基本需求基础上,观看视频是最基本需求,如果长期将目光放在满足客户的基本需求上,就会始终处于一种低层次的竞争。

这也是产品的开放性设计的意义所在:提高激励层次,打造上层竞争力。

在这方面,B站走在了前列,但从整体来看,B站的社区化并不彻底,仍停留在参与式设计的起步阶段,开放性十分有限。

由于基因问题,其他长视频网站想一步到位社区化并不现实,以为建立一个内部社区就是注重用户参与也是一种错误的想法,开放性应该是全局的思想,从组织的全局到产品的全局,而不是具体的某种产品形态。努力从web1.0的专业生产内容思维走出,开始为用户设计,在设计中注重用户参与,一步步走向参与式设计,乃至使用者设计,是一条实用的道路。

在使用一些产品时,常常会想一个问题:产品是谁的?在设计产品时,也会产生一个深重的疑惑:如何设计未知?

随着隐私时代的到来,使用者会逐渐觉醒主人翁意识,期望在产品中自我发展自我实现,而产品也需要使用者的丰富背景,来塑造一个多样性的生态系统。

而随着产品的系统复杂度增加,面向已知的设计已然不足,要使产品具备自我生长自我完善的能力,需要从未知中汲取营养。

文章来源:人人都是产品经理  作者:天下雪

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务


如何在设计中构建共情?

涛涛

同理心对于任何人来说都是难得可贵的,它在人际交往中有非常突出的优势。对于设计师来说,则更为重要。拥有同理心的设计师往往能更好的进行设计,知道用户的需求才有可能做出让用户满意的产品,满足了用户的需求,他们才会愿意长期使用你的产品,从而形成正向的反馈。

在体验设计的过程中,如果不能对设计对象有更深入的了解,设计思维就无法开始;而用户对产品持有的观念、态度甚至意见并不一定会表现的很明显,这需要设计者更加主动的与用户进行互动去构建共情。

这可以使得你能够更加了解他们的需求、想法、情绪和动机,好消息是,你能掌握多种方法来与用户构建共情去获取更多信息;并且当你有足够的“正念”和经验时,你也能成为共情他人的专家。

“正念”:有目的的、有意识的,关注、觉察当下的一切,而对当下的一切又都不作任何判断、任何分析、任何反应,只是单纯地觉察它、注意它。

共情的含义

1. 百科

共情(Empathy),共情又译作同感、同理心、投情等,由人本主义创始人罗杰斯所阐述的概念,却越来越出现在现代精神分析学者的著作中。

2. 通俗含义

我们常说的感同身受、换位思考、同情心、设身处地、将心比心这都是共情的一种描述。

Empathy一词源于德语“Einfühlung”,意为让人们跟艺术品融为一体,比喻走进一件艺术品的奇妙体验。

因此国外常常会看见“站进别人鞋子里去”的共情比喻——(Stepping into their shoes as the saying goes, in order to gain a deeper understanding of their situations.)意为正如俗话所说,站在他们的立场上,以便更深入地了解他们的处境。

对于“共情”我更多的理解成是两个或多个载体之间的一种共识一种情绪共鸣,然后再到行为跟思维上的影响。

但实际上发生完全的共情是不可能的,有时连我们自己也会做一些无法理解的迷惑行为,并且客体是多样化的,可以是跨物种的,跨维度的;而我们要做的就是在工作中定义共情的有效范围,尽可能的与目标用户产生共情以了解更多信息或需求,然后去定义和构思新的需求与设计。

共情很重要,但它不是设计工作中的全部,有效而不要过度的使用也很重要。

  • 共情载体的多样化可以是你通过一幅画感受到了作者的情绪表达;
  • 十字路口听见火车的鸣笛声,从而感知到危险的信号;
  • 当你傍晚处在城市生僻的角落,打开地图软件,亮起了回家的导航

如何在设计中构建共情?收下这份6000+的干货总结!

3. 身边的共情

我们身边的共情无处不在,正是这些共情使得人与人之间的情感更丰富,当然也是因为人类有强大的表达能力。通常当客体情绪在表达出来的情况下,主体是可以更容易得到共情的。

所有当主体更专注的去感受客体的情绪表达时,能够使达到共情变得更迅速。

如何在设计中构建共情?收下这份6000+的干货总结!

常见的共情场景;

  • 身处于电影院,看到某一段感人的情节,很多人开始泪盈眼眶;
  • 朋友讲述着自己的不幸,你听完后的同情与表示理解他;
  • 看着熟睡的婴儿,人们自觉的保持了安静的氛围;
  • 准备上楼,当眼看电梯门就要关上时,里面的人帮忙打开了电梯门;
  • 正在写报告时,突然的停电让你措手不及,也让你的同事措手不及;
  • 与伙伴开黑游戏,共同取得胜利那一刻。
  • …..

以上都是一些生活中常有的共情场景。

通常当我们与其他客体得到共情时,往往我们能够更清楚客体传递的信息是什么、需求是什么,这完全可以应用到我们的设计场景中帮助我们获取更多的有效信息。

共情对体验设计的作用

如果你想要更了解你的产品用户,从而让你的产品更好的服务用户得到更好的体验口碑,那么体验设计师如果对目标用户没有更深入的了解,那么产品设计中的各种设想都是没办法决策的,甚至都难以测试和验证,这对产品研发一定是一个危险信号。

而共情则能帮助我们洞察用户需求和定义问题,所以共情在体验设计中显得基本且至关重要。

如何在设计中构建共情?收下这份6000+的干货总结!

1. 电商的界面设计

产品原型与交互界面时常是有所出入的,其原因在于前者更关注产品本身框架与盈利点,而后者更注重整体的用户体验的细节。

共情用户需求,以及思考商业盈利与用户体验之间平衡的点似乎是无法脱离共情应用的。这便是共情应用的一种体现,也是共情价值与设计赋能的体现。

如何在设计中构建共情?收下这份6000+的干货总结!

2. 移动端常见广告推广界面

一直以来在产品营销广告中,始终存在一些流氓的交互方式让用户苦恼。往往更加注重和尊重用户感受可以更好的提升用户的好感与使用体验,这便能够使产品与用户之间的感情升温赢得口碑。

如何在设计中构建共情?收下这份6000+的干货总结!

3. 组织产品功能架构时

在构建产品业务框架时,大多可能会出现以公司服务资源为中心的构建方式,但同时这种由内而外开发方式会为产品带来更多的弊端(往往产品投入使用后,会出现超出预期的问题)。

尝试去站进用户的鞋子里去,或者找来目标用户甚至是相关的专家来做咨询,减少研发迭代的弯路。

如何在设计中构建共情?收下这份6000+的干货总结!

4. 用户研究中的共情应用

用户画像是体验设计中常见的一种设计工具,它能够帮助产品定义目标用户,能够有效用于产品设计决策或者洞察用户需求等。

一个好的用户画像是基于真实用户的,它不是胡编乱造的。画像在于形成多组可供参考的角色材料,这有利于跨团队跨层级之间快速实现共情,达到业务目标的统一性。

因此一组目标用户画像能否帮助团队快速实现共情是一个重要的衡量标准,而不仅是一组人口调查数据。

如何在设计中构建共情?收下这份6000+的干货总结!

5. 用故事去描述

故事的元素通常会更丰富更有趣味,用故事叙事更能提升用户的兴趣和关注,这能便于构建共情。

因此当你发布测试任务或者撰写研究报告时,都可以加入背景故事或用故事叙事,便于对象更容易理解和共情,你甚至可以用笔绘制故事版,像四格漫画一般。

因为用图传达概念或信息更容易让人记住或回想起来,并且当你用这些方法时,自身也能加强理解。共情不是单向传递的,不要高估对方的理解能力,让你的信息更简单明了的传递也是重要的共情应用!

如何在设计中构建共情?收下这份6000+的干货总结!

6. 仔细倾听和观察

在与目标用户进行互动的时候,通常会借助电子设备帮助记录这个过程,目的是为了更仔细的观察和聆听,并注意到被忽略的信息。

就像一种正念,我们会带有目的性的观察目标活动,并且不会进行干涉,同时不对当下发生的一切提前作出任何结论、分析或判断,直至这个过程有了一个里程或结果,我们再将收集到的各种信息放在一起去思考。

倾听和观察是人与人之间互动的根本方式,相对仔细完整的倾听与观察可以获取到更加有效的共情,而片面的则可能产生共情偏差。

如何在设计中构建共情?收下这份6000+的干货总结!

7. 小结

共情在体验设计的应用中很广泛也很重要,甚至还延展了许多帮助共情的工具,这些都是为了让设计者能够更好的了解市场、发掘用户需求、甚至找到新的产品机会,最终帮助企业解决产品实际问题。

有时在共情工作中,我们就像一个老中医一般,对患者望闻问切。 一旦有了问题,就应该及时使用适当的方式去共情目标对象,定位问题所在,并制定解决方案。

如何在体验设计中构建共情

1. 制定共情的范围

为了寻求更加有价值的目标用户进行共情研究,我们会对共情的目标进行范围筛选,可以是根据某些用户习惯、常使用的产品服务、某个场景、也可以是社会群体(例如学生、司机)、甚至可以是动植物(例如宠物类产品)。

所以第一步你要根据需求去制定共情目标的筛选条件,然后一点点缩小和锁定有效的目标群体,再开始招募、沟通或是进行其他下一步工作,我们没办法跟所有目标用户构建共情也没有必要这样做。

通常五个左右的用户就能够反映出大多数问题,并出现重叠的反馈。

2. 在不同研发阶段尝试与特殊的用户共情

伴随产品的发展过程用户也在时时发生微妙的变化,在跨度大的迭代中,尝试与产品潜在用户或极端用户进行共情研究也是很有价值的。

潜在用户的需求通常存在着更多的不确定,这也意味有发现新机会的可能;而极端用户通常会有一些更刻薄的需求,这些需求可能不是主流,但也有主流发展的潜力,不过至少这些改进会为极端用户带来惊喜。

这就像是在公交车站下安装一台自动售卖机,不是大多数人的需求,也不是当前的主流趋势,但却能够为部分乘客带来方便或惊喜,我们不能忽略这些少数。

如何在设计中构建共情?收下这份6000+的干货总结!

3. 带有目标的进行

在体验设计的过程中,我们需要与目标对象构建共情时,一定是有目的有意图的。

以使用性测试为例,往往我们都会设定一些产品测试任务和目标给用户,再进行观察和共情。这也将允许我们能够在同一个或相似的场景事件中发生共情,这样才能够获取到更真实有效的共情。

以一个吸尘器产品为例:如果对方是在地毯上测试的,而你是在木质地板的环境下去共情的,那么共情结果肯定是有所出入的,所以构建一个共情目的甚至是环境是有效共情的一个重点之一。

如何在设计中构建共情?收下这份6000+的干货总结!

4. 情绪降噪与倾听

构建共情会受情绪影响,在共情前有必要去除负面情绪影响,不要为共情构建带来更多的阻力,另外则是仔细的倾听和理解。

这就好比我们要专注学习,除了认知听讲,脑子里一旦充斥着其他负面情绪或思维影响,就很难完成专注学习的目的。

同理:在用户帮助我们测试产品或访谈时,我们也要首先做好彼此的心理建设,去除主要的负面情绪甚至去除不利的环境影响因素,例如缓解用户紧张不安的情绪,找一个素一点且安静的测试房间等。

如何在设计中构建共情?收下这份6000+的干货总结!

5. 合理的工具辅助

图表、笔记、录制设备是帮助我们共情的最好工具,在不同的场景下,这些工具能够帮助我们更好的收集信息,并且便于我们思考和共情。

我们在短时间能记住的信息是有限的,这也是为什么我们会用到7±2这种定律去控制信息量的原因。

以用户体验地图为例,在记载用户体验产品的过程中,便是一种很好的共情辅助工具,它能够按照使用步骤或阶段记载用户使用情况和情绪变化等反馈。

如何在设计中构建共情?收下这份6000+的干货总结!

6. 构建共情的要素

在我的理解中,共情由四个主要的因素影响来构成。

尊重

受到不同的环境跟经历影响,要去准确理解一个人是很困难的,哪怕是多年的夫妻也是如此。所有首先要做到尊重,消除任何偏见,不要带有批判或评价的心理。然而做到足够的尊重也并不容易。

观察

观察是获取客体传递信息的主要途径,不能掌握足够的信息是无法做到共情的,片面的或者假设的信息都将影响到正确的共情。

思考

对客体的信息与观念进行思考,尝试理解客体的各种行为根因以达成一致的认知。

融入

将自己感受到的情绪与认知代入到共情对象的行径中,去仔细揣摩,以洞察用户的行为、感受、需求、思维方式以及与产品之间的关联,就像灵魂附体一般,以达到更深入的共情来定义问题。

如何在设计中构建共情?收下这份6000+的干货总结!

7. 共情为设计赋能

最后便是共情结果如何应用到设计之中,将共情结果赋能到产品设计也是共情工作的价值所在。

通常这套流程是共情->定义->构思->原型->测试,在这个整个过程中随时是可以返回到前面其他阶段中反复打磨的,而共情作为一个起点也揭示了其重要性。

我们一切的共情工作皆为了能够优化和解决产品的问题,使得产品体验能够更好,这是我们在体验设计中不断去共情的初衷。

如何在设计中构建共情?收下这份6000+的干货总结!

好的共情设计欣赏

以移动端的产品来讲,现在好的共情设计真是百花齐放,这正是创新技术与共情设计发展的好趋势,也是敢于创新探索的好机遇。这里我们放三种典型的欣赏案例说一下:

1. 智能便捷型

给用户提供更加智能便捷的服务功能,使得用户能够获得更轻松流畅的服务体验。

如何在设计中构建共情?收下这份6000+的干货总结!

2. 高效人性化类型

通过大数据与技术手段,为用户提供更加高效人性化的服务方案,提升用户好感度、依赖性,加强产品口碑与体验。

如何在设计中构建共情?收下这份6000+的干货总结!

3. 情感关注型

有一些属于情感关注类型的共情设计,通过获取用户的场景信息或其他数据共情用户情绪,并给予用户合适的关爱、帮助、引导。为用户带来软件有情感,品牌有温度的体验。

如何在设计中构建共情?收下这份6000+的干货总结!

4. 小结

在体验设计中,情感化设计一定会是一个值得深入方向,我们应该关注到不同场景下用户会产生的情绪变化,为用户提供更加走心的服务体验,为产品收获更多口碑。

当然,在产品完善的这个漫长过程中,我们也要随时甄别我们所做的事情是否对用户和企业有更高的价值。在研发资源有限的情况下,划分这些设计点的权重,合理分配研发资源。

共情构建中的认知偏差

能够对共情构建产生影响的认知偏差挺多的,这些认知上的偏差会影响到共情的正确性,不仅是构建共情的主体还是客体都会有影响。

这里围绕构建共情补充了一些相关认知偏差,希望能够在构建共情的工作中再少一些坑:

1. Empathy gap(共情偏差)

共情偏差是指由于经验、预期和态度存在差异,我们很难准确地去体会他人的感受。这一点就是前文提到的我们无法做到完全共情,我们对共情的概念要有一定认知。

建议:通过技巧去弥补,减少认知偏差。多一些耐心的聆听,减少偏见和执念,尝试思考如果是TA该怎么办?

2. Negativity bias(负面情绪偏差)

情绪会对我们的认识和行为产生影响,而负面情绪产生的影响则是最大的,这会对我们的共情判断产生偏差,所以前文我们会提到消除情绪噪点的概念。

建议:尽可能的维持中立或积极的情绪状态会更有助于共情工作,但至少是消除负面的情绪影响。

3. Observer-expectancy effect(观察者预期效应)

观察者常常会不自觉地扭曲影响因素或数据,以得到预期结果。

这就好比在用户进行产品测试的期间,向你咨询了意见,而你很有可能不自觉的给出你的期望或者一些暗示,这会对目标产生可暗示性偏差(Suggestibility),使得目标想到的内容往往会被扭曲。

建议:

  • 对面向用户的测试材料进行自查纠正,尽可能处于中间立场,不要干扰测试结果;
  • 在主持访谈或用户测试现场时,对于用户的主动咨询或交谈中不要解释过多,让用户理解其定义跟概念即可,说的越多越是容易出现观察者预期效应。

4. Automation bias(直觉偏误)

基于自身的认知或经历,有时做出判断会过度依赖个人直觉,而不去收集更多有益于做出准确判断的证据。

这一现象常常表现为产品或项目经理的一拍脑袋的决定,但是往往因为过度依赖直觉而忽略了实际的场景差异等。

建议:对于不能直接给出有效证据的决策,要敢于质疑而去追究其正确性,当使用参考信息时要思考两者之间的差异性。总之不要凭借事件的相识性而忽略差异性,最终凭直觉决策。

5. Authority bias(权威偏见)

人们会过度倚重某些权威的意见,而忽视事情发生的实际背景。以品牌的影响力为例,两种不同的任务实施程序,通常人们会认为大品牌的方案更好更值得信赖,而忽略了一些体验细节。

建议:对于相比较的软件测试任务,我们有时会弱化甚至隐匿品牌信息。其目的便是在比较时减少这些权威偏见,不论是正面的还是负面的,这些都会影响用户判断,所以在特殊的场景研究下,请注意这一影响是否干扰结果。

6. Normalcy bias(正常化偏误)

人们会过度依赖先前的经验,把一些极端事件看作正常的,认为事情很快会过去。

以用户测试为例,当6个人都正常完成了测试任务,仅有一人出现出现问题时,这是一个概念问题,我们不能忽视这仅有的一个用户,更不能安慰自己这只是一个特例。

建议:上文有提到尝试与极端用户进行交流,其实道理类似,问题存在即合理,我们有必要注重和研究这些极少数,它们极有可能带来新的机会点。

7. Illusion of transparency(透明度错觉)

人们高估自己的个人心理状态被他人知晓的程度的一种倾向,时常表现为你以为别人都明白了你的意思,实际上别人明白的还远远不够。

与“知识的诅咒”这一偏差的差别在于,前者是我以为对方明白了实际对方还有诸多不解,而知识的诅咒是你无法给对方进行可理解的解释,有着文化背景或认知的障碍,实际上这两者偏差概念都会影响到共情工作。

实际办公中透明度错觉时常体现在需求表达、文档解释、跨部门沟通中,往往你以为你说的已经很清楚了,但在实际研发中却会体现出诸多差异。

建议:适当的了解其他部门的专业文化,便于更好的解释给对方。

组织好信息框架,简单易懂的信息框架易于对方理解,例如书本的目录大纲、信息的分类等。跨团队或部门的PRD(产品需求文档)尽可能的减少专业术语的应用或者进行注释,文档的目的不在于体现多专业而是更加高效易懂的传达信息。

趣味思考

研究用户从观察自己开始。每个时代的人都会有不一样的特质或者某些现状,在这个大环境下,你会发现与同龄人之间有很多相似点,那么加强对自己的行为理解,是不是就等同研究了这些同龄用户的共有特征?

文章来源:优设  作者:泡泡

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务



SSM框架实战-搭建自己的个人博客1-基础架构搭建

前端达人

前言

本系列文章主要通过从零开始搭建自己的个人博客,来加深对SSM框架的学习与使用,了解一个系统从提出到设计-到开发-到测试-部署运行的过程,并记录在搭建过程中的学习心得、遇见的错误及解决方式。

个人博客的主要功能有:

  1. 博客列表展示:文章按照时间顺序(时间倒序:最新最先展示)列表展示
  2. 博客文章详情展示:展示文章全部内容,包含:作者、创建时间、所属目录、标签、文章标题、内容
  3. 用户权限管理:游客只能浏览文章、管理员可以发布文章、文章下线处理
  4. 添加文章功能:支持富文本编辑。可以调整字体大小、样式、键入代码等功能

界面展示:

前台博客列表界面

前台博客列表页面.png

博客详情页面

博客详情页面.png

后台管理页面 

 

登录页面

 

后台管理页面.png

项目技术简介

系统实现的功能点

  1. 用户权限管理:普通的用户(游客)只能浏览文章、管理员用户可以发布文章、文章管理
  2. 博客列表展示:文章按照发布时间顺序(按照时间倒叙)展示 :博客类别、标签、博客名称、作者名、发布时间、阅读数量、博客的内容概括
  3. 博客详情页面:博客名称、作者、时间、博客内容、标签
  4. 博客后台列表:博客检索(类别、标签、博客名称)、博客列表(博客id、博客类别、标签、时间)、博客操作
  5. 新增博客功能:支持富文本编辑:可以调整大小、样式等

服务端技术

核心框架:Spring:5.2.8.RELEASE

web框架:SpringMVC:5.2.8.RELEASE

持久层框架:Mybatis 3.2.4

数据库连接池:阿里druid:0.2.6

数据库:MySQL5.XX

JSON数据处理:谷歌gson 2.3

前端技术

jsp

Ajax

前端框架:bootstrap

富文本编辑器:百度UEditor

数据库的设计

  • 用户表:账号id、账号名称、账号密码
  • 博客表:博客id、博客名称、博客内容、发布时间、阅读量、类别id、状态
  • 博客/标签对应表:博客id、标签的id
  • 标签表:标签id、标签名称(博客和标签:一对多:一个博客可以对应多个标签)
  • 类别表:类别ID、类别名称(博客和类别:一对一:一个博客对应一个类别)

创建SQL语句:

 
  1. DROP TABLE IF EXISTS `t_article`;
  2. CREATE TABLE `t_article` (
  3. `id` int(11) NOT NULL AUTO_INCREMENT,
  4. `categoryId` int(11) NOT NULL COMMENT '分类Id',
  5. `title` varchar(40) NOT NULL COMMENT '标题',
  6. `content` blob NOT NULL COMMENT '内容',
  7. `description` varchar(500) NOT NULL COMMENT '文章简介 用于列表显示',
  8. `statue` int(11) NOT NULL DEFAULT '0' COMMENT '状态 0:正常 1:不可用',
  9. `author` varchar(15) DEFAULT 'tulun' COMMENT '作者',
  10. `createTime` datetime NOT NULL COMMENT '发表时间',
  11. `showCount` int(11) NOT NULL DEFAULT '0' COMMENT '浏览量',
  12. PRIMARY KEY (`id`)
  13. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='文章表';
  14. -- ----------------------------
  15. -- Table structure for t_article_image
  16. -- ----------------------------
  17. DROP TABLE IF EXISTS `t_article_image`;
  18. CREATE TABLE `t_article_image` (
  19. `id` int(11) NOT NULL AUTO_INCREMENT,
  20. `imageUrl` varchar(100) NOT NULL COMMENT '图片地址',
  21. `articleId` int(11) NOT NULL COMMENT '文章Id',
  22. PRIMARY KEY (`id`,`articleId`)
  23. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='文章图 主要用于列表浏览';
  24. -- ----------------------------
  25. -- Table structure for t_tag
  26. -- ----------------------------
  27. DROP TABLE IF EXISTS `t_tag`;
  28. CREATE TABLE `t_tag` (
  29. `id` int(11) NOT NULL AUTO_INCREMENT,
  30. `tagName` varchar(25) NOT NULL COMMENT '标签名称 唯一',
  31. PRIMARY KEY (`id`),
  32. UNIQUE KEY `tagName_UNIQUE` (`tagName`)
  33. ) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8 COMMENT='标签表';
  34. -- ----------------------------
  35. -- Table structure for t_article_tag
  36. -- ----------------------------
  37. DROP TABLE IF EXISTS `t_article_tag`;
  38. CREATE TABLE `t_article_tag` (
  39. `articleId` int(11) NOT NULL COMMENT '文章Id',
  40. `tagId` int(11) NOT NULL COMMENT '标签Id',
  41. PRIMARY KEY (`articleId`,`tagId`)
  42. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='文章标签中间表';
  43. -- ----------------------------
  44. -- Table structure for t_category
  45. -- ----------------------------
  46. DROP TABLE IF EXISTS `t_category`;
  47. CREATE TABLE `t_category` (
  48. `id` int(11) NOT NULL AUTO_INCREMENT,
  49. `categoryName` varchar(20) NOT NULL COMMENT '分类名称 唯一',
  50. `iconClass` varchar(45) NOT NULL COMMENT '图标样式',
  51. `aliasName` varchar(20) NOT NULL COMMENT '别名 唯一 比如新闻 就用News 代替 栏目Id不显示在url中',
  52. `sort` int(11) NOT NULL DEFAULT '0' COMMENT '排序 (0-10)',
  53. PRIMARY KEY (`id`),
  54. UNIQUE KEY `aliasName_UNIQUE` (`aliasName`),
  55. UNIQUE KEY `categoryName_UNIQUE` (`categoryName`)
  56. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='分类表 只支持一级分类 如果需要分多个层次 用标签来协助实现';
  57. -- ----------------------------
  58. -- Table structure for t_manager
  59. -- ----------------------------
  60. DROP TABLE IF EXISTS `t_manager`;
  61. CREATE TABLE `t_manager` (
  62. `id` int(11) NOT NULL AUTO_INCREMENT,
  63. `userName` varchar(25) NOT NULL COMMENT '用户名',
  64. `password` varchar(45) NOT NULL,
  65. PRIMARY KEY (`id`)
  66. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

image.png

框架结构搭建

SSM项目脚手架搭建

搭建如下框架结构:

目录说明:

 
  1. 目录说明:
  2. |-src
  3. |--mian
  4. |---java JAVA源代码根目录
  5. |----com
  6. |-----tulun
  7. |------model 存放pogo类:基本基本的getter和setter方法
  8. |------controller 展示层类包路径:前端用户请求映射到该包路径下类的实现
  9. |------service 业务逻辑层包路径:业务逻辑实现,调用dao层服务
  10. |------dao 数据库操作层包路径:提供对数据库的操作类与方法
  11. |------util 工具类包路径
  12. |---resource 配置文件根目录
  13. |----myatis mybatis接口对应配置文件目录
  14. |----spring-XXX.xml SSM中mybatis、spring核心、springMVC的全局配置文件
  15. |--webapp 前端页面内容根目录
  16. |---WEB-INF
  17. |----web.xml 前端页面必要配置文件
  18. |-pom.xml maven的配置文件

测试Demo

主要完成各个层之间的连接映射,完成从t_manager表中读取数据并进行回显

 

POJO类

根据数据库表t_manager,创建User类

 
  1. package com.tulun.model;
  2. /**
  3. * Description :
  4. * Created by Resumebb
  5. * Date :2021/4/17
  6. */
  7. public class User {
  8. private Integer id;
  9. private String name;
  10. private String passwd;
  11. public Integer getId() {
  12. return id;
  13. }
  14. public void setId(Integer id) {
  15. this.id = id;
  16. }
  17. public String getName() {
  18. return name;
  19. }
  20. public void setName(String name) {
  21. this.name = name;
  22. }
  23. public String getPasswd() {
  24. return passwd;
  25. }
  26. public void setPasswd(String passwd) {
  27. this.passwd = passwd;
  28. }
  29. }

Spring核心配置文件

这里用到了阿里巴巴的druid连接池

 
  1. <beans xmlns="http://www.springframework.org/schema/beans"
  2. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3. xmlns:context="http://www.springframework.org/schema/context"
  4. xsi:schemaLocation="http://www.springframework.org/schema/beans
  5. http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
  6. http://www.springframework.org/schema/context
  7. http://www.springframework.org/schema/context/spring-context-3.0.xsd">
  8. <!--开启注解-->
  9. <context:component-scan base-package="com.tulun"/>
  10. <!--配置数据源:借助连接池druid-->
  11. <bean id ="dataSource" class="com.alibaba.druid.pool.DruidDataSource">
  12. <!--注入属性-->
  13. <property name="url" value="jdbc:mysql://localhost:3306/test"/>
  14. <property name="username" value="root"/>
  15. <property name="password" value="123456"/>
  16. </bean>
  17. <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
  18. <property name="dataSource" ref="dataSource"/>
  19. <!--注入mapper映射文件-->
  20. <property name="configLocation" value="classpath:spring-mybatis.xml"></property>
  21. <property name="mapperLocations" value="classpath:mapper/*.xml"/>
  22. </bean>
  23. <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
  24. <property name="basePackage" value="com.tulun.dao"/>
  25. <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/>
  26. </bean>
  27. </beans>

Spring-Mybatis配置文件

 
  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <!DOCTYPE configuration
  3. PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
  4. "http://mybatis.org/dtd/mybatis-3-config.dtd">
  5. <!--根标签-->
  6. <configuration>
  7. </configuration>

SpringMVC配置文件

 
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <beans xmlns="http://www.springframework.org/schema/beans"
  3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4. xmlns:context="http://www.springframework.org/schema/context"
  5. xmlns:mvc="http://www.springframework.org/schema/mvc"
  6. xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
  7. http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.1.xsd
  8. http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-4.1.xsd">
  9. <!--扫描controller写注解-->
  10. <context:component-scan base-package="com.tulun.controller"/>
  11. <!--配置映射器-->
  12. <mvc:annotation-driven/>
  13. <!--配置视图解析器-->
  14. <!--视图解析器-->
  15. <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
  16. <!--jsp页面前缀-->
  17. <property name="prefix" value="/WEB-INF/jsp/"/>
  18. <!--jsp后缀-->
  19. <property name="suffix" value=".jsp"/>
  20. <property name="viewClass" value="org.springframework.web.servlet.view.freemarker.FreeMarkerView"/>
  21. </bean>
  22. </beans>

web配置文件

 
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
  3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4. xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
  5. http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
  6. <context-param>
  7. <param-name>contextConfigLocation</param-name>
  8. <param-value>classpath:spring-core.xml</param-value>
  9. </context-param>
  10. <listener>
  11. <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  12. </listener>
  13. <!--前端控制器-->
  14. <servlet>
  15. <servlet-name>myBolg</servlet-name>
  16. <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  17. <!--将springMVC的配置文件进行配置-->
  18. <init-param>
  19. <param-name>contextConfigLocation</param-name>
  20. <param-value>classpath:spring-mvc.xml</param-value>
  21. </init-param>
  22. </servlet>
  23. <servlet-mapping>
  24. <servlet-name>myBolg</servlet-name>
  25. <url-pattern>/</url-pattern>
  26. </servlet-mapping>
  27. </web-app>

pom依赖

 
  1. <dependencies>
  2. <dependency>
  3. <groupId>junit</groupId>
  4. <artifactId>junit</artifactId>
  5. <version>4.11</version>
  6. <scope>test</scope>
  7. </dependency>
  8. <!-- spring依赖-->
  9. <dependency>
  10. <groupId>org.springframework</groupId>
  11. <artifactId>spring-core</artifactId>
  12. <version>5.2.8.RELEASE</version>
  13. </dependency>
  14. <dependency>
  15. <groupId>org.springframework</groupId>
  16. <artifactId>spring-context</artifactId>
  17. <version>5.2.8.RELEASE</version>
  18. </dependency>
  19. <dependency>
  20. <groupId>org.springframework</groupId>
  21. <artifactId>spring-beans</artifactId>
  22. <version>5.2.8.RELEASE</version>
  23. </dependency>
  24. <dependency>
  25. <groupId>org.springframework</groupId>
  26. <artifactId>spring-expression</artifactId>
  27. <version>5.2.8.RELEASE</version>
  28. </dependency>
  29. <!--web依赖/spring mvc依赖-->
  30. <dependency>
  31. <groupId>org.springframework</groupId>
  32. <artifactId>spring-webmvc</artifactId>
  33. <version>5.2.8.RELEASE</version>
  34. </dependency>
  35. <dependency>
  36. <groupId>org.springframework</groupId>
  37. <artifactId>spring-web</artifactId>
  38. <version>5.2.8.RELEASE</version>
  39. </dependency>
  40. <dependency>
  41. <groupId>javax.servlet</groupId>
  42. <artifactId>javax.servlet-api</artifactId>
  43. <version>3.1.0</version>
  44. </dependency>
  45. <!--tomcat servlet api -->
  46. <dependency>
  47. <groupId>jstl</groupId>
  48. <artifactId>jstl</artifactId>
  49. <version>1.2</version>
  50. </dependency>
  51. <dependency>
  52. <groupId>taglibs</groupId>
  53. <artifactId>standard</artifactId>
  54. <version>1.1.2</version>
  55. </dependency>
  56. <!--mybatis依赖-->
  57. <dependency>
  58. <groupId>org.mybatis</groupId>
  59. <artifactId>mybatis</artifactId>
  60. <version>3.4.1</version>
  61. </dependency>
  62. <dependency>
  63. <groupId>mysql</groupId>
  64. <artifactId>mysql-connector-java</artifactId>
  65. <version>5.1.39</version>
  66. </dependency>
  67. <!-- 整合-->
  68. <dependency>
  69. <groupId>org.mybatis</groupId>
  70. <artifactId>mybatis-spring</artifactId>
  71. <version>1.3.0</version>
  72. </dependency>
  73. <!-- 连接池-->
  74. <dependency>
  75. <groupId>com.mchange</groupId>
  76. <artifactId>c3p0</artifactId>
  77. <version>0.9.5.2</version>
  78. </dependency>
  79. <dependency>
  80. <groupId>org.springframework</groupId>
  81. <artifactId>spring-tx</artifactId>
  82. <version>5.2.8.RELEASE</version>
  83. </dependency>
  84. <dependency>
  85. <groupId>org.springframework</groupId>
  86. <artifactId>spring-jdbc</artifactId>
  87. <version>5.2.8.RELEASE</version>
  88. </dependency>
  89. <dependency>
  90. <groupId>javax.servlet.jsp.jstl</groupId>
  91. <artifactId>jstl</artifactId>
  92. <version>1.2</version>
  93. </dependency>
  94. <dependency>
  95. <groupId>javax.servlet</groupId>
  96. <artifactId>servlet-api</artifactId>
  97. <version>2.5</version>
  98. </dependency>
  99. <dependency>
  100. <groupId>com.google.code.gson</groupId>
  101. <artifactId>gson</artifactId>
  102. <version>2.3</version>
  103. </dependency>
  104. <dependency>
  105. <groupId>com.alibaba</groupId>
  106. <artifactId>druid</artifactId>
  107. <version>0.2.6</version>
  108. </dependency>
  109. <dependency>
  110. <groupId>commons-logging</groupId>
  111. <artifactId>commons-logging</artifactId>
  112. <version>1.1.1</version>
  113. </dependency>
  114. <dependency>
  115. <groupId>commons-configuration</groupId>
  116. <artifactId>commons-configuration</artifactId>
  117. <version>1.9</version>
  118. </dependency>
  119. </dependencies>

UserMapper

 
  1. import com.tulun.model.User;
  2. /**
  3. * Description :
  4. * Created by Resumebb
  5. * Date :2021/4/22
  6. */
  7. public interface UserMapper {
  8. public User getUserById(Integer id);
  9. }

UserService

 
  1. package com.tulun.service;
  2. import com.tulun.model.User;
  3. import com.tulun.dao.UserMapper;
  4. import org.springframework.beans.factory.annotation.Autowired;
  5. import org.springframework.stereotype.Service;
  6. /**
  7. * Description :
  8. * Created by Resumebb
  9. * Date :2021/4/19
  10. */
  11. @Service
  12. public class UserService {
  13. @Autowired
  14. private UserMapper userMapper;
  15. public User getUserById(Integer id){
  16. if(id < 0)
  17. return new User();
  18. return userMapper.getUserById(id);
  19. }
  20. }

UserController

查询t_manager中的id为1的数据进行显示

 
  1. package com.tulun.controller;
  2. import com.tulun.model.User;
  3. import com.tulun.service.UserService;
  4. import org.springframework.beans.factory.annotation.Autowired;
  5. import org.springframework.stereotype.Controller;
  6. import org.springframework.web.bind.annotation.RequestMapping;
  7. import org.springframework.web.bind.annotation.ResponseBody;
  8. /**
  9. * Description :
  10. * Created by Resumebb
  11. * Date :2021/4/22
  12. */
  13. @Controller
  14. public class UserController {
  15. @Autowired
  16. private UserService userService;
  17. @RequestMapping("/testUser")
  18. @ResponseBody
  19. public User testUser(){
  20. User user = userService.getUserById(1);
  21. return user;
  22. }
  23. }

UserMapper.xml

 
  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <!DOCTYPE mapper
  3. PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
  4. "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
  5. <mapper namespace="com.tulun.dao.UserMapper">
  6. <resultMap id="UserMap" type="com.tulun.model.User">
  7. <result property="id" column="id"></result>
  8. <result property="name" column="userName"></result>
  9. <result property="passwd" column="password"></result>
  10. </resultMap>
  11. <select id="getUserById" parameterType="int" resultMap="UserMap">
  12. select * from t_manager where id=#{id}
  13. </select>
  14. </mapper>

运行结果

 

错误记录

运行的界面显示unkown the request

 原因是因为端口被占用了,更改服务器的端口号就可以了。

出现这个错误就要检查SQL查询语句,数据源的配置是否正确,经检查我报这个错是因为SQL查询语句manager写成了manger,用户名密码不对也会报这个错。

类似这种错,一是检查@Service有没有加上,二是检查映射文件有没有顶行写,第一行不能有空行。

转自:csdn。作者:resumebb

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

centOS7杀死进程命令

前端达人

查看当前所有正在运行的进程,可以看到80端口被httpd占用了(80端口希望分配给nginx使用,而不是httpd)

netstat -tpnul

 

这里以杀死httpd进程为例:

先查看 httpd 进程 

flaskApi) [root@67 flaskDemo]# ps aux |grep httpd  root      6732  0.0  0.0 230488  5252 ?        Ss   8月06   2:27 /usr/sbin/httpd -DFOREGROUND
apache 22570  0.0  0.0 232572  3888 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
apache 22571  0.0  0.0 232572  3888 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
apache 22572  0.0  0.0 232572  3904 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
apache 22573  0.0  0.0 232572  3904 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
apache 22574  0.0  0.0 232572  3900 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
apache 27544  0.0  0.0 232572  3896 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
apache 27546  0.0  0.0 232572  3900 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
apache 27548  0.0  0.0 232572  3172 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
apache 27550  0.0  0.0 232572  3172 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
apache 27552  0.0  0.0 232572  3172 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
root 27665  0.0  0.0 112728   988 pts/0    S+   15:43   0:00 grep --color=auto httpd

这个就是 apache 的所有进程 

我们可以用  kill -9 加进程ID   如下

kill -9 6732 kill -9 22570 kill -9 22571 kill -9 22572 kill -9 22573 kill -9 22574 kill -9 27544 kill -9 27546 kill -9 27548 kill -9 27550 kill -9 27552 kill -9 27665

再次查看一下httpd正在运行的进程:

(flaskApi) [root@67 flaskDemo]# ps aux |grep httpd root     27835  0.0  0.0 112724   988 pts/0    S+   15:46   0:00 grep --color=auto httpd

全部杀完了... 杀死进程方法有很多种...我这个 只是其中的一种

 

通过netstat确认一下,httpd已经不再占用80端口了

(flaskApi) [root@67 flaskDemo]# netstat -tpnul

 

另如果不想杀死进程,而想修改端口号,

操作方法参照:centos7 ngxin启动失败:Job for nginx.service failed(80端口被占用的解决办法)

 

 

参照文档:

centos杀死进程命令

 

转载于:https://www.cnblogs.com/kaerxifa/p/11534539.html


蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

MVP:七种深度洞察用户需求的方法

涛涛

不论是什么产品都需要考虑到用户的需求,对于用户需求进行分析,确定可行性,最后进行实现;重点要关注在产品中用户需要的是什么,对用户的想法进行探索;本文作者分享了关于七种深度洞察用户需求的方法,我们一起来了解一下。


需求分析是市场研究阶段的重要活动,也是新产品开发流程中的一个重要环节,是产品经理经过深入细致的调研和分析,准确理解用户对产品的功能、性能、可靠性等具体要求,将用户非形式的需求表述转化为完整的需求定义,从而确定产品必须做什么的过程;该阶段是分析产品在功能上需要“实现什么”,而不是考虑如何去“实现”。

需求分析的目标是把用户对待开发产品提出的“要求”或“需要”进行分析与整理,确认后形成描述完整、清晰与规范的文档,确定产品需要实现哪些功能,完成哪些工作;此外,产品的一些非功能性需求(如产品质量、款式、特色、包装、安装、售后等)及约束条件也是需求分析的目标。

  • “消费者不知道他们想要什么。”
  • “消费者无法很好地表达他们的需求或喜好。”
  • “消费者对自己的具体需求很迷茫。”

这些都是从客户(产品开发或者市场部的同事)或者身边一些人(需要更多反馈的感官专家或设计者)在一整天的访谈(包括焦点小组、一对一访谈)、开放式问卷或者与消费者接触的过程中发现的问题;这就需要我们根据调研的初步结果进行深入的“需求分析”才能得到想要的结论和应用价值。

一、马斯洛需求层次理论

在组织行为学中,马斯洛曾经在1943年发表的论文中对人类需求做出了定义,在人类动机理论中,马斯洛提出了需求层次理论模型;这一理论可以有效地观察人类最根本、最基础的需求水平。

马斯洛认为,人类具有一些先天需求,人的需求越是低级的需求就越基本,越与动物相似;越是高级的需求就越为人类所特有。同时这些需求都是按照先后顺序出现的,当一个人满足了较低的需求之后,才能出现较高级的需求,即需求层次。

马斯洛理论把需要分成生理需要、安全需要、社交需要、尊重和自我实现五类,依次由较低层次到较高层次排列,如图所示。在自我需要实现之后,还有自我超越需要,但通常不作为马斯洛需要层次理论中必要的层次,大多数会将自我超越合并至自我实现需求当中。

图马斯洛需求层次理论图谱

1. 第一层次:生理上的需要

如果这些需要(除性以外)任何一项得不到满足,人类个人的生理机能就无法正常运转。

换而言之,人类的生命就会因此受到威胁。从这个意义上说,生理需要是推动人们行动最首要的动力。

马斯洛认为,只有这些最基本的需要满足到维持生存所必需的程度后,其他的需要才能成为新的激励因素,而到了此时,这些已相对满足的需要也就不再成为激励因素了。

2. 第二层次:安全上的需要

马斯洛认为,整个有机体是一个追求安全的机制,人的感受器官、效应器官、智能和其他能量主要是寻求安全的工具,甚至可以把科学和人生观都看成是满足安全需要的一部分;当这种需要一旦相对满足后,也就不再成为激励因素了。

3. 第三层次:情感和归属的需要

人人都希望得到相互的关心和照顾,感情上的需要比生理上的需要来的细致,它和一个人的生理特性、经历、教育、宗教信仰都有关系。

4. 第四层次:尊重的需要

人人都希望自己有稳定的社会地位,要求个人的能力和成就得到社会的承认。尊重的需要又可分为内部尊重和外部尊重。内部尊重是指一个人希望在各种不同情境中有实力、能胜任、充满信心、能独立自主。

总之,内部尊重就是人的自尊。

外部尊重是指一个人希望有地位、有威信,受到别人的尊重、信赖和高度评价;马斯洛认为,尊重需要得到满足,能使人对自己充满信心,对社会满腔热情,体验到自己活着的用处价值。

5. 第五层次:自我实现的需要

这是最高层次的需要,它是指实现个人理想、抱负,发挥个人的能力到最大程度,达到自我实现境界的人,接受自己也接受他人,解决问题能力增强,自觉性提高,善于独立处事,要求不受打扰地独处,完成与自己的能力相称的一切事情的需要;也就是说,人必须干称职的工作,这样才会使他们感到最大的快乐。

马斯洛提出,为满足自我实现需要所采取的途径是因人而异的。自我实现的需要是在努力实现自己的潜力,使自己越来越成为自己所期望的人物。

马斯洛理论把需要分成生理需要、安全需要、社交需要、尊重需要和自我实现需要五类,依次由较低层次到较高层次,从企业经营消费者满意(CS)战略的角度来看,每一个需求层次上的消费者对产品的要求都不一样,即不同的产品满足不同的需求层次。

根据五个需要层次,可以划分出五个消费者市场

  • 生理需求:满足最低需求层次的市场,消费者只要求产品具有一般功能即可。
  • 安全需求:满足对“安全”有要求的市场,消费者关注产品对身体的影响。
  • 社交需求:满足对“交际”有要求的市场,消费者关注产品是否有助提高自己的交际形象。
  • 尊重需求:满足对产品有与众不同要求的市场,消费者关注产品的象征意义。
  • 自我实现:满足对产品有自己判断标准的市场,消费者拥有自己固定的品牌需求层次越高,消费者就越不容易被满足。

经济学上,“消费者愿意支付的价格≌消费者获得的满意度”,也就是说,同样的洗衣粉,满足消费者需求层次越高,消费者能接受的产品定价也越高。

市场的竞争,总是越低端越激烈,价格竞争显然是将“需求层次”降到最低,消费者感觉不到其他层次的“满意”,愿意支付的价格当然也低。

二、KANO 模型

KANO模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品性能和用户满意之间的非线性关系,如图所示。

根据不同类型的质量特性与顾客满意度之间的关系,狩野教授将产品服务的质量特性分为5类。

KANO 模型(产品性能和用户满意之间的非线性关系)

1. 基本型需求

也称为必备型需求、理所当然需求,是顾客对企业提供的产品或服务因素的基本要求;是顾客认为产品“必须有”的属性或功能。当其特性不充足(不满足顾客需求)时,顾客很不满意;当其特性充足(满足顾客需求)时,顾客也可能不会因而表现出满意。

对于基本型需求,即使超过了顾客的期望,但顾客充其量达到满意,不会对此表现出更多的好感;不过只要稍有一些疏忽,未达到顾客的期望,则顾客满意将一落千丈。

对于顾客而言,这些需求是必须满足的,理所当然的;对于这类需求,企业的做法应该是注重不要在这方面失分,需要企业不断地调查和了解顾客需求,并通过合适的方法在产品中体现这些要求。

例如,夏天家庭使用空调,如果空调正常运行,顾客不会为此而对空调质量感到满意;反之,一旦空调出现问题,无法制冷,那么顾客对该品牌空调的满意水平则会明显下降,投诉、抱怨随之而来。

再例如,智能手机的基本型需求有语音通话质量、信号覆盖、操作系统兼容、安全性、日常使用和性能:待机时间、速度等;试想一下,一个智能手机没有信号,通话质量差,操作系统不兼容,被感染病毒,待机时间10分钟就没电,如果手机运行速度慢到接近崩溃,这些都会使用户的不满情绪增加;但是上述这些需求都满足后,并不能带来用户满意度的增加,因为用户认为这些是必须要有的。

2. 期望型需求

也称为意愿型需求,是指顾客的满意状况与需求的满足程度成比例关系的需求,此类需求得到满足或表现良好的话,客户满意度会显著增加,企业提供的产品和服务水平超出顾客期望越多,顾客的满意状况越好;当此类需求得不到满足或表现不好的话,客户的不满也会显著增加。

期望型需求没有基本型需求那样苛刻,要求提供的产品或服务比较优秀,但并不是“必须”的产品属性或服务行为有些期望型需求连顾客都不太清楚,但是是他们希望得到的,也叫用户需求的痒处;这是处于成长期的需求,客户、竞争对手和企业自身都关注的需求,也是体现竞争能力的需求。对于这类需求,企业的做法应该是注重提高这方面的质量,要力争超过竞争对手。

在市场调查中,顾客谈论的通常是期望型需求;质量投诉处理在我国的现状始终不令人满意,该服务也可以被视为期望型需求;如果企业对质量投诉处理得越圆满,那么顾客就越满意。

3. 魅力型需求

又称兴奋型需求。指不会被顾客过分期望的需求。

对于魅力型需求,随着满足顾客期望程度的增加,顾客满意度也会急剧上升,但一旦得到满足,即使表现并不完善,顾客表现出的满意状况则也是非常高的;反之,即使在期望不满足时,顾客也不会因而表现出明显的不满意。

当顾客对一些产品或服务没有表达出明确的需求时,求企业提供给顾客一些完全出乎意料的产品属性或服务行为,使顾客产生惊喜,顾客就会表现出非常满意,从而提高顾客的忠诚度;这类需求往往是代表顾客的潜在需求,企业的做法就是去寻找发掘这样的需求,领先对手。

例如,一些著名品牌的企业能够定时进行产品的质量跟踪和回访,发布最新的产品信息和促销内容,并为顾客提供最便捷的购物方式。对此,即使另一些企业未提供这些服务,顾客也不会由此表现出不满意。

4. 无差异型需求

不论提供与否,对用户体验无影响;是质量中既不好也不坏的方面,它们不会导致顾客满意或不满意。例如:航空公司为乘客提供的没有实用价值的赠品。

5. 反向型需求

又称逆向型需求,指引起强烈不满的质量特性和导致低水平满意的质量特性,因为并非所有的消费者都有相似的喜好。

许多用户根本都没有此需求,提供后用户满意度反而会下降,而且提供的程度与用户满意程度成反比;例如:一些顾客喜欢高科技产品而另一些人更喜欢普通产品,过多的额外功能会引起顾客不满。

前三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。在实际操作中,企业首先要全力以赴地满足顾客的基本型需求,保证顾客提出的问题得到认真的解决,重视顾客认为企业有义务做到的事情,尽量为顾客提供方便,以实现顾客最基本的需求满足。

然后,企业应尽力去满足顾客的期望型需求,这是质量的竞争性因素;提供顾客喜爱的额外服务或产品功能,使其产品和服务优于竞争对手并有所不同,引导顾客加强对本企业的良好印象,使顾客达到满意。

最后争取实现顾客的兴奋型需求,为企业建立最忠实的客户群。

三、因子分析

因子分析是指研究从变量群中提取共性因子的统计技术。

最早由英国心理学家C.E.斯皮尔曼提出。他发现学生的各科成绩之间存在着一定的相关性,一科成绩好的学生,往往其他各科成绩也比较好,从而推想是否存在某些潜在的共性因子(某些一般智力条件)[张乐飞1] 影响着学生的学习成绩。

因子分析可在许多变量中找出隐藏的具有代表性的因子,将相同本质的变量归入一个因子,可减少变量的数目,还可检验变量间关系的假设。

因子分析是社会研究的一种有力工具,但不能肯定地说一项研究中含有几个因子,当研究中选择的变量变化时,因子的数量也要变化;此外对每个因子实际含意的解释也不是绝对的。在市场调研中,研究人员关心的是一些研究指标的集成或者组合,这些概念通常是通过等级评分问题来测量的,如利用李克特量表取得的变量。

每一个指标的集合(或一组相关联的指标)就是一个因子,指标概念等级得分就是因子得分。

因子分析方法的主要应用有两种:其一,减少变量的数量;其二,找出变量之间的结构关系。

在产品开发中,因子分析能够用于关键变量的优先级排序和分组,比如:产品属性之间的关系和产品属性对产品偏好的影响。在实际应用中,通过因子得分可以得出不同因子的重要性指标,而管理者则可根据这些指标的重要性来决定首先要解决的市场问题或产品问题。

四、聚类分析

聚类分析是一种探索性的分析,在分类的过程中,人们不必事先给出一个分类的标准,聚类分析能够从样本数据出发,自动进行分类。

聚类分析所使用方法的不同,常常会得到不同的结论。不同研究者对于同一组数据进行聚类分析,所得到的聚类数未必一致。

从实际应用的角度看,聚类分析是数据挖掘的主要任务之一;而且聚类能够作为一个独立的工具获得数据的分布状况,观察每一簇数据的特征,集中对特定的聚簇集合作进一步地分析。聚类分析还可以作为其他算法(如分类和定性归纳算法)的预处理步骤。

聚类分析的一个重要用途就是针对目标群体进行多指标的群体划分,类似这种目标群体的分类就是精细化经营,个性化运营的基础和核心,只有进行了正确的分类,才可以有效进行个性化和精细化的运营,服务及产品支持等。

常见业务应用场景如下:

1. 目标用户的群体分类

通过对特定运营目的和商业目的所挑选出的指标变量进行聚类分析,把目标群体划分成几个具有明显特征区别的细分群体,从而可以在运营活动中为这些细分群体采取精细化,个性化的运营和服务,最终提升运营的效率和商业效果(如把付费用户按照几个特定维度,如利润贡献,用户年龄,续费次数等聚类分析后得到不同特征的群体)。

2. 不同产品的价值组合

企业可以按照不同的商业目的,并依照特定的指标标量来为众多的产品种类进行聚类分析,把企业的产品体系进一步细分成具有不同价值,不同目的的多维度的产品组合,并且在此基础分别制定和相应的开发计划,运营计划和服务规划(如哪些产品是明星类产品,那些产品是瘦狗类产品)。

3. 数据挖掘、分析、应用

聚类分析是挖掘电子商务网站数据价值的重要方法之一,通过分组聚类出具有相似浏览行为的客户,并分析客户的共同特征,可以更好的帮助电子商务的用户了解自己的客户,向客户提供更合适的服务(如某B2C电商平台上,根据用户的搜索、浏览、购买记录通过大数据分析,通过第三方平台向客户精准推送产品)。

聚类分析是细分市场的有效工具,同时也可用于研究消费者行为,寻找新的潜在市场、选择实验的市场,并作为多元分析的预处理。

五、多维度尺度法

多维尺度法是一种将多维空间的研究对象(样本或变量)简化到低维空间进行定位、分析和归类,同时又保留对象间原始关系的数据分析方法;其特点是将消费者对产品的感觉偏好,以点的形式反映在多维空间上;而对不同产品的感觉或偏好的差异程度,则是通过点与点间的距离体现的,我们称这种产品或项目的空间定位点图为空间图,空间轴代表着消费者得以形成对产品的感觉或偏好的各种因素或变量。

在分析消费者对产品功能的需求度时,首选选择研究对象,如列出某个产品的所有产品功能;然后从目标市场中抽取一个样本人群(通常30-50人),让他们对产品功能的需求度打分;最后采用多维度分析获得一张代表了产品功能需求度关系的可视化图。

可视化图中的维度代表了消费者对产品功能需求依赖的关键要素,为方便起见通常选择2-3个维度。投保人购买保险产品时所需的第三方互联网工具产品功能在生命周期和需求频率上的多维度分析如图所示;通过多维尺度分析帮产品经理区分功能优先级,做出产品决策。

投保人互联网工具产品应用多维度分析

多维尺度分析优点是很明显的。研究者可以利用得到的位置结构图将研究对象进行分类,还可以对隐藏在数据背后的空间维度做出相应的判断和解释。

多维度分析通过把所研究对象的数量关系转化为直观图形,达到直观展现研究对象的目的;多维尺度分析的缺点是分析结果不是唯一的,结果可以在空间中旋转和平移,这为分析者对结果的解释制造了难度。

六、联合分析

联合分析法,又称结合分析法,是对结合效应的评价,从而有效地解决了传统调查方法中需要调研对象独立评价属性的问题。

联合分析有三种主要形式,包括权衡矩阵法、两两比较法和全轮廓法,其中又以全轮廓法最为常用;该方法提供给研究的参与者一系列的产品描述,参与者被要求浏览所有的描述,做出一系列的评价,对调研结果进行数学方法分析后,就可以导出该类产品的各属性的效用值。

对于市场研究领域,在联合分析之前的所有方法几乎都会使用重要性比率尺度来度量产品属性的重要性水平,即都会直接向消费者提问一个产品中他们最看重的属性。

这种方法有几个严重的缺点:首先,调研的经验表明,如果不限制条件的话,消费者倾向于认为每个属性几乎都是同等重要的;其次,消费决策很大程度上依赖的是整体的判断。当消费者被要求分离各种属性并且对各属性进行量化评价并且描述某个属性水平的高低将驱使其购买一个产品而不是另一个产品时,即使是最老练的消费者也将感到无所适从。

在联合分析中产品被描述成为轮廓,每一个轮廓由能够描述产品重要特征的属性和赋予每一属性的不同水平的组合构成。

消费者在实际购买时并不是基于产品某一属性而是综合考虑产品各个属性及属性水平从而做出购买决策的。因此消费者对某一产品轮廓的评价可以分解成构成这个轮廓多个属性水平的评价以及不同属性在决策时所占的权重。

在联合分析中用分值也叫做效用来描述消费者对某一属性水平的偏好,联合分析能够较好地模拟消费者购买的实际过程,从而客观、真实地测量消费者对某一产品的偏好及产品不同属性在购买过程中的重要性。

以QQ会员等级为例,如图向用户展示属性组合以及用户需求等级。在本例中,有8个不同属性,每种属性对应9种不同的属性水平,由此构成的属性组合可以满足不同的QQ用户的需求。

联合分析(腾讯QQ群产品会员等级划分)

联合分析是对人们购买决策的一种现实模拟。因为在实际的抉择过程中,由于价格等原因,人们要对产品的多个特征进行综合考虑,往往要在满足一些要求的前提下,牺牲部分其他特性,是一种对特征的权衡与折衷。

通过联合分析,我们可以模拟出人们的抉择行为,可以预测不同类型的人群抉择的结果;因此,通过联合分析,我们可以了解消费者对产品各特征的重视程度,并利用这些信息开发出具有竞争力的产品。

七、李克特量表

李克特量表是属评分加总式量表最常用的一种,属同一构念的这些项目是用加总方式来计分,单独或个别项目是无意义的,它是由美国社会心理学家李克特于1932年在原有的总加量表基础上改进而成的。

李克特量是目前调查研究中使用最广泛的量表,当受测者回答此类问卷的项目时,他们具体的指出自己对该项陈述的认同程度;该量表由一组陈述组成,每一陈述有“非常同意”、“同意”、“不一定”、“不同意”、“非常不同意”五种回答,分别记为5、4、3、2、1,每个被调查者的态度总分就是他对各道题的回答所得分数的加总,这一总分可说明他的态度强弱或他在这一量表上的不同状态。

李克特量表应用步骤“

1)收集大量(50~100)与测量的概念相关的陈述语句。

2)有研究人员根据测量的概念将每个测量的项目划分为“有利”或“不利”两类,一般测量的项目中有利的或不利的项目都应有一定的数量。

3)选择部分受测者对全部项目进行预先测试,要求受测者指出每个项目是有利的或不利的,并在下面的方向-强度描述语中进行选择,一般采用所谓“五点”量表:

  • 非常同意
  • 同意
  • 无所谓(不确定)
  • 不同意
  • 非常不同意

4)对每个回答给一个分数,如从非常同意到非常不同意的有利项目分别为5、4、3、2、1分,对不利项目的分数就为1、2、3、4、5。

5)根据受测者的各个项目的分数计算代数和,得到个人态度总得分,并依据总分多少将受测者划分为高分组和低分组。

6)选出若干条在高分组和低分组之间有较大区分能力的项目,构成一个李克特量表;如可以计算每个项目在高分组和低分组中的平均得分,选择那些在高分组平均得分较高并且在低分组平均得分较低的项目。

我通常会在产品的早期创建一张范围矩阵表,用来列出所有讨论过功能和内容。这样一个范围工具就出现了,它可以用来支持人们讨论整体的优先级别,以及每一个功能的工作量,然后决定哪些功能应该纳入范围之内,而哪些应该排除在外。

在分析每一个功能的重要性的时候,把人物角色加入这个工具中,就能让这些用户始终停留在每一个人的脑海中,可以大大地帮助你在决定项目范围时,把人物角色变成其中一个积极的部分,如图所示。

李克特5点范围矩阵量表(功能需求度转化)

李克特量表的构造比较简单而且易于操作,因此在市场研究实务中应用非常广泛。

在实地调查时,研究者通常给受测者一个“回答范围”卡,请他从中挑选一个答案;需要指出的是,目前在商业调查中很少按照上面给出的步骤来制作李克特量表,通常由产品经理和研究人员共同研究确定。

文章来源:人人都是产品经理  作者:长乘

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务





登录页需要注意的设计细节和逻辑

涛涛

确保用户成功且无压力的登录体验需要我们不断地思考。




大家好,我是Clippp。今天为大家分享的文章是「登录页」设计。几乎所有的登录页看起来都大同小异,通过输入账号和密码就能够进入,但仔细思考会发现,每个登录页都有差异化的点,而这些点正是产品无一物二的地方。

1、什么是登录体验?

登录体验是指用户通过入口进入应用、网站或服务,建立自己的身份。

登录流程通常由主登录流程和恢复流程组成,其中主登录流程包括填写用户名、手机号、密码等,恢复流程包括忘记密码、重置密码、其他登录方式等。登录体验的目标是确保用户成功登录帐户。

2、设计熟悉的登录流程

使用简洁、常用的页面布局和文字,有助于用户轻松执行熟悉的操作。保持设计简单也有助于将体验轻松扩展到不同设备和屏幕尺寸。

▲ Pinterest采用了居中对齐的重叠式登录页设计,用醒目的红色按钮来突出登录动作,还支持Google和Facebook作为其他登录方式。

登录页是强调品牌的首要接触点。登录操作最好于中心位置,页面上的其他元素应谨慎增加,避免注意力从登录任务上移开。

设计思考:

用户花在登录页上的时间越少越好,要让用户尽快发现产品中的优点和价值!

3、专注设计

登录(或恢复)操作应引起用户的全部注意力:

  • 最好将登录页表单放在页面中心位置;

  • 不需要复杂或冗长的文字解释,例如可以利用简单的“输入密码”来提示用户完成操作;

  • 要求用户一次只做一件重要的事情,例如将找回密码这种复杂的流程分解为多个步骤进行。

▲ Facebook保留用户的登录信息,并将恢复流程分为几个逻辑步骤。

▲ 亚马逊将辅助恢复选项放在“更多帮助”中,这有助于使主要操作保持重点。

设计思考:

使用卡片式布局;

将操作分为主要动作和次要动作;

使用尺寸大而突出的登录按钮;

尽量减少次要操作的次数,以避免使页面出现混乱。


4、给出明确反馈并在操作失败时提供帮助

在登录过程的每个阶段,用户都可能会失败。输入错误的邮箱,忘记密码或网络问题等,所有这些问题都可能导致登录意图急剧下降。

因此清晰及时的反馈设计对用户来说很重要。

▲ 信息输入错误时会提示错误具体的原因。

▲ 密码输入有误时,Facebook会在下方增加“使用Google登录”选项。

设计思考:

鼓励用户尝试合适的替代方案;

登录失败后,将用户导航到单独页面并组织其他登录方法;

展示最有效的登录方法,并在发生问题时及时对用户做出反馈。

5、多种登录方式提供灵活性

除了输入账号密码这种登录方式,最好提供一种或两种附加的登录方式以便用户选择,同时防止忘记密码造成无法登录的情况。

添加过多的登录方式会使页面混乱,降低登录意图,附加选项应该限制为2或3种方式。

▲ Medium登录表单的设计尽管很清晰,但过多的登录方式会阻碍用户的选择和判断。

▲ Airbnb登录页能看到大量的辅助登录方式,过多的选项可能会导致用户的认知负荷。

设计思考:

当前无密码登录正在迅速普及。在很多移动App中,基于手机号的身份验证已成为常态,指纹和FaceID也出现在许多地方,从而实现了无缝和安全的身份验证流程。

找到产品最适合的登录方式,并将其作为主要选择能有效提升效率!

6、登录意味着信任

登录涉及用户输入敏感的个人数据,例如手机号、邮箱、密码等,用户愿意输入信息意味着他们信任这个平台或产品。

虽然减少与用户的摩擦很重要,但有时网站也会提供额外的身份验证来确保用户信息的安全。

▲ B站利用文字验证方式来增强用户帐户的安全性。

设计思考:

登录表单应该代表品牌的形象,任何视觉上的变化都必须慢慢进行,因为完全改变视觉设计可能会导致缺乏信任。

7、确定用户类型

登录意图是一种体验,在这种体验中用户角色和类型可以无所不包。

可以尝试以下方式来定义用户的范围以便更清楚的了解用户:

登录渠道:与PM合作找出在登录流程中用户交互和退出的关键阶段。

登录入口:用户是通过邮箱、搜索引擎还是通过应用跳转到登录页?

常用设备:手机、浏览器等设备可以为用户带来个性化的体验。

用户群组:利用年龄或地理位置等方式也能进行分离用户群主的划分。

8、登录页设计实例分析 

通过分析具有代表性的登录页设计来展示登陆页的多种设计表达。

▲ Google采用多阶段的登录方式,邮箱和密码分两步进行输入。这种格式对谷歌来说有一些安全优势,也可以在下一步为用户提供个性化的选择。

▲ Uber的登录页采用简单的样式,注重使用体验,引导用户输入手机号来进行下一步。

▲ Facebook利用右对齐的登录表单很好地集中注意力,左边的空间被用来展示品牌的信息和形象。

▲ 亚马逊的登录页从视觉设计上看有些陈旧,但却是管理用户注意力的一个很好的例子。黄色的“继续”按钮和简洁的页面使登录看起来简单而快速。

▲ Figma的登录页位于画面中心,顶部首先展示的是以Google登录,这可能是Figma首选和推广的登录形式,页面整体的设计利用线框组成,非常简洁高效。



文章来源:展开  作者:Clippp

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务






热门的手机用户输入设计模式

鹤鹤

对于任何手机应用程序,如果没有来自用户的一些初始和正在进行的输入,就不会发生任何事情。因此,手机产品设计师、开发人员和产品经理必须了解允许用户这样做的最佳方式。

虽然手机应用程序以及使用它们的用户通常是独一无二的,但是有许多常见的模式(新模式和旧模式)被用来解决这个特定的问题。


用户输入设计的6个目标


在我们深入研究模式之前,了解用户输入设计的六个主要目标是很重要的:

  1. 选择合适的输入和资料登录方法

  2. 减少输入量

  3. 设计有吸引力的数据输入屏幕

  4. 使用验证检查来减少输入错误

  5. 设计所需的输入文档

  6. 制定有效的输入控制


模式的概述


在记住以上设计目标的前提下,下面是我们在将本文中详细介绍的设计模式的概述,在我们的电子书《2014年手机用户界面设计模式》中有更详细的介绍:

1.智能键盘
2.默认值&自动完成
3.立即沉浸(或“惰性注册”)
4.操作栏
5.社交账号登录
6.巨大按钮
7.滑动操作
8.通知
9.显性控件
10.可扩展输入
11.撤销


1.智能键盘


Facebook记事本,Android联系人


问题
用户希望快速输入信息。


解决方案
当用户点击应用程序中允许输入信息的部分时,给他们与输入数据相关的键盘。这使他们不必在字母数字屏幕之间寻找正确的按钮,或者多走一步来访问键盘。这不仅方便了用户,而且还指示了需要从用户那里得到什么类型的输入。手机平台允许相应地标记文本字段,这允许在哪些按钮显示在更显著位置方面有一定的灵活性。


例如,在地址簿或拨号器中输入电话号码时,用户不需要完整的键盘。当他们点击这些字段时,数字小键盘就会弹出,而不是整个键盘,这样就减少了不必要的按钮,简化了操作过程。类似地,点击浏览器中的URL栏会弹出一个稍微修改过的键盘,其中“/”和“。com”按钮显示在空格键旁边,而不是符号键后面。通过连接到系统提供的这些智能键盘类型,你的UI可以根据用户当前尝试的操作进行调整。


2.默认值&自动完成

Skype, Flightboard


问题
用户希望快速完成操作。


解决方案
通过为用户提供预先填充的默认值或基于先前输入的数据的提示,预测频繁选择的项并使用户更容易地进行数据输入。这可以与自动完成功能相匹配,比如在谷歌Play Store搜索中,通过加速来显著改善用户体验。这种模式在标准化用户输入和在问题发生之前预测问题方面特别有用。例如,Skype会自动为输入的电话号码匹配国家代码。从用户的角度来看,这是有意义的,因为他们不习惯定期输入这些信息,但在这种情况下,这种匹配很重要,因为Skype是一个国际电话应用程序。


另一种实现方法是保存用户输入的最后一项,并在用户再次输入或搜索时显示这些最近使用过的项。例如,Flightboard在搜索框下面列出了以前使用过的位置,以避免用户再次输入。大多数地图或导航应用程序也采用这种模式,在搜索方向时自动输入用户当前位置,为用户节省几次点击,因为这是最常见的情况。


3.立即沉浸(或“惰性注册”)

Wunderlist


问题
用户希望在注册之前先尝试一下。


解决方案
越来越多的应用程序允许用户在任何事情发生之前——甚至是注册或登录之前——立即沉浸在应用程序中。


记住,他们一次只能做一件事,而且测试每个新产品的时间有限。随着应用程序的日益专业化,在扶持它们之前找到高质量的用户或客户越来越重要——他们可能会讨厌你的产品或很快意识到它不是他们想要的。向用户询问注册账户所需的信息可能是一件很困难的事情,而且会降低甚至是适合的访问者的注册率。在积极的方面,通过让他们立即体验你的产品,他们更有可能被吸引,因为他们能够在第一次体验时深入探索应用程序。这比我们接下来讨论的onboarding walkthrough UI模式更好,因为它向用户展示而非告诉他们应用程序如何工作。


对于Carousel或Duolingo等依赖用户数据来运行的应用程序来说,允许延迟注册是没有意义的,但Wunderlist或Houzz等应用程序可以允许用户在要求他们确认身份之前进入并使用该应用程序。通常情况下,注册会带来一些额外的好处,比如在Wunderlist中进行跨设备同步,或者在Houzz中创建一本想法书,这会让注册变得更有吸引力。延迟注册并不总是一个好主意,但是选择“注册前试用”可以很好地提高你的应用程序的参与度。


4.操作栏

Facebook Paper, Behance


问题
用户希望快速访问常用的操作。


解决方案
从应用程序的操作栏(或iOS术语中的“工具栏”)提供对重要操作的快速访问。虽然导航条主导了web和早期的手机应用程序设计, 但其他模式的使用,如折叠、滑出式工具栏和侧边栏、指向所有内容的链接、按钮转换、垂直的和基于内容的导航,产生了更简单的应用程序视图,用户可以专注于一级和二级操作,而不是二级导航。常见的操作有:在应用程序中搜索、共享和创建新内容。这个存留的菜单可以帮助用户熟悉UI,还可以通过专注于与用户相关的重要操作清除一些混乱。


5.社交账号登录

undefined

Beats Music, Flipboard


问题
用户需要一种更简单的注册和登录方式。


解决方案
整合社交账号登录方法,允许用户通过现有账户登录。这意味着他们少了一个需要担心的用户名/密码组合,同时,你也不必担心密码的安全性。Facebook、Twitter和谷歌是主要的OAuth登录提供商,根据平台和目标受众的不同,你可以在你的应用程序中提供所有这些或其中之一,而不是让用户建立一个他们可能会也可能不会在未来使用的单独的帐户。使用这个注册和登录模式也可以为你提供一些基本的关于用户的数据(当他们使用应用程序时,会自动填充数据), 同时,通过不强迫用户在刚下载的陌生应用程序中输入他们的详细信息,让他们更加舒适。这个简单的特性可以在很大程度上改进你的UX,因此这种模式正在成为一种期望。


6.巨大按钮

Tinder, Shazam


问题
用户希望立即知道他们可以采取哪些操作。


解决方案
理想的触屏点击目标大小可能是72 px,但是一些应用程序,像Tinder,也会给你巨大的按钮让你确切地知道该做什么, 无论你在什么位置,无论你在做什么,你都能很快完成操作——很难错过这些巨大的按钮,即使你没在仔细看。这在更简单的应用程序中尤其有价值,因为在这些应用程序中,用户需要执行的操作非常有限,因此更有理由让他们在各种情境中更容易地执行这些操作。例如,Shazam是用来看电视或听音乐的,它实际上只做一件事。对于试图在这种分心状态下进行多任务处理的用户来说,巨大的按钮是一个巨大的改进。


7.滑动操作

Carousel


问题
用户希望关注特定的内容。


解决方案
允许内容被滑动或移动。这为用户提供了一种非常直观的方式来处理屏幕上的信息。例如,谷歌中的“卡片”现在可以在你不需要的时候被滑走,以清理杂物;类似地,Tinder中的配置文件可以向左或向右滑动,以表示积极或消极的响应。这个模式与我们在导航模式中讨论的滑动视图不同。在这里,滑动手势被用于一项操作,而不仅仅是浏览。有些应用程序结合了两种滑动模式,比如Carousel,它可以让你通过将照片滑动到一边来浏览多张照片,也可以通过向上或向下滑动来分享或隐藏照片。邮箱推广了电子邮件客户端的左右滑动操作,允许你分别通过向右或向左滑动将邮件标记为已读或安排为待处理。Secret用让你发现新菜单的方式来让你发现新动作。向左滑动一个secret代表你喜欢它。


8.通知

LinkedIn, Facebook


问题
用户希望了解他们应该浏览的新活动或操作。


解决方案
通过标记新内容来突出最近的活动。这个模式有几种实现方式。例如,在标签上放置一个计数徽章是由iOS推广开来的,但现在这也可以在许多其他应用程序中看到,如LinkedIn、Facebook或Quora。Twitter在通知按钮上也这样做,但它在时间轴图标的顶部还有一个小点,以更微妙的方式指示新的活动。另一种显示通知的方式是在应用程序中使用一个向下拉的横幅来显示新活动。Facebook应用程序也能做到这一点,当新闻推送中出现新条目时,它会弹出一个小窗口。


9.显性控件

Secret


问题
用户希望快速访问那些二级的或仅与应用程序中的特定部分或内容相关的控件。


解决方案
清理杂物,让用户只在需要时才发现特定的操作。这些看不见的控件可以通过任何手势来访问——滑动、轻击、双击、长按等等(我们在手势模式中讨论过)。这使你能够将这些操作保留在屏幕之外,从而节省一些宝贵的空间。例如,Secret使用手势而不是可视控件。向右滑动,就会出现一个动作菜单,这是我们前面介绍过的折叠模式的简化版。在创建内容时,用户可以在背景上水平滑动或垂直滑动手指来改变背景的颜色和图案,或者在使用图片时,可以改变图片的亮度、饱和度或模糊度。没有其他控件允许你这样做——也不应该有其他控件。这种UI设计模式非常直观、清晰,你一定会看到更多这种类型的交互。Pinterest是另一个使用手势隐藏动作按钮的应用程序。长时间按下一个图像,就会出现一个按钮,用户可以通过将弹出控件拖动到该按钮上来对其进行固定或评论。


Uber是这种设计模式的另一种实现方式。Uber还可以让你在预订和查看车费估算之间进行切换,只要你选择了你想要的乘车类型,就可以通过点击滑块按钮来查看车费估算。这是一个简单而又重要的UI设计模式,每当我在做五件事的同时还想搭个便车,同时还要确保Uber不会用峰时价格来骗我的时候,它都会让我微笑。Snapchat和Facebook Messenger允许你在需要的时候通过滑走所有朋友的账户来访问这些功能。


10.可扩展输入

YouTube


问题
用户希望关注内容,而不是牺牲屏幕空间给控件。


解决方案
设计当用户点击时会展开的控件。这使得大多数控件在用户需要它们之前都不会出现。例如,YouTube和Facebook通过将搜索栏隐藏在一个图标后面来节省屏幕空间,当用户点击这个图标时,它就会展开成一个搜索栏。


11.撤销

Gmail, Chrome


问题
用户希望在没有中断(例如:确认)的情况下快速地执行操作,但是可以选择恢复意外操作。


解决方案
为用户提供一个简单的方法来撤销他们的操作,而不只是要求他们事先确认。在某些情况下,某个操作可能会导致不方便或数据丢失,例如删除电子邮件或编辑一些文本。用户可能因为不知道会发生什么而完成了一个动作;一个宽容的用户界面可以让他们体验到更多的参与感和友好。对于高级用户来说,撤销功能也很强大,他们会喜欢在整个过程中不用UI反复询问他们是否确定要继续操作,就能更好地控制局面。在解释将要发生的事情时,确认弹出窗口可能很有用,但是用户可能直到看到操作的结果才会理解其含义。在这种情况下,最好是让开,同时提供一个安全网络,以防出现错误。


获取用户的输入
时刻记录你应该从用户那里获得输入的位置,他们是否曾经查看过这些输入区域,他们使用这些输入控件的频率,他们从哪里来,又从哪里进入应用程序(即用户流),等等。不断地重新安排、重新排序、调整大小和调整这些控件,直到你获得更多所需的操作。当然,当用户能够提供输入时,要深入考虑他们实际上是如何使用你的移动应用程序的——确保你在设计应用程序时没有遗漏什么明显的东西。

文章来源:站酷  作者:马克笔设计留学

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

Web产品的适配设计选型

鹤鹤

开篇


  • 宽度单位我是用百分比还是px?还是rem?区别是什么?

  • 什么是屏幕尺寸、屏幕分辨率、屏幕像素密度、设备像素、css像素?浏览器窗口大小和设备大小和分辨率大小区是什么区别?

  • 什么是响应式网站,自适应又是什么?两者有何区别和联系?

  • 百分比宽度布局和流式布局和前者的关系是什么?

  • 既然响应式这么流行,为何淘宝、京东等没有去做,而是单独开发了一个移动端版?这里面有那些坑需要避开?



历史长廊


在早期,硬件设备落后,网页使用的是绝对静态布局为主,绝对固定宽度的布局被称为是静态布局(StaticLayout),也有叫固定布局(Fixed Layout)。


后随时代变迁,技术发展。因浏览器的增多,开发者们忙于兼容各种浏览器。在这个期间,实际已经有了针对各设备适配的解决方案,只是未成为主流,这种新布局方式叫自适应布局(Adaptive Web Design,简称AWD)。

在当时,大多指的就是宽度自适应布局。在这种新思想下,又出现了两派的具体解决方案:百分比宽度布局和流体式布局(Fluid Layout)。


在当时,大家都还没有响应式布局的概念,但此时出现了一个新的词--渐进增强。渐进增强出现后,另一个词优雅降级也随之出现了。这里只是举个典型的例子:gmail和qqmail。这两个都是百分比宽度布局,都属于自适应布局,但有区别。


qqmail就是css hack的完美体现,你用任何一个浏览器,几乎可以看到同一个样子的邮箱,为的是用户体验统一。gmail则使用了渐进增强,你的浏览器越新越强,你看到的效果就越好,为的是用户体验增强。再后来,Google发布了Android,移动互联网爆发,html5标准发布。


互联网大战从PC打到了手机。手机虽然屏幕变小了,但是却提供了更丰富的功能,用户要求不断提高,网站更加看重的是用户体验了,所以,谷歌式的渐进增强被广泛认可,结合自适应的思想,出现了响应式布局 (Responsive Web Design)的概念——2010年由Ethan Marcotte提出。


描述响应式界面最著名的一句话就是“Content is like water”——无论用户正在使用笔记本还是iPad,我们的页面都应该能够自动切换分辨率、图片尺寸及相关脚本功能等,以适应不同设备。



现如今,为何需要考虑多设备的兼顾呢,依然是因为时代发展与生活方式的变迁:

  • 即便是PC或Mac用户,有查显示只有一半的人会将浏览器全屏显示,而剩下的一般人使用多大的浏览器,很难预知;

  • 台式机、投影、电视、笔记本、手机、平板、手表、VR……智能设备正在不断增加,“主流设备”的概念正在消失;

  • 屏幕分辨率正飞速发展,同一张图片在不同设备上看起来,大小可能天差地别。

    结合自身产品用户访问浏览器分辨率

  • 鼠标、触屏、笔、摄像头手势……不可预期的操控方式正在不断出现。

因此我们需要在了解基本布局方式的特征下,选择适合自身产品的布局实现方式。


布局方式对比


静态式、自适应、流体式、响应式布局,A+R混合布局的特点对比如下


静态式布局:

窗口缩小后内容被遮挡时,拖动滚动条显示布局。不管在哪种设备,哪种浏览器上浏览都是一个样。移动设备上则显示太小或不全。



自适应布局:

用自适应技术(Adaptive)我们可以开发和提供不同的布局来为类似纯触屏或者混合触屏设备这样的一类具体场景提供最好的体验。


分别为不同的屏幕分辨率设备设计不同的样式布局,相当于多个静态布局组成的一个系列合集,每个静态布局对应一个屏幕分辨率范围,页面通过百分比自动适配设备屏幕分辨率和可视窗口大小,当可视窗口改变时,不会出现横向滚动条,UI,图片,文字会自动缩放,元素内容、布局、交互方式基本不变。



弹性布局:

以百分比作为页面的基本单位,可以适应一定范围内所有尺寸的设备屏幕及浏览器宽度,并能完美利用有效空间展现最佳效果。



流体式布局:

属于自适应的一个子集,也是通过百分比自动适配设备屏幕分辨率和可视窗口大小,不同于百分比自适应的是随着窗口大小的改变,页面的布局会发生小的变化,可以进行适配调整,这个正好与自适应相补。



响应式布局:

如果从广义上讲,响应式布局实际上就是更好、更机智、更灵活的去实现自适应,他们都算是一种弹性布局。再通俗点讲响应式重在于「响应」它会随着设备属性(如宽高)的变化。


页面的设计和开发应当根据用户行为以及设备环境(系统平台、屏幕尺寸、屏幕定向等)进行相应的响应和调整。具体的实践方式由多方面组成,包括弹性网格和删格、布局、图片、css media query的使用等。


狭义上讲,响应式网页设计指的是一个网站能够兼容多个终端——而不是为每个终端做一个特定的版本。



A+R混合模型布局

R和A上的区别

当响应式设计在基于预定义断点之上用CSS或者JS调整布局和内容。调整方法提供基于用户代理和设备类型的预结构化模版。


他们之间主要的区别是DOM结构,当采用响应式思维开发时,HTML代码在各种情况下都会一样(除非你用JS移除某些DOM节点),而在自适应开发中我们可能会有不一样的代码结构和体验。


R采用流体+断点,在断点之间,页面依然会随窗口大小自动缩放(通过fluid grid),直到遇到断点改变界面样式布局甚至内容。R一般来说需要在网页设计初期就开始(通常采用mobile first策略),所以旧的网站要做RWD很可能要完全重建。


A只在针对几种分辨率(如320,480,760,960,1200,1600px)进行优化,在断点之间的自动过渡比较少。而A则采用保留现有桌面网站(desktop version)而对于更小的分辨率做针对性的优化(适应),减小重构的成本。



两种设计思维都是有效的,需衡量在项目中有多少组件、复杂性如何以及是否存在一种体验是适合所有用户的。开发web应用时经常会用到响应式设计,例如通过自适应开发来构建定制化体验。


两种方法各有利弊,但是如果同时使用它们到底会得到什么呢?A+R模型结合了基于单个主要临界点的自适应和响应式方法。


混合式布局就是为不同终端设备的屏幕分辨率定义布局(适配各种尺寸的PC、手机、穿戴设备等等),在每个布局中,页面元素随着窗口调整而自动适配,混合了百分比、像素为基本单位的组合方式。可以把混合式布局看作是弹性布局、自适应布局的融合。



自适应布局、弹性布局、混合布局都是响应式布局方式的一种。其中自适应布局的实现成本最低,但拓展性比较差;而弹性布局与混合布局效果都是比较理想的响应式布局实现方式。


很多时候,单一方式的布局响应无法满足理想效果,需要结合多种组合方式,但原则上尽可能是保持简单轻巧,而且同一断点内(发生布局改变的临界点称之为断点,后面内容会讲到)保持统一逻辑。


否则页面实现太过复杂也会影响整体体验和页面性能。一般通栏、等分结构的布局适合采用弹性布局方式,非等分的多栏结构布局则需要采用混合布局的实现方式。


选型

如何考虑实践过程中的判断呢。一是看应用场景,二是看如何设计“响应式”方案。简单、轻量的页面直接用media query实现响应性就很好。比如blog、小型企业站之类。现在的CSS框架基本都具备响应性。


但请注意响应式不仅仅是响应式布局。对于大型站简单用media query是远远不够的。于是在同一个controller层上,识别UA,渲染不同版本的模板,组合相应的静态资源。这也算是响应式。开发及维护成本明显提高。

当各个版本间的差异很大时,维护成本很可能会大到无法接受。即便分开做,架构上也要调整,后端服务化,应用层app化。


根据不同公司的技术特点,调整的成本也难讲是否可行。对于大型站,分开做更清晰,同时用响应式组件解决复用、功能同步的问题。总之,根据场景响应式可以从各种层面,各种粒度上做。这是现代web开发的特点。


建议开发一套响应式电脑网站(过渡到平板端,不过渡到手机端)和开发一套响应式手机端网站(过渡到平板端以下的尺寸,不过渡到平板端)响应式布局有可能造成冗余的代码较多,对研发的要求也更高,比如如何更好地让图片,适配,UI动画自适应各种布局。


大站还是要考虑数据计算和承载的问题,会对桌面和移动端输出不同数据,减轻压力。



实践与技巧

首先,我们需要了解几种分辨率的差别。


ps:原生应用可查询横纵两个方向的像素密度,通常浏览器可查询1个系统像素对应多少物理像素。而设计角度通常需要参考的是所获取的系统分辨率


以一个SaaS类后台产品为例,对于基本流量来自Web端网页的产品而言,需要了解当下的浏览器分辨率现状 Web端不同屏幕分辨率占比情况,数据来源百度统计,如图所示:



如上所述,选择适配方式时,设计目标为:区分web与pad端可共享的设计布局大于手机端,且产品规划上web端为主流量来源,pad端属于短期兼顾。考虑技术维护成本与开发成本的平衡,于是判断需要选择A+R模式来完成产品的跨端设计。


自适应(A)方法能让我们在不同的设备上有不同的体验、内容甚至是功能。如将960px作为主要的自适应临界点,根据全局统计信息定义,我们会得到一些相似处:

  • 左侧的可视区代表整个屏幕小于960px时的具体布局和内容

  • 右侧的可视区代表整个屏幕大于等于960px时的另一种布局



在使用响应式(R)技术时,我们可以利用主要临界点创建两个互不相同的体验情景,每种体验里,我们都可以在可用空间内定义二级临界点去调整布局。



通过结合自适应和响应的方法,我们得到A+R模型。利用自适应技术,我们将致力于体验和功能,作出两种不同的情景设计。使用响应式组件,我们可以处理上下文内的UI组件和布局。



这种设计方法要求设计师真正了解他们想要提供的体验,以便于定义要遵循的模型。此模型非常适合那些在较少功能或结构完全不同的小型移动设备上运行的大型APP。就像你看到的,你的产品将具有很强的灵活性,但同时也很复杂。


因为你要处理不同的代码库和环境(非强制性),Twitter、Facebook和Github将此模式应用在他们的移动网站上。如果你在移动设备上浏览这些网站,则可以根据移动用户的期望来检验它们是如何改变的用户体验的。


其他辅助手段


删格

栅格系统可以帮助我们设计,但却不能保证我们的设计。它有多种可能的用途,并且每个设计师都可以寻找适合其个人风格的解决方案。对于简化复杂的响应式布局规则而言,这是一项十分有效的辅助手段。


1. 列和槽(Columns and Gutters)列(Column)用于对齐内容。其中的槽(Gutter)是指相邻列之间的空间,把控页面留白,有助于分隔内容。



2. 页面边距(Side Margins)页边距是指内容和屏幕边缘之间的空间。将边距宽度定义为固定值,这些值决定了每个屏幕尺寸的最小呼吸空间。



3,用于组成栅格的列数称为列结构。8、12、16和20是响应式布局中最常见的几种列结构。而这取决于我们对产品的设计要求。12列结构是相对灵活的。它可以进一步细分,将内容排列在4-4-4或3-3-3-3大小的文本框中,也有部分设计系统采用来24列的形式,如Ant-D

4,断点是指屏幕尺寸的特定范围,列结构、列宽、槽宽和边距都取决于断点。在这个范围内,布局会根据可用的屏幕尺寸重新调整,以获得最佳的布局视图。


如果较小的屏幕有足够的可用空间容纳内容,则列将按比例缩小。如果一列的内容无法在较小屏幕上显示,该列将垂直放置图文内容。

5,网格规则,列跟槽的宽度是以网格作为基本单位来做增减,所以应该先定义好栅格的原子单位,“网红款”8点网格指的是设计页面时,也应该遵循8点规律。值得注意的是,列跟槽的值尽量取8的倍数,但不是非得是8的倍数。


产品中各类元素应该遵循这个倍数原则(图标、组件大小等),不同的设计系统根据自身需求,设定这个规则。例如在Material Design中使用的是2X网格。

6.流体栅格与混合删格

流体栅格有不同宽度的列,固定的槽和固定的边距。流体栅格有灵活的内容宽度,根据屏幕大小变化在流体栅格中,列可以增长或收缩以适应可用空间。


混合栅格既有不同的宽度,也有固定宽度。在现代布局中,一些元素超出了网格边缘,与屏幕边缘对齐。页眉、页脚、出血都是一些常见的例子。


如果内容宽度大于可用的屏幕尺寸,那么一个固定栅格就会转变成一个适应屏幕可用空间的流动栅格,以充分适应内容。

结语


设计需在技术方案前介入,根据你的产品特点,进行设计方案评估,可借助的手段有删格,网格规则等,设计断点规则时,需关注设备的常见系统分辨率。


移动和桌面设计的差别远不止是布局问题。只要有足够的编程量,这些差别是可以通过响应式设计来解决的。事实上,你可以认为如果一种设计不能兼顾两种平台的主要差别,就不能算是合格的响应式设计。


但是,如果确实想要处理好平台间的所有差异,我们就回到了原点:进行两种不同的设计或者使用A+R的模型,在寻求合适的过程中,关注技术的革新。


A与B不是硬币的正反面,它们为了解决同一个问题而生,是同一种思想的延伸。

文章来源:站酷 作者:酷家乐

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务



日历

链接

个人资料

蓝蓝设计的小编 http://www.lanlanwork.com

存档