博文

“这是个普通的小列表” ——work case 系列二 先聊天后画图

对于产品设计而言,充分的想象力以及对需求的理解程度会极大影响后续的时间分配以及最终设计产出。本文主要通过一个小项目作为切入点,通过实例展示设计师如何能更好的切中需求以及进行后续的设计和思考。 #需求描述 “现有产品希望增加一个资讯内容频道,目标会推出以下几个板块的内容:专栏/市场解读/新闻资讯/小课堂/企业动态”。与此同时,运营希望提供置顶位并且有位置能放其他内容和推荐。” 说到底,这看起来是个极为简单和常规的项目,但是很多事情如果不事先仔细确认或是有个大体的预设框架,就容易后期较为被动。 #分析与沟通切入点 对于这类重度运营的需求而言,最为核心的要素是——内容供应。运营方面实际上能在可预期的未来能提供的内容本身,对于整体产品最终形态会有决定性的影响。因此,比起急忙构建分类进行画图,或许我们需要先确定一些可能的问题: 各种内容的提供频率是怎么样,如新闻资讯会每天更新吗? 内容的排序方式 推荐内容与各个分类之间的关系 有没有视频 或者 音频类内容(可以做一个播放器 类似电台节目用户一边看post一边听) 各种内容之间能不能进行组合,比如提供精选作为主页容纳最新的内容 专栏,新闻资讯等内容中,会提供图片吗?是直接内容中抓取还是精心选择过的。 各种内容之间是否存在组合 比如专题 可能既有专栏也有市场解读 我们期望的用户粘度和互动是怎么样的程度的 偶尔来看看 每天定时来看看 ?提供评论?点赞?转发? 这些内容本身会和我们的产品销售存在关联吗? #产品设计的想象力 对于一名熟练产品设计师,不能满足于简单粗暴的把需求转化为原型以及进行简单的排版以。对于最终的产品形态的可能性以及其展示方式,产品设计师本身应该提供更多有趣的可能性: 如何展示分类的内容——头条模式?微博模式(把栏目当作关注的对象)?消息更新模式? 如何展示各个分类的更新 穿插在内容当中 还是直接顶部提供tab,还是提供更新提醒? 如何进行页面刷新,以及是否需要细致的设计流畅的更新机制 还是简单的下拉刷新 重新进行分类 把内容本身按照主题或者日期编组 而非简单根据来源或者类型 比如一个个卡片每天滑动来看 主体内容强调文字还是图片?(说实话 同样是严肃类新闻 apple

“虽然最终是个小提醒 ” —— work case 系列:如何解剖需求并且进行产品设计

最近在做一个小小的优化,这个优化的结果虽然比较常规。但是整个过程可以作为一个很小的案例,展示一名产品/交互设计在整个需求过程中的努力以及产品设计的微妙之处。希望入门的小伙伴看了以后能有所启发吧。 需求简析: 一个基金销售平台上存在两款余额宝类产品,A B,其中A为当前主推产品,B为以前的主推产品。因为某些历史原因,平台上现在发售的券商C类产品(不常规的发售,有额度限制)只能在存入B后进行预约。与此同时,存入B后无法即时进行预约,只能在份额确认后用户自行上平台进行预约。因为产品C虽然有用户基础,但是却并非平台现阶段的主要盈利点因此暂时没有太多动力进行整体流程优化。 由于平台主推A,部分用户容易把钱存到A后抱怨缺乏足够的提示信息。值得一提的是,产品AB名称和功能都极为类似,以至于本平台目标的中老年用户更不易区分这两个产品。 #设计流程-“伸手,握拳,放松” 对待需求,我通常沿用较为固定的处理模式。 分析问题大致的基本可优化方向(后面会详细的讲这个分析本身) 产出一个基本方案 以及和产品讨论这些方向本身 根据讨论确定的方向画草图确定基本方案 然后进行尝试(此处可能会有循环) 根据确定的方向产出基本的方案 根据基本的方案适当进行优化 迭代 以及细节上的改变(此处也可能会循环往复) 最终产出方案交付研发 可能后期还有修补(因为开发过程中,才会真正发现一些问题) 比如在这个需求中,我先是大致的陈列了一些可供优化的方向并且大致讨论出了这个方案。最初产品方面坚持要把这个用B预约C的功能作为一个常规的功能来看待,并且希望把其他A B(如A可以定投,可以转换为一些其他产品,可以T0提现)的功能点进行包装与拆分。但是在多次尝试后,贸然的对整个产品形态进行更迭(比如弱化AB两个产品,突出他们的功能)或是整合AB(比如统一展示AB,且在转入页面进行选择以及提示,这样针对性会更好。)也不一定能解决问题。最终在多轮讨论中,还是把B预约C作为一个小小的promote标签存在,当C产品可以预约时出现小标签提示用户可以通过B进行预约。 在这个过程中,不仅仅需要充分尝试迭代方案,也要逐步进行确认可行性,更明确改动的影响范围。这是一个先放再收然后在放的过程,先是拓宽思路尝试可能的优化点,然后找准大致的方

设计工具吐槽 之 protopie

最近买了protopie打算做更细致的设计方案,可是大致研究一番以后突然有那么一种奇妙的熟悉感。结合近期的跳坑经验,来谈一下protopie和支持动画的原型工具的意义所在吧。 #别以为你换了马甲我就不认识你了 protopie的操作核心是依然是遵循则经典的模式:对象+输入+输出,本质上其实还是对编程语言的图形化模拟。因此,只要是一路研究过origami的中老年设计师,都能对这些变量输入条件判断基本得心应手,因为protopie里面提供的条件、判断、变量与联动机制,其实只是适当的合并了patch以及简化了操作而已。(相比而言principle其实也有这些,但是用更加图形化的方式在时间轴当中进行表达,设计师不需要那么关注逻辑层面上的变化。。)。 #巧妙的混合体-多场景与时间线 在许多传统的工具类,比如axure会提供很多图层面板,principle和AE则会基于时间线让画板发生变化,protopie则提供了场景这一功能。虽然场景之间的切换过度较为简单,与之对应的是对是单一场景类的精细交互的强调——比如各种各样的输入输出和变量控制,以及细致的动画选择(参数选择+时间线+数值线进行控制)。这些功能配合上更传统的动画设计工具——时间轴+数值轴,单一面板内能模拟很多丰富有趣的常用交互动画了。与此同时,大量定义好的动效曲线以及贝塞尔取向的选项+弹力的设置选项,也算是锦上添花,毕竟绝大多数场景下交互动画取向都是在简单的模拟基本的物理和材质,因此简单的参数设置就够了(参见material design内关于动画的篇章吧)。 #参数 变量 以及代码化 protopie让我惊讶的一点是对于表达式的支持如此完整以及开放。说实话,这类动画参数不一定具有实际上的生产意义(优化&性能&不同平台动画逻辑处理),但是提供参数本身能让设计师从变量的角度思考问题,更好的表达和思考自己的动画效果实际上是如何对应到跨平台跨设备的装置上的。值得一提的是,居然还提供了各种文本处理剪切换行和字符串转换功能,简直是一门mini的编程语言了。。。。 #为啥我要买它 可设定触发区域比物件大,不需要额外制作一个层 可以触碰底层区域(方便做多层的交互效果 图层叠了也不怕) 文字图层的设置较多 比如可以加粗 可以设置间距 这样就可以直接在图层里面做按钮(而非切图)

