作为产品工作者,与设计师协作,是产品建设过程中必不可少的一环,而本篇内容将结合笔者工作中与UI设计师、交互设计师等合作的经验与感悟,分享一些与之友好、高效协作,并提高对你认可度的“诀窍”。
笔者的“诀窍”
以上做到,不仅能使你在产品设计时更具审美高度,人机交互意识,同时也会让你在与UI设计师和交互设计师等进行沟通时,如鱼得水,如虎添翼,容易得到较高的认可与信任!
每个行业都有相应的行业理论知识,UI设计和交互设计都有相应的设计理论知识,这些知识是作为产品设计人员的你&我应该了解的。不仅能帮助我们在思考产品时有的放矢,更能帮助我们同设计同事达成一致,更好、更快的推进产品进程。
那么,都有哪些作为产品设计人员需要了解的设计理论知识呢?笔者总结如下:
1)平面设计理论知识:logo(标志)设计、配色设计、字体设计、图文布局设计等;
2)界面设计理论知识:web端设计、移动端设计等;
3)交互设计理论知识:web端交互、移动端交互等;
现在信息通达,资源丰富,有很多的书籍和网站可以学习和了解以上设计理论知识,在此列举一些笔者读过的相关书籍和常用的设计网站资源:
1)平面/界面设计书籍:《标志设计》、《色彩设计》、《字体设计》、《Grid systems 平面设计中的网格设计》、《品牌至上》、《西文字体》、《写给大家看的设计书》、《写给大家看的设计书》等;
2)交互设计书籍:《触动人心:设计优秀的iphone应用》、《点石成金:访客至上的网页设计秘笈》、《方寸指尖:移动设计实战手册》、《在你身边,为你设计》、《用户体验要素》、《设计心理学》、《瞬间之美》、《锦绣蓝图》、《About Face3 交互设计精髓》、《UCD火花集》、《交互设计沉思录》、《情感化设计》、《简约至上》、《赢在用户》等;
3)设计网站资源:Dribbble、Behance、站酷、UI中国、花瓣、Iconfont、千图网、昵图网、海洛创意等;
通过了解这些知识,在实际工作中,能给我们产品工作者带来哪些帮助呢,笔者总结如下:
1)建立一套相对丰富的、成体系的设计理论知识,能够帮助自己在做产品设计的时候,从无到有的整个进程中,都能够做好设计层面的把控,从界面到交互,都有自己基于理论知识的理解与思考,这样保证设计的产品是有理论支撑的,首先能够让自己信服。
2)增加信任感。产品设计人员交付的原型或者是在与不同阶段的设计同事进行沟通时,都能够站在专业的角度,与之平等交流。比如:产品人员交付的原型,界面间的链接逻辑,功能间的跳转等交互,界面的基本布局等,为什么会这样设计,大到整个产品,小到一个控件,都能够道出相应的缘由和设计依据,这时候有足够的理论知识支撑,将会更加让人信服,而不会给人一种臆想般的自嗨感。
3)与平面设计同事(有的公司没有单独的平面设计岗位,由UI设计兼任)交流时,主要是关于产品logo设计,产品相关宣传册设计,宣传海报设计等。如果你了解平面设计的一些理论知识,那么你在和对方交流时,就不会信息不对等,显得不专业。比如:交流logo设计时,可以提出一些设计参考,参考的依据可以是,色彩搭配和谐,贴合产品定位和行业属性,是需要图形logo,图文结合型,还是文字logo;交流宣传册设计时,可以提出对封面(首页)设计,版式,主题色选取,内容页排版风格,图文搭配比例等的思考;宣传海报的设计,清楚不同场合的尺寸要求,风格和版式等有较为明确的需求,当然能够引导设计师发挥能力,创作出超出预期的作品,也是需要基于设计理论探讨出来的。
4)与UI设计同事交流时,主要是关于产品界面配色,界面布局等。如果你能够了解web端和移动端以及其它硬件终端的UI设计理论知识,那么你和设计的沟通效率,执行效果都将会提高很多。比如:对于web端的UI设计,你能够对web页面的配色,不同字体大小,不同网站布局风格,网格系统理论,格式塔原理等都有所了解,并结合自己对产品的理解,有一定的设计思路;对于移动端的UI设计,不同端的字体设计单位,模块间的间距规律,按钮大小,行间距,元素间距等,闪屏页,广告banner,网格系统,格式塔原理等设计知识有所了解。
5)与交互设计同事交流时,主要是关于产品界面间的交互逻辑,控件间的交互逻辑等。如果你能够了解web端和移动端的UI设计理论知识,那么你和设计的沟通效率,执行效果都将会提高很多。比如:对于web端的交互设计,是基于鼠标的点击、滚动等操作。页面的滚动方式,模块的滚动方式,按钮的默认、悬浮、点击的不同状态,控件点击后的反馈形式(弹窗、Toast、定位、新页面等)的设计,产品设计人员需要有一定的了解;对于移动端的交互设计,是基于用户手指的滑动、点击、长按等操作。页面的滑动,模块的切换方式,按钮的不同状态(默认、点击、长按、禁用等),控件点击后的反馈形式(弹窗、Toast、定位、新页面等)的设计,产品设计人员需要有一定的了解。
同产品设计岗位一样,各个设计岗位也有对应的需要产出的设计交付件。
笔者准备阐述的不仅仅是结果性的交付件,也包括与设计合作过程中,一些过程性的交付件。对此,笔者总结如下:
1) 结果性交付件:UI设计视觉稿。UI设计师根据产品设计人员提供的原型图,进一步美化设计的文件,包括配色、布局、控件、弹窗、banner以及不同内容字号的设计等内容。作为产品设计人员,你需要熟悉这些元素,并能够同自己在设计的原型文件时进行的表现层的思考结合,分析出UI设计师产出的视觉稿交付件是否达到预期,是否有超出预期的地方,这些判断能力都是必要的(UI设计师需要配合输出视觉设计规范,产品设计人员可以就此文件与设计人员进行深入探讨)。
2) 结果性交付件:交互设计稿。UE设计师(用户体验/交互设计师)会根据产品设计人员提供的原型图和需求文档进行交互设计(也有可能产品人员兼任交互设计的情况)。包括页面间跳转,跳转方式,跳转等待期间的动效设计,跳转失败的提醒设计,页面滚动或滑动形式,弹窗动效,页面加载动效,控件点击动效等,这一系列的动效设计,除了看其表象(呈现样式),还需要深入了解实现方式和具体参数。比如,一张图点击后,放大查看的动效,虽然都是点击后放大的样式,但是实际上,UE在设计的时候,花的心思往往是你不易察觉的。同样是点击放大查看效果,不同的动效节奏和运动曲线,造成的细节体验区别会是很明显的。你需要同交互探讨动效组成部分,每个部分的意义,运动曲线是怎样设计的,缓进缓出各自所用时间等,甚至自己能够在结合理论知识的基础上,通过动效网站,动效设计软件进行效果模拟,同UE深入交流。
3) 过程性交付件:图标资源。不管是web端还是移动端,图标资源都是必须产出的。从图标样式是否符合产品主题,风格是否统一,图标形式是面型还是线型,以及不同终端图标的输出格式(移动端一般需要五种不同倍数的图标用于适配),作为产品人员,对这些的要求和评估都需要足够熟悉。
4) 过程性交付件:点9图。点9图是一种移动端设计中比较特殊的产出文件(研发人员也有点9图制作工具),一般用在需要保证元素纵向或横向拉伸不变形的情况下,比如非规整的聊天框,随着字数的增多,会拉长或拉宽,如果不做成点9图,那么就会造成变形,边缘模糊等。所以掌握点9图知识,知道怎么制作点9图,或者自己会制作点9图,也是不错的技能。
各端都有属于对应的设计规范,该设计规范交付件一般会由UI设计师产出,产品设计人员能够熟悉这些规范,对协作和评估规范严谨性是大有裨益的!
根据不同终端属性,可以分为web端UI设计规范和移动端UI设计规范等,而设计规范一般需要包含:
1)色彩设计规范: 所使用的色彩种类,主色与辅色的搭配;
2)文字用色规范:所使用文字的颜色,不同的应用场景应该搭配相应的颜色,一级标题,二级标题,内容,提示,备注等;
2)文字字号规范: 所使用文字的字号(大小),不同的应用场景应该搭配相应的字号,一级标题,二级标题,内容,提示,备注等;
4)ICON(图标)规范: 所使用的icon设计规范,不同的应用场景,ICON的不同用色,是面型还是线型,都需要相对统一,成体系;
5)控件设计规范:包括输入框、按钮、滑杆、页卡、开关等控件,同一类型的控件,需要统一设计规范,形成一套体系;
6)间距设计规范: 不同页面,同类型间距的尺寸需要统一,符合规律;
7)交互设计规范;包括滚动,滑动(上下/左右等),点击反馈,弹窗动效等的交互设计,同一场景的交互样式,需要保持统一;
以上就是笔者关于——“产品应该掌握的设计知识”的分享内容,希望对各位有所帮助!总而言之,就是希望各位能够多迈出一步,去了解对方行业相关知识,提高工作效率的同事,提升协作双方的满意度!
免责声明:本文版权归原作者所有,文章系作者个人观点不代表蜗牛派立场,如若转载请联系原作者;本站仅提供信息存储空间服务,内容仅为传递更多信息之目的,如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈!
]]>为什么会谈到从概念到落地这个话题呢?因为很多人听过很多方法,却依然做不好设计。

