当前位置：首页 > 范文大全 > 实用文>PM与工程师交互设计

PM与工程师交互设计

2025-01-28 10:01:17 收藏本文下载本文

“soul_kiss”通过精心收集，向本站投稿了10篇PM与工程师交互设计，下面是小编为大家带来的PM与工程师交互设计，希望大家能够喜欢!

PM与工程师交互设计

篇1：PM与工程师交互设计

过节前看到一篇文章，讲产品项目就应该由工程师来主导，但国内让PM去驱动项目，搞得乱七八糟，很恼火，怎么可能做出一款好产品来呢？

很显然，写这篇文章的是一位愤怒的工程师，Angry Engineer！我跟他至少有两点共鸣：

1、国内的PM确实常常折腾工程师，甚至不乏“把工程师当工具对待”的情况，

2、如果工程师有开阔的产品视野与全面的设计素养，知行合一，由工程师来驱动项目是一个完美的选择。

可惜由于教育环境的问题，国内通才太少。一个优秀的工程师，同时又是一个优秀的PM，凤毛麟角，只能人任其长，各自做自己拿手的活儿。这时候更擅长需求分析与产品设计的PM来驱动项目，也是不得已的选择。

说来惭愧。需求不靠谱，或是来来回回修改，折腾工程师的事儿我也做过不少，直到最近一年多才算是大有好转。我应该忏悔……虽然能做好PM的工程师极少，靠谱的PM其实也不算多，最后大家都得写周报对不对？

在产品行业远远不够成熟的现阶段，痛苦的来回折腾难以避免。但最起码，PM应该把工程师作为伙伴而不是工具，想法设法地站到一条战壕里去，争取他们的理解。因此抛开难以鉴定的需求的对错，仅仅从协作流程的改进上，我积累了以下的经验。

首先要得到工程师对整个项目的认同。每个月都有一场一小时的部门月会，对着PPT，我来讲下个月乃至下个阶段，我们的任务规划是什么，目标设置又是什么，详细解释制定规划与目标的原因，近景与远景分析，为咩做这件事情为咩这样去设计等等。希望工程师能认可他即将做的事情是有价值的，值得为之而努力的。为接下来PM与工程师的沟通做好铺垫。

月会上还有一个环节，详细分析本月发生的所有数据，尤其是最近发布的新功能的数据。这个环节也是为工程师准备的，使他们了解自己的工作能产生多少实际效果。

至于月会上送出的新功能礼品（以前讲过许多次），最开始是为工程师专设的彩蛋，再后来才将PM与运营包括了进来。我得承认自己对工程师偏心眼，因为有信心能激励PM与运营，却出于沟通深度不足，需要借助更多的手段来激励工程师投入项目。

项目任务分两种，大版本与小模块。对于大版本，在基本框架定下来之后，PM提前向工程师讲解，听取技术视角对设计方向的建议。整个设计过程中还会反复讨论三五次，为技术上的合理性征求意见。小模块则在策划案基本敲定之后，与工程师共同确认一次，视觉稿出来后再通报一次。（所以PM与工程师坐得近是很有必要的）

我曾经在部门月会上公开承诺说，任何一个需求，只要工程师认为是不合理的，都可以停下来不做。直到PM能说服工程师为止。如果死活谈不下来，才由我和技术经理出面来协调。强硬要求服从的情况在我这里基本上没有，被工程师说服倒是时有发生，按工程师提出的意见来改方案。我也常常跟PM讲，小分歧你们都听工程师的，没有必要坚持己见。你让他爽一点，开发速度就快一点，大家都获益。再说你多听听技术伙伴的意见有什么不好呢？帮助你转换思考的角度，共同找到提高开发效率的方法。

最后方案定下来了，PM说OK，工程师也觉得方向大致没错，细节基本合理；进度方面则由工程师进行评估。PM觉得时间太长接受不了，再找到我和技术经理一起商量，看是分阶段砍需求呢，还是加把力加点班。除了极少数紧急修复任务外，不会由PM单方面确定开发时间安排。包括一系列任务的优先级安排，也由PM先提草案，工程师根据开发情况来调整顺序，再共同确认。

在PM提出需求的整个流程里，始终在进行不断的协商，保证工程师对任务是理解并且接受的，不会出现抗拒，或者是麻木的心态。如果遇到突发性的需求变更，更加会向工程师反复解释，请求谅解，因为浪费了他们的工作成果而心存歉意。为此而花费的时间对比更高的开发效率，稳赚不赔。虽说具体协作时还有一些不到位的地方，但态度总归是好的，基本的效果也是有的。

