曾经有个朋友问我，从Web设计到移动产品设计你感觉最大的差异点是什么？我觉得，最大的差异点在于用户使用场景的变化，场景的变化引发了交互方式巨大的变化，从而也使得信息呈现方式有所不同，再加上硬件设备的差异，最终使得2者千差万别了。所以，移动产品设计之设计应该首先从用户的使用场景出发，同时考虑用户的硬件设备差异，综合以上2点去帮助用户完成某个任务。

当然，从生态系统的角度而言，移动生态系统也是迥异与互联网生态圈的。移动生态系统可想象成拥有许多层的系统，每一层都依赖于其他层，他们相互依存构成了无缝的端到端的体验。

运营商在最底层，他们是移动生态系统正常运作的基础，他们负责基础设施建设并维护与用户的关系；运营商运营着无线网络，而网络能力同时也受制于设备与与天线的类型；而由于不同设备对工业标准解释的不同直接早就了移动生态系统最大的挑战，移动设备碎片化；软件与服务要在设备上运行就需要有平台，移动平台主要分为授权平台、专有平台、开源平台，其中我们熟知的有Java ME、iphone、Balckberry、android等；移动平台通常是与他所运行的操作系统绑定在一起的，比如symbain、Windows Mobile、ios、android；而开发者通常能够访问到的就是这些平台的应用程序框架并以不同的语言来开发应用程序。

在移动产品设计的过程中我们也会经常有意无意的涉及到生态系统的某个层面，而哪怕用户只想在移动端做极其简单的事情比如“访问我的博客”，都必须通过这些层，所以，这导致整个的移动环境十分复杂，整个移动产品设计需要具备的能力与素质也相对更甚。

移动产品设计之使用场景的变化

（图片来源：Tapworthy）

没有了舒服的人体工程学座椅，只有拥挤的车厢或者顶着烈日的街头；没有了灵活的鼠标和舒服的键盘，只有晃动的屏幕和方寸间的按钮；你不再是一边放着歌一边刷着网页，而是希望能够迅速的找到你想去的那个店铺；你也不会成天挂在线上，而是会经常担心这个月的流量是不是又超标了……

这种场景的变化呈现给我们的是用户在移动设备上不断的碎片时间的消耗，用户越来越没有耐心。这看起来挺糟糕的，可实际上也是好事，这种使用场景的变化会迫使你放弃做类似Web端大而全的产品设计的想法。相反的，你会聚焦去解决用户在某一个碎片时间段里的需求。这种更聚焦的“单核思维”需要贯穿与整个移动产品设计中（详见：更多的限制，更简单的设计）。

移动产品设计之设备的变化

你的用户会使用什么样的设备来访问你的应用？这个问题是每个设计师在设计最初需要思考的。你的用户所使用的设备需要从多个维度去考虑，如操作系统、使用的网络环境、设备的分辨率等，这些信息都必须被综合起来考虑，最终运用到产品设计中去。对没错，这就是移动产品设计中臭名昭著但又很好玩的“适配”。2个同时使用android手机的人在使用同样一个应用程序的时候可能体验是天堂与地狱的差别，而即使同样都使用iphone但是在不同的网络环境下体验也不一样。这些，都需要去考虑…..

当然，这里有另外一个问题我觉得可以探讨一下，那就是不同平台直接的设计借鉴与移植。我的感觉是ios与android完全可以按照同样的一套架构去设计，只是在具体的交互方式上按照不同平台的特性去做就OK。比如同样是删除在ios上是左右滑动在android上是长按。

另外，这种硬件设备的变化也是移动产品设计与Web产品设计一个很大的差异。在移动产品设计上，一定要充分利用设备本身去完成设计。相对Web产品而言，移动设备自身提供了很多硬件能力，比如光感、磁阻、陀螺仪、….对这些能力的运用是移动产品设计的起点（详见：移动产品设计之硬件能力）。

移动产品设计之交互方式的变化