本文大纲:
由产品经理提出需求。用研做需求验证,进行用户调研。交互设计师对需求进行交互流程和页面布局设计。视觉设计师对交互原型图进行视觉设计。视觉稿完成之后,进入开发环节。

交互设计师的工作是交互架构、页面架构和功能层级的设计。进入UI设计环节后,UI设计师的可发挥空间被交互所限定,看上去可发挥空间不大。

那么UI设计师能干什么?
难道UI设计只需要美化界面设计?
举个例子:同样是台式机电脑,右侧的iMac电脑的外观上比左侧的电脑看上去高级先进很多。

初代powerbook G4苹果笔记本设计感远胜左侧的windows系列的笔记本。

通过上面两个例子可以看出,虽然是相同的产品功能,但是概念不同,会产生截然不同的产品。
产品设计首先需要满足功能,在交互上符合基本的用户体验。接下来就是美化界面,在视觉上符合人类的审美需求。最后是传达概念,在产品和营销上面像用户传达产品概念。

人类在认识过程中,从感性认识上升到理性认识,把所感知的事物的共同本质特点抽象出来,加以概括,是本我认知意识的一种表达,形成概念式思维惯性。在人类所认知的思维体系中最基本的构筑单位。
概念可以大众公认的,也可以是个人认知特有的一部分。表达概念的语言形式是词或词组。概念都有内涵和外延,即其涵义和适用范围。
概念随着社会历史和人类认识的发展而变化。中华人民共和国国家标准GB/T15237.1-2000:“概念”是对特征的独特组合而形成的知识单元。
德国工业标准2342将概念定义为一个“通过使用抽象化的方式从一群事物中提取出来的反映其共同特性的思维单位”。
简单的说,就是一个抽象的东西。
举个例子,如何实现中华民族的伟大复兴,需要五年规划,最后落地到提升全民教育和健康水平/提高民生保障水平…
从总概念拆解多个完整的子概念,然后每个子概念再进一步拆解,拆解成可落地元素。