当然，这套流程的实施得具备两个前提。第一是有稳定的团队，如果变成提单协作，这个月一起干下个月分道扬镳，那就不可能实现共同的项目归属感。第二是工程师的个人素质基本靠谱，沟通顺畅；尤其是技术经理可以服众，协调好分歧而不护短。比如说一个功能能不能做，至少开发多久，我和PM都搞不掂，主要靠技术经理来做最终判断；如果出现开发过程中的失误，或是不按照约定好的方案进行开发，则由技术经理进行处罚。我对开发组更多作行政管理，全靠这位技术核心伙伴来负责业务管理，他也会更深入地参与到产品的结构设计，任务规划里来。

这样做，也就撇开了把工程师当工具对待的嫌疑，

我觉得把任何同事当工具都挺可耻。怎样才算是伙伴呢？比如交流必要的信息，理解对方；比如能站在对方立场去换位思考；比如多一点点鼓励与帮助。

换个角度看，我这边曾经出现过由工程师来提出大致构思，PM认可并负责细节设计，再由这位工程师来实现的情况。结果皆大欢喜。我后来多次在月会或别的场合征求工程师的创意，换一换视角，引入新鲜的想法与灵感。即便想法不一致，也会非常温和地解释反对原因，绝不可能一口否决。唯恐工程师们默不出声闷头干活——听不到技术伙伴的意见是多大的损失啊。

以上来自：/uidesign/0503/91582.html

也谈：PM与工程师

来自：/uidesign/20110503/91582.html

看了纯银写的《PM与工程师》，也参加了PMCAFF深圳3月份的活动聚会，就这个话题聊聊自己的感想。

PM与工程师最容易产生冲突的地方在于需求和进度：产品需求变更折磨工程师、项目进度延迟、产品质量不过关，影响到产品的上线和运营。

大体上，可以通过下面几点来避免：

(1) 认同，归属感

在产品规划阶段，跟工程师多聊聊，聊一聊项目背景、市场机会、我们做这个产品对公司有什么好处、以及很关键的一点是产品的成败对我们切身利益的影响。建议工程师的认同感，归属感，并唤起他们的主人翁意识。

归属感这点：在抄送邮件时，我也会主动提起某某工程师的名字，对他们的配合表示感谢，对他们的工作表示赞同。

（2）产品评审，可行性分析

快速产出一个产品DEMO，召集工程师、运营人员等相关人员评审，简单再讲讲产品背景，我们要做的是什么；这个版本是拿来投石问路的，一方面是可行性分析，另一方面集思广益。

在这个评审会议上，产品的主要方向和功能点都能确定下来。

（3）需求传达清楚

产品设计文档描述清楚，产品逻辑合理，产品定位清晰。

（4）版本规划、进度安排

功能优先级划分：根据业务需求，制定功能优先级，优先开发主要功能。再根据项目上线要求，安排工作进度，确定几个关键的时间节点；

通常互联网产品都讲求敏捷，小版本快速迭代的思路，如果需求比较大，制定版本规划，1期实现核心功能和主要功能，2期实现次要功能和附加功能。

砍需求：这个是最容易出现的情况，对于一些技术上比较难实现的有些工程师往往会跟你讨价还价；对于商业价值不大的需求，往往也会被领导砍掉。通常，评审之前对于哪些需求会被砍，是心里有数的。

（5）开发协调、进度把控

理论上，在产品评审会议上有进行过需求解释，但是实际上在开发过程中也会产生种种疑惑（有的是需求没理解到位，有的是产品设计不完整），在开发过程中，PM要保持跟进，尽量不产生偏差。

进度把控：开发中通常会有其他任务插入，比如紧急的需求和人员被抽调出等，这个时候要协调好资源

（6）取舍

有舍有得，这个是真谛。开发过程中,一些零碎的小需求，以及用户体验上的小东西，实现上工程师会跟你有争议。通常小范围无关大局的可以从了工程师，但是原则上的东西一定要坚持。

切忌，别跟工程师死磕，也别把工程师逼得太狠了，团队和谐的气氛很重要。

（7）需求明确，尽量少变更

业务层次上的需求变更是没办法的，如果有对工程师工作推到从来的情况，最好多跟工程师沟通好，比如“领导决定的，我也很委屈”，表明自己也受伤害了。

对于功能层面的，PM在做产品规划时要考虑清楚再下手，产品设计过程中，为什么要这样做，为什么不这样做，要有合理的根源；有疑议的地方最好拿出来和大家讨论清楚，或者等需求明确了再下发。

头脑清醒，内心强大，这是最PM追求的境界。而无数次评审会练就强大的内心力量。

（8）技术基础

最好能多去了解一些基本的技术原理，HTML/CSS/PHP数据库。工作中也要多问，虚心地向工程师请教，一般工程师会很乐意为你解答的。

（9）沟通、协调

配合好，积极主动的工程师真的很难得。有产品意识的工程师更是可遇而不可求。和工程师的交谈，最好能站在他人的立场上，用工程师的语言来沟通。

沟通能力、协调能力甚为关键，这两点也不是三言两语就能说清了，这里就先不多说了。

人情练达即产品，路漫漫其修远兮。

篇2：情感与设计交互设计

