只是记录一些对我个人有用的关键点，对于一个高效的执行脚本。（话说这是我08年起的一个草稿贴，汗颜）
1、清晰指出该次执行的探寻焦点。形式上可以是关键字，也可以是一连串的问题，前者适合于当执行者不大熟悉研究主题的情况，能快速的上手且准确执行，但容易遗漏关键字以外的关注点；
2、没有严格的执行顺序，但有清晰的场景定义。这点对刚入门的用户研究员尤其需要避免。看到很多脚本，由于研究员在设计时考虑到很多的“问题逻辑”，所以在脚本中设定了严格的执行顺序（例如先问什么，例如先做什么）。
这对于千变万化的用户思维，有时是弄巧成拙的，一方面是造成执行现场的冲突，更麻烦的另一方面会严重损坏用户数据的真实性。
全文…
问题的定义说明：
1、用户问题：通过用户测试发现的问题。市面上也有人提“可用性问题”的，我还没想明白侧重哪个方面会更有利于产品的优化。
2、严重程度：就是某问题的严重程度- -~ 通常会和问题的解决优先级挂钩，也是问题发现者和问题解决者不断纠结的重点，初表现为产品设计者与开发者的冲突，或可用性分析师与产品设计者的冲突。
在这几年实际的应用过程，让我觉得，严重程度不仅仅是一次性问题的解决优先级，它在机制上其实应该和设计规范相辅相成，相互补充、更新。它反映的是对于某设计团队或对于某产品所要达到的设计目标中的一部分，具体的说是与用户使用相关的那部分。
所以可以说，严重程度部分反映的是，我们希望产品设计团队怎么做，关注什么，而且它所反映的设计要求是非常基础的水平，因为再往下就是“用户出问题”了！
严重程度的作用，在于：
意识，解决的是“what to do”；这样的判断，有时是来源于业务经验，有时来源于专业，有时来源于灵感。这样的判断，往往是没有对错的，至少无法在短期内看到结果的验证。如果仅仅通过投入产出比来衡量，很容易陷入“对暂时无法衡量的产出，尽可能减少投入”的惯性思维。
方法，解决的是“how to do”；关于采用哪些方法来达到某个目标，只要目标描述清晰，是可以在执行方法后得到即时验证的，至少能得到“是否有助于目标”的趋势验证。此时，计算投入产出比对做出这个判断是很有帮助的。
全文…
 |
设计遇到挑战不止一次，归根到底或多或少的指向到设计的价值和设计的目标这点上，设计可以带来商业价值，但设计的价值和目标就只用商业价值来衡量么？或许这里有咬文嚼字的嫌疑，但完全把用户体验和商业价值完全等同起来，相信在现有的理论和商业现实中都难以让人信服。
所以我仍然在坚持，设计不仅仅只带来商业价值，还需要给人类带来优质的高体验水平，这两者针对的都是设计的最终效果，都是设计在被使用后所带来的最终结果。既然两者是2个东西，两者的衡量方法或许有所不同，而对于某个特定设计工作，这两者的衡量指标可以有所重叠。
用户体验水平是什么呢，这取决于如何定义“用户体验”，水平，顾名思义，只是好到什么程度，差到什么程度的不同，最好是量化的，但不必需是。而也不一定要追求行业统一，用户体验的内容，需要根据产品和用户群来定义。
全文…
记得第一次接手界面设计时，很是激动的对着百来页的PRD（ProductRequriementDescription），按照我的理解密密麻麻极其曲折复杂的把业务流程用viso画出来，并极富感情的为自己打印出来，钉在屏幕旁边，自觉我已经很好的跨入了产品设计的门槛，对这个产品了然于胸。接下里很顺理成章的任务，就是把这些流程与PD反复沟通，不断丰富其中的分支异常流程，最后按照定稿的流程图把一个一个的页面补充进去，收工。
接下来有将近半年时间我都是如此在做设计的。现在回头来看，有些地方算做对了，但有几个事情原来我一直没作，恰好那些还挺重要：设计第一要事，决定做什么，不做什么。
说的虚一些，就是定义出这个设计的主要方向和重要的大设计原则，具体而言就是做什么，不做什么。
居然还有当时勤奋翻译的可用性评价问卷，太寒了，不分享对不起自己。
原文在这里，还是别太多被2年前的我误导。http://sumi.ucc.ie/
还搜了个其他同仁翻译的，给大伙儿参照着看，哈哈
http://yuezh.blogbus.com/logs/3817893.html
——————————————————————————————————————————
全文…
老掉牙了也非我原创，看图。只是很粗略的概念。
三块的内容整体构成了产品，对应有着不同专业要求的人员对其负责
专业的人做专业的事，别让你的不专业为专业的事拍板。
今天特别高兴，我总是很喜欢和朋友聊聊天。
瞎掰到一点，极端乐观的看，随着用户体验越来越接近商业价值，它不可避免也会越来越接近核心策略，成为企业一项必须的关键的无形资产。那么，对于有能力可以长期发展这项资产的企业，会非常有可能大力建立用户体验团队，把它当做一项关键技术来进行发展和保护。此时，咨询和外包项目的方式只能越来越少介入其中。哈哈，用来说服咨询们的专家加盟产品企业的强大理由。
全文…
作为一个非设计出生的研究思路偏向的设计师，带着少了设计师自恋和自怜的眼光，我记下最近一年来感受到的交互设计师的尴尬。
这句话更多是我从设计外部门听到的，通常他们搞不清咱们内部的WDVDURUIUE一溜绕来绕去的概念，而是从产出物来定义一个角色，交互设计师的出现往往代表着会拿出界面，但在深入打交道后他们才发现原来交互画出的界面也比他们好看不了多少，黑白框、空内容、随意的交互细节。而且原来到真的换个颜色时，跟交互说也不抵事，更别提要修改下某个css了。原来设计外部门人员的概念当中的实实在在的产物，没有一个是交互能做的。而交互设计的产出物只是设计过程中的一个交付物而已。
全文…