整个移动产品的的交互过程可以概括为，用户触发某个任务跟客户端发生交互，客户端将该任务反馈给服务端，服务端向后端请求数据并做数据拼接同时反馈结果给客户端，客户端将最终结果展现给用户。当然，某些复杂的任务实际上需要客户端向服务端并发数次的请求。

考虑与服务器端的交互并不是移动产品设计所独有的，但是却是移动产品设计过程中最需要设计师去“设计”的交互。因为这关乎3个事情，对用户流量的消耗和用户操作的流畅性，同时也是对客户端性能的一个考验。 这是我认为目前移动产品设计的用户体验最重要最根本的地方，保证客户端性能的稳定性，用户可以在低网速条件下顺畅的操作，同时尽可能的帮助用户节省流量，而UI层面的体验问题反倒是其次的。twitter和foursquare不论是在ios和android甚至symbain上都没有花哨的界面，但是他们仍然是我心目中当之无愧的最优秀应用。

同时，从键盘机到触屏机再到多点触控甚至于目前的语音助理，我们发现移动端的人机交互方式在不断的演进。于此同时我们也发现，越是高端的移动设备用户的“惰性”反而越强，用户期望能够使用更低成本的交互更快速的完成任务，这也是移动产品设计必须要面对同时也是移动产品设计师最能有成就感的地方。

最后，单就手机端产品设计而言，对于移动平台的选择

iphone这2年的势头太猛烈了，加之推广渠道单一产业链相对完整，所以iphone客户端的设计、推广都很容易见效且效果巨大；android太过开放，直接结果就是渠道纷繁复杂但无一能处把控之势，所以推广费力且收效甚微，小团队可以在开辟完ios战场并有成效之后果断跟进；symbian？如果可以，迅速放弃吧！WP7势头可观，但目前不太适合小队伍入场，大团队可先做储备。

在Web端做表单设计设计师考虑更多的事情是表单的布局方式、表单的提示语言、表单的长度、甚至表单的判定状态。这些东西有无数的人写了无数的文章。但是在手机端，对于表单的设计似乎没见太多的讨论。即使有讨论，设计师们也把目光集中在了如何精简表单上，但是对用户输入的关注却很少。

在移动端产品设计上，一个应用是否足够友好不仅仅取决与其自身的功能对用户是否足够友好，而也应该考虑这个应用对其他应用是否友好，当用户在调用这个应用去完成其他应用的时候他们是否会发生冲突。

得益与android生态的足够“开放”，android上存在着很多输入法应用；受利与android系统的足够“包容”，android上的输入法可为千奇百怪，输入法应用程序的界面高度也百怪千奇，应用开发者们照例要为这些开放买单。于是，设计师们在做需要调出输入法进行相关表单操作的页面的时候又多了一项课题——如何不让提交按钮和输入表单被软键盘遮挡……

以登录/注册表单为例，从Google自身开始，这个问题就存在，不管是其自带的输入法软键盘还是第三方输入法软键盘。一般来讲，用户的操作流是：找到输入框——点击弹出软键盘——输入——点击下一个输入框——输入——寻找按钮提交——没找到，于是搜索屏幕——哦，在屏幕的最右下角——点击完成，把软键盘放下去——点击按钮提交。

这个流程中，很多小白用户直接迷失掉，很多老用户也很郁闷的每次长途奔袭一次去把软键盘关掉…..

那解决方式呢？

1、将提交按钮挪到右上角。这样虽然不是很符合用户的视线流，但是相比长途奔袭到页面右下角的话稍有改善

2、将提交按钮设置成固定“悬浮”与软键盘上方，这样当用户填写完表单之后能够最快速的找到提交按钮。但是也会有2个问题，视觉上如何跟软键盘的颜色做区隔，不给用户的输入造成干扰。Twitter在android上的解决方式较为可取，同时Gowalla让整个页面随着软键盘的打开而上滑的做法也不错。

