PIT BOSS 掉坑永无止境

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

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

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

#前提 假如你抱着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” 有好些棘手的设计都存在很多要点，因此在设计过程应该尽早列举出这些要点。（当然有些人会更感性一些，但是如果一路迷糊下去可能发现最终方案存在某些重大缺陷...）列举出要点以后开始排序确定优先级，随后逐条排除并审视哪些限制因素可以通过别的方式去除（比如某消息提示功能，预留较少的区域存在风险。如果要减少风险，可能要从别处下手——和产品商量简化全部消息提示的字数）。无论是通过头脑风暴还是断断续续的设计新方案，都根据已经列举出的要点进行一定的评分（当然要分权重啦）。如有必要，尽可能及时修正评分系统（比如某些设计到一半才发现的风险因素）并且进行重新评分。 列举出设计要点的最大好处是提供同行评审的依据（或是回答为什么要这样设计这类问题的时候），以及对那些不常见的设计却符合该场景的设计提供充分依据。评价针对于某个项目的小方案，提宏大的设计准则并不那么切题（除非设计本身太奇特），反而具体的限制更为重要。 ...

上一篇“ 如何面试交互设计师 ＃基本思路篇 ”内提供了关于试题设计的基本要素。在本篇内，主要探讨一些常见的题型以及对应题型的处理方式。 ＃试卷类型：现场 or 预先筛选 在所有测试方式当中，常见而很不可取的一种方式是头脑中随便就想出一个题目，随后提供给设计师并让之作答。这种方式通常含糊不清且如果内容较多则容易某些部分被遗忘，更重要的是这类方式的答案通常也缺乏审视。面试官同时也多半是设计师or产品经理，如果大boss随便口头说一个需求就让他们提出完整的方案，多半会成效不佳吧。 现场测试最好提供纸质或电子版试题；试题数目通常以6题问答题为佳（可以采取10选6/8选6等方式，每题10分钟左右）。最好每道题目都写清楚答题的需求和方向，譬如让设计师设计一个拍照功能。那么最好尽可能说清楚场景／前提条件等等，还说明该设计所处阶段——究竟是希望设计师多做一些创意性的方案还是希望给出一个较为完整的方案（流程图＋主要页面＋部分说明）， 如果是预先筛选的测试，设计师通常有一定时间进行更加详细的方案设计。在这种测试中，除了遵循上篇文章提供的原则外，还要注意给出更确切的交付要求。通常预先测试提供的题目都是方案设计类的题目，此类题目特别需要提供靠谱的题目（碰见含糊的需求，再好的设计师也不敢轻易下手）和  较好的评分准则（比如设计版面的美观／方案细致程度／各类产出的完整性／设计的完备程度／对异常情况的处理）。 针对于不同的试卷类型（现场或预测试），评分的标准和侧重点应该有所变化并且预测试的方式应该和试卷类型相同（想三天得到的结果当然比想10分钟要靠谱和有趣很多）。现场设计天生更不容易产生创意性的方案（快速头脑风暴中本来就容易产出有缺陷的方案），因此如果倾向于评估设计师的想象力那么可能试题上对于该设计的实际可用性要求应该降低。 ＃具体试题的一些设计要点 ——考核点控制 每个试题的考核点通常分为两个部分：知识储备和设计能力，前者包括是否了解常用的控件等等知识性的内容，后者涉及提供好的设计方案并且做出取舍的能力。每个试题能够考核的内容最好能简化为有限的要素（便于评分也便于交叉考核，减少随机性），并且最好不要同时在一个题目中同时考核多个领域的内容（对出题答题双方而言难度都会飞速上升）。 试题内容应该一开始就围绕着给定的考核点设计（...

