“最快乐的人”通过精心收集，向本站投稿了8篇产品之道用规范来封装自己交互设计，下面小编为大家带来整理后的产品之道用规范来封装自己交互设计，希望大家能够受用!
- 目录
篇1：产品之道用规范来封装自己交互设计
工作两个多月了，上周给公司提交了工作报告，统计了最近的工作，大大小小的策划稿出了七、八个，
原本是计划一周写一次工作小结的，但因为目前项目的保密性要求，所以很多东西都没办法写出来。写案例是最有效果的，光写心得缺少实际的情景和内容，所以尽量找一些可以分享的东西出来。
本章写一些规范性的内容，主要思路是，做产品的，要用规范来封装自己。这里说的不仅是设计出来的产品要规范，另一方面更要时时有这方面的意识。
在可用性设计的原则中，有一条很重要的指标就是一致性，同个性质的元素不应该出现二种以上的形态，便于用户识别和体验。
而产品的规范，也是一致性远离，不过目的不一样，产品规范的目的一方面是有效沟通、另一方面是快速完成工作，导出高效、高质量的产物。
最近项目中跟同事配合整理了整个项目中的UI规范，个人觉得一个项目特别是多模块的大项目，一定要在事前理清好这些规范，在开发的过程中，才不会引起混淆及后面需要额外付出人力成本来统一，
规范的类型，在我的第一次学习计划中有提过，包括：
（一）策划文档规范
（二）功能结构、功能清单规范
（三）用户调研模板（调查问卷、访谈问卷等等）、人物角色规范
（四）原型图规范（模板和控件、规则和说明规范）
（五）交互设计规范（UI规范和交互规范，概念设计）
（六）流程图规范
（上面的案例都是上个项目的一些产品，有些地方可能做得不好，大家看看就好，不过过多注重形式）
在我参与的最近两个项目以来，一直在陆续整理着这些方面的相关材料。
有志于做好产品的童靴，建议多花点心思在这些方面。
本文出自：joshes.cn/post/9.html
篇2：产品规范之道交互设计
对规范更深层次认识来自于YUI的启发，这个几乎已经是控件代名词的英文缩写，可能很少有人注意全称The Yahoo! User Interface Library，其实就是整套带有开发模式的界面规范，因此我也喜欢把整理好的各种规范叫做XXX Design Library，
产品规范的应用对象，分为设计师、工程师两类人。对设计师来说主要是“协调”工作，使交付物统一；对工程师来说主要是“配合”工作，使开发效率提高。
1. 规范的时机
我倾向于在概念设计的低保原型之后，也就是说得先有第一批可开发的页面。我反复强调的原因，概念上不管做产品还是平台，核心都是由一个个页面组成的网站，有效规范只针对于最终产出。
很多朋友提到边设计边整理规范，这是对设计工作的总结。我的看法，产品设计与开发是整套系统工程，所以更进一步，应该边开发边整理规范，让规范与开发同步，互相契合更新。也就是说，每次迭代之后，都应该升级规范。
对工程师而言，上手来一份事无巨细的规范，读完要花两天，熟练要花十天，在庖丁解牛的开发过程中，简直就是噩梦。于是还没等走完这个过程，早因想痛打设计师而消极怠工了。这也正是不建议使用现成规范的原因，第一国情不同，第二时机不对。
2. 规范的程度
经常听到种声音“规范对开发工程师的约束力太弱。”我认为并非问题根源，因为规范的目标不是约束。产品规范对工程师的唯一好处就是快，越快越简便完成任务，工程师才越可能认可。打算让工程师把工作重心偏移到界面体验来完全不现实，因为各自的工作职责不同。
注意使用工程师的思维来横向描述产品，尤其在模块和组件角度，更有必要最终细化到代码和字段。工程师不愿意遵守，做规范的人首先应该扪心自问，是否阻碍了别人的工作？作产品设计规范不能只考虑如何设计好，关键是如何配合执行好，更不是完全主动的监督，
规范最大的作用，在于方便分享，减轻沟通压力。规范越翔实，越容易体现专业的大家风范，也就越凸显设计价值，对拿了钱就走人的设计师来说很受用。高瞻远瞩只是看上去很美，不具有可控的操作性，强制执行的后患无穷。
3. 规范的内容
概念文档，固化产品架构和业务大流程。便于设计师快速了解全局结构和流程，同时有助于工程师搭建程序结构，以及数据库逻辑。但是得注意，满脑子函数的工程师们，普遍对信息架构、交互设计不敏感。
页面设计，固化界面布局和表现。用于设计师协作完成原型设计，同时起到指导工程师修改页面的作用，尤其是页面结构、样式定义、信息块标注。忙于功能的工程师们，对界面的仔细程度往往也不如设计师。
模块控件，固化功能落实和操作小交互。既便于设计师新增、修改界面，也便于工程师嵌程序和调整。最好是做成各种精确的Module或者Pattern，做到有据可依有档可查。尤其是对状态描述，能省不少解释的口舌，也便于小范围升级和做版本管理，做到工作流程中的Don’t make engineer think。
4. 规范的执行
规范的监督成本，全部建立在规范本身的有效性之上，也就是说，对产品和团队有足够可控的了解，是提高执行效率的基础，并非设计单方面合理就行。
在项目时间受限制的情况下，工程师解决问题一定有优先级，功能高于界面不仅合理，而且完全应该这么做。我观察到的矛盾，绝大多数都因为产品方提要求的时机不合理所致。
如果没有时间压力，也没有任务压力，工程师仍然不遵守设计规范，那是工作态度问题，应该尝试与工程师团队沟通解决，或者把协调级别再调高。多注意沟通，互相调整工作方式，任何小矛盾和不契合都可能因时间而被放大。多尝试改变自己，这也是种挑战，除非有权利选择同事。
模块化开发中，工程师最怕因为乱引起的麻烦，而不是技术难度，因为难度可以妥协解决。作为设计师，多学习技术并亲自实践，除了能精确把控节奏，所获得的经验也将成倍增长。
来自：ucdchina.com/blog/?p=478
篇3：用什么视角做产品交互设计
昨天在书友会上讨论信息分类和方法，有位朋友问：“大家现在讨论的还是几年前那套web2.0的东西，有没有一些新的东西可以分享？”
我当时确实感觉很诧异，在没有深入理解那位先生想沟通的意图的前提下，针对这个发问我就感慨，信息分类或者说信息学本身是一个知识领域，本身无所谓新旧，tag标签和分类目录本身也是信息组织的一种方式，不是对立关系，也没有优劣之说，以至于千鸟的回答更加直率“tag本身就是很新的东西了。”
更有甚者，我不认为产品设计师要区分web1.0和web2.0的特征和区别，那是媒体宣传的需要“捏造”起来的概念，作为产品设计师，眼睛里的应该是需求而非概念，不管你2.0不2.0，我只看你满足用户什么样的需求，信息如何组织架构的，
或许昨天的讨论(中途有事提前离开了讨论)，应该围绕一些垂直的领域来谈信息分类会更加有效，比如说商品信息，甚至更加细化到某一类商品信息。或者某一种信息属性的领域，探讨如何分类才有意义。以至于直到现在，很多网站在根本不了解信息维度和属性的情况下，因为2.0,因为UGC，所以要用tag标签。
媒体的很多报道都只关于产品的表象，即使是官方的说明，基本不涉及产品的规则以及架构逻辑，用这个视角来探讨产品设计，很难得到有用的结论。
最后分享我的PPT：信息分类和方法
篇4：产品、做产品的人与用产品的人交互设计
故事的起因是一个微博：
@iamsujie：@SharkUI提到，社区运营，运营人员的特质会反过来决定核心用户，比如55bbs的例子，随着那帮女运营从小姑娘变成少妇，几年间，最活跃的版面从服饰、到装修、到婚嫁、到孕育~~~
然后，有不少人跳出来认同了这个现象：
Lena_Zhang：还真是眼睁睁地看着55BBS就这样了，。。还好多死忠用户活跃着呢，真不容易，最早铺软文的阵地。
粒透碗：真的，我智齿发炎的时候会推荐拔牙的帖子。
但也有人说，这其实是核心用户的变化导致的：
ZEAL：也不见得是运营人员在主导变化。要看活跃版面上的活跃用户是不是那帮最早混55BBS的忠实用户，随着这些忠实用户从小姑娘变成少妇，关注的话题自然也在改变。社区，很容易陷入的困境就是新用户的融入问题。一旦新用户不容易融入，随着老用户的淡出，社区自然瓦解衰退。
上面两种观点，其实无所谓对错，产品运营人员与核心用户是通过产品本身互相影响，互为因果的：一方面，产品运营人员的特点会决定产品的方向，从而选择性的服务用户，这批被优待的用户更容易成为核心用户；另一方面，核心用户的特点会变化，也会反过来影响运营人员的方向，从而改变产品。
这倒是衍生出一个值得思考的问题——对“锁定核心用户”的理解，到底是锁定有ABCD特点的人群，还是锁定abcd几群人，于是，我提出了一个命题：
现在的产品都还太短，等生存了5年、的产品越来越多之时，就有个问题了：是保留自己产品的定位（锁定有ABCD特点的人群）而服务另一批用户呢？还是跟着用户长大（锁定abcd几群人）改变产品的定位？或者说，这个选择要考虑哪些因素？
我同意这个观点，产品不成熟的时候，比较容易跟着人（做产品的人与用产品的人）走：
Blueonline：这只是因为55bbs没有自己的核心内容，如果有的话，当运营人员的特质改变以至于不能维持核心内容，就会被自然淘汰或者被核心内容改变，而不是反过来核心内容被运营人员改变，
所以这种情况并不会发生在一些成熟的商业化社区里，比如汽车，财经，旅游，数码等等。
我的观点很简单：成熟的产品应该保持定位，如果发现之前的核心用户已经改变，有能力的话，不妨用另外一个产品来满足，否则，随他们去吧。比较明显的就是某些游戏，多少人上学时玩，工作后不玩，然后一群群新的学生补充进去。
55BBS其实是渐渐的变成了另一个产品，对于不成熟的产品，这也可以看做一种探索产品定位的过程，最终，它会稳定下来。
呃，或者，这是废话，成熟产品的定义之一就是有明确的用户定位？成熟的产品是人喂出来的系统，已经有了自我意志，已经不是产品运营人员或者用户可以改变得了的了。
最后，话题继续延伸，当一个产品成熟以后，到对产品、运营人员的选择有什么考虑：
@SocialBeta：社区运营人员的自身特质对于社区本身的影响是明显且强烈的。因此，对于运营人员的HR管理其实是社会化媒体运营成功的逻辑前提，关键在于运营人员的年龄 段、兴趣点与社区的核心定位之间是否能够在同步成长中产生高度契合。一句话，没有好的社区HR管理，就没有好的社区商业运营。
这也说明，我们只能为“似我者”做好产品（特别nb的人不在讨论之列啊），这也是为什么游戏公司经常招游戏发烧友，无线产品喜欢招随身带三五个手机的人。
那么，提个问题：为什么帮我们审电影的人都是中老年呢？与其说管事儿的不懂这个道理，不如说是我们自作多情了，我们本来就不是核心用户，核心用户也是一帮中老年呢，审电影的是要挑出他们喜欢的，和我们没关系。
以上，是我从一条微博出发，对“产品本身、做产品的人、用产品的人”三者关系的杂乱思考——三者一起成长，从不稳定逐渐明确，哎，废话啊~~~
VN:F [1.2.0_562]
篇5：用面包屑来简化多层的tabs交互设计
一个网站信息结构需要表现给用户看，这样用户才能知道当前是在哪儿，才有可能去猜测某个内容可能会在哪儿，
如何表现网站的信息结构给用户呢？
用导航。
Tabs导航不错！
Tabs导航是一种表现形式，可以很直观的表现出当前所在的栏目和与之同级的其他栏目。
用tabs这种形式来表现导航是个很好的办法，也是很常见的。然而，如果一个网站的信息结构很复杂，层级很多，那么就经常会是tabs套tabs套tabs套tabs…
四层tabs…
我们抽象一下就成了下面这样：
怎么优化过多层的tabs？
最直接的想法当然是收起一些tabs来。
实际上，时时刻刻展示出所有层级的tabs并不必要，是有浪费的，浪费了用户的注意力。
上图的例子中，当我点开第三层tabs中的“歌手”后，我的诉求更多的是看“歌手”下更多的分类，以便我找到某位特定的歌手，这个时候并不会太关注“背景音乐”“我的收藏”“留言板”“相册”…这些tabs项此时成了干扰信息。
仍旧显示出一二三层tabs的价值主要在于告诉用户，当前的“歌手”栏目是在“音乐盒”->“正版音乐库”下的。那么，对于上面那些层tabs，可以只保留有价值的信息—表明当前所在栏目，而不显示与之同级的其他栏目。
去掉一、二、三级tabs中可供访问的tabs后的样子：
再整理一下…
是的，这就成了面包屑导航导航。
面包屑导航是另外一种反应网站信息结构的形式。因为省略掉了与当前栏目同级的其他栏目，所以面包屑导航的信息量小，
电脑资料
将上面演绎的过程总结一下：面包屑导航可以简化多层tabs导航中那些不太重要的层级。
要省略哪层呢？
就象上面说的那样，把当前页面以上以及同级的tabs都简化掉？显然不是，设计如果是这么简单的，那就不要设计师了。
我们来看看yahoo：
进入Autos栏目中，只展示Autos下的tabs，而不再展示与Autos同级的其他栏目。
看Autos的时候并不会经常会想着切换到财经、游戏等其他栏目，那么，简化掉第一级，只显示Autos栏目隶属于Yahoo！下。Autos频道下的两级菜单需要经常不断切换着看，即便当前是“LATEST MODELS”，上一级tabs“Home，New cars…”也依旧保留着，不简化。
再看amazon：
不断寻找商品的过程是不断往下找的过程，目前已经到达“Bikes”了。“Sports & Outdoors › Bikes & Scooters › Bikes & Accessories ›”这些都是当前页面“Bikes”的父级。相比之下，当前，用户更需要在“Bikes”里进一步筛选，而不是退回去选sports&outdoors类的其他产品，所以，“Bikes”下的进一步分类要充分的展示，而之前逐层筛选过的那些父级，统统的面包屑掉。
从上面的两个例子中，我们可以看到：
可以省略，也是需要省略的，是那些当前较少可能去选的、不需要反复切换的…
并非凡是当前页面上一级和平级的tabs都要简化，当然也不是都不简化。
这里说的用面包屑来简化多层tabs，要解决的问题源于网站结构层级太多，解决这个问题最好的方法当然是让信息层级结构本身简化点儿，少几个层级。
来自：www.chouyu.com.cn/?p=324
篇6：怎样让用户来帮助你做产品？交互设计
好的产品设计师要学会“跟大多数人商量，听少数人的意见，自己做决定”，这句话来自百度论语，说的是产品团队内部做决策的一个基本方法，但是我想把他引申一下，到产品外部，到产品的使用者那里，因为你的产品是做给人用的，而不是做给产品者自娱自乐的，所以，“挖掘大多数用户的需求，听少数用户的意见，自己做决定”是一个让用户帮助你做产品的基本方法。因为最近在接触用研的一些工作，也在自己亲自收集竞品用户的反馈，所以对于这方面有一些小心得，希望跟大家分享。
怎么去让用户帮助我们做产品呢？我这里先粗浅介绍一些基本概念：
高端用户：活跃在行业浪尖的弄潮儿
目标用户：产品设计之初拟定的潜在用户
典型用户：非常明确的目标用户
相似用户：同类或类似产品的用户
真实用户：真正在使用产品的用户
先导型用户：比较有前瞻性的用户，他们的需求代表未来的普世需求
尝鲜型用户：喜欢尝试新鲜事物，并无明确需求
核心用户：对产品有较强忠诚度的用户
一、高端用户有时候是先导型用户
有时候我们过于强调不要被高端用户误导，认为高端用户的需求会偏离真实用户的需求，其实高端用户往往是先导型用户（lead user），他们的需求有时候是前瞻性的，可以拿他们的需求去真实用户那里验证，也许可以有不一样的突破点。但是要规避尝鲜型用户，因为他们只是喜欢新鲜玩意，他们有很强的容忍能力，喜欢去尝试各种可能对自己有帮助的东西，却不确定自己需要什么。比如，最近我去某产品论坛围观了一下，发现他们的真实用户提的需求，竟是我之前想象中的高端用户的需求，而且还呼声很高，这也不难相信，硬件设备正在以18个月更新换代一次的速度飞速发展，今天Symbian用户发图可能还有障碍，18个月后说不定千元机发视频直播都没多大问题。
二、产品设计之初就要有目标用户
产品设计之初往往要定义人物角色（Persona），人物角色可以算是从我们的典型用户的抽离出来的，但人物角色一定不是靠想象力来绘制的，而是需要通过跟真实的用户交谈，获知他们的真实喜好、性格等等。而当我们没有明确的典型用户的时候，就要先拟定目标用户，跟据目标用户找一些活人靶子，来进行一下人种学研究（ethnography research）或者用户日志。人种学研究要求和用户呆在一起，观察他们使用同类产品的相关的活动，以及除此之外的一些其他的日常活动，有点像田野研究。而用户日志可以持续一周或者更长，通常让用户每天或者每隔几小时便记录下自己的活动、感受和期望。产品团队常常把自己的需求当做是用户的需求，设计之初就定义了目标用户，并绘制了人物角色可以避免犯这类错误，
三、时刻窥探真实用户和相似用户
产品上线之后，你是可以通过建立一些在线的论坛、圈子、QQ群来收集用户反馈的，并靠一些运营活动、积分换礼等活动积累用户主动参与到项目中来，提出他们的意见或建议，通过这样的用户协作方式，基本上是可以获得非常及时且免费的反馈。而且，别忘了，你的竞争对手也有类似的反馈论坛、群组，不妨以一个卧底用户的身份潜伏进去，看看用户对竞品的反馈如何，有哪些是自己需要借鉴的地方。当然，微时代，一个官方的微博也必不可少，官方微博可以成为你信息发布和收集的渠道，在那里通过关键词时刻关注着微博用户的反馈，并及时回复，答疑解惑，会给你树立非常好的企业形象。
四、从真实用户那里获取改进意见
真实用户是你最大的财富，你可以从他们的使用数据来直观推测他们的使用情况和需求情况，当然，需要你有非常强的数据解读能力。你也可以请真实用户过来做可用性测试，发现产品中的体验问题。不过最好定量的数据分析和定性的用户测试是可以互相验证的，比如数据反馈用户在购买前验证手机号这一步骤流失比率较大，而可用性测试的时候，发现用户在验证手机号的那一步不知道需要点击发送验证码，所以导致流程卡住，无法继续。那么可以知道，这里的设计是有问题的。
五、从核心用户到特约用户
产品一旦对外发布，就要在一个自然的生态系统中经受磨砺，而核心用户的推荐，会让产品形成良性循环。不如从核心用户中找一些特约用户，每次还没有对外发布的内测版都可以给他们进行体验，谦卑的听取他们的意见，鼓励他们在各种场合炫耀自己对该产品的优先使用权。特约用户不能太多，太多就失去荣誉感；而且特约用户要求是产品的潜在目标用户，一定不能是尝鲜型用户。如果你手头还没有几个特约用户，赶紧去招募吧。这也是我在《启示录》上学到的，参见第15章。
六、给用户的需求分类
《InnovationX》这本书里有句话讲得好，“用户的需求大致可以分为功能上的需求和体验上的需求，但是除此之外还可以从其他方面去分析用户的需求：需求在现有的产品中已被满足还是未被满足？需求是由用户清晰地陈述出来的还是隐藏在众多表象和信息的背后？用这些方面可以将需求划归到2乘2的矩阵中”
对于版本升级来说，最重要最紧急的，肯定是优先解决期望内未满足的需求；而对于新产品来说，如果竞争对手没有解决期望内未满足的需求，那么你提供这样的服务，的确是解决了用户的痛点问题，会有比较乐观的上升空间，如果竞争对手有可能很快解决期望内未满足的需求，而你解决期望内未满足的需求却需要不少的时间，那么这样做可能会有些得不偿失，不妨考虑转战期望外未解决的需求，而这个需求却是真真切切的潜在核心需求。
最后，我们的目标是创造有价值的、可行的、可用的产品，希望能站在用户的立场，借助用户的力量，来帮助我们达到这个目标。
篇7：2011交互设计体验日用讲故事的方式来做手机产品交互设计交互设计
2011中国交互设计体验日在北京举行，elya和Alex代表百度MUX出席并主持了“用讲故事的方式来做手机产品交互设计”的工作坊，
A5 交互设计体验日-用讲故事的方式来做手机产品交互设计
下载链接：www.slideshare.net/cyelya/a5-9374817/download
随着移动互联网浪潮滚滚来袭，移动设备交互设计师是时代的弄潮儿。你需要知道怎样为真正的目标用户做设计；需要知道真实用户的使用场景；需要知道怎样让你的产品变得用血有肉；需要知道怎样用讲故事的方式来做产品；需要知道怎样将讲故事的方法贯穿到设计循环中去，本次工作坊也是力求通过一些我们尝试过的方法，跟大家一起展开探讨。
一、手机产品交互设计
十年间，从小屏到大屏，从按键到触摸，从电话到智能终端，移动设备发生了太多的变化。手机已经可以逐渐替代相机、导航仪、游戏机、视频播放器、网络设备，App Store里的25万个应用、65亿次下载量让开发者看到了希望，苹果最牛的地方不在于体验的精良，而在于构建了新的移动生态系统的战略眼光。
1. 移动设备有哪些独特的优势呢？
真正的个媒体时代
永远在线的大众媒体
永远随身的媒体设备
内置收费模块的工具
无限想象力的引爆点
2. 移动设备交互设计有哪些挑战呢？
设备碎片化
平台多样性
适配多种分辨率
考虑多个方向
为拇指而设计
考虑多种环境
3. 人们使用移动互联网的方式有哪些不同？
从舒适的环境到多变的环境
从良好的网络环境到不稳定的网络环境
从充足的电源到悲催的电池
从精准的点击到模糊的点击
从精力集中的到注意力分散的
从复杂开放的到简单私密的
4. 移动交互新规则
保持简单
重视交互方式的差异
了解平台但不要受限于平台
了解目标用户
重视环境的影响
学会讲故事
5. 为什么要用讲故事的方式呢？
做设计本来就是在讲故事，设计的不是交互，而是情感。故事有起承转合，设计也有轻重缓急。用讲故事的方式，可以深入到问题本身去解决问题，有利于激发新的ideas；用讲故事的方式，可以让设计师产生跟用户接近的情景体验，产生同理心；用讲故事的方式，可以帮助设计师更好的讲述设计，传达设计需求。
二、找到真正的目标用户
在不同时期，你需要为不同的用户做设计。在新产品探索阶段，你需要定义目标用户，为目标用户做设计；当产品发布之后，就会有了第一批真实用户，其中有20%的核心用户贡献了大部分内容，还有更多的主流用户可能只是围观却对产品产生着不可替代的影响作用，这时候你要为真实用户做设计；在用户基础及产品形态都比较稳定了之后，开始探寻潜在用户，为了市场扩张，开始为潜在用户做设计。
至于定义目标用户，则有非常多的方法。你需要先有一些人口统计学的资料，然后至少访问30个可能的目标用户，拿到一些定性的结论之后，再通过问卷的形式去验证一下，得到一些定量的数据结论。这时候，你才算是有了一个清晰的目标用户。
挖掘潜在核心需求的时候，是可以先去先导型用户那里深入沟通，然后去目标用户那里求证的。因为目标用户可能比较迟钝，对自己的需求没有那么清晰的认知，而先导型用户则有明确的意愿，知道自己想要的是什么。但是一定要注意区分先导型户和尝鲜型用户，尝鲜型用户不是需求导向的，而是好玩导向的，他们容忍能力超强，也不太清楚自己喜欢某个功能是因为自己有需求还是纯粹是觉得酷，
目标用户可以绘制人物角色，而人物角色不等于真实用户，有了真实用户可以绘制用户画像，然后调整策略。
1. 设计工具：人物角色
三、还原真实的使用场景
拿到一个功能需求的时候，首先搞清楚给谁去用，其次考虑的就是在什么场景下去使用，否则你的设计就会变成功能堆砌、页面调整逻辑、点击和响应，对于设计师来说，失去了场景还原能力，失去了跟用户的同理心，你的立足点就动摇了，所以一定要先想清楚，给什么人？在什么场景下？什么目的？怎么去做？
举个例子：
1. 设计工具2：使用场景
2. 什么人？
用户是谁？你对用户了解多少？你能预言出用户的那些行为？
3. 什么场景？
用户身在何处？是公共场所，还是私人领域？是室内还是室外？白天还是夜晚？
用户何时使用？是在拥有充裕时间的家里，还是只能忙中偷闲的工作中？等车的空暇时间？
用户怎样使用移动设备？拿在手里还是放在口袋？打开还是折叠？竖着还是横着？
4. 用户为什么使用？
用户为什么使用你的应用程序？
用户在当前条件下，能够从内容或服务中获得什么价值？
5. 怎么做？
达到目的可能采取的手段有哪些？
可能需要的行动步骤有哪些？
可能遭遇的特殊情况有哪些？
可能产生的同步/异步交互有哪些？
四、讲好一个生动的故事
1. 设计工具3：网站路径图
你需要可以在上面绘图的东西，越大越好；大量不同颜色的记号笔和小贴纸；一些Persona，如果有照片就更好了。
先画一个大圈，代表交互系统；再画一些用户，就是与系统交互的所有用户；原则上最重要的用户放在左上角，采用完全不同的方式使用英语的用户放在右边。
参考场景文档，选择一个主流场景，从最主要的用户开始走流程从主页开始，考虑所有可能发生的事情，每件事情画个圈考虑其他用户，可能跟已有事件产生的交叉点。
2. 一个例子：陌生人交友
3. 设计工具4：故事版
4. 故事版有什么作用呢？
体验问题情景
寻找解决方案
发现新的问题
多方沟通工具
5. 故事版的四个要素？
角色：目标用户、人物角色
功能：对于故事板来说，可以是确定的内容，也可以是不确定的功能
环境：环境的概念包括物理环境和社会环境。具体到故事板中，环境的概念就成为了一种情景。情景包括时间、地点、周围的情况等一系列的内容
事件：是具体的人和系统的交互行为，它将人、物和环境结合起来，构成了整个故事的内容
五、用故事串起设计循环
做设计的过程，就是一个不断讲故事的过程。在前期找到人物角色，还原使用场景，讲清楚一个故事之后，还要把故事拆分成任务，按任务优先级去绘制交互原型。然后拿着低保真原型去找用户测试，最好可以在真实环境中去测试。等到高保真DEMO出来之后，还是要迭代测试，还原真实的故事，然后把问题反馈到讲故事的环境，再去修改情节和场景，使故事不断丰满。
篇8：知己知彼――清楚自己的产品 去做竞品分析交互设计
正所谓“知己知彼，百战不殆”，做产品也是如此。
知己，意味着知道自己产品的定位是什么，核心竞争力在哪里，产品定义是什么等等。
知彼，简单的说就是清楚竞争对手的情况。知彼是建立在知己的前提下：清楚自己的产品，才会知道对应的竞品有哪些。但是并不是说知己，就一定会知彼。这就免不了要深入的做竞品分析，才能更懂对方。
不客气的说，现在很多产品经理，包括交互设计师，既不知己，也不知彼。很多人还停留在先盲目照抄竞品，再增加其他功能的思维框框里。
交互设计师也是如此，立场不坚定就很容易被PM牵着走。最近我做了一个内容型页面，接到需求文档后（更准确的说应该是一个文摘集锦），然后就开始排版了。但是越做越觉得不靠谱，在一些关键点上和PM有分歧，但又总讨论不出来结果。最后我恍然大悟：是因为前期漏掉了很多必要的工作。
首先，应该明确这个页面的目的是什么：这个页面可以为用户创造什么样的价值？第二，我们如何为用户创造价值？是通过我们的臆想去教育用户？还是向用户展示他可能关心的内容？如果选择后者的话如何确定哪些内容是他关心的？第三，根据用户可能关心的内容，我们应该提供哪些内容模块？第四，这些模块的优先级是什么？这些都确定好了，才开始做排版布局的工作，
为什么出现这样的问题？因为这个内容丰富的页面，PM只给了半天的时间，在这种环境压力下，交互设计师很容易迷失自己，把专业的流程统统抛到脑后，而只想着如何按时完成任务。
由这个页面，我的思维延伸到了整个产品上：我们做这个产品的时候知道自己的核心竞争力是什么吗？知道如何甩开竞争对手吗?我们了解会有哪些人使用我们的产品且这些人的期望是怎样的？他们会如何使用我们的产品？我们的产品能满足他们的需求吗？对于这样一个业务复杂的专业产品，我们认真的研究过竞品吗?我们真正了解这个行业的特性以及用户的需求吗？
一切都是否定的。只是简单看看几个竞品，就凭借经验和感觉去勾画一个产品是远远不够的。越到后期，就越觉得心里没底。在设计的过程中，总是会不经意的发现新的设计质量不错的竞品，让我备感压力。也许靠着公司的牌子和广告资源，做的再烂也有人埋单。但这毕竟是短期的，不仅这个产品救不活，就连公司的品牌形象都会逐渐被透支。
产品设计已逐渐接近尾声，而我作为一个交互设计师，却说不出几个竞品的名称，也不了解竞品的情况，真是非常惭愧。我回想这一个多月，到底都做了些什么？为什么要对时间妥协？为什么不能以专业的素养来向产品方建议正确的流程呢？大家其实都非常想把事情做好，但是往往被眼前的限制冲昏了头脑。
亡羊补牢，未为晚也！明天，开始和PM商谈竞品分析事宜！
★ 用恃才傲物来造句
★ 用孑然一身来造句
★ 用孤芳自赏来造句
★ 用一边一边来造句
★ 怎么用呵责来造句
产品之道用规范来封装自己交互设计（精选8篇）