很多关于设计的观念都不是孤立的理论，广义来看，我们周围的一切事物都是设计的载体，而 Norman的《设计心理学》的英文原名正是The design of everyday thing，在他紧接《设计心理学》之后的著述《情感化设计/Emothinal design》中又提出了另外设计的阶层概念，本能的、行为的和反思的。这三个名词是中文版中的翻译，十分晦涩并且也与原著中的语义有所差异。

这并非一个全新的设计理念，在Norman提出这个理念之前，广告界早已洞悉情感在营销中的重要作用。优秀的产品设计和成功的广告是相似的，都试图将自身与使用者或客户的某种情感联系起来，通过这种方式使用者或客户对于产品形成了独特的理解和联想，以至于形成目标的满意度和忠诚度。

Norman在文中提出了很有趣的问题，当我们看到美丽的产品，但却会因为糟糕的使用体验而感到沮丧，而有时我们又会因为一个产品的独特而忽略它难以操作？是什么使得我们喜欢或者厌恶一个产品？情感又是如何作用于我们对于一个产品的感受？Norman有话说，但在阅读的时候我也慢慢提炼了自己的观点。

首先在于Norman用人脑对信息的加工方式来定义与之对应的形成设计的三种水平，本能的、行为的和反思的，我并不完全认同。对于设计而言，外观设计只是设计过程的一小部分，并不能作为设计的水平的分界线，且本能的设计也不能和行为的以及反思的设计成为阶梯序列。设计的复杂之处在于它不仅仅是为了满足大脑本能的信息处理，而是经验式的。从设计的阶段来解读的话，我更接受用功能的、易用的和情感的来描述设计的不同层次和水平。

任何设计的目的都是为了解决问题，而解决问题是设计的最基本的要求，

如果不满足使用者对于一个产品的定义和要求，那么这个产品要么是失败的，要么是超越的。以Norman在文章开始举例中的那个“不可能的茶壶”，尽管它很难用，但Normal却非常喜爱，因为它“讲述了一个极好的故事”。但这个例子是否也恰好说明了Norman对于产品设计概念定义的瑕疵？因为如Norman所说，虽然那些茶壶基本上不用，但仍然喜欢，因为它们是“雕塑艺术品”。Everyday thing和艺术品的最大区别就在于艺术是无关用途的，他们或许具有意义，但却从不考虑用途。也就是说，如果一个我们每天使用的产品无论如何的招人喜爱，但如果它不能用，那它也是失败的。

这本书的意义不在于人脑的加工模式如何影响使用者对于产品的感受，而在于将情感的价值引入设计领域，设计不仅仅是要卖的产品，设计本身也是营销。

Norman在文中谈到Mihaly Csikszentmihalyi和Eugene Rochberg-Halton的一个有关什么是“特别的物品”的理解，有段话非常好，

“特别的物品结果是那些具有特别回忆或者联想的物品，那些帮助拥有者唤起特别情感的物品。特别的东西都能唤起往事。”

这是一个很重要的概念，“特别的”是满足情感需求的。尽管同样的旅游纪念品能够带给不同的人以不同的回忆和感受，但从更大的范围来看，能够使得一款产品对每一个人都能具有不同的感受的话，只能依赖定制和个性化。这或许阐释了设计的未来方向，设计的作用将不仅仅是满足能用、好用，还要能在用的时候形成独有的体验。用一款IPod满足一个大群体的时代将慢慢成为历史，定制和个性化所形成的无限细分市场也将在未来改变设计的格局。

本文来自：www.tianya8.net//06/blog-post_12.html

篇3：边缘与交互密度交互设计

市面上现有的主流手机操作系统有一些优秀的体验，比如android从顶部下滑出的通知中心，Palm的context menu 从屏幕下部的感应区呼出。Nokia N9 就更为纯粹，把just swipe——从侧面滑动切换手机态视为核心的设计理念。仔细看还挺邪门儿的，从顶部向下，从底部向上，从侧面向内——它们是如此热衷于边缘，以至于当我们想再这么做的时候，发现四周都被它们用光了：）

为什么是边缘？我想到两个原因，第一个记忆成本，第二个fitts定律。

画了三张图，试着每张图停留5秒钟，记住黑点的位置：

事实上可以将黑点理解为界面中需要定位的信息，随机摆放的情况下，5秒钟的时间很可能一个也记录不下。

下一张，仍然是5秒钟的时间

同样是5秒钟的时间，结果确有所不同。原因就在于本来一个黑点对应两个信息（x，y），但再这张图中,其中一个信息被大大简化了，以至大体能记下一两个点的位置。当我们真的用到边缘的时候，情况还更简单一些，比如下一张图，同样是5秒钟时间。

显而易见的一个结论是边缘的记忆成本要低一些，道理也很简单，如果黑点在屏幕内，每个点有两个维度的信息，x，y，而在屏幕边缘时，因为边缘只有四个，很容易区分，以至这个维度的信息几乎可以忽略，这样自然更容易定位了。