给新手设计师的细节设计案例

本文的目标主要针对一些细节场景的设计提出一些思考框架,以便于新手设计师面对一些细节问题能更好的分析以及作出对应的设计判断。通过提出一些思考的角度和方向,有利于新手设计师对着自查自纠。 场景如下: 本平台用手机号作为注册名,有5%的客户会更换绑定手机号。 此时用户名不会改变,希望在发送短信验证码时,提示用户会发送到绑定的手机号上。 谁会收到这个提示&这个提示会出现在什么地方 -全体用户? -只是更换过绑定手机号的用户? -最近更换过绑定手机号的用户? -某个特定页面(如登录) or 全部可能会针对平台绑定手机号发送验证码的地方 这个提示用什么形式展现? #dialog-在页面下方出现一条时间稍长的提示 带提示链接 联系客服 #toast-直接用toast提示发送到绑定手机号 尾号xxx 时间3s #popover 最为简单粗暴的弹出 #hint 在手机旁边作为提示 提示该号绑定手机号尾号为xxx #component 作为页面的组件存在于页面下方 #流程拆分 直接拆分两个步骤,第一个输入用户名 第二个页面输入验证码并且展示发送到的手机号 设计这个提示需要考虑什么? -平衡点 究竟要展示多少信息呢,简单的展示绑定手机号 还是要进一步的提供帮助 这个提示会不会对于绝大部分用户而言并没有很大意义 -通用性可否实现 如果要考虑在多种场景下复用,那么会影响展现的方式 -可否尽可能缩小影响范围 精确的针对需要提醒的用户 -重新设计/命名 直接为部分用户展示出他们的绑定手机号 并且在其他相关位置不用用户名而提示用户输入绑定手机号 -挖坑 平台用户名体系修改,只有绑定手机号 用户名用其他唯一字符串作为映射 (涉及平台账户体系设计 不细谈)

交互设计进阶题 #写给新手设计师的练习题

#缘起 本文主要列举出一些交互&产品设计方面的小试题,旨在给新手设计师提供系统化且循序渐进的一些练习题。本文会列举出这些题目的主要考点和难点,其目的并非参考答案,而是希望新手设计师能有针对性的对产品设计的某些方面进行更深入的思考。 与此同时,因为这套题目是写给同事妹子用的,因此场景上会偏向于更加偏向实用化的功能设计上&贴近我司业务&生活常见场景。 #初级 基础功夫要扎实 基金申购页面 支付方式选择 主要考点:逻辑设计 -逻辑的梳理 支付方式选择包括很多业务场景 支付方式的默认选择 排序方式 以及可能会把部分提示整合到这里(比如手机银行直接汇款) -业务细节多 比如涉及不同产品起投金额不同 可用的支付方式不同 等 -需要权衡最终的逻辑复杂成都 整套体系如果太照顾客户 可能会过于复杂  提供短信验证码登陆  主要考点:表单设计&状态呈现&细节流程设计 -表单设计是非常传统经典的内容 随着技术的发展有着很多很多的优化 -流程上比较简单 但是依然有一些判断条件 预先进行流程规划的设计师好评 -功能本身入口有比较多的变化方式 考验设计师对本产品的定位 以及对其他相关功能的体察(比如忘记密码的时候提示用户可以先用验证码登录一下) -表单的多种状态 譬如输入的聚焦和选中,以及让用户更流畅的优化 如输入后如何校验数据并且进行下一步  -表单的出现 消失 变化 以怎么样的方式展现给客户 内容如何递进 动画?翻页? 基金组合列表以及产品详情展示  主要考点:信息展示与梳理 -列表设计是一个看似简单 有很多参考对象 但是实质上很难恰到好处的功能 要考虑到内容简单有吸引力 & 内容要突出各个产品的特色 不然用户只会简单看数字 -关于基金组合实在有太多可以展示的内容了 特点&理念 调仓记录 关于组合本身的各种数据  -需要对信息进行分类 更需要把握信息展示的偏向 小白客户?专业客户?还是一个产品做两个页面? -对于详情所展示内容的重新思考 比如更定制 做得犹如专题页面 还是更产品化一些 方便多个产品公用 #中级 方方面面要周全&更进阶更需要经验才能驾驭的内容 定投入口设计

短信验证码登陆 —— 交互设计师考察小题目

#缘起 最近新来了一名同事,也在做一个小需求作为交接工作的开始吧。这个需求并不大,但是很能看出一个设计师的基本底子以及细节把握能力。 #题目 现在平台可以用指纹or密码进行登录,如果需要增加短信验证码登录 那么你会如何设计和沟通这个需求? -这个需求分为好几部分:业务/流程/细节 业务而言: 这个登录方式和密码登录方式是什么样的关系 是辅助性的 还是默认的方式 这个登录方式重要吗?需要在导航上突出吗? 这个登录方式本身会不会影响注册流程 or 以后用验证码登陆和注册合二为一 这个带来的后果就是弱化登录密码 我们愿意如此吗? 要不干脆就用获取验证码作为主要的登陆方式? 用户有没有别的登录方式 那些登录方式不一定绑定了手机号(也就是历史数据的处理问题,此处大坑不谈) 会不会有什么潜在的坑 比如用户名和手机号不是同一个 所以发送短信的时候是发到后来绑定的手机号上面去 简而言之 确定重心 排除业务上的坑 (这个是需要尽早确定的) 这部分重点考验的是设计师的基本意识 能不能找准需求的重点 and 有没有排雷的习惯 ———————————————— 关于这个功能本身的流程: 如何从这个页面返回到上一种登录方式? 需要提供一定的校验码 在获取验证码的时候 可能需要先输入验证码 通过以后才发送短信 可能需要在发送验证码以后 toast提示用户(有些平台甚至每次发送验证码都有序号) 在点击验证码登录后直接发短信 ? 验证码是不是固定位数 这样用户在页面直接输入六位数后进行登录 类似输入交易密码 不必点击确认按钮 用户需要手动点击才发送验证码 是否提供一些限制 这些限制平台当前是怎么样做得?比如多次重复发短信方面的提示 假设用户多次点击发送短信 是不是收不到短信 有没有语音验证码or提示让他去输入密码or提供其他的帮助信息? 如何校验验证码 一边输入一边校验?输入完成六位直接校验?点击按钮后请求并且进行校验? 用户如果多次提交短信验证码 是不是要出现图形验证码等其他限制 验证码输入错误 网络问题等 如何提示 是否沿用平台现有规则 关于可能影响到的别的流程: 当用户输入密码/指纹登录失败多次错误,提示可以验证码登录 在登录页面的找回密码入口 是否