另外，在android上常见的需要输入简单内容的表单可以采取弹窗的方式完成。弹窗的形式相当于在一个新的界面上只有输入框和软键盘了，相对而言可操作区域变大，用户的视觉有所聚焦。不过，这种弹窗方式不太适合常表单的做法，比如android自带的这个Wifi连接表单就杯具了…..

其实，在iphone的应用设计上也会存在这个问题，但是没有android严重。而iphone系统本身也试图教育用户利用软键盘右下角的“Join”按钮及其变种来完成表单提交的，不过，过多的小白用户还是一样迷茫….随着iphone机器的普及，这种用户会越来越多，也许是时间该考虑一下他们了

首先，我理解的交互包括2个层面的交互，单页面的交互和系统层面的交互。单页面的交互是最常见的对交互设计师的定位，比如把一个注册和登录页面做到极致，把一个搜索框体验做到最好；而系统的交互则是各个页面之间的交互，各个页面之间如何更好的联系在一起，目前显见交互设计师谈到这方面的话题了。

按照传统的瀑布模型，需求分析 – 产品设计 – 产品研发 – 功能测试 – 发布与维护 ，在这套流程中下一个节点必须在上一个节点完全搞定才可以开始。所以在大部分的情况下是产品经理先做需求分析，然后开始撰写足够详细的(注意这个程度)产品需求文档，交互设计师根据PRD文档开始做交互设计，完事后交付给视觉设计师做效果，最后交付给技术人员做开发。而在这个过程中，从最开始的需求到最终开发出来的东西往往很难保证其需求传递的准确性，也让交互设计师的生存空间大打折扣。于是，最常出现的情况就是“我明明想要的是齐天大圣，可是最后你却给了我一个孙猴子”。为了避免这样的情况出现，我们尝试将流程做了如下改进：

1、需求分析阶段

产品经理在产品调研及需求分析阶段产出一份调研报告，这个报告需要说明这个项目的项目背景、项目收益、需要满足用户的核心需求点、为了满足用户的这些核心需求，我们需要使用哪些功能模块。在这个过程中，产品经理只需要考虑如何最大程度最优雅的满足用户的需求，完全不需要去考虑技术实现难度。一定切记不要让某些技术思维使你的思维被僵化或者局限了！

在整个需求分析完成一次之后产品经理需要做的一个重要事情就是跟开发工程师确定需求实现的难度，哪些需求是立刻可以被实现的，哪些是需要长时间开发的，哪些时目前技术无法实现的，….。然后对需求做第二次的筛选与分析，同时试图寻找替代方案，目前无法实现的可以暂时存入需求池，排入工程师研发规划中。

2、需求第一次传递

需求分析迭代完成并通过评审之后产品经理需要开始将需求可操作化并做第一次传递。一般包括，需求的优先级排序、如何将这些需求衍化到一个可操作的产品中去、以怎样的形态进行展示等。在这个阶段需要输出2个东西，需求概述和产品架构图。需求概述主要对需求分析阶段得到的经过团队成员统一意见后的做总结，其实是继续准确的描述“解决什么人在什么情况下的什么问题”；而产品架构图则是该阶段最为重要的产出物，他是承载整个产品的根基，包括产品包括哪些模块，各个模块之间的关系如何等。

产品经理将需求概述和产品架构图交付给交互设计师，由交互设计师来完成需求的页面化,包括产品架构下的页面逻辑确定、单页面的交互逻辑确定。打个比方的话就像是产品经理提供给交互设计师一颗颗的珠子，并告诉交互设计师这些珠子的串联规则，而交互设计师需要完成的就是将这些珠子串联起来，以最动人的形式展示给用户。这个过程中，产品经理需要给交互设计师足够的信任，但前提是二者对于产品的核心需求点理解一致，由交互设计师主导完成珠子的串联，产品经理做方向把握。最终，产品经理和交互设计师共同接受原型评审，同时完成产品需求文档并做第二次传递。

在产品设计流程中，相对于其他环节的需求传递，产品经理将需求传递给交互设计师的环节最为重要，交互设计师对需求的理解和把握会直接决定后续需求传递的效果如何。