第二可以说明边缘道理的就是fitts定律，它可以简单的描述成定位一个目标的时间，取决于目标与当前位置的距离，以及目标的大小（还有其他因素，但和界面相关度较小）。距离越近时间越短，目标越大，时间越短。更详细的内容可以参见这里

表面看来，fitts定律和边缘没有什么直接的关系，但仔细想下，我们所谓的“移动到边缘”和“从边缘移入”实际的目标点并非边缘本身，而是“边缘外”。可以想象，如果我们需要定位到边缘上的一点，多了少了都不算数，其实还是蛮难的，但如果只要移出边缘就算数，那显然会容易很多，

套用到fitts定律上，目标点的位置实际上是边缘的一些像素及边缘之外的全部面积，这个目标点就足够大了，以至fitts定律因为一个分母的增大而使得界面的效率提高。如下图。

另外还有一些我曾经做过的设计作为案例，比如下面的解锁界面，上边为概念稿，下边是我们再产品正式开发前改进的稿件，这个设计可以在现在市面上的腾讯定制的手机上可能到。

右图中的小字为“拖动图标到屏幕边缘解锁”。这个设计充分利用了屏幕的四个边缘，出去可以从fitts定律解释的效率提高外，同时有的优点包括：可以盲解锁（解锁键在屏幕正中，感应区域也较大，容易定位），进而可以不用看到屏幕既可完成解锁甚至还可以进入到你想要的应用（屏幕四周对应四个常用界面），也就是说在你从口袋里拿出它的这个过程，从解锁到选择应用一并完成了。

当然，不论什么设计都不是完美无缺的，比如这个设计也受到一些挑战，诸如：“为什么有四个入口，一个不是挺好，移动端设计力求一个页面完成一个功能，不用这么复杂”。这点我不认同，也涉及到另外一个有关交互密度的话题。移动端的设计虽然力求功能简洁明了，但不能一概而论。100个功能不可能安排100个页面来完成，交互密度需要和用户熟悉程度相关。画了下面的图标，但只是感觉而已，未经论证：

在NOKIA工作的时候，一个设计师说起他们的调研结果：用户每天在手机屏幕停留的时间，大约60%-70%以上在主屏幕（home screen）上，这一结论好像那个直接导致了我们看到nokiaN97刚上市时那个繁华的过了头的主页面，先不论这个设计的好坏，数据上是比较客观的（3年前的数据）。对于用户非常熟悉的界面，我们虽然不必像N97的主页面一样排满功能，但在功能，内容布局中将密度提高一些是可以接受的，这样有利于用户有效的提高操作效率。也一并解释上述设计中四个入口的问题。

摩托罗拉在去年年末推出了一款新的手机，界面上和我们之前的设计非常相近，并非想说moto抄袭，应该只是个偶然，因为腾讯也经常要面对抄袭的指责，可能大家都是中国人，习惯这个词了，但是设计上并没有那么多抄袭可言。好的想法是可以碰撞的。总的来说这并不是一个很烂的设计。

关于边缘及交互密度，在桌面软件中有很多应用，mac，win7系统中有很多相关的优秀体验。最近我们在QQ的概念稿中也有充分的体现，短时间内不便放设计稿上来，终究它能带来一些不错的体验，值得实践一下。

篇4：论视觉设计与交互设计

在整个产品设计的过程中，视觉设计与交互设计的“工序”非常紧密，两者关系也是相辅相成，互相影响，而视觉界面作为最直接与用户交流的层面，如何把交互设计以良好表现形态展现给用户，这里主要集中探讨视觉在提升交互的可用性方面的作用：提升可浏览性

在整个产品设计的过程中，视觉设计与交互设计的“工序”非常紧密，两者关系也是相辅相成，互相影响。而视觉界面作为最直接与用户交流的层面，如何把交互设计以良好表现形态展现给用户，这里主要集中探讨视觉在提升交互的可用性方面的作用：

提升可浏览性精确与高效地传递信息与任务贴合用户的心智模型让交互富有情感

1.提升可浏览性：

1）信息结构的良好表现

视觉设计在对交互的帮助中，首要满足对产品与交互信息结构的展现，展现信息的清晰可读性，然后才是品牌，情感的传达，

视觉语言可以通过分层，分类，对比等语言手段对产品概念及信息进行处理。

例：

pic.01

pic.02

对上面两图进行对比，同样都是文章详情页面，相信没有多少用户在浏览pic01时能快速准确地知道网站想给他什么信息，或者让用户做什么。信息主次的分布，层级，色彩，均无做好有效分布，用户一边迷惑，一边迷路。而pic02对内容按主次程度来划分，最重要的文章详情信息一目了然，结构有序，条理清晰。

我们能感受到视觉语言的有效干预，能对信息结构的展现起到很大的帮助作用。