总概念就是产品的品牌,子概念就是产品的架构和交互,落地元素体现在最终的视觉上面,如icon、字体等。

总概念的品牌印象是100%抽象,常见的抽象概念有亲切、稳定、安全、阳光、真实、快捷等。

子概念里面,主要包含框架和交互。其中50%是抽象,50%是具象。
子概念里面包含:颜色倾向、降低信噪比、对比、重复、接近、连续、闭合、一致性、费茨定律、席克定律等等。

落地元素体现在视觉设计,100%是具象。包含:颜色、风格、字体、icon、动效等等。

概念通过设计策略得到落地,在这一过程中,涉及到框架层、结构层和范围层。落地是基于商业诉求产生的概念。
以深圳地铁购票为例,下图是深圳地铁购票三个主界面。图1是深圳地铁行购票界面。图2是选择站点的界面。图三是查看取票二维码。

下图是一个买票的主界面。里面包含出发站、到达站和票数选择等功能操作。

购票界面的总概念是方便快捷。
子概念是交互,意味着更加明确和符合用户心理模式的操作流程。更合理的布局,这里需要运用席克定律和接近法则。
落地元素是视觉,更加明确的信息点,降低信噪比。更符合用户心理预期的形式——票(对比)
根据接近法则,购票相关联布局在一起。相同的颜色,大脑归为一组。