最近换工作，面试了好些公司后发现他们对设计师的考核方式比我的前公司还不靠谱。至少当年前公司用了一份难度适中而且内容也比较合适的试题对设计师进行面试。有些人随便就拿出他们系统中的一个不太常见的功能对设计师进行面试（有10个指标，or 有10个东西在运行，你怎么样展示。。这么抽象的描述是什么鬼）。也有人会提出含糊不清的问题或是自己都不理解的问题（比如问我用户在网页浏览的眼睛运动轨迹分布，我回答常见的是F形分布，对方一脸懵懂。。呵呵。。） 为了让更多人能够招聘到靠谱的交互设计师／考察ui设计师在交互方面的能力，所以我打算写一个小小的系列讨论面试方法的问题。既然本系列需要讨论交互设计师的面试考核，就需要给出一定的前提条件和基本思路并且以之作为后续讨论的基础。 ＃测试的基本要求；信度和效度 对于任何测试而言，都要重视信度和效度，前者强调这个测试是公平而不是随机的，后者强调能真实衡量设计师的水准。为了达到这个水准，最好在出题后邀请其他设计师围观试题并且作为简单pre test，这样能更好的修正现有试题的缺陷，也能提高参考答案的靠谱程度。 ＃尽量考核设计师对于各个平台和各种领域的知识的知识 比如：web端／app／pc桌面端／动效设计or鉴赏／用户研究基本方法／流程优化和流程图绘制／用户行为的基本习惯和不同平台的场景用户行为和习惯／常见控件or常见功能的设计／其他基础知识。。尽量不要局限于某个方面或是某一种类型的设计能力（比如某个小动画的制作方式，比如逻辑能力） ＃尽量考核设计师的通用能力而不是某个偏门的问题 只要基础好，经历一段时间的熟悉，多数设计师都能针对当前系统和情景做设计。如果考核某些仅仅在某行业才独有的特殊功能的设计问题，那么连前提条件都不清楚的设计师肯定倾向于多问问（要是脑子马上一头热血开始设计，反而可能暴露这位设计师过于紧张or设计之前可能缺乏考虑）。 ＃不仅仅考核专业知识，也尽量让试题设计师日常工作的习惯 这年头很多过于细致的知识实际上并没有死记硬背的必要。。。比如问你个卡方分布如何计算出来。。。再如问axure里面的repeater的使用方法 。比起考核过于偏门或是需要死记硬背的知识，考核设计师对关键知识的理解程度和设计过程展现出的细致，逻辑能力，思考能力，以及 沟通能力等等特质更为重要 ＃尽量不...

＃这是个悲伤的故事——期望值令人叹气 ——回顾文献确认试验方法 小规模的原型测试通常让用户进行某些简单的操作从而在两个版本中进行选择。虽然能进行测试的内容很少，但是也同样有着一定的前提。研究者最好意识到这些前提：如原型测试虽然看似测试用户偏好，但是测试的流程可能涉及到用户进行学习以及迁移学习经验的过程（比如识别版式，记认icon）。要解决这些问题，最好根据实际情况合理的安排参与者如何使用原型以及适当模仿类似研究的思路进行研究设计。 ——样本缺陷与描述性统计 简单的原型测试的样本选取过程通常都是有缺陷的，通常都无法代表总体。这某种程度上是一个好消息，因为研究者就此不必进行某些复杂的推断性统计——因为违背了推断统计需要的前提（其实多半情况下人数都不够= = ）。 ——原型本身的缺陷 既然作为原型而不是正式的软件、网页，所以必然有着很多局限性——比如原型只能模拟有限的效果和操作（axure不支持双击）；比如原型的制作需要一定时间；再如复杂的原型其实和代码一样可能有各种逻辑需要处理也需要慢慢debug。 ——我们究竟需要什么 在研究之前，就应该清楚的意识到数据本身的意义，也应该尽可能思考更多的衡量角度。比如用户所需要时间少就能发现某个功能，那么这样意味着这是一种好设计吗？设计的好坏在很大程度上取决于某种整体性的需求（或者说是概率），数据的处理本身也必须根据这种需求以及情景量身订造。不讨论业务特性和业务需求只看简单的数据计算，最终得出的数据结果不能导向好的结果。 ＃这是个麻烦的故事——原型制作到小规模测验 ——无数被迭代掉的版本 进行正式的原型测试之前，通常会有无数个原型图以及好几个基于原型图的高保真版本。无论是正式上线的ab test还是原型测试，所能使用的测试原型数量都有限。这就意味着，如果在最初的原型方案就筛选掉更有潜力的版本或是最终高保真阶段的选择不当可能导致整个原型测试的努力都被浪费。同时，原型测试中所使用的版本，最好是确定在此后不会有太多变动的版本。如果该设计如果其后会因为先前没有充分考虑的因素（比如要处理某些消息和状态，再如一些常见的一场状况），那么必然导致最终版本的设计必须进行一定的修改。这些修改可能会让用户偏好该版本的原因烟消云散，原型测试的结果沦为鸡肋。 ——原型制作需要与实验过...