3、需求的第二、三次传递

经过上面的传递后产品需要满足的核心需求得到认同，产品的框架与产品逻辑都得到确认，在接下来的传递过程中，主要涉及到视觉设计师、开发工程师，问题已经不大，面临的一个核心问题就是排期。这里可以直接采用《用户体验的要素》中提到的方式“不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段的工作”

图片来源：用户体验的要素

另外，由于移动设备的特殊性，移动互联网产品设计较传统的Web设计又有其他差异，交互设计师、视觉设计师提供的效果不似Web设计可以在真机上完全模拟。所以，在移动产品设计中，必须要加入交互设计师、视觉设计师的真机效果确认。

絮叨了半天，其实总结起来就是这么几点：

1、满足什么人在什么情况下的什么需求之过东西，必须在每次传递的过程中被准确的传递，同时整个团队形成统一认知；

2、专业的人做专业的事，交互设计师是整个流程中最至关重要的需求传递环节，最好由产品经理提出初略的产品需求纲要，由交互设计师来完善这个纲要，然后向下传递

3、不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作

4、移动设备产品设计的特殊性导致必须要求各个环节最终效果都在真机上做一次回归

5、交互设计师是一个可大可小的职业，这，完全取决于你自己

先温习一下在axure中什么是组件什么是模块，高手请直接跳过：

组件（控件）是用于设计线框图的用户界面元素。在组件（控件）面板中包含有常用的控件库，如按钮、图片、文本框等。从组件面板中拖动一个控件到线框图区域中，就可以添加一个组件。组件可以从一个线框图中被拷贝(Ctrl+C)，然后粘贴(Ctrl+V)到另外一个线框图中。组件面板工具栏中可以加载已有组件库、创建新组件库、编辑当前组件库、或更新组件库，也可以对组件进行搜索。

模块（Maste）是可以重复使用特殊页面。一些常用模块如页首(Header)、页尾(Footer)与导航(Navigation)。模块可用在页面中或是其他模块中。只要修改模块，在所有引用这个模块的页面中的模块也会相应跟着同步更新。 模块的概念犹如PowerPoint 中母版、Dreamveawer中模板的概念，熟练掌握模块可以大大提高原型设计的效率，并使原型易于管理维护。

组件的复用是axure默认传达的第一个复用原则，axure内置有基本的Web组件和流程图组件。当然，axure还提供了更高级的组件复用——自定义组件库。在Web设计中，为了保持一致性每个系统模块都会有大量的重复设计出现，如按钮样式、链接样式、表单样式、Tab页签样式、翻页样式、图片大小、输入框交互等等等等

Axure的自定义组件可以使用有心人制作的，比如官方提供的基于雅虎风格的Web组件套装和mobile原型设计组件(下载地址)、比如有个牛逼的老外制作的2套Web原型（下载地址）；也可以自己在项目过程中自我总结创建。

在控件面板中点击下拉菜单的“Create library”（创建组件）选项，这时会弹出一个保存对话框让对这个.rplib文件进行命名和保存，Axure会立刻启动另一个执行程序并打开这个刚建好的 .rplib文件。

在新的Axure程序界面中，原本站点地图面板的位置会被组件库面板(Widget Library Pane)所取代。你可以像处理页面一样对组件进行新增、删除、排序。

Axure启动时，如果已经把创建好的自定义组件库(.rplib文件)放在Windows文件夹的―我的文件> My Axure RP Librarie目录中，则该组件库会被自动加载到控件面板中。另外，你也可以手动选择你所指定的 .rplib 文件进行组件库加载。新建立的自定义组件库的操作方式就如同其它的默认组件库一样，以拖放(Drag&Drop)的方式将组件放到画布上进行画面的绘制。

虽然自定义组件和模块都基于组件的组合，但组件与模块的区别在于，组件是针对Axure存在的，在所有基于axure完成的页面中都可以使用该组件；而模块是基于某一具体的axure页面存在的，仅在该axure文件下可以使用，如果打开新的axure文件则该模块不存在了。模块针对某一具体项目以单个axure文件为单位组合复用；组件针对所有axure文件为单位组合复用。