落地元素,界面设计更符合用户心里预期的票的形式。

通过接近法则和更加明确的信息,产生如下图2。通过降低了界面的信噪比,界面设计更加符合用户的认知。

优化之后,并不代表优化结束,产品的总概念是方便快捷。
根据席克定律:一个人面临的选择(n)越多,所需要作出决定的时间(T)就越长。用数学公式表达为反应时间 T=a+b log2(n)。在人机交互中界面中选项越多,意味着用户做出决定的时间越长。
席克定律多应用于软件/网站界面的菜单及子菜单的设计中,在移动设备中也比较适用。
进一步优化,减少选项。优化之后如下右图所示:

在以上基础上,能不能在便捷快速一点?
进一步减少选择,通过后台数据监控,大部分老用户是固定线路。所以默认选择用户出发和终点站。

下图是用户选择路线的交互。路径层级深,交互操作繁琐。用户选择线路需要点击【按站点线路图选择】列表才能进入下一页线路选择,点击线路才能进一步选择具体站点。挑战页面过多,过于繁琐,交互操作简直反人类。

选择站点界面的总概念是方便快捷。
子概念是交互,简短操作路径。更短的操作路径,这里需要运用席克定律和接近法则。
落地元素是视觉,更好识别的路线,更加明确的信息点,降低信噪比。
根据费茨定律:Fitts法则最基本的观点就是任何时候,当一个人用鼠标来移动鼠标指针时,屏幕上的目标的某些特征会使得点击变得轻松或者困难。目标离的越远,到达就越是费劲。目标越小,就越难点中。
如果我们要想鼠标比较快速的命中目标可以采取两个措施,要么减少鼠标与目标之间的距离,要么使目标足够大。
简化操作路径,将层级页面跳转变为左侧导航进行切换路径,以此减少页面层级的跳转,如下图2所示:

由于部分用户有查看地图来选择路线的需求,所以增加地图,用来辅助用户选择路线。

取票二维码的总概念是方便快捷。
子概念是交互,固定的形式、统一性和稳定性。
落地元素是视觉,梳理信息层级,更好理解的『票』。

根据统一性原则,形式越统一,用户理解成本越低。下图1的形式结构和购票界面不统一,下图3的这个形式和购票界面形式统一,且概念呈现购票形态,用户认知成本低。

下图是深圳地铁行优化后的三个主界面。以上过程完成了如何从概念到落地。