最近因为某些原因接触到affinity designer，发现这是一款很有趣的软件。在一番试用后，我觉得有必要谈论一下sketch对于ui设计的支持和缺陷。sketch在图形绘制方面所缺失的部分，恰恰可以由affinity designer进行补全，因为affinity 也是一款专注于矢量图形绘制功能并且融合了ps和ai当中许多重要的工具set的软件。为什么我不用ps或者ai和sketch进行对比，因为adobe家的软件大多是很贵而且有着漫长历史的巨无霸。更为重要的是，affinity designer作为一款性价比较高也足以应对日常图形绘制需求的软件，可以和sketch配合作为逃离adobe路上的重要助手。 #interface绘制——sketch的特长 ——布局绘制 sketch是一款专注于ui绘制的软件，因此对于基本的布局绘制有着较为完善的支持。比如自动参考线工具，能方便设计师精确的布局每个要素的位置。再如scale工具能迅速缩放某个元素以及支持元素形状变化的方向，都能方便设计师对于常见元素的尺寸有更好的把握。这些功能对于插画绘制而言并非必须，甚至可能造成干扰。对于ui设计这种强调于尺寸和布局而非单纯的视觉感受的场景，sketch（以及其插件体系）有着充分的支持。 ——样式管理 谈论样式管理无法脱离sketch社区中所流行的插件，craft和sketch measure。craft通过快速制作表单类要素，达成了某种程度上的“用真实数据进行设计”。与此同时，craft能生成可以同步style guide让设计师更方便的管理他们已经绘制的要素，从此设计师不必刻意建立和维护share style。sketch measure最开始是一款能够快速标注的软件，后来延伸出了导出html和自动切图功能。通过这些功能，真正让设计师实现了只要在设计稿中精确作图，让程序员自己爱点哪里看哪里的目标。sketch原生提供的share style还有symbol的功能也让这款软件能方便设计师快速复用已有要素，并且尽可能减少不必要的重复劳动（一次修改，多处变化）。 ——作为平台存在的sketch sketch本身不仅仅是一个工具，也是一个提供多种多样可能性的插件平台。sketch有着丰富而活跃的周边支持体系，这些体系能让sketch与现实生产环境...