纠结主义要不得 #设计师进阶血泪教训(二)

本文甚至是这个系列都并不打算写那些会时常更新并且会迅速过期的内容,比如什么登录方式设计。这些具体的产品设计总是会有更新更好的方式,可能是观念的变革也可能是技术的进步。本系列打算谈论探讨一些需要稍微进阶的设计师所要关注的思维方式。 这个系列不会迅速更新,估计更新速度以半年为周期.....虽然每一篇都力求短平快.... ——正文开始的分割线—————————————————— 流程设计当中,设计师总有无数需要纠结的细节 譬如一个提醒功能 到底是更轻盈还是更重度才好 这里是用红点呢 还是一个有数字的红点? 这里需要贴个小标签 还是一个可关闭的小提示? 这里是要一个全屏的提示 每次都提醒一下用户可以在这里查看? 还是只提醒一次就好,抑或是日后根据某些条件再次提醒? 在这个时候,或许有这样一些方法可以减轻压力: -画最简单的草图 -做表格 把各个设计方案拿出来做对比 不一定需要画图 -先提供一个方案 然后去歇一歇清空头脑 然后尝试回顾下其他类似的东西/整套体系 再考量这个细节本身怎么样处理比较轻重拿捏到位 -先继续把这套方案给做完,确定掉那些能确定的因素,把真正重要的坑给填掉 -尝试和其他同事一起讨论 不要自己憋着 简而言之,自个儿纠结在一个点上,对于整体的进度把握以及总体的效果而言都有风险。 tip: 针对提醒类设计 有些设计师倾向于 从轻发落——能做得轻盈尽量就不要太强调 并且尽可能通过场景进行触发 这有个好处,就是为了日后“更重要”的提醒,留一个位置 否则界面密密麻麻的贴满了提示犹如牛皮癣并不美观和实用

挖坑要找准地方 #设计师进阶血泪教训(一)

本文甚至是这个系列都并不打算写那些会时常更新并且会迅速过期的内容,比如什么登录方式设计。这些具体的产品设计总是会有更新更好的方式,可能是观念的变革也可能是技术的进步。本系列打算谈论探讨一些需要稍微进阶的设计师所要关注的思维方式。 这个系列不会迅速更新,估计更新速度以半年为周期.....虽然每一篇都力求短平快.... ——正文开始的分割线—————————————————— 新手设计师最喜欢做的就是针对一个细节使劲的想办法优化(嗯,某些追求极致体验的人也如此)。 举一个简单的例子——需要优化基金定投列表页面,提供一些“新闻资讯”以及提供一些数据汇总。 这个需求听起来特别简单,因为通常都是这些套路: 提供更好的空白状态:你看到别人能定投赚钱,你就定投吧 更多的数据呈现:你看到你以前的赚钱过往 or 看到我们的测算 ,你就试试吧 更多的产品推荐:你看,其实这个产品不错哦,你也可以试试啊 更有针对性的服务:针对用户过往产品购买和赎回情况 推荐更适合他的产品 然而这个需求的重点是。。。你一个空白页面人家为什么要点击进来,因为好奇? 淘宝有那么多功能,你啥时候有空没空去看一眼? 以及,如果你需要提供内容,这些内容是不是需要事先开始找运营开始策划和准备了。 或者。。干脆果断找上运营,这个页面就复用一下 或者做成专题页???不作为常规的功能来看待了。。。 emmm 或许,优化内页本身不如考虑下优化一下入口,先保证大家都愿意or能进来这个页面吧...... 有限的运营资源,或许要考虑下怎么样。。吸引大家进入这个入口吧。。。 —这是第二个故事的分割线————————————————————————— “在绑卡过程中出现了一条错误提示(toast),这条错误提示客户看不懂” 设计师碰到这个需求怎么办? 简单的想法是: 查一下这些错误提示,并且找一下后台看下这些错误提示的映射,然后想办法优化掉这些提示给客户提供更有价值的内容。甚至可以做的更重一些,把这套被配置做成界面交给运营&相关同事以便各个银行卡渠道发过来的和银行卡校验相关的信息及时进行更新和变动。 或许同时也需要别的解决方法? 比如:对所有绑卡失败的报错进行进行统计和梳理,以此优化部分功能。 tips: 这里还需要区分那些真正出错次数多or因为交互原因

塞尔达 荒野之息 中的交互与体验设计(下)