篇5：论视觉设计与交互设计

在整个产品设计的过程中，视觉设计与交互设计的“工序”非常紧密，两者关系也是相辅相成，互相影响，而视觉界面作为最直接与用户交流的层面，如何把交互设计以良好表现形态展现给用户，这里主要集中探讨视觉在提升交互的可用性方面的作用：

提升可浏览性

精确与高效地传递信息与任务

贴合用户的心智模型

让交互富有情感

1.提升可浏览性：

1）信息结构的良好表现

视觉设计在对交互的帮助中，首要满足对产品与交互信息结构的展现，展现信息的清晰可读性，然后才是品牌，情感的传达，

视觉语言可以通过分层，分类，对比等语言手段对产品概念及信息进行处理。

例：

pic.01

pic.02

我们能感受到视觉语言的有效干预，能对信息结构的展现起到很大的帮助作用。

篇6：人际沟通与信息设计交互设计

最近参加公司组织的关于沟通的培训课程，课后整理笔记，深刻体会到做信息设计就是与用户沟通的过程，产品是承载沟通的载体，架构就是沟通的组织框架，以下罗列几条可供设计对应思考的：

沟通的心态：

自我，自私，自大还是真正为沟通对象考虑，关心为先，

我们的产品设计则强调关心需求，关心用户的难处以及满足用户的期望，让用户难以拒绝。看来关心为先和用户为中心的设计是一脉相承的。

再说沟通的基本原则，最核心的是主动，避免等待，更不要出错和产生误解。我们的设计则强调界面友好，积极和及时的反馈，主动培养语境。把最重要最频繁的信息、功能快速送给用户。

沟通也需要注重地位、文化、经验、情绪的差异，而设计同样需要考虑目标用户的属性，地域文化，认知经验和情绪。

同样，在组织沟通中存在的障碍，主要是由三部分构成：信息不对称，组织氛围，缺乏回应。

沟通中为了避免信息不对称，理解上的偏差，有两个措施来解决，

1.避免信息泛滥，避免废话连篇，我们的信息设计用信噪比来衡量它，来检测页面的信息负荷度。我们用元素即界面的原则来约束信息元素的不当使用。

2.避免信息过滤，我们的交互设计、视觉表现是否在层层过滤信息的传达？

为了培养一个好的组织氛围，我们需要从硬件和软件两手抓，还要避免单独的私密沟通，术语叫狼顾，

同样在信息界面上，无论是CS端还是BS端，我们都要给用户提供一个舒适的视觉界面和相对精心的功能以及流畅的交互，适合操作和互动的氛围。避免用户在不同阶段碰壁或者产生消极的心理。

还有就是缺乏回应，回应是沟通中信息流动的媒介，沟通中我们需要积极的回应发起方，一是基本礼貌，而是对信息接收的肯定和反馈。以前最闹心的事情就是拜托某位朋友帮忙某事，等了猴年马月也没后话的，借钱也怕这样的主。

最后，从沟通的结果来看，其实我们可以理解为从用户体验的结果来看。

没有目标的沟通肯定是徒劳的，沟通要有的放矢，要聚焦。因此产品设计要控制范围，信息量。

有情绪的沟通肯定是不良的，沟通中警惕双方因为自己的立场，意识和知识背景，主观的放大彼此的缺点产生情绪对抗，这是最差的结果。而最终想避免这种情况的发生，我们需要控制情绪，理性的倾听声音。紧紧围绕目标来沟通，来协商或讨价还价，最后达成一种共识，我们的体验设计的过程，是不是一模一样。体验的好坏是不是也有一个平衡和各因素间的考量。

文末，分享一句话：

1.不在于你说什么，在于对方听到什么？不在于你感觉如何，在于听者的感受如何？

我照葫芦画瓢翻译一遍：不在于你设计多牛，在于用户能获得什么？不在于你感觉有多良好，在于用户是否能被打动，并且感觉良好。

原文链接：jary.findesign.cn/?p=1823

篇7：自然描述与自然任务交互设计

这次我们来说一些很小的东西，相当小，不过先说一个故事：

这天晚上，你打算出去下一次馆子，就行动了，找到了一家新开的小店进去坐了下来，服务员很殷勤的走了过来问你想吃点什么。

你问：“你们有什么好吃的么？”

答：“我们有黄豆与可食用菌落群酿制剂与 Carassius auratus 共同高温加热制成品；大豆蛋白经氯化镁、硫酸钙、氯化钙及氯化钠作用固化物与Carassius auratus 共同长时间高温加热制成品；单独Carassius auratus 于蒸汽环境高温加热制成品。”

你当时就辶耍仿佛你所在的并非人间。然后隔壁桌的 CDC 的哥们儿告诉你，其实就是红烧鲫鱼、鲫鱼豆腐汤和清蒸鲫鱼。

你说：“好吧，我都想试试。”。