#对机核以及内裤门关于辐射4评论的回应。 这是一篇吐槽文，起因是看见机核上一群老玩家和内裤门对于辐射4的评价，感觉他们的评价颇为理所当然…因为他们的论断表现出了某种神奇的优越感和傲慢以及是对于游戏开发过程和对bethesda这个工作室的无知。我承认他们的批评是出于某种善意或是偏好，但是许多批评都和基于某些不切实际的假设或是对bethesda甚至是游戏开发的误解。我觉得我有必要写点什么，我无意对辐射4的吹捧或是无视其缺陷，但是我希望能尽可能通过事实和论据说明bethesda以及辐射4并不是许多人所脑补的那样。 #辐射4制作时间不够？ 很多人质疑，辐射4制作的时间只有两年多？由于时间太少，所以导致辐射4赶工因此内容不足。遗憾的是，这说明他们对于现代大型3A游戏的开发流程所知甚少。现代大型3A游戏的开发时间分为两部分，一部分是前期验证玩法以及构建基本概念，一部分是后期大规模进行制作。betheda也是采取这种工作方式进行工作，如果看过skyrim制作历程那么就能发现，skyrim在oblivion完成后就开始了初步构思。辐射4的大规模制作从2012年初，也就是skyrim正式发布后就正式开始制作。证据之一就是bethesda在2012年初曾经有一次招聘，那一次招聘显然就是为了制作辐射4而发起的。从12年初到15年年底，三年多的时间，对于一款3A游戏而言并不算得太短。 #辐射4投入的人力物力不够？ 辐射4是bethesda至今投入最多的作品，虽然他们并没有大力鼓吹自己为此投入了多少钱。从专门为此开一个e3展前发布会到铺天盖地的媒体宣传，从营销的角度而言也是betheda史上投入最多的一款游戏。为了做好打枪部分，从id（我很怀疑收购id就是为了改善辐射4的打枪环节）和destiny挖人来专门调试枪械手感和音效。辐射4的录音数量是skyrim和辐射3的总和（110000条），辐射4里面配音演员出演人数也更多。当然，用gtav的成本对辐射4进行苛求是不切实际的，因为gtav的受众比辐射4远远要广泛，预期营收也要更好。至于用cdpr的孤注一掷的做法讽刺辐射4是刻薄的，因为游戏业界这种冒着不成功即成仁的巨大风险的公司最后又有多少成功了？mgsv就是一个投入和收益不成比例最终只能整个系列终结的例子。 #辐射4一直都在用祖传引擎？ 很多嘲笑辐...

#origami studio？ 今天惊闻facebook推出了origami studio，围观视频后发现只是把原有origami的patch单独抽取出来，重新包装了一个外壳并且提供图层管理的体系。原有基于逻辑和连接patch的体系并不会发生改变。虽然这个产品暂时不能下载使用，但是根据我个人对origami的使用和学习经历而言，这个产品可能并不会如principle等动效工具那样流行（只要你们上dribbble去搜索下对应的tag就知道origami在设计师中并不那么受欢迎）。 #origami和quartz composer 要讨论origami studio就要线讨论origami和quartz composer，因为前者并没有在核心理念上有太多变化，都是基于图层的变量和逻辑体系进行构建交互行为。用户通过连接一系列的patch从而定制他们的种种行为变化。这套理念的优点和缺点都相当多: ——优点： 基于代码，便于最终转化为代码也便于设计师用代码的逻辑进行思考和设计动画效果。 quartz composer本身提供许多高级控件，提供从变量管理到时间线精确控制甚至是导入外部数据的可能性 （因为支持js，所以理论上的可能性实在不能更多，加上quartz composer也有一些其他的插件和patch） 可以互动，在使用过程中进行不断调试。 支持patch体系，可以更好的复用动画效果也能进行更好的调试。 加深设计师对于交互动画原理本身的理解。 ——缺点： 制作时间较长。 基于代码和逻辑也就让设计师需要处理逻辑问题，在单纯基于时间线的软件中可以规避这些问题。 学习资源较少，学习周期较长。 简而言之，这套体系提供的是一种利用可视化组件进行编程的体验。这种体验对于部分有一定编程基础（因为要学会用那些体系思考问题，比如数据的类型，还有学会用编程的方式有意识的管理模块抽取变量等等）的设计师而言，这种方法能给他们相当程度的便利。即便并非全部作品都使用origami进行制作，但是在构思一些高级和复杂的变化时，origami以及quart composer提供的机制能方便他们调试和制作某些效果。 #路径依赖 origami以及以后的origami studio如果需要获得成功，那么设计师群体的支持...