后台回复:ppt或者keynote,获取完整版源文件。
免责声明:本文版权归原作者所有,文章系作者个人观点不代表蜗牛派立场,如若转载请联系原作者;本站仅提供信息存储空间服务,内容仅为传递更多信息之目的,如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈!
]]>交互说明,是交互设计师必不可少的‘写作能力’,它能让研发同事更加了解你的方案说明、交互想法。但写得不好,容易出现流水账式、逻辑不清楚、文案臃肿等情况,给自己带来额外的工作量,还影响着与研发同事的对接效率。

所以今天想总结个人对‘交互说明’这块的知识,让你和研发同事更加愉快地玩耍~
目录:
传统的交互说明,是根据自己的意识、主观想法进行描述,但由于每个人的文笔不同、思维方式不一样,容易出现特别杂乱的说明,相关同事看了表示压力山大想拔刀…

其实我们可以利用开发熟悉的技术术语、代码逻辑来阐述交互说明,使开发对交互说明有更加直观的理解,比如if else逻辑、switch case逻辑、数据库标识字段。
· if else :
一种判断逻辑,根据判断条件正确与错误来执行对应的操作。它可以更直观地表达逻辑关系,更利于开发同事的理解。
比如用户登录的多逻辑说明,可以这么写:

· switch case:
一种选择逻辑,根据选择项执行对应的操作。比如根据用户投入钞票的面值,决定可选择的商品类型。

‘default’是容易疏忽的选项:匹配不存在时做的事情。
比如上面的例子,若是用户投了1元,或者投了一张纸怎么办?
这是就需要‘default’的处理了。
· 用数据库标识字段
另外,一些‘动态参数’用数据库里的字段名称来标记也是一个不错的选择。
比如:‘用户’,在数据库里的储存字段是 #UserName#,用它来代替交互说明里的动态参数,可以提升开发的理解效率。

怎么知道每个字段对应数据库的表达?
接口文档:前端和后台之间用来传输信息的文档,那里既有数据库的表达,也有对应的中文描述。
注:以上例子来自-唐韧《产品经理必懂的技术那点事儿》
密密麻麻的文字说明,是早期交互设计师比较常见的‘毛病’。
一是列全所有说明,可以减少被diss‘考虑不周到’的可能;二是间接证明自己的专业能力。

但是!交互说明毕竟是要给人看的,堆积的文字谁看得下去??
只会带来额外的阅读压力和极高的理解成本,交互设计师修改起来也麻烦。
一俩个页面还好,多个页面都是这样的说明,开发没约你‘一起去爬山’就不错了。
所以个人建议,只针对有异常状态、特殊交互、分支流程、关键节点等特殊地方进行说明即可。
对于一些常识性、无异常点的地方就不用写了。
无特别需交代的地方,写了只会让开发产生怀疑:这个地方是不是在特殊交互?
不要幻想单凭一份交互说明,就能让开发完全、正确明白你的想法,那几乎是不可能的事。
在我看来,交互说明只是个和开发传达内容的黑板报,一个沟通工具。
想让开发真正理解你的交互说明、方案逻辑等,还是得基于黑板报上的内容,亲自与开发沟通对齐。这样才能确定方案的有效性、实现难度、是否有需要调整的内容等,让双方的想法保持对齐。
前期与开发沟通清楚了,后面交互说明可以起到一个‘回顾、确定’的作用。
而对齐的方式可以是交互评审会、工位口述、电话沟通等。只要目的能让开发理解你的交互稿,对齐形式可自主调整。
这个‘模块’有2层意思:
一是类似于‘内容组件’:对于重复性强、出现频率高的内容,设置一个模板内容及说明即可。
对于重复出现的地方,直接代替过去就行,能够大幅度减少交互设计师的工作量,开发也方便理解。

二是分页面/位置来展示:当整体交互原型较多时,没必要全都铺在同一个页面进行展示说明,会显得整体页面很臃肿、浏览起来比较费力(尤其是文件很大时)。
可以尝试:单独展示某个模块、分支流程、场景等下的交互稿。小而聚集,内容更精简、理解更方便。