然后服务员下去了，不一会儿，服务员走回来了，说：“先生大事不好了！1号厨师把醋当作酱油了！2号厨师在给鲫鱼开膛的时候把鱼胆扎破了，鱼肉变苦不能吃了！3号厨师的压力锅爆炸了，鲫鱼下落不明！另外我们的食材配送员刚才遇到了车祸现在正在医院抢救！”

你开始思考这一套杯具的背后有什么含义，CDC的哥们儿告诉你，其实就是说“放弃吧，鱼没了。”

你准备走了，服务员却叫住了你：“先生请付茶位费100元。”

你愤怒和忧郁的问：“这个怎么没有提前告诉我？”

服务员很淡定：“餐具的包装上有一行精致的灰色小字先生一定没看到。”

你想要找证据，可是餐具的包装早已被扔掉了。

于是你只好微笑着问服务员：“您想知道我右手有多大力道么？”

这是一个关于自然描述与自然任务的故事，看起来就好像用来骗稿费的三流小说。

就好比故事里点菜的情节一样，我们的绝大部分用户是不带技术词典过日子的。所以使用符合用户习惯与场景的自然描述是无障碍设计的必然要求。

这已经是一个很广为人知的原则，从我还不知道什么叫交互设计的时候它就存在，大家都明白一般情况下不要对用户使用专业术语或者不通用的俗语，比如在内存溢出的时候跳出一个写满了各种代码的对话框是很不推荐的做法，又比如在填写表单时警告用户“此字段已存在于数据库中”之类的话也是让人相当郁闷，这方面设计师们都做的很好，而且更多的畅游在专业术语中的开发人员们也渐渐能够在开发和沟通中主动使用自然的描述。（请原谅我这么说，但是一段时间之前的确不是这样的，这让交互设计师们都很郁闷。）这个就不多说了。

在此之外，某些情况下自然描述并不能完美的搞定某些场景和任务，自然描述一般来说是措辞上的原则和技巧，针对任务场景和流程的优化原则我管它叫“自然任务”:

接下来举两个例子折腾一下：

案例1. 下载任务遇到了问题。

用户在开始下载一个任务的时候，会碰到几个特别的问题，技术角度上，当用户将下载请求提交给服务器后，从服务器反馈给用户的情况有以下几种：

初步来看，自然描述的情况下，客户端会显示以下几种提示：

单纯从表述角度看基本这样反馈基本是自然的，但是根据具体的场景来看，其中前两种反馈在客户端的表现都是下载进度停止，需要用户等待，而且用户也只能等待等待, 而后两种反馈在客户端的表现都是下载失败，需要用户重启任务或取消任务，除此之外什么也做不了，因为事件发生在服务器端，

这种情况下如果不考虑这些提示，在用户看起来实际上只是遇到了同一种问题而已。

如果对用户来说所能看到的和所能做的都一样，并且虽然发生事件的原因不同但返回的结果基本类似，那么为什么还要给他那么多种反馈呢？于是我们把表现和处理一致的反馈进一步的归并为更为概略的情况：

这样一来，问题看起来变少了，世界也清净了。对于正常的用户来说，其实不需要去管后厨发生了什么大事件，只要知道鱼没有了就足够做下一步决定了，因为这是预期中可能出现的意外之一。

在这个例子中，原本的各种反馈都是自然的描述，都没有错，也没有什么问题，但是事实上它们有些多余，甚至有可能好心办坏事，说的太多反而容易让用户浮想联翩，产生额外的预期，引发不必要的不安全感和多余的思考。将多个表现和处理一致的反馈以相同的，常见于预期的方式呈现，可以减少用户所遇到的事件种类，减少思维负担。“多说多错”，这句话虽然比较灰色，不过这个例子里确是有些这样的味道。自然任务原则把已经是自然表述反馈进一步控制在用户的预期之内，避免节外生枝。

案例2. 关闭一个提示气泡。

有一个包含操作的提示气泡，由于它的重要性不能使用自动消失的方式，我们需要提供一个“关闭按钮”，而由于任务特点，它被关闭之后便不能再出现。我们这时有三个候选方案：文字连接“关闭”、文字连接“不再提示”、代表关闭的图标“×”。

这三个候选方案都像大自然一样自然，看似用哪一个都无所谓，可是我们纠结了很久之后，选择了最嗦的方案——文字连接“不再提示”。

我们先看看这个理想中的小小的任务流程：

其中，我们希望用户阅读气泡里的提示，我们还希望用户对气泡以后不再出现的特性有预期。那么回过头来看看三个候选方案，“关闭”的文字和图标真的太自然了，这个世界上如此的使用方法遍地都是，一个不小心就会踩到一例，自然到用户可能顺手就点击了下去，于是他将会错过我们的两个希望，那么今后将碰到更多的麻烦。如果使用“不再提示”的文字，用户会因为特殊的“不再”两个字而停顿那么一下，这个简单而且没有太多负担的停顿就足够他意识到这个提示的重要性了，那么他完成我们的两个希望的几率会非常高，我们也会很满意于用比较自然的描述就达到我们不自然的目的。