最近出现了越来越多新的设计软件，这些软件大多数focus在一个专门的领域并且有着较为便捷的操作方式。由此在设计师团体中产生了一些分歧，某些设计师认为有photoshop（或者ai）就好——毕竟是业界流行的软件并且有着最为广泛的适用性。另外一些设计师则开始革新他们所使用的工具链，并且尝试新的工作流甚至是协同方式。同时，即便是关于设计软件本身，虽然有不少资深设计师指出设计中最重要的是设计师本身的能力、眼界、审美等要素，可是多数新手设计师对于软件学习更为热衷。 由此本文希望针对这两个问题进行一些简单的讨论。 #工具影响思维方式——以principle为例 principle是一款轻量级的交互动效制作软件，这款软件最独特之处是支持时间线和driver机制。由于有着基于时间线的交互方式，所以在principle上，用户能更方便的针对多个不同的物件调整他们的的出现时机和顺序，也能快速调节某个参数是否进行变化。与此同时，在principle中用户可以轻便的调节多个部件以及其变量的时间变化也能更好的处理他们之间的顺序和关系，由此用户就有更多动力在这个向度上优化交互动效中的时间变化。 因此如果使用principle这款软件制作动效，那么也会比flinto甚至是origami，更专注于创建随着时间有着丰富细致变化的交互动效。事实上，交互动效软件大多都有不同程度对于时间控制的机制，但是他们或复杂（origami里面的时间控制机制有好几种，而且都要用一定基础才能理解），或者过于针对某个部件（如flinto）。在这种情况下，用户调试和修改的成本也相对较高，更别提有意欲去做出更多尝试。没有各种优化和尝试，也自然无从设计出足够优秀的动效作品并且形成示范作用从而驱动更多设计师去使用。 趁手的工具有利于做出更优秀的设计 #工具影响工作流程——以sketch为例 sketch是一款轻便易用的ui设计软件，这款软件有着精简易用的功能，也有着不少局限性。要谈sketch，就无法离开这软件专注与ui设计这个领域以及周边的生态体系。sketch本身轻巧易用，能让ui设计师更快的修改和迭代设计（特别是symbol和craft）。与此同时，因为sketch本身的易用性，许多开发者也能够利用这款软件独立设计出他们所需要的产品。同时，sketch周边的支持体系，比如m...

#现有方案 我司的交互设计师所使用流程图系统是一套较为复杂而不易掌握的符号体系。这套符号体系在最初运行得较好（至少看以前的文档感觉还挺规范），各种符号都大致被正确的运用。 随着新晋设计师开始使用这套体系，这套体系较为复杂繁琐的一面使得设计师并不能很好的运用。同时随着时间变化，因为许多特殊的符号使用不便并且不能及时反映最新的交互行为变化，因此逐渐被各个设计师所遗忘和忽略。流程图作为交互设计师的产出，其主要的阅读对象是负责界面部分的程序员以及测试人员。一套较为复杂的体系不利于程序员的记忆和学习，更不利于他们快速分辨与理解其中的主要内容和流程。原有体系有多种多样的颜色和形状，力图涵盖交互过程中的诸多细节。事实上这些多种多样的要素，反而让流程图混杂着各种颜色和形状而降低了整体可读性。 #竞品分析（文献回顾 市面上现有各种各样的流程图方案，其中部分以高保真界面为主，通过连线展现各个界面之间的关联。这种流程图似乎较为适用于移动端并且需要大量时间进行绘制，与此同时产出结果通常是一张很大的图...遗憾的是多数程序员和产品经理都没有配备较大的显示器。也有部分流程图方案强调把页面各种各样的要素抽象化为图形，并且希望连接这些图形。遗憾的是，要维护和记忆一套较大的符号库对设计师和团队而言都是负担。软件工程本身的uml体系中有许多不同的符号，但是这些符号本身使用并不容易。首先其图形较为复杂所以无法在其中排布太多文字（这样设计师就需要画更多精力进行排版），其次各种各样的图形以及其含义并不容易记忆，也容易导致各种符号在使用上被混淆的情况。 （本处并不考虑那些更接近信息图的流程图.... ##第一部分小结——为什么要重新设计流程图的相关控件和规范： ——便于设计师学习，记忆，使用 ——便于工作流上下游的各方都能快速阅读流程图，并且迅速分辨主要流程 ——便于用软件进行整齐的排版，减少赘余要素 ——减少团队潜在的维护成本 —————————————————————————————————————————————— #重新设计的前提条件 ——继续以流程图本身为基础，流程图内不包含实际界面 ——流程图尽量保持合适的规模：过于细致的小功能不必然需要流程图；过为庞大的流程需要拆分为多个流程 —...