提醒 本文为  塞尔达 荒野之息 中的交互与体验设计 系列的下篇  上篇 请点击这里 #地图设计  视野与记忆 本作的地图要素实际上分为三部分,通过眺望功能所展示出光柱标记,游戏主要视野中右下角的mini小地图,以及菜单内的大地图。对于这些要素,实际上为地图功能提供了三种不同视野和不同层级的互动,以及分布了三种不等量的信息。其中,光柱和mini地图都依托于底层的大地图进行设置。 要谈野吹的地图设计首先需要谈及的是游戏的体验与视野。在这里必须再次强调这个游戏的基本调性:这是一个地图很大的开放世界游戏,这是一个高互动性强调探索的游戏,这也是一个有着立体地图(爬山!飞行!盾牌滑行)以及多重探索方式与体验(游戏进程不同阶段的不同探索态度)的游戏。 首先,这个游戏的日常视野是眼睛所视的风景——草原,雪山,沙漠,雨林。在这个基础上眺望放大并且标记地点形成光柱,形成了地图的第一个层次。这个层次主要是用来标记那些眼睛所看到的位置并且记录在地图上,强调的是在高处/开阔之处所窥见的兴趣点以及持续进行探索。配合本作的爬塔机制让玩家一开始就来到高处,以及海拉尔中间的一大片平原之地,光柱的标记意义就更为凸显。值得注意的是这个光柱仅仅眺望可见,也就是算是一种辅助性+更高层级的地图标记,并不会干扰视野更不会影响探索本身(如果这个光柱类似流星水平那样长存于视野中,那么玩家的目的性就会更强更倾向于直奔目的地)。值得一提的是,游戏本身提供了很好的视野上的分区,地形起伏高低远近的层次以及许多设计上鲜明独特的景色(譬如神兽),这些自然的存在实际上就是标记的一种,也弱化了光柱标记存在感。 第二个层次是右下角的mini地图,虽然此地图在主视野ui内长久存在却充当的是辅助性的角色。这个地图承载了各种标记(普通的地图标记以及带有光柱的高级标记),玩家能根据这些标记及时调整方向和位置(特别是在大距离移动比如骑马和飞行时)。同时,因为游戏的天气机制,视野会被干扰而模糊不清(平原之内有暴雨/雪山上有冰风暴)mini地图此时可作为充分的导航辅助。值得一提的是沙漠中的沙尘暴,在这个时候mini 地图(包括大地图)都失效,不仅仅考验玩家用记忆/视野进行探索的能力,也算是极为拟真与现实的难忘体验。 第三个层次是大的等高线地图承载的是全部的地图信息以及标记内容。大地图本身

塞尔达 荒野之息 中的交互与体验设计(上)

#前言 本文旨在抽取塞尔达 荒野之息(下文中简称为野吹)中的部分小的交互流程设计,探讨在大的开放世界游戏当中应当如何展示信息以及设计小的体验流程。值得注意的是,界面交互以及次要gameplay元素的设计受制于游戏的整体调性并且需要从整体的信息负荷上维持在适中的层次上。 #在塞尔达里烹饪美食 塞尔达的做饭流程其实相对较长: 打开菜单-(翻页或者不翻页来到材料页面)-选择材料-(可能翻页)-关闭菜单-选择材料后在锅上选择烹饪-最后在动画和音乐-展示得到的菜品-关闭菜单。 ​其中包括了 进入菜单  选择菜品  退出菜单 展示成果 关闭菜单 这几大环节。除了烹饪以外,塞尔达也当中也允许玩家进入菜单后选择物品,并且放置物品在地面上进行使用(比如做个火堆,比如制造上升气流,比如放八抓鱼气球抬升铁板)。​做饭实际上是这套物品互动体系的一部分,因此交互上也保持了一致性。这套体系的优点非常明确——玩家所得到的物品都是实实在在的并且可以与之更为真实的进行互动,整个游戏本身从整体设计都支持这种“拟真”与“高互动”的设计模式(比如物理系统以及各种互动)。 然而,做饭本身相对于普通的物品使用又是一个更为集中并且带有一定重复性的操作。游戏中提供了锅,只有在锅上才能做饭。因此比起普通的物品使用(比如制造火堆)玩家更可能一次烹饪多个料理(毕竟锅都分布在怪物营地,村落或者驿站)。在这个过程中,反复进入菜单后离开菜单以及点击确认按钮关闭菜单,就显得较为累赘了。 可是仔细一想,这些累赘的要素很难被简单的优化。例如每次做饭后都会出现确认料理成果的界面,这个界面首先是游戏当中提示性信息的界面,譬如第一次获得某物就会有类似的界面提供介绍说明。其次这个界面承载的了料理功效的信息,即便是同样的菜品也可能会功效不同(根据材料/时间/以及游戏自带的一点的随机性机制 非红月的时候也会有)。最后,这个界面是在一连串音乐与动画后出现作为信息反馈和成就感提供所存在的(当你做了一个蛋糕。。。) 这个流程本身单独而言较为机械反复,可是从更大的总体流程而言,一定的机械性的操作也能算是玩家在游戏流程当中的调剂(比如爬塔除了loading也有调控游戏节奏的作用)。如果需要单独为这个流程而优化(譬如不离开界面直接做完料理)那么就会和已有的整套物品互动体系形成差异,由此会额外增加系统复杂

麦当劳自助点餐体验小谈

最近每天都在使用麦当劳自助点餐机点早餐,由此也逐渐留意到这类超大屏幕的交互以及设计当中的尴尬之处以及可能的若干讨论点。本文的全部讨论都基于一个熟练的互联网&年轻客户的偏好和习惯进行探讨,可能会对麦当劳实际运营上的考量缺乏体会。 硕大的屏幕与尴尬的操作 麦当劳的自助点餐机的屏幕非常巨大,这种巨大有其优势所在:可以展示的内容多;屏幕高度足够高所以能给孩子们提供专门的模式(如图);以及字体够大能方便中老年人的使用。然而这个硕大的屏幕也很容易带来一个问题——视线的和手指的移动距离更大以及信息搜寻和操作的成本更高。 比如麦当劳的点餐菜单是常见的左右模式,也就是左边导航右边是具体的菜单(如图)。这就意味着我的视线必须从屏幕的最上方看到最下方以寻找我要的菜单,再从左到右搜寻菜品,视线移动距离极大。 偏偏这些菜单和导航都很喜欢用产品的图片作为icon,然而偏偏各个汉堡的图片在缩小后视觉区分度并不清晰明了反而多种色彩需要更专注的阅读和搜寻信息。这导致我在一片 眼花缭乱的内容中需要一个个读取文字,导致整个搜寻过程极为疲惫。当然,其导航的设计也为这种糟糕的状态,首先进入页面映入眼帘的是当月推荐,随之而来的是注意到右侧一个个麦当劳自己的产品线分类以及该产品线内的常见组合搭配。这些组合搭配在选择后还会提供令人意外的二次选择的机会(比如你以为点餐的时候点的是粥+薯饼,但是在你点击后会提示你其实还可以加五元选择油条而不要薯饼),嗯,为什么不事先告知用户可以如此搭配呢?或者为什么不提供别的选择。 更为令人更为困惑的是很多按钮的分布一下子在屏幕上方一下子在屏幕下方或是中间,本来就较多的步骤(下文会讨论其中一些流程设计)配合上必须每一步都要找一下按钮的分布位置,整个过程更显得迟钝以及缓慢。 这类超大屏幕的点餐机器(除了麦当劳还有很多餐厅都会提供这类机器)都会让我想起科幻电影以及hololens里面的各种全息操作和各种vr体验。我认为他们都承担了多种功能,比如鼓励我转头和移动肩膀避免肢体僵硬。或许我们可以通过摄像头,自动把屏幕变成适应使用人的身高并且只展示ipad屏幕大小的空间?以及优化界面让界面更清晰易读?那为什么麦当劳没有这样去优化呢? 臃肿的流程 自助点餐机的流程从总体而言充满着许多选项和过渡性的界面,导致整体交互缓慢。可以理解这些界面的出