就像吃饭时最后一个意外一样，在太自然的环境中用户容易错过一些东西，我们在适当的时候要通过合适的自然描述促使用户自然地产生预期、自然地生成任务。强迫总是不愉悦的，这也是利用自然描述的一个进阶处理。这像是在节外生枝，但在特定的场景下的确是必要的，当然要生的自然才可以。

这个例子和死猫在《多按钮共存》中提到的关于按钮链接化的例子可以放在一起理解。

上面两个例子是在自然描述的基础上的进行的自然任务，和前面说的一样，自然描述的应用是基于语义和场景的，自然任务的应用是基于场景和任务的，对于特定的场景和任务，选择自然描述也要自然而然、通俗易懂、符合预期，常常可以很好的控制和引导任务场景的发展。

自然的原则，在自然描述完成之后还在进一步发生着，这的确是一个很小的东西，从这个小东西看开去，以小见大举一反三，很多交互技巧其实都是这个原理，说到底就是道法自然。

本文来自：cdc.tencent.com/?p=2166

篇8：从支付宝充值流程的交互说起充值的界面交互，PM与ID各持己见交互设计

如图：（点击图片查看大图）

支付宝的充值页面，已选择银行及金额，点击“下一步”后，来到：（点击图片查看大图）

在此页有提供返回重新选择银行的链接，假设我在此时想返回使用“网汇e”，步骤是：

1、后退或点击返回重新选择银行

2、点击“网点充值”，选择“网汇e”

后来，我重新规划了下，见演示：（点击图片查看大图）

图中将网上银行、支付宝卡通、网点充值（充值码充值、网汇e充值）这几种充值方式同时展现在选择充值方式前与准备充值时。

意思是说，已选择银行及填写金额后我可以中断当前操作，能重新选择“网上银行、支付宝卡通、网点充值（充值码充值、网汇e充值）”这其中任一种方式。

－－－－－－－－－－－－

问：此类需求过份吗？有必要吗？

－－－－－－－－－－－－

我随访了几个同事，我问是否会在充值方式、金额选择后，再返回重新选择其它充值方式，答案是需要的占一半以上。

可是，用户不是也会撒谎么？用户访谈的结果与用户实际行为可能会不符，

电脑资料

PS：从支付宝引开话题貌似有点标题党行为，哈哈。不过，确实在目前项目的一个充值流程中碰到PM与我各持己见。。。

PM坚持认为：

需要上述的 “已选择银行及金额后我可以中断当前操作，能重新选择“网上银行、支付宝卡通、网点充值（充值码充值、网汇e充值）”这其中任一种方式。”

而我坚持认为:

在充值前，用户就会思考或判断哪一种充值方式更适合他，

已经选择充值方式，行进过程中不需要存在太多路径，这样用户反而可能会迷糊。（PS：我面对的项目里边，充值接近10种方式，所以排起来绝对不是上述支付宝般最多四个的＝。=）

我说信息不是越多越好，塞一堆给用户，让用户在充值流程行进中不断地分散视觉流，不是个好主意。

快速完成！充值有多快就多快，让用户完成任务后离开或继续做他想做的事。

我试图设计成让用户使用鼠标或键盘通过 next -->next...... 这样快速完成充值。而不是next-->...(陷入思考)return...-->再next......直到完成。

－－－－－－－－－－－－

针对上述问题，大家有何高见？

本文出自：blog.touchnext.com/design/1211/pay-pageflow.html

篇9：角色法设计与实施交互设计

之前的PPT，翻出来和大家分享、探讨，《角色法设计与实施》下载

什么是角色法？

角色从本质上来说，是通过创建典型用户来代表具有不同目标的用户从而满足具有类似目标和需求的用户群。

我该如何去做？

♦角色框架定义

♦用户数据采集

♦分析过程设计

♦角色确认

♦角色法应用

通过以上6个步骤来完成角色的创建和应用

PPT案例：

如何使人物角色真实可信？

Jack角色如何应用？

1、将最终得到的人物角色介绍给同事和决策者，大家统一用户认识；

2、相关规划、需求、设计讨论，将角色应用其中，以用户的角度去讨论、决策问题；

3、根据角色确定一个界面是否能够满足用户目标，或者需要开发两个或以上的用户界面；

4、对哪一个功能比较有用进行设计决策；

5、在制定内容时，可以使用角色作为指南，这样以确保内容可以支持用户的目标以及回答他们共同的问题；

6、帮助我们进行用户分析活动，比如任务分析；

7、指导专家做可用性评估；

8、根据角色确定可用性测试场景和用例；

9、可以为产品的市场营销工作做出贡献，

其实最难的也就是最后一步：角色应用

如何让我们创建的人物角色发挥威力？需要我们不断去努力和实践。