#地址 http://www.cardcrawl.com/ #性价比 写这篇评测的原因是深感这个游戏异常精致的同时非常超值（2.99刀，没有其他内购要素）...玩了一个多星期后打算安利给诸位... 我之前没有任何卡牌游戏的经验，只是围观过同事玩炉石（感觉好复杂的样子！！！！） #精致美观的动画效果 这个游戏虽然价格不高，但是质量一点都不含糊...华丽精致的动画贯穿了整个游戏..从每一局开盘时的烛光药业和小精灵摇摇晃晃端上酒杯的引导到每次获得金币时刻卡片散落成碎片流向玩家的细节...甚至每张卡片购买解锁后，锁头裂开以及卡片摇晃的画面..诸多细节能让人感觉到制作者的诚意和审美水准.. #较多的卡牌和多种玩法 前期玩家只有5张卡，后期玩家通过游戏胜利换取的金币可以购买解锁35张卡片...这些卡片作用各异，能带来许多特殊的效果（虽然我觉得有些卡片并不划算，因为如果在前期出现就只能白白送去卖掉（还一分钱都没有！））。与此同时，游戏在中后期都提供了多种多样的模式给玩家提供进一步的挑战（比如胜利10场，20场，以及购买了全部卡片后都会开启的新模式），甚至可以从网上下载其他人做好的关卡- - .当然游戏本身也提供随机已有卡组以及自己组卡（5张）的模式，仅仅这两个模式就足够玩家玩很久。 #轻度游戏 我最欣赏这个游戏的一点就是简单易懂容易上手... ——玩家手上和场上的牌都不多，玩家不需要多么深思熟虑（所以连我这种卡牌无能的低智商草履虫都能在一周内凑购钱买到心仪的卡片） ——高级卡片价格并不贵，玩家能比较方便的买齐卡片，而且也有更多机会试错和探索 ——每盘时间三到五分钟，很适合等地铁上下班通勤随时拿出来玩一盘 ——卡牌游戏都是看脸，运气不好赶快重头再来 ——提供多种模式选择 ——单机游戏！！ ——没有内购！不需要联网！ #令人遗憾之处 ——有些模式，比如任务模式似乎难度很高..... ——似乎无法联网获取关卡？（或是墙的问题？） ——因为卡片出现时间不固定，所以某些能稳定带来收益的卡片必然更容易被玩家所喜爱 ——熟悉了卡片以后，二周目就懒得尝试和挑战，解锁了自己喜欢的卡片就能一直玩下去了 #小结 相信我，就算你是非洲人也能玩下去（笑 

