标题这句话，正着读或者倒着念，都可以。

用户接触到一个产品，往往是这样的一个路径，

点击图标/输入网址，首先感受到的是产品的色彩，他是白色纯净的还是橘红热闹的。这是视觉设计师的功劳，是用户最先感知的部分；

接着看到的是排列好的界面，这里是促销展示，那里是商品排列，那里是操作入口，那里是一段文案提示。这是界面设计师的功劳，是用户其次感知的部分；

再接着点击了一个商品图片或者操作入口，进入到商品详情页面，或者打开了输入表单，键盘被弹起来。这是交互设计师的功劳，是用户接着感知的部分；

再继续，用户不断的被引导操作，完成一项项任务，这是常见意义上产品经理的功劳。

这一切构成了我们常见意义上的产品。场景设计（用户任务）和功能设计、交互设计、界面设计、视觉设计。

上面是用户对产品的感知路径，而实际上，产品的设计路径是完全相反的。

首先，要做场景的设计。观察与分析用户的需求，拆分出用户任务，进一步设计相应的功能来满足用户的需求/任务。

其次，针对任务的拆分来设计流程引导，第一步做什么，第二步做什么，完成不同的任务。

第三，细分到每一步中，用怎样的界面来表达，要表达哪些元素，这些元素如何展示出来。

第四，对每个界面的每个元素用有品位的视觉做表达。

这是一个非常有趣的值得思考的现象。用户是个感性的动物，他对产品的第一印象，来自于感性的色彩、界面、文字；而产品则是个理性的产物，构成产品的核心是理性的分析与模式的构建。

设计的看上去很好看的产品，往往并不能走很远，因为架构与模式不对；架构与模式很好的产品，又往往设计的并不好看。被流传的产品，是两者相结合的产物。

于是，这必须要求，理性的产品需要具备感性的审美，感性的设计师需要具备理性的思维。

换句话说，不管是产品还是设计师都需要有讲故事的能力，能够清晰明确的在脑海中有场景感。

总结起来看，

1、产品设计的过程就是一个讲故事的过程。

先要讲好一个故事，然后把这个故事用计算机语言表达出来。

比如，我们要向朋友推荐一个司机的时候，我会说，这个司机长的很帅、开车技术很好、车也很好、很多人都坐过他的车。

我们用语言表达的时候，并不难，因为我们就是讲着话长大的。语言的传播是多维度的，用词、语调，都能很好的帮助我们表达想法。

然而，计算机语言中的故事表达就难很多，尤其是在仅用图形和色彩，也就是界面来做表达的时候。用户所见的界面是有限的，表达的内容是要很多的，你首先需要对内容做排序，其次要做排列，然后再思考用什么形式表达，这确实是一件很有挑战的事情。

这是产品设计最难的地方。这个思维，产品需要具备，设计师更需要具备。不具备这个思维的设计师永远都做不出有灵性的界面。

2、交互设计与界面设计是在用逻辑表达来讲一个故事，而视觉设计则是在用视觉语言解决逻辑问题。

不论是交互的设计、界面的设计、视觉的设计，都是要解决问题，不是为了美，美是品位的一种体现，解决问题才是重点。

3、大多数时候，解决问题与品位被割裂了。

在大多数设计师的心里与行动中，解决问题是产品经理的事情，我要做的是有品位。而在大多数产品经理的心里与心动中，品位是设计师的事情，我要做的是解决问题。

这是扭曲的根源，是狭隘的分工导致的恶果。

4、更多的时候，产品与设计师是被自己禁锢了的。

从用户场景出发，先思考如何最优的满足用户需求，然后再思考技术如何实现，而不是倒过来。

这句话，肯定会有很多人会觉得不对。因为，我思考了一个方案，技术不能实现，那不是白扯吗，你还催着我上线呢？

但是，我要说的是，这是一种正确的思维方式。在开始思考的时候，不能禁锢自己，人脑被禁锢的久了，就会越来越狭隘。永远，不要禁锢自己的想象力。

5、同样的道理，市场要有产品的思维，运营要有市场的想法

这是一句废话。

2011年11月左右，FB发布了新的ios和android客户端，其中一个重要的变化就是导航模式的变化，推出了新的抽屉式的导航，同时强化了对Timeline的展示。

FB推出这种新的导航模式不久，Gmail的ios版本同样采用了这种导航模式，再之后path 2.0版本也采用了这种抽屉式导航并将其演变到极致。至此，这种抽屉式的导航模式迅速窜红与ios产品设计中。

我在2012年7月曾经对抽屉式导航做了总结，在「说说抽屉式导航」中我认为，大部分APP会使用抽屉式导航，核心原因是为了突出核心功能，将其他的功能隐藏掉。

现在来看，这个说法并不完全对。2011年到2012年，是中小屏幕移动设备占绝对主导的时代，中小屏幕，单手完全可以操作，不存在太多的操作盲区。同时，中心屏幕使得可以展示的内容有限，所以，抽屉式导航是最合适的做法。将导航收缩到一个入口，放在左上角最显眼的位置，用户操作也没有困难，其他核心的内容直接显示出来。