模块的复用常用于在某个产品模块中会重复出现的情况下，如展示商品的列表、未登录的弹层、页面头部、导航、页面底部等等。共同的特点就是，在该产品模块下都需要且表现形式都一样。也就意味着如果要修改就得全部修改，如果出现就要不断的“CTRL+C”在“CTRL+V”，由于这些组件并不是单一的，如果是复制的话很可能复制不全，即使你使用了组合。模块则可以很好的解决这些麻烦。

模块有2种制作方式：在页面中框选住需要转发的组件，右键选择“转化成模块”；在左侧导航部分选择“Add Master”（添加模块）进行模块制作。在实际操作中个人觉得第一种方式应用更多，因为肯定是先在页面中进行了全局设计才知道这些组件是可以转化成模块的，有一个全局的考虑先。

模块有以下3种行为：

• 普通行为（Normal）：模块可以被移动与放置在线框图中的任何地方，对模块所做的修改会在所有模块实例中同时更新。

• 背景行为（Place in Background）：模块应用在线框图中时，会处于线框图的最底层并被锁定。模块实例中所包含控件的位置与在模块中的位置相同，常用于作为模板、布局、底板。

• 自定义控件行为（Custom Widget）： 模块应用在线框图中时，模块实例中的控件与原模块失去关联，模块实例中的控件可以像一般控件一样可以进行编辑，就好像只是进行了复制和粘帖操作。常用于创建具有自定义属性、注释和交互的自定义控件库，例如：具有白色文字的蓝色按钮。

使用一个工具并把它用透，比使用多个工具但每个工具都会使用一点要高效的多。别去追求炫目，追求效率，这是俺在使用工具上的一点小感悟，记录如此。

电子商务网站的主导航设计是整个网站最最最核心的模块之一。导航需要解决的问题就是，告诉用户如何快速准确的到达他想要去的任何地方。

在所有电子商务网站中，Amazon（注意，不是卓越亚马逊）的导航设计向来是所有电子商务网站学习与仰慕的对象。Amazon的导航在经过数次变迁之后被从顶部挪到了左侧，从横向Tab变成了纵向Tab。Amazon的这种Tab页签式导航，相对与卓越亚马逊的标签列表式导航而言缩短了主导航的高度，在第一屏的时候就能把所有商品大类全部暴露出来，降低了用户的寻找成本。因此，这种模式的导航被越来越多的电子商务网站所接受。

大约在1年前，QQ商城改版，借鉴了Amazon的这种导航模式，同时做了创新式的扩展。QQ商城在每个Tab页签里不仅展示了二级类目，同时还展示了品牌，这使得整个主导航从纵向上进一步缩短同时往横向上扩张。
随后而来的京东商城和淘宝商城（扩展有分类推荐与品牌推荐）以及淘宝电器城纷纷相仿并采用了这种扩展式的Tab导航模式。

不过，我觉得这种创新在某些交互细节上有待改进，我们先来看一下QQ商城的主导航截图：QQ商城的这个主导航在Tab页签的标题上显示的形式是“一级分类标题+二级分类推荐”的形式。
从这个表现形式上看，“运动鞋”、“棒球帽”是2个标签，我这么认为是没问题的吧？

我们假设这样的一个场景：你来到QQ商城，很明确的就是想购买“棒球帽”，你肯定是会直接奔去点击“棒球帽”（注意，是点击）。因为这个“棒球帽”长的跟一个标签一模一样，我们之前的Web使用经验告诉我们，标签就意味着是带超链接的，是可以点击的。可是，当你把鼠标移到“棒球帽”这个标签上的时候，你发现，他是个伪娘！
你点击了半天，发现没有反应，你再仔细一看，他引导你打开了整个“运动户外”下的二级分类….这个时候，你的鼠标需要在做一次长途奔袭，去弹出来的弹层里寻找“棒球帽”，当然，你还得小心点别奔袭到界外，不然整个弹层就关闭了，你需要再来一次（图中虚线）。
这个场景里，我们经过几个动作：1、准备点击；2、无数次点击后觉醒；3、鼠标小心翼翼的滑过弹层去寻找；4、点击。
P.s:其实，图中这个例子我们在弹层里也找不到“棒球帽”，因为它被变异成了“运动帽”？

