Specifying Interaction with Mockups

About this Tutorial

Designers, filmmakers, and animators have used low fidelity, static representations of content for communicating motion and interaction for years. Many of those techniques have been borrowed by software designers designing for the screen, and there are well-known practices for communicating interaction in static documents. This tutorial provides some tips for designing interaction in Mockups using these techniques.

The tutorial starts with a brief explanation of why these techniques are used, but if you like you can skip to the examples.

Low Fidelity Interaction Design

The spectrum of techniques for specifying and communicating interaction ranges from sketching to prototyping. Mockups is the sort of tool that sits somewhere across these techniques, and we think it bridges some of the gaps between sketching and wireframing, and only touches prototyping.

These are the techniques typical in design and development for specifying interaction in software, web sites, and applications.

Continue reading →

Why We Aren’t Doing Interaction in Mockups

Opinions matter

Every so often we’ll get a request to add features that would change Mockups from a sketchy wireframing tool to a prototyping tool. When these requests bubble up, I take the time to explain to people what Mockups was designed for, and often point them to our Manifesto, which discusses this and other beliefs we hold as a company.

We have a tutorial that illustrates various methods for designing for interaction, and shows where Mockups fits into this picture. It sometimes helps to share this, because occasionally I’ll discover that the person asking is not aware of these methods for specifying interaction. More often than not, they’re satisfied to have this information.

Mockups is primarily an application for describing interactive behaviors with static pictures, and this statement doesn’t always sit well with people who believe that deliverables have to come very close to the real product in order to communicate the design. We have a different opinion.

The debate: sketching vs. prototyping

There are arguments on either side of the debate about whether or not you have to use interactive prototypes to describe interactive behaviors. On the prototyping side, the argument is that you can’t communicate interaction without working prototypes that resemble the real thing. But animators and film makers have communicated motion with static drawings for as long as these media have existed, and at least in early-stage ideation, many still do. The same holds true for designing interaction.

Continue reading →

产品与项目的区别、软件开发方法学的争议

最近在看一本关于Scrum敏捷开发方面的书，联想到了工作这几年的一些零散感触。趁着有写东西的激情，挑些整理一下。

先整理一下我理解的产品与项目的区别，这个比较简短，而且在后面的软件开发方法学中会有涉及。

到现在算是做了四年的产品和一年的项目。大概去年和同事聊我们现在做的是产品还是项目时，我说是项目，他觉得是产品。当时我是凭感觉，但一时没有想出特别的区别方法。后来某天上班走在路上时，突然想出总结了以下产品与项目区别：

产品：先做后卖，不好没人想买，迫使团队不断升级产品赶超对手。

项目：先谈后做，控制成本满足需求，以后尽量避免变更。

接下来是关于软件开发方法学的争议。

最近看的书里狠狠的批判了瀑布方法学，把案例公司的项目失败的原因归根在了方法学上，这是我很不认同的。当然了，书的几个编著人这样做是有目的的。当书里写道Scrum模式的敏捷开发时，有一点我是很赞同的，就是提出人的重要性，强调以人为本，加强沟通。

瀑布方法学虽然很老了，也有不少人批判。我也曾经怀疑指责过，查过不少资料，知道了有迭代式方法学、递增式方法学、RUP、XP等。两年前痛恨瀑布方法学的同时也迷惑了，有些方法学看似很好，但在实际操作中也会有局限和困难。

后来和一位十来年经验的项目经理聊方法学，解开了我大半疑问。严格的瀑布方法学是不合适的，但它仍然是软件开发的基本框架方法，具体工作中，可能根据需要融合迭代式或者递增式等其他方法学。

刚刚参考《面向对象分析与设计(UML 2.0版)》的时候，还看到了类似的说法，算是合并方法学的思想。在中大型公司中，我是比较赞同这种方法的。如果是小团队，可能又会选择更敏捷高效的方法。

因为产品和项目的特点不同，具体的操作和方法也会有不同。下面谈的有点偏向于项目规划和需求方法了。

有一种经典的项目失败场景是：项目做完，客户看到时说不是他想要的，和他想的不一样。。。这时大家都傻眼都痛苦了，程序员更悲剧了。

对于这种情况，我认为首要是需求阶段的问题。（当然，基本前提是项目组是团结合作、有能力、也是努力实现目标的。）即使SRS（软件需求规格说明）很详细很正确，如果只是文字描述，客户是很难有直观理解的。在客户看到有形的产出前，常常很难确定自己的想法。

理论上的方法应该也有不少。以前跟两个项目经理聊过，他们的经验是，利用高保真原型，拿高保真原型给客户看和体验，这样客户会有直观的概念和想法，根据反馈再完善需求。这样就把风险尽量前置了，而且制作原型的时间和成本比开发一套系统要低得很多。