2012年之后，大屏幕成为移动设备的一个新趋势。一方面手机从一个单一的工具，逐渐演变成人们生活的一部分，不可或缺的一部分，用户在手机上处理的事务越多，使用的时间越长；另一方面，屏幕尺寸和内容消费效率及阅读舒适度极为相关。所以慢慢的，手持舒适度和携带便利在整个产品设计众多决策里面的重要排序便没有那么高。

所以，我们看到4寸屏、5寸屏越来越成为主流，尤其是iPhone6和iPhone6 plus的推出，大屏幕手机时代就这么不可阻挡的来了。有一篇老外的分析，点击这里查看。

手机屏幕越来越大，带来了哪些问题呢？

最简单直接的就是，内容显示变多了，但是，单手操作变难了。曾经有报告显示，49%的用户是单手操作手机的，现在，是改变单手操作的设计的时候了。

这张图，非常直观明了的告诉了我们，为什么抽屉式导航衰退了。因为，一个需要被经常操作的入口，现在，处在了操作盲区。

那么，伴随着抽屉式导航的衰退，在大屏幕时代，该如何去设计呢？这是每个产品设计师面临的一个新的思考。我有几点感受，可以分享出来

1、手势操作将会变的更加重要。

Android上有单独的back键，而iOS的返回一直依靠左上角的导航。大屏幕下，iOS的左上角点击返回将非常低效，在屏幕边缘右滑返回是最高效的模式。另外，针对信息流类产品，点击顶部迅速返回到最开始的信息的模式，也是一种高效的交互。阅读类产品可以考虑使用双击关闭这类的手势交互。

相应的，一个产品统一使用上滑、下滑来进行导航的产品将会更多。

2、底部Tab模式导航重新受追捧

实际上，底部Tab模式导航在iOS和Android上一直是「最安全」的一种导航模式，他不怎么出彩，但是绝对不会犯错。在大屏幕时代，底部Tab模式的导航更能适应，也更好设计。

3、浮动导航入口有可能出彩

在path的3.0版本，那个浮动在左下角的「+」号曾经一度流行。在大屏幕时代，这种浮动的入口很有可能出现优秀的设计。

4、将提交类操作按钮，放在弹出的键盘的顶部

这个模式，在Android中较为常见，但是同样存在不同屏幕的适配问题，需要仔细考虑。

5、语音交互，谨慎看好

语音交互，始终感觉没有一个好的使用场景。

按照我的理解，场景、任务、用户可以称之为设计的三要素，每一个设计实际上都是试图去帮助用户在某个场景下完成某个任务的。同样的设计遇到不一样的场景就会有不一样的方式，从Web设计到移动产品设计亦然。

曾经有个朋友问我，从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篇文章大致来表述对于两者之间关系的我的一些观点，在“我理解的产品经理”中我认为产品经理需要同时关注产品设计、工程技术、产品运营3个方面；在“基于axure的PRD写作思考”中我简述了在没有交互设计师辅助的情况下产品经理如何做一个更像样的“破画图”的。今天，结合最近的一些项目经验，总结一下产品经理如何更好的跟交互设计师合作。

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

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

1、需求分析阶段

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

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

2、需求第一次传递

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

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

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

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

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

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

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

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

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

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

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

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

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

呃，这是一篇半扯淡式的回忆录，数一下咱曾经与现在使用过的画原型的工具。那篇“非炮灰不原型”的草稿还躺在草稿箱里，惭愧….

最开始，用Word以打表格的方式画；
更多小技巧可参考Junchen的这篇用Word画原型。

后来，试试Viso；

更多小技巧参考山寨产品经理小宝的这篇用Viso制作线框图。

然后，便于演示和简单效果的话可以用PPT；

使用PPT制作原型就是对交互动作进行分解，然后逐帧进行播放，这个比较适合进行演示，这里不在做图。

P.S：实际上我最近开始对Axure的交互动作有些许质疑，特别是使用很多动态面板的时候。这样许多交互步骤表面上被隐藏了，如果技术们不知道去 点，其他同事默认为线框图就是平面化的，那么，这些花费了很多经历做出来的交互动作就等于Zero！有的时候我常常会把一个交互动作进行分解，使用 Axure做出不同的状态，然后注明第一步的时候、第二步的时候…

其实，Excel也可以的；

（这张图来自Yahoo中国）

进化一下，用Axure；

关于Axure，写的太多了，不再说。

偶尔新鲜点，玩玩Balsamiq Mockups等等（意味着以他为代表的一系列）…

关于这一系列的也太多，作罢，看高人们的介绍吧。

最后，最方便与快捷的方式其实是，纸！

（该原型由elya同学提供）

甚至是，餐巾纸！

于是，现在的方式是，先在纸上做出框架图和交互草图，然后，使用Web工具做出来。草图是为了整理思路，而Web原型是为了传递与交流。

P.S：当然还有N多种可以画线框图的方式，如photoshop、Dreamweaver、illustrator等等等等。工具是死的，人是活 的，工具是多样化的，没有最好的，只有最适合你的。如果纠结与工具，那人就变成了死的…

让我们再来重复一下那句关于交互与用户体验之间的关系的论断： 优秀的交互设计应该是用最低成本的交互，最愉悦的满足用户的需求。

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

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

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

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

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

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

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

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