我们再来看京东商城和淘宝电器城（注意，不是淘宝商城）。其实跟QQ商城差不多，只不过样式上做的难看点….当我目标明确的奔着“洗衣机”去的时候，鼠标所到之处弹层出现了一级分类“大家电”下的所有二级类。同时，“洗衣机”、“平板电视”这2个处在Tab页签标题上的推荐二级类被覆盖了。
这个场景里我们经过的动作：1、准备点击；2、发现要点的家伙没了，开始寻找；3、点击

从这个意义上讲，我认为，京东商城和淘宝电器城的这种处理方式要比QQ商城在体验上更好。QQ商城在鼠标Mouse on之后给了我2个道路：点击，拼命的点击、鼠标奔袭到弹层；而京东商城和淘宝商城直接覆盖了之前那2个长的像标签的家伙，我只有一个道路：鼠标奔袭。
有的时候，给用户越少的选择更能让用户集中起来完成目标任务。

OK，案例观摩完毕，分析一下为什么会出现上面的问题？
很简单，我觉得就是没有把一个东西做到极致，随心所欲的使用表现层的东西去覆盖了框架层与结构层的事情。展示在Tab页签标题上的那些（洗衣机、平板电视）其实并不是标签，但是，他们在展现上跟标签一模一样（京东使用了灰色字体，说明他们意识到了这不是标签，但是我觉得还不够）。

解决方案？
请参见Amazon的做法。
把那些长得像标签的家伙砍掉，使之不具备标签的属性，换成文字描述就OK了。

最后，几句题外话：
1）不知道京东商城暴露在每个Tab页签标题栏里的那2个二级分类是怎么来的？我仔细看了一下，似乎是程序直接调用而不是经过人工编辑的？如果是让程序来调用这个黄金地段的内容，那就真太可惜了。
2）京东商城在首页左侧主导航里的一级分类都是可以点击的（如数码手机），但是在全部分类页面却变成了不可点击的，Why？
3）QQ商城暴露在每个Tab页签标题栏里的那2个二级分类似乎是经过编辑的，但是这种标签式的展示让我很挫败，比如我想买个棒球帽，结果找了半天只发现个类似的运动帽….
4）最后， 大熊哥主导的淘宝商城在此次主导航比拼中最终胜出！

那么，什么是最低成本的交互？我的理解，用户需要的时候才出现交互，用户用不到或者不能使用的时候就不出现交互；当用户需要交互的时候如果能二步完成就坚决不搞成三步。用一句通俗的话说就是：看人下菜碟。

在大的层面上，在对产品进行需求分析的时候我们会考虑不同的用户群，他们对一个产品的使用需求和使用方式都是不同的，在这里我们对用户进行了划分。我们把这个思想坚持到交互分析里来，对于不同的用户在不同的使用环境下需要的交互方式也是不一样的。
之前，顺网UED的同学们对用户交互行为的分析提出了“交互表格”的方法：划分2个纬度，页面元素和用户行为。最左边一列是页面可见元素（包括光标）；最上面一行，是用户的行为（尽量按操作流程）。中间交叉的为场 景描述。通过这种枚举的方式可以详尽的列出所有可能存在的交互行为，然后我们对每个交互行为再划分出不同的交互方式。