曾经和一个项目经理做比较大的项目时，他甚至把项目周期的一半时间分配给需求分析和高保真原型，可见对需求的重视。刚开始有点诧异，时间比例比一些理论值大了不少。虽然不一定是最合理的，但对一些目标和时间比较明确的大点的项目来说，很有实战意义。

如果是做产品，上面这种方法就太低效了。既然是产品，就应该有个产品经理（参考文章：产品经理的主要职责）。如果团队合作默契、互相信任，需求的交流和工作应该是高效的。产品经理对需求应该有清晰的认识，如果有大变更或者变更多，首先是产品经理的责任。在原型方面也可以减少很多工作量，对于复杂的产品，也许画个线框图。对于简单的，草纸或者口头交流清楚更好了。不管哪种，当面交流是最高效、效果最好的方式。

话说回来，产品经理也不一定是拍板的人，也可能是夹板和炮灰，也有不少人达不到职责应有的水平。对于部门和人员多、分工详细的大公司，产品经理也不一定负责详细需求。接着就会引申出流程和内耗一些问题。方法学又开始纠结了。。。

各种方法学在具体操作时都有成功和失败的案例，个人觉得没有哪种是最优的，要看公司和产品/项目特点，团队和个人，甚至还有客户的特点。方法学和流程什么的还是人定的，目的是帮助团队，需要情况灵活应用和调整，关键还在人。

需求工程师的素质要求

需求工程师需要什么样的素质呢?

《软件需求》一书的作者 Karl E. Wiegers 在文章 “So You Want To Be a Requirements Analyst?” [1] 中列出了需求工程师的任务和素质要求，简要摘录如下。

Karl E. Wiegers 认为，需求工程师需要和系统的各种涉众沟通，成为他们之间的纽带。所以，需求工程师需要具备以下素质:

需求分析师负责沟通各种人

关于需求工程师的素质要求，Karl E. Wiegers列出了以下几点:

1. 倾听的能力。积极倾听包括排除干扰，保持专心的姿态和眼神接触，并重复要点来确认你己经理解。你需要抓住要点并从字里行间推断出对方犹犹豫豫没有说出来的东西。了解对方喜欢什么样的沟通方式，尽量避免把你的个人理解强加到客户身上。

2. 访问能力。大多数需求输入来自讨论，因此一名分析员必须能够询问正确的问题。例如，用户一般会把精力集中在正常的、符合期望的行为上，而每个程序员都知道需要大量代码来处理错误，可以问类似这样的问题“如果这样，会发生什么事情”或“会出现这样的问题吗？”Donald Gause和Gerald Weinberg在书中[2]描述了“context-free questions”的技术。

3. 分析能力。有在不同层次进行抽象的能力。有时你需要从高层往下钻到细节，有时需要从某个用户的特定需要泛化到适用于整个用户类别的需求集合。评价各种从不同来源收集到的素材，调和冲突，从用户的需要中分离出真正想要的，并把解决方案从需求分离。

4. 协调能力。涉众需要需求工程师作为中立的协调员，协调员需要强的提问和观察技巧，以帮助团体建立信任、改善业务人员和技术人员之间有时会出现的紧张关系。Ellen Gottesdiener的书[3]中提供了协调员的建议宝库。

5. 观察能力。在持续观察用户做工作或使用一个应用系统的时候，你可以推断到一些微妙的东西，这些东西可能在讨论的时候没有涉及。这样就揭示了新的需求领域。

6. 书写能力。你为顾客、营销人员、经理的主要交付物是书写好的规格说明。为了完成这个任务，你需要有坚实的(自然)语言能力。力争做到清楚，避免含糊词语和语法错误。

7. 组织能力。你会面对一大堆在启发和分析中得到的混乱信息，快速地把它们组织起来，把碎片拼成相关的整体。这需要高超的组织技巧，还有耐心和韧性。

8. 建模能力。从流程图到结构化分析模型(数据流图、实体关系图等)到UML标记，需求分析师的工具箱里应该有这些画图工具。在和用户交流的时候，一些这样的技巧是非常有用的，和开发人员的交流也一样。你会经常需要教育其他涉众这些技能的价值以及如何阅读它们。

9. 交际能力。你必须能够使有不同兴趣的人一起工作。你应能自如地和组织中不同级别的个体交谈不同的工作，你可能还需要和分布的团队交流，它的成员分布在不同的地点，时区、文化、语言都有区别。

10. 创新能力。分析师不只是一名抄写员，顾客说什么他就记什么。James Robertson[4]建议最好的分析师应提议需求，分析师可以构思创新的产品功能，设想新的市场和业务机会，想出能够使顾客震惊和高兴的好方法。一名真正有价值的分析师能发现创新方法来满足用户一直不知道自己已有的需要。

11. 领域知识。事先拥有一定的领域知识，才能使以上的能力 发挥出来。对于需求工程师，并没有标准的教育程序和工作叙述，他们大多数来自不同的背景。如果你从类似于系统用户这样的角色进入到需求分析角色，你需要在你丰富的业务知识和软件工程工作环境之间作出平衡，并学会和你的技术同事们沟通。如果你是从开发人员转换而来，你需要增强对业务的理解，随时提防滑进自己的技术陷阱中。