从熟手画图工到设计师 我这几年的变化

#前言     最近会开始写一些,我这几年如何从一个原型画图工到一个独当一面的产品设计师的变化。对于一个有3-5年经验的设计师而言,后半程的发力点逐渐从单纯的提供方案以及确认交互上的逻辑和细节,转向于一些更模糊而难以界定的技能。这些技能有些属于职场经验(本文不会多提)有些则是更深层角度对自己设计的思考和审视。 身为史莱姆的设计师 对于一名产品设计师而言,最重要的并不是拥有锐利的眼光,而是甘愿当一只史莱姆“黏合 吸收”来自各方的反馈并且进行“吞噬与统合”。 例如,许多重度运营相关的功能,产品的设计应该与运营规划同步进行互相配合,才能够达到比较好的最终效果。如app首页设计,可能存在好几个展示的位置:公告(可关闭)/顶部banner(轮播)/站内信入口(可用红点提示)/热点新闻入口。规划出这些功能仅仅是万里长征的第一步,更重要的是要和运营一同协商,确认这些位置能保持足够的灵活性与区分度,并且达成一个相对一致的规范。举例,假设平台需要暂停服务——可以放到公告位,也可以放到banner位置。再如平台获得某某奖项,可以放在banner作为其中一条,也可以包装成为新闻,放在热点新闻的位置上。通过这些一系列的约定以及对常见场景的规范,就能减少不断叠加“更明显的提示”,比如不需要额外的弹窗就能达到比较好的推广和展示效果,也尽可能避免公告位置被滥用。这种预见性也能让产品的设计更倾向于灵活的对待各个可运营位置,并且一步到位提供足够可用的后台配置选项和设计。 诚然这样会花费不少来来去去的以及拉扯,也甚至会让最终的方案更倾向于中庸。但是,比起一个“更有趣”的方案而言,这个方案的最终效果可能会好一些(稿件通过概率也会高一点.....). 身为猫头鹰的设计师 黑格尔把哲学家比喻为密涅瓦的猫头鹰,在我看来设计师在团队当中也充当着类似的角色,始终保持清醒与审视的态度。对于一名设计师而言,挖坑的诱惑的诱惑是难以抵御的,毕竟这能至少能在充实经验,尝试新东西,也能在简历上提供更丰富的内容。可是许多功能并不一定值得匆匆忙忙去做。比起匆匆画图,或许不断退后审视功能的本质以及分析出当前阶段需要发力的点更为重要。 比如,提供一个功能,为用户评估出他的资产配置健康程度并且鼓励用户更理性的投资不同类型的产品。 的确,这个功能可以做的很有趣,因为

塞尔达 荒野之息 游戏设计观察系列(四)开放世界与人物塑造

这是塞尔达荒野之息系列吐槽的最后一篇  #前言 你第一个打的神兽是?水神兽 大象露塔?还是直接去找雷神兽 骆驼?抑或是直奔加农大魔王? 在游戏过程中,你满怀热忱 一心希望拯救身处水深火热被红月祸害的海拉尔大陆上的人民群众?还是沉迷寻找yahaha无法自拔? 你一个周能有多少时间玩游戏?每次玩游戏会玩多久? 最后一个问题: 你认为?塞尔达荒野之息里面令你印象最深刻的角色是?女装林克?米法老婆?塞尔达公主?萝莉普尔亚? 本文将从三个角度,论述为什么荒野之息当中的米法被许多玩家玩家爱称为老婆,以及荒野之息——一款专注探索型的开放世界游戏如何塑造令人印象深刻的角色。 #所谓的官配就是“钦定” 米法真的是一个占据了天时地利的角色。 从游戏整体流程角度而言,本作花费了许多细节指引玩家找到水神兽从而也让米法成为第一个出场的英杰: 一路上怪物难度的设置(直接往雪山奔路途遥远防寒不易,前往大漠或火山路途遥远且怪物难度较高);双子山下一众路人的指点,甚至伯库林的踪迹都在指引你一步步走向水神兽之路。这段流程刚处于游戏的初期,正是多数玩家初次接触游戏&逐渐熟悉并且跟随官方指引的阶段。 在开放世界游戏中,玩家越到后期,也越偏离制作组所设定的路线。因此,越早出场的角色,就越可能以制作者设定的方式进行接触。当然,每个游戏的开头5-10h的体验,都会被精心polish以求达到好的第一印象。绝大多数玩家都不会认真玩游戏并且持续通关,绝大多数玩家最有乐趣和热情的阶段处于游戏刚开始的5-10h,至此以后玩家可能会以更零碎和片段化的时间体验游戏,并且在熟悉套路后刻意避开制作组的精心设计的任务线直接奔往自己所热衷的内容(无论是探索还是刷人马) 从千辛万苦走到卓拉领地到击败水之加农的这一段历程,本作提供了极为巧妙而跌宕起伏的体验: 新手玩家在大雨之中匆忙赶路,电蝙蝠,电箭蜥蜴“教做人”,一路艰难跋涉跋涉,好不容易跑到水之宫殿却发现众人对你态度矛盾而复杂。游戏几乎为每个卓拉领地的居民都设置了对话,几乎每个人都对林克有着自己的态度和看法。他们有些曾经和你一同玩耍,并不计较那些后来的悲剧,而有些人始终对当年的事情耿耿于怀,认为你没能保护好米法。也有些人认为他们需要你,比如悉多王子,也有人认为你这个海利亚人只能带来麻烦。

塞尔达 荒野之息 游戏设计观察系列(三)