若各模块/分支流程/场景中的交互稿存在一定的关联性,可以先弄成一张总体性的‘概览图’,再去单独展示。
让开发知道整体方案之间的关系、又能了解各个细分方案里的交互说明。
像一些常见、使用频率较高的说明,完全可以建立起一个‘交互说明库’。
一是方便自己及时调取,节省时间与精力。
二能统一你的交互说明风格,减少开发的理解成本,也能提现出你的专业素养。

想必这个大家都知道,随便性地举例、描述数据,会让开发对内容的真实性、有效性、逻辑关系等产生怀疑。
比如以下哪个‘发文数’,更容易让人理解与‘启用数、启用率’之间的逻辑关系?

为了减少这种误解,还是用最新、真实合理、上线数据等进行描述。
如果在会议上让leader、boss对这些数据/内容提出了疑问,就丢大发了,也会让同事质疑你的基础能力、责任心。
交互稿里总有一些比较复杂、难以文字来说明的想法,像是一些动效、状态、流程演示等。
对于这一些比较复杂的说明,完全可以用demo演示、视频、gif图等形式来演示你的想法,让你的说明更加可观性。
像一些按钮或功能存在多种状态时,也可以‘表格/列表’的方式进行展示。

除了以上情况外,若交互原型有了调整(包括交互说明),一定要与团队成员告知!!并提示修改位置(在哪个页面)。
否则产品、前端、后台、测试等同事的相关想法、工作会停留在上个交互稿里。
别因为信息没对齐而造成了不良影响。就算改了一处小东西,也尽量和同步一下。
最后想说一句,没有人百分百、完完全全顾虑到所有细节和场景,即使你完全地走查了一遍甚至好几遍…

请关注公众号回复‘走查’领取
但由于不同角色的职业视角、预览目的、经验想法等都会提出新的疑问、挑战你的方案说明。
这是很正常的事~
更何况,在方案没对齐前,交互稿(包括交互说明)上都存在太多的未知性、待优化点。
即使当前阶段确定了所有的细节与场景,随着方案时间的推进,后续总有新的想法、遗漏点、优化点涌现出来,那些我们觉得的‘完全OK的方案说明’,也都变成了‘过去式’…
我们要做的,必须是多听听多方视角的声音,并尊重、虚心接受他人的意见,而不是抱怨自己为啥考虑不周全、停留在原地钻牛角尖。
好了,以上就是个人平时写交互说明的一些感悟,完全是处于个人习惯和主观经验得来的,可能不太对,请多指教~
免责声明:本文版权归原作者所有,文章系作者个人观点不代表蜗牛派立场,如若转载请联系原作者;本站仅提供信息存储空间服务,内容仅为传递更多信息之目的,如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈!
]]>日常工作中,产品经理在给需求文档和原型的时候,方案基本已经确定,线框图也很详细,那交互设计师该如何体现价值呢?

日常工作中,产品经理在给需求文档和原型的时候,方案基本已经确定,线框图也很详细,那交互设计师该如何体现价值呢?当你有这些疑问的时候,或许你的思路已经错了:太注重实现界面了。不要被产品经理画的线框图限制住,多问问自己:用户需求是什么?产品目标是什么?
交互设计是否就是拖拽控件,形成DEMO就可以了?不是的。设计最终呈现的包含了界面交互设计,以【输入列表】原型为例:

拿到原型之后,可以先问几个问题:
(1)这个需求确定是用户想要的吗?这里举个耳熟能详的例子:

(2)交互方式是怎么样的?流程如何操作?是否需要反馈,接收响应、错误处理、还是执行确认?
(3)展示效果是什么样的?下拉列表、可编辑还是文本框?数据对齐方式是怎样的?
小型企业(一般20人以下)根本就不会有交互设计师这个角色,有这个流程才是关键。视觉和交互,在小型企业看来是一个职业,因为不需要画出高级矢量图的艺术家,也不需要搞眼动仪等用户研究,只要能把页面做出来就OK。但每个人都有一颗大厂的心,在大厂,每个人做的事情单一,也专业,如果连交互都做不好,谈何更高层次的用户体验设计?想要在公司做用户体验设计,技术能力不够,还需要影响力,这样有价值的推荐可以说服老板。
关于设计的职业发展,可以从招聘信息中了解,以下为简单总结
初级交互设计:执行、优化
高级交互:分析、整合、判断优先级
资深交互:探索、创新
架构师:架构(行业影响者)
以我自己为例,UI的我承担了部分PM的内容,比如需求整理分析、原型图绘制等,管他什么工作内容,以学习的心态去做事,在工作中总结,一定可以让自己成长的更快(从不懂交互到主持评审会,我看到我的成长)。

以下是我在学习了课程和结合工作之后,关于初级交互成长的总结,仅供参考:
(1)转变思想:
不要从感性视角设计,不要角度局限,不要接到需求就画图。
(2)掌握交互设计核心思想:
自上而下的建设,从抽象到具体,从概念到完成。可以从战略层、范围层、结构层、框架层和表现层这五个层面去了解掌握。提供一个基础框架,在框架上,才能讨论用户体验问题,每一个层面都是由他下面的层面决定的,在战略层上的决定将具有某种自下而上的连锁效应。每个层面展开都有很多知识点,如战略层的需求和目标,需要通过用户研究、用户画像、体验地图等方式获得。
(3)补全交互知识体系:
从交互基础知识开始,建立属于自己的知识体系:包括基本流程、流程节点的扩展知识、基础原则等,然后慢慢的进阶到高阶,在进阶到可以自己总结梳理一套属于自己的方法论。
(4)设计落地:
刚开始接触交互的视觉设计师,要先掌握交互的思维方式,即目标导向设计思维。STAR就是一种清晰的,有逻辑的叙事模板,如果你想表现出自己叙事的清晰性、条理性和逻辑性时,可以套用这个模板。
交互设计要有分析解决问题能力和归纳总结问题能力。将复杂的问题进行拆解分析,并对应给出设计方案且可以落地实施,分析能力表现在用户研究、数据分析、竞品分析等手段;将自己处理问题的方法、方案形成可被复用的理论或者资源(可以直接套用尼尔森、格式塔、用户体验五要素等设计方法论),以便后续更有效率的解决问题,日常工作里可以使用控件、组件来提高效率。
不论是专业设计师或是产品人,具备跨界知识是必要的,需要横向发展。因为在市场强烈竞争的情况下,对于产品突破的要求越来越高,唯有融合各领域的精华才有可能在产出有效地创新点。建议设计师们除了在设计专业上奠定良好的基石之外,也能保持开放的态度去学习其他相关领域,例如心理学、品牌、数据、运营和营销等。
(1)自查目的:发现问题,查漏补缺
(2)走查时间节点:设计前中后都可以,最高频还是设计前。
设计前:摸清现状,走查现场问题,进行优先级排序逐一优化。
设计中:对设计的内容点进行确认分析。
设计后:对于设计内容的复盘。
(3)自查方法:根据目标去进行。
自查流程是否顺畅:把全流程跑一边,看看过程中你会如何操作?接到任务、情景理解、判断显示、尝试控制等。操作后有什么感觉?接受响应、错误处理、执行确认。你从操作中明白(获得)了什么?产品(服务)认知、期望判定、体验提升。
自查框架表现:关注每个界面的框架表现。
自查bug:根据出频次、严重度等去评估优先级
免责声明:本文版权归原作者所有,文章系作者个人观点不代表蜗牛派立场,如若转载请联系原作者;本站仅提供信息存储空间服务,内容仅为传递更多信息之目的,如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈!
]]>