#时间永远是个问题 时间对于交互动效的构思到实现都是需要精确拿捏的要素。ios原生动画的时间大概在300ms左右，因此非原生的自定义动画大概也最好在250ms（人眼能反应过来的时间）到400ms左右。 dribbble上有很多fancy的动画效果，他们能给用户提供愉悦的情感以及充分的状态反馈。遗憾的是，这类作品中相当一部分的目标受众是设计师而不是用户。试想要等待邮件发送成功的状态需要等两三秒动画，是对于用户耐心的挑战。 面向移动端的设计本来就需要顾及用户所处状态——更加零碎化的时间以及更缺乏耐心的状态。在这种前提下，单纯遵循传统动画制作的准则，过度强调反馈和拟物化甚至是适当的夸张并不是出路。material design把拟物要素精简为对于material本身的模拟并且创造一种新的材质为内容的展示过程赋予新的意义。material类似现实生活中的物质却是其简化以及变体。或许现代的交互动画也应该把所在媒介本身视为新的物质，而非过度从传统动画中进行学习与仿效。毕竟传统意义上的动画呈现面向的受众，情形，以及受众对信息接受的预期和方式都有所不同。 #交互状态本身 交互动效是用户交互行为中的一个环节，所以交互动效的设计必须考虑其他交互状态的出现和呈现。为什么需要动效，最终目的是传达某些信息达到更好的体验。在这个前提下，设计交互动效之初就必须非常清楚这个动画的前后状态以及场景。假如设计一个用户注册登录的动效，那么必须连带考虑到各种出错状态以及因为网速不同带来的loading时间不同等情形。个人更偏向于优先展现内容框架而不是强迫用户必须看完长达2000ms甚至更长时间的动效。尽管有更多的时间动效可以更为细腻丰富，但是这些丰富本身可能与整体交互设计的目标——提升用户效率，有所违背。从这个角度反面来看，那些被各种状态限制得较少的动效反而容易精致。例如新产品引导界面和可离线游戏内的动画效果，因为在内容的加载上并没有过多限制所以动效发挥余地也更大。 #用户一千次，一万次使用这个功能 在实际工程需求下，只有重点功能和独特的控件才会有独立针对化的动效设计。许多通用性控件有着不可预期的使用场景因而动效设计偏向于保守以及简单。无论是何种情景，真正功能和控件被使用的频次以及传递的信息量都需要仔细斟酌。让用户在无数次使用产品的过程后，动效不会喧宾夺主阻碍用户...

#题材 生命线是一款以拯救坠毁的宇宙飞船上的宇航员为主题的文字冒险游戏。这款游戏曾经在中国apple store付费榜排行第一的出色表现足以为这款游戏的质量做背书。这款游戏更妙的一点是玩家是作为第二人称参与进入游戏，而并非是通常游戏中的旁观者。宇宙冒险求生的主题（很容易让人想起火星救援）让这款游戏更显得不落俗套。更为巧妙的是，这款游戏居然有apple watch应用和根据真实时间进行推送游戏内容的设定，在游戏中（一周目）玩家必须等待对方的回应而不能自主选择不断继续游戏一路通关。等待中的焦虑以及寥寥几句就再度归于等待的碎片化游戏体验为故事本身提供了一定真实感和代入感。这款游戏甚至一开始就为apple watch而设计，所以只有寥寥两个选项并且在游戏进行的过程中不断推送提醒给玩家。如果设定并不是拯救那个惊慌无助却流落太空的少年（少女？），那么游戏的核心玩法，推送和等待，都并不合理。 #缺陷还是妥协 ——选项太少 apple watch上没有位置显示太多内容.与此同时，这是个不断推送内容的移动端游戏，玩家本来也只能碎片化的时间进行游戏。假如玩家必须游戏体验中读几百字后进行深思熟虑随后再做出选择，那么如此缓慢的过程与游戏本身玩法和节奏的设计并不符合。长时间阅读中玩家更容易成为旁观者而非参与者参与到故事当中和主角一起经历求生历程，这也会削弱代入感。虽然选项少，但是在一些选项中能明显看见制作者努力把长选项拆分成较短的小选项，所以实际上游戏中依然存在一定的分支和选择。 ——故事的复杂度不够 因为只有若干BE和两个HE，所以本作被诟病为不够复杂。传统意义上文字冒险游戏强调选择的意义和多结局，可是这并不能作为衡量一款游戏的质量标准。鉴于针对于移动端的设计以及不断拆分对话选项的游戏特点，如果有变化较大的多结局可能会带来较大工作量。同时这种多结局本身不一定能为本身轻量级的游戏提供很大的价值。最后，这款游戏的价格本来也就1美元，指望这款游戏有着太丰富和深入的内容都有些不切实际。 ——玩家的选择有限 游戏中有很多选项都会体现制作者的倾向以及主线走向。某些选项即便选择了某些分支后游戏会继续呈现相似的选择一遍让玩家回归主线。某种意义而言，这个游戏最终会选什么都一样（除了死掉），一些看似能有完全不同剧情的展开分叉点并没有被充分利用。与此同时...