本文旨在从塞尔达系列新手&游戏设计观察评论的角度,对塞尔达荒野之息系列的许多游戏设计细节进行粗浅的探讨和观察。本文作者是个手残&严重的投机取巧主义者(会定时farm amiibo卡片的人...) 因此观点可能颇为失真... 同时 本文不建议没有玩过游戏的人食用 —————————————————————————————————— 本篇会挑选部分游戏中通过探索世界的过程中所自然呈现的关卡进行分析,其关注点在于如何使用逐层递进的方式指引玩家逐渐上手并且提供不同层次的挑战。 #千辛万苦走到卓拉领地 这个任务实际上就是个大型教学关: 路线上的传送点比较有限(只有一个试炼神庙)并且附近的塔也无法飞到卓拉领地。 雨天限制了玩家的攀爬能力,玩家需要通过战斗一路推进路线。 雨天同样也限制了玩家的补给,没有锅可以随时做饭。 跳动的八爪鱼气球和会射电箭的蜥蜴训练玩家的弓箭技巧准备神兽露塔的关卡。 一路上玩家会面临密集的挑战 从落石 蜥蜴 到 闪电蝙蝠 玩家必须学会节约战斗资源或者进行一定准备 本作并不注重战斗环节,可是玩家依然需要一定的战斗技巧才能进行游戏,而千辛万苦卓拉领地相当于对玩家的战斗技巧进行了一定的训练,假设玩家以往偏向避战那么玩家也能从关卡中掌握基本战斗技巧从而继续游戏。 #在迷雾森林拔出大师剑 本作中,其实早早就给出了各种提示暗示玩家去寻找大师剑: 做完水神兽的任务后国王会提醒玩家勇者佩戴的大师剑哦 给玩家扩充背包的伯库林也告诉玩家他要回背面的森林才能继续兑换yahaha种子 平原附近的驿站也在有npc希望看到玩家身上的大师剑 种种都是暗示 而拔出大师剑的过程更是一个递进的阶段: 玩家先是到森林,需要跟着火堆走,一开始火堆的距离很近,随后只能观察火堆里火的飘向寻找下一个火堆,最后直接没有火堆只能用一旁的火炬寻找火堆...一路逐渐走到大师剑目的地以后提供了进阶的挑战,其中一个挑战就是玩家这次必须一边应对战斗和解密一边应对这盲目的大雾。 #费罗尼之塔 费罗尼之塔附近有着著名的榴莲收获地,该地点的三层结构也很有趣。第一层只有蜥蜴和史莱姆以及很多榴莲树,第二层有独眼巨人以及几颗榴莲树,顶层没有榴莲和香蕉却有一只人马。值得注意的是,独眼巨人和人马都属于能带给玩家大量宝贵资源也同时需

塞尔达 荒野之息 游戏设计观察系列(二)

本文旨在从塞尔达系列新手&游戏设计观察评论的角度,对塞尔达荒野之息系列的许多游戏设计细节进行粗浅的探讨和观察。本文作者是个手残&严重的投机取巧主义者(会定时farm amiibo卡片的人...) 因此观点可能颇为失真... 同时 本文不建议没有玩过游戏的人食用 #惊喜与惊吓 游戏里存在着很多惊喜或者惊吓的瞬间..每个都是小小的赌博 沙漠地区埋在地下的宝箱可能是个会动的宝箱怪物 河边的野草可能是伪装好的八爪鱼随时给你喷石头 搬起石头可能发现下面有个蓝色卢比也可能那石头其实是小石头人 雪山上没有融化的冰雪里藏着的可能不是yahaha而是一个大蜥蜴怪 这个游戏处处充满着小小的惊喜 同时这些惊喜可能也是惊吓,甚至你看到一个yahaha的小谜题 你没有踏上树桩之前并不知道是轻松的滑行或是飞行或是打靶游戏。这种未知的可能性吸引着玩家试一试,不知不觉就能花很多很多时间。 值得一提的是超级马里奥奥德赛里面类似的设计,很多时候爬到旗杆顶上并没有yahaha(这是避免yahah太多or太套路化的设计)可是奥德赛通过非常充分的金币供应,让玩家永远都不觉得太亏。从这点而言,奥德赛的探索机制更为轻松愉悦更有成就感。 #景观与探索 关于本作如何通过地形地标和开塔体系指引玩家进行探索,已经有很多很多人的讨论了。本处是希望提供一些更细致的片段切片对这个话题进行分析与探究。 - 游荡于天空中的龙 本作有三条龙,三条龙各自游荡于不同的区域,他们除了给玩家提供宝贵的材料以外,其本身既作为一种关卡(猎取龙的各种材料,特别是解救冰龙的过程)也作为一种景观吸引玩家的注意力,更重要的是——他们通过新的方式,链接了各种区域 让玩家意识到各个区域的连通性。比如雷龙从雨林飞到荒漠,再如冰龙从雪山顶到平原,龙的存在和飞行路径,也是对超出塔作为区域划分的新的一种区域构成... 特别是当玩家需要获取龙的材料的时候,四处探索发现龙经过的各种位置和路径,时间,对于区域之间的连接,会形成新的理解。 - 山顶之上 在哈诺特村的传火之旅也是一个很巧妙的任务。玩家一路传火的过程不仅仅熟悉了村落,并且能观察到海岸线以及远处的小岛意识到世界的宽阔。由此玩家可以选择新的探索方向,纠结是去海边走走还是继续在山林之中游荡呢? 与之类似的是神兽露塔的任务最终也是指

塞尔达 荒野之息 游戏设计观察系列(一)

本文旨在从塞尔达系列新手&游戏设计观察评论的角度,对塞尔达荒野之息系列的许多游戏设计细节进行粗浅的探讨和观察。本文作者是个手残&严重的投机取巧主义者(会定时farm amiibo卡片的人...) 因此观点可能颇为失真... 同时 本文不建议没有玩过游戏的人食用 #节奏转换 本作提供提供了大量的内容,比如随处探索找yahaha;寻找神庙进行解密;各种从滚雪球滑雪到骑马;探索开塔搜刮资源;乃至于每个村落的任务。 这个时代的开放游戏内容量都不算少,本作的难得之处是多个环节能无缝融合,玩家可以不断循环下去不厌烦。比如,玩家看到远方的高塔打算去探索,那么他可能会要做准备规划自己的路线,路上遇到敌人后可能战斗或者进行半解谜的战斗(观察并利用环境以及各种能力攻击敌人),中途一路搜刮可能会遇到神庙或者yahaha的小考验,进行一定解谜后可能耗尽资源返回(神庙可以作为传送点),最终到达塔下可能又是一番需要利用观察环境(阿卡莱之塔)或者解决敌人(湖之塔)才能爬上塔,爬塔的过程又是相对放松的休息过程,爬到塔上后又能发现新的可探索区域和兴趣点。 同时,为了促进这些节奏上的变化,游戏提供了很多限制: 沙漠地区的沙尘暴直接让你没办法利用小地图和传送。 平原地区的下雨天,让你猝不及防就没办法一路爬山直奔目标。 迷蒙的雪地&炎热的火山都让你必须舍弃身上一些buff(平原地区可以服装&食物双层buff 这里只剩下一重) 武器有耐久所以最好多利用身上已有的能力如炸弹或者多观察环境。 还有很多独立的关卡比如孤岛试炼比如漆黑试炼还有大师之剑 这些设计并非完美,但是都多少能不断鼓励玩家思考并且调节玩家的行为。塞尔达的成功不仅仅在于新颖的物理体系以及把世界作为关卡,而是充分让这一切真正融合到了一起并且能让玩家体验多种不同的内容,同时又能够保证玩家用简单粗暴的方式也能应对许多挑战。 敌人很强大,但是玩家可以花样虐怪也可以跑路,可以提升自己以后才来挑战。 下雨天沙尘暴都很可怕可是玩家也可以瞎转转甚至一直等一会儿等时间过去。 武器有耐久但是游戏也提供了一些地方给你持续刷武器比如人马大哥比如神庙守护者。 玩家可以玩刷刷刷可以收集狂可以疯狂探索他可以选择“乏味”也可以选择“丰富多样的可能性” 他可以自由切换