需求获取技术
Karl E. Wiegers还列出了一些搜集需求数据的方法：
• 访谈
• 需求工作组
• 文档分析
• 问卷调查
• 现场观察
• 业务流程分析
• 工作流和任务分析
• 列出外部事件以及相应的系统响应
• 竞争对手产品分析
• 逆向工程现有系统
• 回溯以前的项目

参考文献
[1] So You Want To Be a Requirements Analyst?, Software Development, July 2003
[2] Exploring Requirements: Quality Before Design, Dorset House, 1989
[3] Requirements by Collaboration: Workshops for Defining Needs, Addison-Wesley, 2002
[4] Eureka! Why Analysts Should Invent Requirements, IEEE Software, July/Aug. 2002

Word需求文档模板(带自定义快捷键)

这个Word需求文档模板经过我很多次的修改，包括需求大纲、文档排版、自定义快捷键。期间也学了不少Word编辑技巧，很有意思。

在这个模板里，我设置了一些自定义快捷键，编辑文档时很方便。比如可以一键设置样式（字体、字号、行距、大纲级别、多级编号。。。），保你用了忘不了~

以下是我自定义的快捷键：

快捷键 功能
F2 标题1（大纲级别1级 + 多级编号 + …）
F3 标题2（大纲级别2级 + 多级编号 + …）
F4 标题3（大纲级别3级 + 多级编号 + …）
F5 正文
F6 标题4（大纲级别4级 + …）
F7 项目符号
F8 编号
Alt + D 打开/关闭 文档结构图
下面在线预览（如果看不到，说明Google Docs Viewer被墙。。。）。

Axure和Visio中流程图链接到页面的对比

Axure中流程图的Widget可以方便的链接到页面，所以我希望在Visio中的画流程图也能链接到页面。
小琢磨了一下很简单，做个演示视频分享一下~
PS, 这还是我第一次在Axure中完整的做个小流程图。画流程图、活动图之类的图形，还是要选Visio。
存在我空间里的Video缓存起来很慢，所以把Video放到了优酷上。但是优酷把Video压缩的很厉害很模糊，如果想看清晰的（1200*800，Video里的字都很清晰），可以在这下载。

在GoDaddy上更换主机OS

这里说的是更换shared hosting的OS。

更换主机OS本身还是很简单的 >>

  1. 在【GoDaddy》My Products》Hosting】中，选择想要更换的主机域名。
  2. 选择【Edit Account Details】tab。
  3. 在【Plan】菜单中选择新的OS。
  4. 选择【Save Changes】。如果有差价，补齐差价。

OS

然后就是等待生效。官方声明的是72小时内完成更换，如果空间中的数据小，那么会快些。更换完成后，GoDaddy会发送通知信。

Notes >>

  • 如果你在【Plan】菜单中看不到想更换的OS，可以联系customer service。
    我当时更换时没有看到Linux Server是因为安装了MS SQL Server，删除MS SQL Server后就看到了。
  • 更换OS前必须删除主机不支持的数据库。主机支持的数据库，GoDaddy会保留。
  • 更换OS前，最好备份数据库和其他重要数据。
  • 如果新主机不支持旧主机的一些功能和语言，那么更换新主机后，之前的功能和语言是不能用的。
  • 我的空间从Win主机更换成Linux主机后，WordPress Blog主页正常，但是博文URL会报404。进Wordpress后台重新设置保存下URL形式就恢复正常了。

Use Case (用例)之间的关系

用例之间的关系可以把用例更好的组织起来，更便于描述系统。

用例之间的关系有以下3种：generalization（泛化）, include（包含）, extend（扩展）。

Generalization（泛化）：用例之间的泛化就像类之间的泛化。子用例继承父用例的行为，子用例可以在父用例上增加或者重写一些行为，子用例可以用在父用例出现的地方。
利用泛化关系，可以描述系统更高目标层的需求，而不用涉及具体细节。
泛化关系的图示如下，

generalization.gif

Include（包含）：如果第1个用例明确地包括第2个用例的行为，那么第1个用例包含第2个用例。被包含用例（第2个用例）从不作为单独的用例存在，而只作为基础用例（第1个用例）的一部分。
利用包含关系，可以把相同的行为提取到被包含用例中，以便于复用。
包含关系的图示如下，

include.gif

Extend（扩展）：如果第1个用例在一定条件下包括第2个用例的行为，那么第2个用例扩展第1个用例。基础用例（第1个用例）可以单独存在，但是在一定条件下时，它会被扩展用例（第2个用例）扩展。
利用扩展关系，可以描述不是必须发生的系统行为，可以描述一定条件下才发生的行为。
扩展关系的图示如下，如果想更详细的说明扩展条件，可以在扩展箭头上添加注释。

extend.gif