本文出自：www.kdued.com/2008/12/%e8%a7%92%e8%89%b2%e6%b3%95%e8%ae%be%e8%ae%a1%e4%b8%8e%e5%ae%9e%e6%96%bd/

篇10：关于VIP用户研究与产品设计交互设计

一、VIP服务设计的中心思想

派恩二世，吉尔摩在《体验经济》中提出了体验经济时代产品和服务的划分，从这个角度来看，我们可以将用户全集合理解为正在使用和可能使用产品的用户，VIP用户则为使用高级服务的用户，

我们由此可以产生一个假设，如果VIP用户存在，则意味着产品服务可以进行分级，而且存在一些高级用户愿意为了某些特殊服务（主要是定制服务）付出更高的代价，这个在各个行业都是普遍的，比如高级成衣制作，银行贵宾卡服务，VIP游戏玩家等等。

那么我们可以将核心问题转移到：为什么那些高级用户愿意为特殊服务付出更高的代价。对于这个问题, 尼尔.雷克汉姆的提出：“没有需求，没有销售。”用户的需求又由用户使用该服务获得的价值而决定。我们可以归纳为一个公式：

“用户购买高级服务的期望=用户使用高级服务获得价值-用户付出的价值”

当然很多时候这个价值标准是很难量化的，我们通常需要研究各种数据来确定，比如定价提高后用户使用率的曲线图也是一种很好方法。作为商业机构，我们需要根据多维度来进行观察，我们可以使用以下公式来预测VIP业务商业价值

“定价×用户使用率×alpha = VIP业务商业价值”

所以，提高定价和提高用户使用率是获得VIP业务商业价值的两个主要途径，但是定价与用户使用率总是成反比例关系，而这个问题主要通过产品设计来解决，即通过提高VIP服务用户可获得价值来提升定价和用户使用率，而不是向相反的方向来延伸。

二、如何进行VIP用户角色模型构建？

VIP用户绝非有钱的用户，而是愿意为高级服务买单的用户。

VIP用户研究和普通的用户研究有明显的差异，VIP用户研究需要基于产品概念假设进行研究。比如当大众普遍免费邮箱的标准是1G时，我们可以假设VIP用户可能使用海量邮箱、个性化邮箱，基于此进行用户研究，了解该项VIP业务的市场规模以及高级用户愿意为之付出的价格。即VIP用户筛选模型为：

一般，用户角色形成需要根据大致的目标用户特征进行市场调查、访谈（比如焦点小组）研究，最终可以得到一些用户情感特征、行为特征以及用户期望，我们可以将这些归纳成为用户角色：

最终，可以将用户归纳如下：

有很多人提出模型过于标准化可能导致功能覆盖面不全以及概念提取不完全的问题，事实上如果后期的用户研究可以基本解决这些问题，而针对persona进行设计避免了产品设计中容易焦点分散的问题，能够有效的提升产品设计的质量。

三、如何进行VIP业务规划

VIP业务设计和普通设计的功能业务不同，VIP业务设计需要考虑更多的市场因素和产业发展因素。比如当Google开始1G免费邮箱时，Yahoo的邮箱业务（尤其是VIP业务）自然会受到市场冲击，所以Yahoo不得不进行整体的邮箱业务升级，提出海量邮箱概念，事实证明这些产品升级活动都是有效的，尤其是升级后的VIP业务在其后给Yahoo带来了大量的利润。

VIP业务设计可以是对现有服务的扩展和升级，也可以是新功能的开发等等。VIP业务设计的原则是提升用户的使用价值，尤其是提升相对价值，比如增值服务等。所以当我们开始VIP业务设计时，首先应该忘掉VIP概念，而是在概念设计完成后，再通过竞争性分析提出整个业务体系的VIP部分，

通常，我们可以通过业务状态研究（Current Product Status）进行分析，从而进行业务规划。

如图所示，我们可以明显地看到，业务状态研究得出的VIP业务的设计区域，（当然用户付出的价值标尺不一定是钱），我们可以通过业务状态研究得到各个业务的价值对比，从而得到产品和服务的差异化数据。此外，我们也可以用业务状态研究方法来对其它企业的相似产品线的用户体验进行桌面研究。

VIP业务规划的重点在于：基于基础业务设计，分析竞争对手以及用户可获得的相对价值，估计VIP增值业务可能的范围，从而进行VIP业务规划。

四、从规划到立项

从规划到立项有几个关键因素需要进行深入的研究：市场容量分析、盈利性研究、VIP业务对其它业务的影响（产品整合度研究）、成本研究、以及内部提供的技术准备方案。

? 市场潜力和盈利性潜力估计

我们首先要调查几个因素（当然，如果有市场部门帮助你的麻烦会少很多）：

1. 业务购买者和使用者确定（目标用户）

2. 购买者和使用者数目

3. 估计购买率和使用率

4. 竞争者市场份额