关于creation club——世间没有免费的午餐

#前提 假如你抱着bgs就是懒就是懒就是贪婪的心态,那么这篇文章你别读了,回去自我yy吧。 #creation club是什么 这是(估计包括bethesdanet以及nexus)的体系上,官方支持的一种mini dlc行为。在这个基础上,现有内容并不能拿过来收费发布, 必须是全新的内容且完全原创才能加入这个体系。这就避免了以前skyrim paid mod的问题——随便拿别人的mod来漫天开价、开发团队啥都不干躺着赚钱、低质量的mod满天飞。 anyway,这个东西肯定会被无脑污名化——因为在部分高贵的玩家老爷们看来无论bethesda投入多少精力,他们的游戏就是unfinished并且偷懒。作为开发者就必须免费无偿提供后续一切服务,并且满足他们的一切需求和脑洞——即便这样并不是一种健康正常的商业模式甚至不太可能。 #creation club 对现在的mod体系会带来什么影响 ——双向博弈: 对于开发者而言——如果选择发布mod,那么他们有机会招揽支持者和证明自我的机会(这样就只能通过donation模式获得收入),他们也可以选择加入creation club 接受qa等开发流程并且开发出更高质量的作品。 要记住: “Creators are paid for their work and start receiving payment as soon as their proposal is accepted and through development milestones.” 这对于开发者而言,相当于被雇佣了!所以他们可以得到长线支持,在开发过程中得到资助!对于希望全职开发的mod制作者而言,这极大的降低了经济负担和心理压力。 ——原有mod体系得以保留 https://creationclub.bethesda.net/en “No. Mods will remain a free and open system where anyone can create and share what they’d like. ” ——经济激励以及app store模式 如果这件事最终成了,更多高质量开发者的加入也会让mod的质量得到保证,甚至有人可以以此作为职业获得收入。想象一下这把游

为什么设计师这次发挥不好——多一点沟通和信任,少一点盲目指责和气急败坏

#本文目标读者 ——愿意和团队成员积极沟通,提高团队设计质量的产品经理 ——有着一年到三年工作经验ui ux设计师 #请以下人员赶紧撤离 ——给自己封上ux designer实际上却对设计了解甚少还不自知的产品经理 ——资深设计师或是刚工作不久的新人 ——不愿意和团队沟通协商解决问题,只愿意当甩手掌柜的产品经理 ——碰到问题认为多花时间就好的产品经理(比如说你们加班就可以了,或是多给两天就可以了) #为什么设计师这次做得不好? 如果一个人不懂写代码那么去review他人提交的程序,那么是不是有些荒谬?但是在现实的工作中,许多产品经理并不懂得如何评估设计质量,他们只会保佑设计师太差劲了...如果一位有水平的设计在本次设计中并不能提交令人满意的设计,那么这篇文章或许能给你一些必要的帮助。 留意这些影响设计质量与选择的场景: -是否在成本上有所暗示 如果事先暗示设计师这不是一个重要的项目,或是不希望设计师投入过多成本,那么指望设计师主动绘制精美的图标复杂的插画制作精美的动画....这就像是让程序员赶紧写个小功能赶着上线却要求性能超好bug也特少——纯属异想天开。清楚的告诉设计师自己对于该项目的预期很重要,如果设计leader或是产品经理对于该项目抱着一种随意的态度那么设计师就可能把本来就有限的时间放在无用功上。 -是否沟通不足或是沟通意愿不足 部分项目涉及多个部门的沟通和预期,应该给予更多时间明确各方需求发掘对方真正的诉求上。前期少开的会议少画的草图都会导致把有限的经历花在修修补补某个半吊子当中。 -是否希望设计师脑补 部分产品经理内心总是有着某些期许,这些期许可能是希望产品有更多有趣的设计,可能是来源于竞品,可能是个人对产品形态的一些理解。如果设计师无法实现这些期许——那么他就会认为这是设计质量问题,设计师工作态度等等问题。有期许没有问题,但是不表达自己的期许和方向却默认设计师按照这个方向进行那么就可能带来不必要的沟通问题。更糟糕的是菜鸟们(即便入行很多年也可能是菜鸟)通常容易仅仅抓出某些向度不放(我就是要那种高大上的感觉,我就是要简单!简单!简单!为什么你们没有做到人家巨大精英团队用很久做到的事情!!!!)那么容易带来误判以及更多的沟通不畅。对于产品最终形态有偏好没有问

设计流程之前期设计(概览篇)