比如：我们要做一个积分商城的积分兑换交互。经过分析、合并，我们知道可能存在这么几个场景：①用户未登录（注册）；②用户已经登录，但是积分不足；③用户已登录且积分足够。
下面，我们选2个电子商务方面的代表网站（京东商城VS支付宝）来看一看他们怎么处理的：
京东商城的积分商城页面里，不论你是否登录（注册）、积分是否足够，积分兑换详情页的内容永远保持“一致性”。当未登录点击兑换的时候会跳转到登录页面；当登录后积分不足点击兑换的时候会弹出窗口提示积分不足； 当登录且积分足够的时候，会显示兑换成功。
支付宝的积分商城里对上述问题做了改进，我们看到支付宝的设计师对业务逻辑做了足够的分析：先对用户登录行为做判断；把用户所持有的积分放在了所需积分的下面；积分不足的时候给出提示。

那么，这些足够了吗？不，我觉得还应该有改进空间（京东商城的设计完全不具备交互性，不做分析）。对照“看人下菜碟”的说法，我们来看看哪些是可以改进的。
1、如果用户没有登录（注册），用户是否需要去点击“兑换”OR“评论”按钮？答案是否定的。这个时候用户最需要什么交互？是登录！
当然，这里会存在一个用户是否需要注册的行为？我个人认为，在积分商城这个产品场景里，注册是存在几率很小的行为，完全可以放到登录的引导页面里去。（积分兑换的前提是注册用户，且在网站上发生了用户行为产生过积分才能兑换，就算是注册送积分也是需要先完成整个注册过程的 吧）
2、如果用户登录但积分不足，用户最需要什么交互？了解积分还差多少，如何获得更多的积分。其他的交互行为对这类用户来说都是多余的。
3、 如果用户登录且积分足够，用户最需要什么交互？兑换。这个时候用户是否需要“点评”交互？我觉得不需要，还没有兑换使用，怎么点评？“点评”这个交互行为 应该出现在用户兑换之后再次浏览到这个物品的时候。
下面，是我对积分兑换这个交互模块做的改进。
1、如用用户没有登录（注册）：不做用户持有积分判定（当然，也没法判定）；不出现“兑换”按钮，他的位置由登录提示取代。
2、如果用户登录但积分不足：做用户持有积分判定，同时提示积分差额；不出现“兑换”按钮，他的位置由积分不足提示取代，可夹塞广告，如何获取积分。
3、如果用户登录且积分充足：做用户积分判定；出现兑换按钮。

（左：支付宝的积分兑换交互；右：我的修改版本）
当然，这里只是一个简单的交互条件限定，还可能会有更多兑换限制，从而出现更多的交互行为，比如：注册多久的用户对可兑换、实物兑换 的时候填写收货地址，发货时间段（这个很重要！）、可兑换的数量、等等。

对于任何一个Web页面而言，都必须承担着2个功能：顺利的完成本页面的任务、流畅无误的进入下一个任务。对于如何实现这2个功能，我的土方法就是：有的时候我需要强制你专一的完成本页面的任务，不给你回路；如果这个页面上你要完成的任务太多，我可以考虑帮你拆解。
比如，在注册页面除了注册表单什么都不放，什么面包屑导航全部去掉，甚至LOGO也要搞成不可点击的，这些都是为了“强迫”用户完成本页的任务；用户在后台录入产品的时候，可以考虑对产品的属性进行分块，然后把录入页面拆开（当然，你不能无限制的拆分！）….

我个人的感觉是，之所以交互过程被搞的很笼统，大部分原因在于交互设计师很懒。懒的做分析，认为只有流程能走通就OK了，不愿意继续细分；懒的做交互Demo，认为这些给技术说明白就可以了。前几天做某个模块的时候我偷了个小懒，在DEMO里把工商银行写成“工行”，然后在PRD文档里做了详细说明。今天再看测试，好家伙，还是“工行”！搞的我羞愧难当，这个问题的责任完全在设计师本身，设计师懒就不能指望技术勤快！当然，这里还存在一个原型图的制作问题，改日再谈。

PS：为了迎合“微”时代，我以后的博客都会以“本文想表达的意思是….”开头，看完导语如果你有兴趣可继续，如果觉得扯淡可以略过，省的搞到你读着伤脑筋， 我想怎么回复你的评论麻头皮…