本文主要以某海外银行个人网银登录后的首页设计为案例,尝试解析交互设计过程中前期设计这一步骤的要点。本文主要分为上下两篇,上篇主要列举出前期设计的要点,下篇则通过一些案例解说前期设计当中某些具体步骤。 #引言 除了部分极为简单的项目,多数设计都需要经历前期的概念尝试和后期方案完善及文档输出两个阶段,区分这两个阶段有助于提供更好的交付产出以及与周边的同事形成更好的协作与沟通。(因为可以提供一些方案给他们选择,并且在方案中期及时沟通优于方案完成后临时修改。) #为什么需要前期设计 ——分批交付成果,在设计阶段中就与同事及时沟通和交流 ——不同阶段关注不同问题,避免眉毛胡子一把抓 ——在前期设计阶段就与产品经理等需求方进行沟通,推动需求细化与更优方案,落实需求细节 ——尽可能通过前期设计尝试一些新的可能性,并且分辨一些概念是否靠谱 ——在前期设计的过程中找出当前设计的难点和关键要素,便于规划时间分配 #前期设计做什么 ——阅读产品需求,并且确认其中细节并且进行相关沟通。 ——尽可能收集相关数据或者已有的反馈,作为设计的依据 ——关注相关竞品设计或类似组件的设计(只要其本质相通即可) ——查阅资料(根据具体项目和设计师熟练度而言) ——构思大体布局以及基本使用流程,并且产出几个预选方案 ——分析预选方案的主要优缺点以及受众的阅览顺序和关注重点(通过 高斯模糊的办法 ) #除了画图,在提供预选方案的时候还要做什么 ——尽可能找出当前备选方案可能存在的优化点(比如信息分布过于松散)—后续详细设计时可能会进一步重点优化 ——明确当前每个预选方案的特点与亮点所在(方便对付那种一句话解释你这个方案的情况) ——记录下关键要点,如每个方案的缺陷/限制/或者其他注意要点(这个很重要!) ——关注自己在设计的时候受到的一些前提限制 ——如果排除了某些设计方向,最好进行简单的记录和分析 ——除非有特殊状况,避免在某个细节中耗费过多时间 ——如果需要运用动画或是不常见的切换等交互,在这个阶段就尽可能提供gif或者视频给研发or产品以供参考 #前期设计需要避免哪些坑 ——过度关注于某个既定的方向(除非产品的要求非常清晰和明确,而场景本身也不需要太多新的设计方案

交互设计文档的元问题

有关于交互文档撰写和输出的话题,已有无数文章进行讨论。本文主要集中与交互文档以及文档规范设计的一些少见的关注点和一些交互文档规范设计的经验教训。 #受众 前公司曾经有一套相对复杂的交互文档设计规范——这套文档规定了设计师需要在visio上进行流程图绘制且在axure上进行原型绘制和输出。其中,visio内的流程图以及相关注解采取不同的颜色不同类型的线以及不同颜色的注释框进行注释,甚至关于点击和双击都有对应的不同符号。整套较为繁琐交互文档的假设在于协作者(主要是研发)会经常阅读此注释并能长此以往能够记忆这些注释的规范从而提高效率。 然而现实并不那么美好:首先除非能保证稳定的对接对象以及一定的频率,否则研发很容易会忘记这些小细节的意义。许多复杂的箭头、符号和颜色区分本身并不方便记忆同时视觉区分度也不一定足够,所以研发也可能有所遗漏,相反简单直接的文字倒是更能抓住视线。 同样延伸出一个常见的说法:交互文档需要提供变更日志。的确,对于较大的项目而言的确应该提供设计变更的日志以阐释设计上的增删和变化,但是对于日常绝大多数的文档而言,开发者更宁愿看见一个终极版本而不太在意版本的变更状况或是因为产品需求的变化而带来的变动点(因为通常到产品开发阶段后,方案都会最终确认除非某些意外状况)。 #为文档撰写者而设计 本人尝试为交互文档中的注释提供一套tag系统...简而言之就是每一条注释前面都用上一个标签说明这条注释的要点:或逻辑,或细节,或动画等等诸如此类。但是这种设计最终并没有得以在团队中顺利推广——因为太繁琐了。设计师每写一条注释都要添加一个tag,并且本来简单一句话就能说明的东西为了tag可能要拆分并且为此添加tag…除此以外,tag的来源是axure的library,且axure本身对于富文本多样式和页面排版的支持着实有限(意味着如果需要在注释中插进一段新内容,需要选中一堆东西后往下移动,十分繁琐) 这个tag系统的推广失败延伸出另外一个问题——文档撰写者的使用体验同样重要。一份过于繁琐和复杂的交互文档体系对于维护者而言是一种负担,不仅仅增加新人的学习成本也变相促使使用者偷懒(文档中一些模棱两可的组件可能一直没人用等等)。交互文档规范的设计应该尽可能减少不必要的繁琐细节,让设计师用尽可能少的控件就能组装出最终的文档。

交互设计自省-进阶版

#前提 这篇文章的目标读者不是新手设计师(工作1年内),而是那些一定设计经验但是尚未足够成熟的设计师。我并没有太多的成功设计经验,但是我希望用我做各种项目中所获取的小小经验和洞见,为进阶的设计师提供更多帮助。本文不打算针对理想状况(队友和上司都很靠谱且支持项目),更不打算针对极端状况(项目本身极为复杂)进行讨论。 本文无意于成为用以在每个项目进行或完成阶段让读者一一对照进行查缺补漏的表格。本文希望提出一些进行设计中的有益技巧(附带说明)和反思角度(分点列举),希望设计师通过这些辅助推进设计乃至于项目本身。 #“我还能抢救一下” 在构思方案的过程中,总会留下不少草稿或是简单的想法。多数情况下,这些草稿本身并没有太大意义,但是草稿当中所蕴含的想法可以提炼出来作为新的方案。如果仅仅局限于静态的布局和图片,那么许多方案可能根本行不通。思索如何通过各种各样的交互行为改善方案(如滚动条、如展开面板、如动画效果)也是值得尝试的途径。另外,假如一个方案在绝大多数情况下都能很好的运作,那么过度顾虑1%的异常状态带来的混乱不一定值得。对待过往的草稿,不仅要尽可能识别其缺陷,判别其优点以及缺点的影响程度也很重要。 注意: 尽可能保存草稿,并在旁边写下注解 不要在开会的时候直接搬出草稿,草稿不是你的备用方案 # “take a note” 有好些棘手的设计都存在很多要点,因此在设计过程应该尽早列举出这些要点。(当然有些人会更感性一些,但是如果一路迷糊下去可能发现最终方案存在某些重大缺陷...)列举出要点以后开始排序确定优先级,随后逐条排除并审视哪些限制因素可以通过别的方式去除(比如某消息提示功能,预留较少的区域存在风险。如果要减少风险,可能要从别处下手——和产品商量简化全部消息提示的字数)。无论是通过头脑风暴还是断断续续的设计新方案,都根据已经列举出的要点进行一定的评分(当然要分权重啦)。如有必要,尽可能及时修正评分系统(比如某些设计到一半才发现的风险因素)并且进行重新评分。 列举出设计要点的最大好处是提供同行评审的依据(或是回答为什么要这样设计这类问题的时候),以及对那些不常见的设计却符合该场景的设计提供充分依据。评价针对于某个项目的小方案,提宏大的设计准则并不那么切题(除非设计本身太奇特),反而具体的限制更为重要。