(特价书)iOS应用软件设计之道

第2章　画草图 12
2.1　边画边思考 12
2.2　谈话中论设计 13
2.3　绘制草图的工具 14
2.4　草图毕竟是草图 15
2.5　何时画草图 16
2.6　利用先例 17
2.7　应对唱反调 17
2.8　绘制界面草图 18
2.9　画交互过程草图 19
2.10　画工作流程草图 20
2.11　小结 22
2.12　练习 23
第3章　熟悉iOS 24
3.1　流向：从一个画面到另一个画面 24
3.2　对标准组件的建议 32
3.3　定制控件 41
3.4　小结 42
3.5　练习 42
第4章　线框图 43
4.1　以画面考虑 44
4.2　以点考虑 45
4.3　视觉度量 46
4.4　画线框图的工具 48
4.5　布局原则 49
4.6　排版 56
4.7　布局图：放置所有东西的地方 57
4.8　小结 62
4.9　练习 62
第5章　实体模型 63
5.1　何时进行实体模型设计 63
5.2　式样：显见的设计规矩 64
5.3　实体模型工具 66
5.4　色彩：用“色调–饱和度–亮度”思考 67
5.5　严格数值 69
5.6　对比度：考虑图片与背景的关系 69
5.7　好的对比度与视觉分量 70
5.8　恰当的背景 71
5.9　透明度 73
5.10　1+1 = 3 73
5.11　呈现图片内容 74
5.12　评估对比度：色调分离 74
5.13　对比度示例 76
5.14　按钮的生成 78
5.15　组装实体模型 83
5.16　尺寸可调的图片 84
5.17　视网膜资源 84
5.18　图层设计 85
5.19　小结 85
5.20　练习 86
第6章　原型软件 87
6.1　在设备上测试 87
6.2　原型的种类 88
6.3　纸质原型 88
6.4　纸上原型指导 90
6.5　动作草图 90
6.6　预制的演示视频 92
6.7　交互式原型 93
6.8　概念证明性软件 95
6.9　为何要做可用性测试 97
6.10　如何进行可用性测试 98
6.11　小结 99
6.12　练习 99
第7章　跨平台行动 100
7.1　平台分类 100
7.2　独立、迷你和伴随性的应用软件 102
7.3　从头开始 102
7.4　回到提纲 103
7.5　案例研究：苹果公司的Mail 103
7.6　小结 112
7.7　练习 112
第二部分　原则
第8章　优雅的界面 114
8.1　暂停怀疑 114
8.2　疑惑时刻 115
8.3　即时反馈 116
8.4　通过布局实现优雅 117
8.5　六种可靠的手势 118
8.6　三明治问题 120
8.7　用奇异的手势作为快捷方式 120
8.8　手势的逼真度 121
8.9　黏滞效应 121
8.10　阈值 123
8.11　宽大的触击 124
8.12　有意味的动画 126
8.13　让SnackLog得体 127
8.14　小结 128
8.15　练习 128
第9章　得体的界面 129
9.1　指示与内涵 129
9.2　暗示 130
9.3　比喻 132
9.4　文字 133
9.5　写作：秘而不宣的设计约束 134
9.6　冗余消息 136
9.7　对码混乱 137
9.8　用户需要的时候给予指导 137
9.9　状态可视 138
9.10　情景状态 139
9.11　看不见的状态 140
9.12　探险的感觉 143
9.13　才能 144
9.14　预防性设计 144
9.15　体谅 145
9.16　让SnackLog彬彬有礼 149
9.17　小结 150
9.18　练习 151
第10章　整体体验 152
10.1　服务于精神 153
10.2　传达才能 154
10.3　文档说明 160
10.4　支持 164
10.5　本地化 165
10.6　可访问性 167
10.7　气质 168
10.8　尊敬 168
10.9　小结 171
10.10　练习 172
第三部分　寻求平衡
第11章　专注与多能 174
11.1　揭示“简单”与“复杂” 174
11.2　专注型设计 175
11.3　专注SnackLog：标记 179
11.4　多能型设计 180
11.5　小结 184
11.6　练习 185
第12章　宁静与张扬 186
12.1　空间上邻近 187
12.2　时间上叠加 188
12.3　渐进式的显露 189
12.4　按含义分类，按重要性排列 190
12.5　升级与降级 191
12.6　划分差异 193
12.7　iOS喜欢情景 193
12.8　隐藏而非禁用 194
12.9　消失 195
12.10　触击不费事 196
12.11　响亮而清晰地说出 197
12.12　让SnackLog宁静 197
12.13　让SnackLog张扬 198
12.14　小结 199
12.15　练习 199
第13章　阻挠与引导 200
13.1　难度曲线 200
13.2　体验分量 201
13.3　为什么要添加阻挠度 202
13.4　怎样增加阻挠度 203
13.5　非本意的阻挠 204
13.6　引导 206
13.7　合理的默认设置 209
13.8　小结 212
13.9　练习 212
第14章　常规与出格 213
14.1　这是如何做到的 213
14.2　掌握《iOS人机界面指导原则》 214
14.3　常规性设计 215
14.4　专注化的设计 219
14.5　小结 223
14.6　练习 224
第15章　奢华与简约 225
15.1　彩色与单色 226
15.2　深度与平整 229
15.3　现实主义与数码形式 233
15.4　小结 238
15.5　练习 238

.　　“第4章线框图”。你早晚需要将草图转换成精确、逐画面的定义，以指出应用软件如何组织。线框图就是一份说明布局和程序走向的文档，还不必纠结于精确到每个像素的页面图。
　　“第5章实体模型”。设计并非唯一要考虑的东西，但它关系到应用软件的表现。本章将分解图形应用软件，了解如何将各种漂亮的零件组装成令人赏心悦目的整体。
　　“第6章原型软件”。有时静态的界面图并不够。你需要知道它如何动作。本章介绍对组成你的应用软件的交互过程进行仿真和检验。
　　“第7章跨平台行动”。大量应用软件都不只作为单独的体验存在，而是作为多平台套件的组成部分。本章探究在你想对多种设备构建同一应用软件时，需要处理的内容。它采用的示例是要在iPhone、iPad和Mac计算机上都运行的应用软件，研讨说明一个灵感如何表现为三种不同的界面。
　　“第二部分原则”提出了一些通用原则。如果你想让人们赞赏甚至热爱你那高效的应用软件，就应该遵循这些原则，它们适用于任何设计。心理学家唐纳德·诺曼（Donald Norman）提出了三层认知理论，这一部分的各章都基于其理论的某个层次，以确保你的应用软件工作于每个层次。这些原则许多都适用于所有软件设计，但它们针对iOS的力度和挑战做了调整。每章的练习都提供了示例情形，以帮助你了解如何运用每个原则。
　　“第8章优雅的界面”。该章探讨认知的感官层面。这关系到人们与软件交互时的感受。它处理的事情诸如触摸输入、适时性和给人的感受。这里关注的许多方面都是下意识的。用户可能不会注意它们，但它们在微妙地影响人们使用软件时的愉悦程度。
　　“第9章得体的界面”。该章探讨认知的行为层面。这意味着用户如何不时地做出决定，而应用软件如何把状态和可能性表达出来。本章还探讨应用软件如何鼓励冒险，从而让用户在探究各种用法的可能性时感到受欢迎且安全。
　　“第10章整体体验”。认知的反思层面是最大、最含糊、最不可捉摸也是最重要的层面。该章解释人们在长远上如何感受你的应用软件：他们是否会高度评价它；是否会将其推荐给朋友；是否会尊敬你这个设计者；还有是否会再次购买你的产品。让用户快乐才是终极的目标。
　　“第三部分寻求平衡”对设计应用软件时遇到的决策点提供参考、鼓舞和探究指南。它蕴涵的原则就是，所有设计都是个折衷过程，许多决策都没有一种正确的答案。这意味着同样一个设计问题可以有多种解答，而且每个设计，不管它多么老套，或者看上去多么简单，总有某些东西可以供人学习（许多批评家似乎忘了这个事实）。你可以查看每一章的相反方法，这就像一个滑动条，在两个极端之间有各种各样的答案。对于每种设计挑战，像你一样聪明的设计者就会找出那种最适用于你的应用软件独特哲学的答案。日久天长，你也许会发现你倾向于滑动条的某一侧，而非另一侧。你可能选择专注于某个（些）功能，而不是什么都要顾及。或者也许你更乐意寻求亚力士多德的黄金分割法，而非不偏不倚就在中间位置。那样很好，这意味着你有自己的风格。每种决策类型都通过同一问题的不同解决方案表现出来，这取决于你倾向的角度。这些练习将鼓励你在某种特定条件的若干可能答案中，找出自己喜欢的解决办法。
　　“第11章专注与多能”。你要对应用软件做出的一个最深远的决定，就是其范围。你想完美地做一件事，还是擅长做许多事情？可行方案取决于你目前的资源和能力，以此来定义你对此项目的期望。
　　“第12章宁静与张扬”。大部分人在谈及设计时，会认为它“不过如此”，那是因为他们以为，设计是按部就班的，给出的就是一些可理解的信息和控件。其实，设计方案在尽可能表现内容时，会有自主权。该章说明如何管控应用软件画面切换的简单性，这取决于你要激发的情感。
　　“第13章阻挠与引导”。软件设计师的部分工作就是让许多事情成为现实，但也要通过体验来温馨地引导人们。该章讲述界面可以安排些套路，鼓励用户这样行动或那样行动，或者让其小心谨慎检查后再采取下一步骤。
　　“第14章常规与出格”。将你的应用软件与其他同类应用软件区别开，既有好处也有风险。在回想设计精良的应用软件时，能够进入你脑海的都是那些打破常规、侥幸成功的软件。但遵从业已存在的指导方针，通常是更明智的做法。该章帮助你决定何时墨守成规，何时背离它们。
　　“第15章奢华与简约”。应用软件的可视化风格是表达其设计的最显著方式。不管它的功能如何，应用软件可以看上去是大气或柔和、逼真或数码化的。该章帮你调校应用软件界面的深度、颜色和真实度，以设置其基调和个性。
　　访问网站
　　本书英文版的网站是http://learningiosdesign.com。你可以在此找到如本书各章给出的Photoshop和OmniGraffle示例的源文件等资源。你也可以在此对本书提出反馈意见，并获取更新的内容。
　　你和你的团队
　　在工作于自己的应用软件思路时，你可以沿着本书循序渐进，特别是在实践第一部分给出的结论时。即使你还没有某个应用软件项目，或者你的应用软件已经在手，你想修改它生成新版本，你都可以从本书获益。第二部分和第三部分适合深入挖掘灵感和建议。
　　倘若你是个与软件工程师或团队协同工作的设计人员，本书也能提供参考。当然，并不需要一定是这种情况。也许你是那个“高贵”团队的一员，或者孤独地身兼程序员和设计师。也许你是个产品经理，希望更好地理解设计。这些都无所谓，本书在提及“工程师”这个词时，指的都是你。
　　兼具艺术性和科学性
　　设计充满了所谓“该死的问题”。这些问题很难定义，也不可能有明确的答案，而且没完没了。这么说可能会让某些人寝食不安，但正因为这样，也使设计充满乐趣。你总是不知道自己会遇到什么情况。总有些办法改进你的工作。每件事都是在品味，而有些答案显然比其他答案好。没有一定之规，随处都有各种智慧和灵感可以找寻。
　　设计不仅是一种艺术，而且是一种科学。或者两者都不是。史蒂夫·乔布斯喜欢说，苹果公司所做的一切，就是交汇“?技术和自由主义的艺术”。你也许发现团队在争论如何做决定。一方主张用数字显示，用可用性指标能够清楚地表达A设计比B设计高效。而另一方争辩，基于美学，A设计并不赏心悦目。谁会赢呢？也许这只是二中取一，也许还有第三种新选项。找出这种选项也是设计令人兴奋的一个原因。
　　你可以采取完全科学化的方法，在没有研究完之前拒绝一切偏倚。你还能采取完全艺术化的方法，在应用软件形式上跟着感觉走，创作你的个人杰作。但这两种方法都不能让一个人单独做得多好，这涉及数据和才智的局限性。
　　灵感无处不在
　　在为iOS设计应用软件的过程中，你会遇到特定的话题和情形，本书会给出具有针对性的建议。但作为设计人员，你的成长更取决于你从周围汲取灵感的渴望程度。要关注所有类型的设计：图形的、内部的、架构的、游戏的等任何东西。广泛阅读心理学、艺术、历史、生物等任何科目。也许某一天有个看似完全不相关的知识，能够以某种独特的方式启示你的设计工作。如果你不做别的任何事，就使用反响良好的应用软件，考虑它们成功在什么地方。你越检查和思考各种各样的杰出成果，就能越好地提升自己。
　　再次说明，作为设计人员，成长是个终身的过程，但这里有个必要的阅读材料清单供你起步。其中有些书会在其特别有关联的章节再次提及。
　　William Lidwell、Kritina Holden和Jill Butler合著的《Universal Principles of Design》里面收集了125个思路，适用于各类设计。非常适合你浏览，以快速寻求设计灵感。
　　Robert Bringhurst著的《The Elements of Typographic Style》是最精心创作的、充满智慧的书籍之一，适用于任何时代。不错，Bringhurst将带你了解排版知识，但也会用其系统、雅致的方法来激发你的设计灵感。
　　Edward Tufte著的《Visual Explanations: Images and Quantities, Evidence and Narrative》或者其四部主要著作中的任何一本。Tufte倾向于打印的信息设计，但其推崇的那些原则会让所有有兴趣把事情做好、做漂亮的人受益。
　　Bill Moggridge著的《关键设计报告：改变过去影响未来的交互设计法则》（Designing Interactions）收纳了数次访谈过程，包括对从原Macintosh软件带头人Bill Atkinson到游戏设计的传奇人物Will Wright的访谈，并提供DVD光盘。
　　Bill Buxton著的《用户体验草图设计：正确地设计，设计得正确》（Sketching User Experiences: Getting the Design Right and the Right Design）：技术设计者在绘制草图实践方面的威望，很大程度上归功于Buxton。绘制草图对你的大脑和工作都有裨益。
　　Donald Norman著的《设计心理学》（The Design of Everyday Things）是经受了岁月考验的经典书籍。该书率先揭示了糟糕设计体验带来的用户不满，开启了让世界变得更和谐的一代设计者的诞生。
　　Jeffrey Rubin和Dana Chisnell合著的《Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests》：如果你对设计的科学面有兴趣，本书将是一本绝佳的指导书，告诉你利用应用软件从目标受众收集数据的过程与原理。
　　Erik Stolterman著的论文“The Nature of Design Practice and Implications for Interaction Design Research”是一篇简短的学术论文，其中引用了其他许多有影响的论文，讲述了设计的本质，以及处理其复杂性的方法。
　　Charles Wallschlaeger和Cynthia Busic-Snyder合著的《Basic Visual Concepts and Principles: For Artists, Architects and Designers》可以奠定你感知和构建物品美感的坚实基础。
　　Andy Hertzfeld著的《苹果往事：开发麦金托什的非凡岁月》（Revolution in the Valley: The Insanely Great Story of How the Mac Was Made）围绕首代Mac计算机开发所涉及的文化和创造性展开，是关于这段经历的第一手珍贵材料，值得收藏。如果连它都无法让你为做技术兴奋，那就没别的书能做到了。
　　Steven Pinker著的《How the Mind Works》涉及我们如何理解人类心理的全面历程。它不只直接相关于软件设计，还深入探寻人如何思考，设计原则如何对人们发挥作用。
　　Daniel Kahneman著的《思考，快与慢》（Thinking, Fast and Slow）是一本有关人们如何注意、判断形势及做出决定的书，是有科学头脑的设计者的另一本有看点的图书。
　　下列文献材料不是书籍：
　　Bret Victor的半小时谈话“Inventing on Principle”。Bret Victor是iPad及其他杰出成果的交互设计师。他在技术设计方面拥有最周到和充满灵感的头脑。这段谈话是学习他的很好材料。你可以一年左右听一次他的这段讲话。
　　Ideo方法卡。产品设计公司Ideo制作的一种扑克牌。每张卡片都描述了一种“以用户为中心”的实践方法，可供设计者用来处理某个有趣的问题。你可以时不时地翻动这副扑克来寻求思路，对某个给定项目拿出部分卡片组成小副扑克，或者取出大部分卡片组合出自己的办法。
　　倾斜策略。一组卡片，每张卡片上面都有个深奥的单词，可以激发遇到创造性问题的人，并指导其努力方向。它们最早是由Brian Eno和Peter Schmidt为音乐家创作的。由于各行各业有创造性的人们发现，用它们突破困难很有用，所以都在用它们。这些卡片本身已经很少见了，但可以找到大量基于网页或应用软件的版本。
　　我发现上述资源很有用。希望它们能出现在你自己的影响与灵感世界里。
　　好了，下面开始设计软件。
　　致谢
　　动手写本书挺难的！对那些帮助成书的人，我非常感谢。
　　谢谢Barbara Gavin和Erica Sadun给我机会，邀请我出席Voices That Matter系列座谈会，并让我这个内向、不善言辞的人在会谈上发言。这最终促成了本书写作项目的确定。感谢Addison-Wesley出版社的Trina MacDonald，他在我写书过程中提供了指导。感谢Betsy Hardinger编辑本书，使我这个蹩脚的作家进步不少。非常感谢我的审校团队：Lukas Mathis、Jim Correia和Jon Bell。我相信他们的智慧，这是我在努力写书时保持信心的原因。
　　感谢我在Omni集团的所有同事，是你们给我机会来工作，以创作好的软件，并能够与睿智的人们交流。每一天，我都感觉自己在侥幸成功。感谢我在华盛顿大学“以人为本的设计与工程；理工硕士项目”（Human-Centered Design & Engineering professional M. S. program）的导师和同学。在那个项目中，我最终获得学术基础，从而从事目前的工作。感谢我在#rosa的亲爱的朋友，因为你们给了我无尽的支持与鼓励。
　　我还要向Yasunori Mitsuda致以敬意和感谢，他的Xenogears相册给我提供了按键的音轨。还要感谢西雅图那几个咖啡屋给我提供的完美写书环境。
　　似乎每本书的致谢都会提到家庭成员的耐心，我现在也理解了。在此向我的妻子Hiroko致以感激和爱意，因为她给了我坚定的支持和耐心。我所做的每件事都终将感谢她。
　　读者服务
　　请访问我们的网站，并在informit.com/register注册本书，从而可以方便地访问更新资料、下载文件，以及本书日后可能提供的勘误信息。
　　

.　　画草图。
　　画线框图。
　　做实体模型。
　　做原型软件。
　　但这仅是为了把它们以“某种”顺序呈现出来，并不意味着你得按这个顺序去做。在实际工作中，项目确实是按非线性且有组织的方式推进的，在这些步骤间交织，通过对手边设计问题最有效的解决路径进行，如图1.1所示。如果你想设计任何有价值的东西，即使在整体软件开发过程严格固定的单位，仍然需要在这些实践间往复、半随机性跳转。
　　图1.1某软件设计项目的纷乱过程
　　1.2编写软件说明
　　你可能熟悉典型的提纲：一种层次的、缩进的条目清单。这是个跟踪项目的奇妙方法。有许多应用软件都保存着这样的清单。但在阅读本章时，请考虑下面所有这些关于软件设计和开发编写的不同实践方法。
　　传统提纲很适合于在最初理清头绪时探寻各种念头，组织需求文档，并与团队交流复杂的想法。在项目的任何位置，如果你发现自己受某个复杂问题的困扰，可以考虑做个传统提纲来理解这个问题。有分析头脑的人会觉得提纲是组织信息的最自然方式。Mac和iPad上有一些不错的提纲应用软件，它们能让你更方便。
　　无格式文本是个速记你的想法和要考虑的事项的简单易行的办法。但将文本文件层次化、条目化有些困难。它们易于共享，尤其在通过云服务将其保持同步时。
　　待办事项应用软件的任务能够在你规划出要做的事情后，让你按部就班地去做。它们往往只是短期使用，且供个人使用，而不会为团队提供对某个话题的全面、准确定义的记录。
　　缺陷跟踪数据库中的记录单可以让团队的每个人都更容易看到目前问题的情况，围绕它所进行过的讨论，以及人们提到过的解决方案。但它不适宜给出整体概述。你不能指望缺陷跟踪帮助你了解任何超出某个单独问题的内容。
　　纸和白板对于快速进行个人规划，或者在与别人会面时是个极好的工具。没有比这种方式更容易地完美结合提纲与草图了。一旦你和别人在白板做了交谈，就可以拍个照片永久保存，以备日后你回忆“那次会议上我们是如何考虑的”。
　　在项目管理软件中的计划是个跟踪待办事项的正规方法。对于项目经理等管理者来说，这是可以在一张大图上观察项目现状的宝贵工具。但在面对困难的设计问题时，它们不能帮助观察决策之间的细节，因此也就没那么有用了。
　　设计说明文档即“spec”，是团队对一份软件计划和意图的明确、完整的描述。这取决于你的组织和过程的正规程度，对于这类文档，可能会要求遵循IEEE 1016标准。
　　最可能的是，你会组合使用这些工具，来保持对设计项目若干层次细节的跟踪：例如，用文本文件报告缺陷，记录白板照片，列出若干提纲清单等。你喜欢用哪些工具取决于你需要什么程度的细节，你是否与团队协同工作，以及你最擅长运用哪些应用软件。
　　重要的是，把全面的、条目化的事物放在一起，从而通盘考虑项目：从最泛泛的目标到细微的、吹毛求疵的细节。有些提纲有几百个条目，例如，将某复杂应用软件的所有组件都列出来；有些提纲则只有几条很精确的决策，花几个小时就能搞清楚。
　　即使你没准备正式的文档，有一份（或一套）文档仍然很有价值。你可以让这些文档正规或者随意，但要充分描述团队对其所做项目的理解。（即使你未与一个团队协同工作，这仍然很有用。）要确保这些说明文档像源代码一样，也放入版本控制系统中，确保它们总是最新的。
　　还要将设计里（以及讨论中）被摒弃的想法保存起来，这些想法说明了你没有采取某些看似诱人的选择的原因。被摒弃的想法可以防止你为同样一件事情而纠结，它们应成为应用软件的“需求禁忌”，这将在后面论述。将软件按说明文档创作是个好方法，通过它不会丢失对待办重要事宜的跟踪，人们也不会误解软件未做完的地方是有意为之的，还是终归要做到的。
　　1.3厘清头绪
　　好了，是该勾勒你的应用软件的外形了。在项目的最开始，从头脑中梳理出你想到的所有功能、挑战、想法和问题很有价值。你把它们都写到一张清单中，随后将其组织成层次结构，或一开始就按层次结构排列。重要的是要列出想到的所有东西。清单中的某一条目可能会带出其他条目等，快得令你跟不上思绪的步伐。或许，你可以静坐片刻，让大脑休息一会儿，从而想出更多的东西。
　　在你考虑项目时，下面这些建议可供你拓宽对某些问题的想法：
　　一般性需求：应用软件是干什么用的？哪些人是受众群体？
　　需求忌讳：应用软件一定不要干什么用？哪些人不是受众群体？
　　初始设置。
　　数据类型。
　　观察数据。
　　添加、编辑和删除数据。
　　分类与层次化。
　　特别迅速或容易做到的任务有哪些？
　　可能要支持但对于主要目的只起补充作用的任务有哪些？
　　导入、导出及共享。
　　与其他应用软件或服务的兼容性。
　　偏好。
　　最终，你可能会有张或长或短的清单，其中表达了按你目前的理解要解决的所有初始的设计问题。也许日后证明有些条目是多余的，大部分会证明还包含许多子问题，还会牵扯出新的问题。但毕竟这份初始清单给你指明了起点。
　　1.4列出提纲时的更多输入
　　除了厘清头绪外，要列出提纲还有许多输入源。你可以通过开会来推敲出某项功能的细节。提纲是个随你所想，跟踪所有话题、子话题、问题和决策的极好方式。
　　如果你能直接与现有用户沟通（因为你正工作于已有产品上），或者与目标受众中的成员沟通，就可以获取海量的深层次信息。毕竟，你不能一个人想到所有东西，与用户沟通（来自支持邮件、评价等）能够让你关注自己的不足，而不是对其需求表现出全面、均衡的表达。
　　可供你收集那些应用软件的用户的看法的办法很多，下面是最常用的一些。
　　会面：这既可以是正规的，你邀请目标受众中的成员参加有组织的对话，在此你记录数据，随后分析；也可以不是正规的，你事先准备几个关键问题，在会议或行业展览上遇到某个用户，就问问他。如果你擅长从人们那里得到诚实的答案（只要他们真诚待你，这很容易），与某个热心用户交谈15分钟，其效果比在单位内部开一星期的会效果还要好。
　　情景探究：倘若你在寻求帮助人们做某件特定的工作，这会是个深入探究你要处理问题的极佳办法。在情境探究中，你在用户工作时拜访他们，观察他们的工作过程，尽可能地获取他们的说明。如果你对这种做法感兴趣，可以看看Hugh Beyer和Karen Holtzblatt合著的《情景式设计》（Contextual Design），此书是这种做法的鼻祖。
　　竞争分析：如果你想做个东西，挤进业已存在的产品市场，就一定要做些工作，找出现存产品没有做到的地方。你的应用软件做的哪些事情其他应用软件也做到了？依你看，这些开发者为何选择这样的功能集，做出这样的设计决定？什么是他们知道的，而你却不知道？更重要的是，你的应用软件有什么优势，让人们愿意买你的软件而不是别人的？系统地考虑这些问题，能够让你更深入地了解如何把你的产品差异化，做出真正有价值的东西。
　　Ideo方法卡（在前言中做过说明）有好几种做法，可供你搞清楚用户真正希望和想要的东西。
　　一旦你做出来产品，供这个世界使用，提纲和缺陷数据库就是个记录用户反馈和研究用户的结果的好办法。倘若没有数据库，即使你阅读了有关应用软件的全部邮件和推特信息，只是偶尔做一下用户测试，你也很难让用户告诉你有关应用软件的喜爱与讨厌之处。
　　在保存记录时，你可以实际查看人们是否爱抱怨如何使用某些功能，或者测试参加者与设备交互时是否存在麻烦，而不是依赖令人讨厌的选择性记忆。但是，一定要记住，你得到的用户反馈并不精确代表用户对你的应用软件的所思所想！它代表的是人们体验的一部分，人们的体验会被乐意写信反映问题的少数用户曲解。在第10章中，我们会详细讲解开发人员与用户的关系。
　　如果你开发过软件，就可能熟悉版本控制系统（如Subversion或Git），它维持一个团队所有源代码变动的中心仓库。版本控制不仅对代码有用，还可以放入所有设计资源。能够访问你的设计思路历程是无价的，不至于让你回想已经丢失的草图，而需要再画一张图。
　　版本控制系统不必是必需的；如果你用的不是命令行方式，可以使用诸如Black Pixel的图形客户端Versions（其可视化比较工具Kaleidoscope用来查看不同版本的设计文档，效果非常好）。另一个杰出的工具是Layer Vault，是专门为设计人员创作的基于网页的版本控制系统。
　　1.5列出需求提纲
　　产品需求文档可以是相当正规的东西，用来确保团队为最终交付的成果负责。提纲不是这类文档。如果你的组织在用产品需求文档，最初的提纲可能最终演变成正式的需求文档。但这里它是作为一个工具来帮助你思考的，以在头脑中形成一个产品思路。设计团队（很可能只有一个人）之外的人没必要看到这份提纲。
　　引入SnackLog示例应用软件
　　本书将频繁地用到一个假想的示例应用软件——SnackLog，这是一个记录每天购买物品的工具。不必看此应用软件的详尽描述，只要看看其最初的需求提纲，就能透彻地了解该应用软件的思路，如图1.2所示。
　　图1.2所用示例应用软件SnackLog的需求和需求禁忌提纲
　　相信你已经明白了，SnackLog的整体要点就是方便地记录诸如咖啡、停车费等临时开销，而不必是完善的钱财管理应用软件。出门在外，你需要SnackLog记录小额开支，避免这些开支从你的全面预算系统中漏掉。
　　请注意，这个需求提纲并未提到任何有关画面、走向和各功能如何工作的内容。实际上，需求提纲只是列出要做的事，而如何做则是以后考虑的问题。
　　1.6需求禁忌
　　应用商店（App Store）让顾客在一个地方就能够浏览为此平台设计的所有应用软件。突出你的应用软件的强项能够让人们在是否给予其机会时，有截然不同的效果。但在App Store里说明你的应用软件不能做什么，从而将你的与别人的应用软件差异化，也同样
　　重要。
　　App Store有一大堆面向商务旅行者的开销报告应用软件，还有旨在平衡家庭预算的钱财管理应用软件。SnackLog不属于它们中的任何一个，这样能够让产品的服务领域很清晰，使你关注自己的设计。你无需在App Store的说明中直率地指出应用软件不能干什么。但在潜在用户阅读了你的说明，看到你的屏幕截图后，他们头脑里应该对你的应用软件要做的东西没有疑问。在人们实际需要某个略微不同的应用软件时，在下载你的应用软件前对它的理解偏差应尽可能小。
　　用户反馈在理解人们使用你的应用软件时如何感受是非常重要的。但一些经常要求的功能可能按照你的哲学并不合适。不要逐功能地与你的竞争对手比拼，或者如果它们不适合你所做应用软件的个性，也不要实现广受欢迎的要求功能。应坚持你的需求禁忌！App Store上有充足的空间供大量应用软件关注解决同样问题的另类方法。请参看第11章来了解关于精减你的产品功能的更多内容。
　　1.7定义纲领
　　正如你在考虑你的应用软件应当擅长什么，应该避免哪些问题时，也许你会发现自己经常遇到类似的问题。如果你能很好地理解应用软件将来的个性，你就能定义一种纲领（如同政治纲领那样），其中列出了应用软件的核心价值、假设条件和目标。那么在你贯穿项目生命期作决定时，就能引用这一纲领指导你。例如，SnackLog可以有下列这些纲领条目。
　　人们需要长时间地记住所购物品，才能将其列支到全面预算系统中。
　　人们的小额购买通常只需归类到较短的清单中。
　　人们倾向于重复购买一些东西（如咖啡、点心等）。
　　倘若购买的记录过程长于15秒，人们就不会愿意用它。
　　如果人们在携带一杯热咖啡时不能方便地记录开支，他们会决定不用这个软件，而不是放下饮料记录开支。
　　任务管理应用软件可能包含下列论断的纲领：
　　待办事项清单并不是日历，约会不会在其上。
　　当规划你的待办事项清单时，你应该能看到所有的条目。
　　当查看自己的待办事项清单时，你应该只能看到目前要做的事情。
　　在人们想到新的待办事项时，应当能够快速容易地记录，而无需脱离目前操作的环境。
　　视图设置不能让用户轻易地隐藏他们的重要事项。
　　倘若你坚持这样做课题，那么你所开发的应用软件就能独树一帜。只要你有了真正信赖的纲领、坚决的论断，营销文案几乎不言自明。事实上，你也许想达到纲领定义的方法，就如同你在为并不存在的应用软件编写营销文案一样：在你设计应用软件之前，编写你期望其在App Store里的说明文字。这样可以帮你考虑受众和目标，而不单单注重功能。你将应用软件纲领定义得越好，越能让人们确信它有趣和独特的原因，并让人们相信值得安装它。
　　1.8列出分歧
　　请注意，SnackLog提纲中的有些条目是问题。通常，你并不知道某个功能是否适当，直至你真正地考虑它。后面的阶段（画出草图、绘制线框图、做出实体模型、推出原型软件）通常会让答案更清晰。但提纲还帮助你对主要问题推敲出所有可能的答案（以及更深入的问题）。下面是探究两种备份选项分歧的提纲。
　　电子邮件？
　　正方：超级简单，相当容易实现，可与别人共享（如果你因故需要把购买记录发给别人），不需要通过计算机就可以实现。
　　反方：文件会随着时间变得庞大，用户必须记得备份（提供偶尔的提醒器，这可能有些烦人。难以算出适用于每个人的提醒周期），自动发出电子邮件？（也会是件烦人的事。）
　　iTunes？
　　正方：容易实现。
　　反方：用户必须记得备份（在连接上计算机时），难于同别人共享，必须使用不太理想的iTunes文档管理界面。
　　分歧提纲是个自我开展辩论的好办法，从而找出对一个想法的所有支持因素和反对因素。在写下此提纲之后，你大概会发现电子邮件是个比较好的办法。它并不完美，但比其替代方案更具吸引力。目前，你需要知道的就是，在开始画草图时，哪个方向更有前途。倘若若干选项都难分伯仲，那么可以使用草图来对它们进行对比。
　　1.9iOS与特色
　　在考虑你的iOS应用软件的特色时，你就在考虑平台了。iPhone和iPad的部分魔力就在于，它们能够大刀阔斧地删掉对各应用软件所期望的功能。平台是基于触控的交互模型，相对有限的硬件说明文档，以及即时反馈的高优先级，使应用软件显得更健壮、瘦小。iOS对强大、功能丰富的软件有足够空间，但典型的应用软件远比其桌面计算机版本更有效率、更专注。这里的“专注”意味着你可以让目标用户体验精确调节，而无需过多操心取悦每个人。
　　所以对于你考虑的每个问题，宁可在省略功能上犯错，特别是你后来添加的功能。当然，庞大、什么都想做的应用软件照样还会庞大、什么都想做。但它们没有你在桌面计算机上的版本那么庞大、什么都想做。
　　本书的第三部分，尤其是第11章，会详细介绍如何判断哪些功能适合放到你的应用软件里和哪些适合放到iOS平台上。当考虑是否在最初提纲中容纳所提及的功能时，也许你可以在那里得到些有用的指导。
　　1.10减少问题
　　列提纲时还要顺便解答一个关键的设计问题：这些条目会不会是同一件事物呢？设计的相当大一部分工作就是找出产品到底要做成什么样子，它的每个组件如何组装到一起？两个需求能否通过一个功能满足？某个功能是否做的事太多，若分解成多个功能，会不会更顺畅些？作为设计人员，你的个人风格很大程度上就是你在合并、拆分应用软件的组件时的力度，所以要准备花大量的时间来考虑这个问题。
　　例如，在SnackLog设计中，你正考虑是否要包含标记和多用户支持。在组织提纲时，你发现它们似乎均可以放到“分类化”下面。这是个信号，表明它们也许可以被合并。要考虑是什么（如果有）造成了这种区别。它们都要求设置、应用购买标签。在浏览购买记录时，它们也需要过滤或搜索。看上去是如此相似。
　　你可以列出好几条多用户支持的功能，因为它们不太像iOS的功能。例如，对其他用户隐藏某个用户的购买记录。iOS设备通常是一个人用的。如果有多个人在一台设备上存放记录，他们也很可能是一个家庭的，因此不会介意共享信息。最后，在iOS应用软件里支持多用户并不合理。但如果人们真想共用SnackLog，可以为每个人创建个标记，就可以得到多用户支持的绝大多数功能。所以这两个功能可以合并。
　　所以基于两点原因，你就可以放下支持多用户的想法。一是在iOS上似乎没有必要；二是你可以采用标记的办法实现多用户的多数功能。事实上，你还不算真正地抛弃这个功能，而是将其合并到一起。在iOS上充满了此类功能的合并问题。
　　还要知道，有些时候看似一个功能，实际却要拆分为一个或多个更专一的功能。以删除为例，乍一看，删除所有条目只是删除单一条目的变种操作。所以无论你构思到哪种操作，都要每一条目逐个表现出来可删除的功能（在实际交互过程中，可以想象有个垃圾桶图标，你点击它时会提供“单个删除”和“全部删除”按钮）。这么做有点可怕。人们经常会删除单个条目，但很少想把整个购买记录都干掉。虽然都是删除操作，但你需要用迥然不同的方式来设计它们。在修订自己的提纲时，你可以把“全部删除”从浏览功能移至设置区域。你也许不再将它称为“删除”，而改称为“复位”，以示区别。构思符合你的有关功能思路的词汇，将有助于你设计实现它们。
　　1.11列出架构提纲
　　你已经很好地了解了要包含的功能，现在该考虑如何将它们放到应用软件的不同位置了。这里，架构提纲将有助于你画草图和线框图。这类提纲让你便于在充满控件的屏幕、子屏幕上组织各种功能。你或许会在画草图时发展提纲，因为你所画的各种布局会支持你已经确定的功能。图1.3给出了简单的架构提纲。
　　1.12提纲即待办事项清单
　　接下来在绘制草图、线框图，实现实体模型、原型应用软件时，都可以参考先前所列的提纲。它们起到对所有要考虑事项的检查清单作用。你对这项功能画过草图吗？你的线框图能解决那个问题吗？对照提纲逐个检查条目，确保你没有遗忘任何东西。开发应用软件是个巨大的项目，要拼凑大量细微的部件，所以你要确保在最后一分钟前添加或修改了所有需要的东西。但预先做好这些工作，会让你避免出现最坏的情况。
　　1.13小结
　　缩进而分层的清单并非将思路理清的唯一方法。但它们是很好的方法。你可以采用各种组织良好的书面材料来跟踪项目。但要尝试记录需要包含到设计的每一项内容。列出所有形状尺寸的提纲，有利于在设计应用软件的任何阶段，对复杂课题分门别类。
　　从厘清头绪开始，把所有的想法都写到纸上。构思最早的需求提纲，会让你直面项目的所有设计挑战。精简问题、概括问题有助于强化需求提纲。
　　1.14练习
　　1. 既然你已经看到简单应用软件SnackLog的最初需求，尝试创建一个自己的应用软件。考虑该应用软件需要做的所有事情，不必操心特定的实现或交互细节。指出某些功能应该怎么做，会让人感觉舒服（反应迅速、不让人眼花缭乱、个性化），但现在还无需写出具体的设计（按键、颜色、流向）。还要列出你的问题。任何有趣的应用软件思路都会有几个没有答案的问题。
　　2. 检查你列的提纲，找出可供精简的功能或概念。有些思路是否应被合并？还有些思路是否应被拆分？
　　3. 试着把问题也列成提纲，要明白应用软件该如何与其他iPhone或iPad应用软件协调。列出支持意见和反对意见。然后看看应该采取哪个方向，否则还要深入研究一番。
　　第2章
　　画草图
　　画草图是设计的中心活动。作为一名设计人员，你应该能够把头脑中所有的、随意的想法画成草图，将这些想法从头脑中抽出来，形成人们能看到的样子。有时，对你来说，明白一个思路很重要，有时对别人来说明白一个思路很重要。在你有什么事物要分享、引用、着手做时，只有这样，你才能在其基础上继续发展（或者摆脱原本的想法）。
　　列提纲是为了探究设计问题，而画草图则是用图解的方式来研究问题。取决于这个问题，你可能需要创建一个提纲、一个草图，或者两者兼而有之。随着你的不断练习，你会更好地理解何时用到哪种形式。有时你还能把两者都跳过，直接画线框图，请参看第4章了解更多内容。
　　要成为一名高效率的软件设计人员，并不是要有艺术技能，不断冒出炫人的灵感，或者维护一篇令人喝彩的设计日志（尽管内容并不重要）。而更多的工作是把你和团队的思路画成草图，研究它们如何协调工作，然后画出更多的草图。作为设计人员你的价值与构思伟大点子的能力无关，但要有能力去意识到一个点子带来的希望，无论这个点子来自何方，然后不断推动直到它表现得生机勃勃。
　　倘若你被草图的威力所激发（也应该如此），就该读读Bill Buxton的书《用户体验草图设计：正确地设计，设计得正确》（Sketching User Experiences）。通过阅读一个懂得并推崇画草图的人的书，了解其哲学和产品设计流程，将是一个激动人心的历程。
　　2.1边画边思考
　　草图让你可以在视觉上自我沟通，或者与团队的其他成员沟通。即使有些东西在你的头脑里相当明晰，也应将其画出来，才能确保它说得过去。这只需花费片刻时间。
　　一旦你有东西画在纸、屏幕或者白板上，就可以供别人指点。你和团队可以说，如果这个东西放在那里会怎么样？屏幕上的主要元件是什么？这次交互过程的主体是什么？这个体验的核心是什么？即使你还没有详细列出细节，大体明了计划包含什么、产品存在的空间在哪里，仍然都是无价的信息。
　　最令人振奋的设计思路往往都是在画草图过程中产生的。大多数应用软件都是大量明智、实用决定的结晶，贯穿着各种智慧和创新的设计思路。智慧和创新这两种类型的思路都用草图表现。有时，草图能让人们召开会议，也可以是咖啡机旁的谈话；还有些时候，孤行的设计人员通过草稿本来进行自己一个人的“交谈”。
　　2.2谈话中论设计
　　你在开会。会议已经开了半个小时。每个人都在谈论你关于Framistan应用软件设计的提议。他们都自认为清楚你提案的概念和分歧。有些人赞成你的想法，有些人则反对。
　　最后，为了阐明其中一些细节的要点，你把Framistan画到白板上。突然，房间里有一半人站了起来：“我没想到这里有个‘取消’按钮！”，“噢，这只是个消息框，而不是全屏窗口？”，“啊，但如果你旋转了iPad，结果会怎么样呢？”，等等。这说明每个人对Framistan都是各不相同、模糊不清的想象。一旦他们明白你对Framistan的外观是如何构思的，他们才能建设性地添加自己的主意。
　　用草图开启这样的会议，并在交谈过程中不断绘制草图，能够杜绝这种混乱。随着会谈地进行，草图也不断进化，体现出团队对你的思路的共同理解。删除一些东西，砍去某个东西，添加一些东西，让草图不停更新。由一至两个人负责绘制，以便让草图在更新时保持连贯性。如果有竞争性的思路，要把它们逐个画出来。完工后，你可以拍下白板（或纸张、iPad）的照片，通过电子邮件发给组里所有的人，并添加到设计文档中。
　　无论在哪儿，只要谈及设计，都应有个白板或者其他不费气力的工具供你绘制草图。经常删除上面的内容，鼓励人们使用这些工具（参看图2.1）。
　　当然，你也许并不在一个团队工作。你可能是孤独的设计加开发人员。那就随意画草图吧。只运用你的想象力还不够，还需要个快捷的方法来自我交谈。你可能会发现，你做过的假设并不成立，或者忘记了某些重要的组件。最终，你对应用软件轮廓会有个好得多的设想，你会更好地准备明确该产品的规范。
　　许多时候，你在画草图时中途嘎然而止，意识到其背后思路其实是错的——这很好。你越早画出草图，就能越早地发现其错误之处。标新立异的草图是迅速剔除走到死胡同思路的绝佳办法。
　　即使你已经知道某个想法是错误的，把它画出来仍有助于你找出原因，怎样可以做得更好。标出它错误的地方。也许这个错误草图的某个地方还能激发出新的想法，让你收获正确的草图。
　　橡皮鸭法
　　编程领域里有个橡皮鸭法，它也适用于设计人员。这个故事来源于某个不知名的程序员，他的办公桌上放着一只橡皮鸭，只要他遇到一个看似难办的问题时，他就面对这个橡皮鸭，跟它说话，把问题解释给它听，如同它就是一只不懂编程细节的水鸟。相类似，试着把你的问题讲给别人（任何人）听，当你说清楚时，解决的办法可能就显现出来了。
　　设计人员的橡皮鸭法与此相似，只不过经常还包括绘制草图这个过程。如果你遇到没有明显答案的问题，就把它画出来。把它一步步地讲出来，如同向一个对你所做项目毫不知情的人讲话。你会惊奇地发现，这种做法经常能不知不觉地降低问题的复杂性。
　　许多时候如果设计者把橡皮鸭当成一名团队成员，无意中就能解决问题。我的组员Joel有时随意晃到我的办公室，和我谈谈他正揪心的设计问题。大部分时间，我们都会正常地来回交谈。但后来有个项目我没参与，所以他先向我说明事情的现状，终于提到所遇到的问题，并试着把存在的麻烦告诉我。同时他在我的白板上涂鸦。在某句话说到一半时，他突然很兴奋，因为有个主意钻进了他的脑海。他打断了刚才的话：“所以我们不能用‘编辑’按钮做这件事……除非……是啊，太感谢了，Bill！”在这个时刻，我并未说一句话，依然帮助Joel解决了问题。我说：“我很乐意今天当了你的橡皮鸭。”而他，匆忙回到办公室去实现他的新主意。
　　2.3绘制草图的工具
　　任何东西，只要能让你迅速画图并修改、涂鸦的东西都可当作绘制草图的工具。不必选用精致的本子来打草稿，如纸张考究、完美的格子、匠心独运的皮制封面。可以花一辈子时间来尝试铅笔、钢笔、记号笔、纸板和其他画草图的工具。还可以安装使用全屏的绘图、素描型iPad应用软件。
　　就这样！人们喜欢用装备精良的工具来做事，用这样的工具是种享受。但不要买椟还珠，迷恋工具的精确性，而忘却画草图的要点。草图应该画起来迅速、粗糙可更改。返工和回想先前草图应该能信手拈来，而一旦这些草图达到你的目的，你可以得意地销毁它们。要是在你那每页值25美分的笔记本上，用总是怕丢的名牌铅笔画出你那5个疯狂点子的草图，很难说这是否妥当。
　　纸和白板是最显而易见的选择，而且几乎仍是再合适不过的了。采用它们，无需费劲或费心就能把脑海里的简单想法摆到台面上。在你构思的过程中不断更新草图。要确保草图能擦除，除非你画的图特别简单，以至于每次改主意时还可以重复把它画出来。
　　软件在重现纸和白板那些活泼、惬意的草图方面做得越来越出色，特别是在iPad上。尤其你在拿起一杆电容笔，在触摸板上绘图时，可以运用下列应用软件，慢慢试着替代用笔记本做的同样的事。
　　Paper是个日益受欢迎的草稿软件，带有模仿模拟工具材料的强调功能。
　　Remarks是个画草稿和写注释的特色草稿软件，方便绘图，还有各种同步选项。
　　OmniGraffle是个纯粹的绘制流程图、图形的应用软件，支持矢量图形、层等，还包括徒手绘图功能。
　　Penultimate是个很流行的书写与绘图的应用软件，带有“护腕”功能，如果你想在绘制时把手放在屏幕上。
　　但是，用iPad有个很不方便的地方，就是尽管iOS的延迟出奇得小，仍然没有快到让人感觉是在实时绘图。屏幕还是跟随你的绘制有拖尾，这会打断思绪，让你迟疑，放慢思维的脚步。画草图应当迅速、容易。如果你有太多时间花在绘图上，是否会正确反映你的思绪，或者总是要撤销刚才的绘制，因为线条并不按期望的角度出现，或者手绘有些地方不连贯有损毁，还是考虑用模拟的工具吧。
　　2.4草图毕竟是草图
　　草图是有意粗糙的，它们只是反映一个想法的要领，而不是整体、完全正式的产品规划。画草图是为了提醒看的人注意其概念，而不是执行过程。好的草图知道它是草图，而不是实体模型（看似最终产品）或者原型应用软件（操作起来像最终产品）。
　　如果你担忧自己的美术技巧不够好，这是没必要的。画草图还不是画图。你只需要在纸上作标记，来沟通想法，让谈话进行下去。这与其美观或整洁是没关系的。
　　要慎用那些图形软件，它们能创作出太过完美的图形和文本。这些一致的绘制手段会拖慢你的思绪，因为你会想要把画的东西排列整齐、有序组织。将其保存成线框图和实体模型，它们的目标才是精确性。（有的绘图应用软件，如OmniGraffle，在你需要时，可以容易地将草图风格的东西直接转换成精确、高度逼真的物件。）
　　更重要的是，草图的草稿性质让看它的人不会关心其风格、尺码、精确位置或者其他特定指标。这有助于你更快地画草图，而不关心是否要创作美观效果。它还让查看的人在评判时有自己的期望。所以在绘图应用软件模仿模拟文具时不只是敏锐度的问题，粗糙的风格有助于沟通绘图的尝试性本质。
　　草图只是提供某种潜在方式的建议，事物可以是什么样子的，可以和周围事物发生怎样的联系。它们传达的信息是：“屏幕上有这些东西，大致是这么安排的。”“在这里，你可以到那里、那里或那里。”“这里没有回退按钮。”它们绝对不会说：“这个面板有个界线，应采用没有饱和的绿色背景。”或者“这个按钮高32个点。”或者“这个表格视图上的文本应当这么精确地组织。”
　　由于只是草图，日后回顾起来可能会让人糊涂，尝试搞懂它。所以只要你领悟到草图绘制过程的精髓，就应写出或绘出你的收获，这将很有好处。不要指望草图本身帮助你记事。
　　2.5何时画草图
　　在若干情况下，画草图是很有必要的。
　　描述架构提纲。最初，你要仔细检查整个架构提纲，画出每一幅画面的内容。每个功能都要能看到，每步流向都要明确，架构提纲里的每个条目都要以某种形式在草图中体现出来。一时间，你的各个想法和注解组成了可供检查和发展的基础。这些草图和提纲一起呈现出了对应用软件应该如何表现的高层次理解。
　　直接画架构草图。倘若应用软件规模较小，其功能可以通过所提供的画面显示来定义，就可以跳过架构提纲，直接从架构草图开始。对小不点型的应用软件（如内置的Stocks或Notes），这是最简单的办法。它们只有几个画面，界面大都是静态的，没有太多的流向。
　　混合方法。有些时候，甚至在早期，你已经对应用软件主界面有相当好的直觉理解。这些情况下，如果相信直觉，你可以从画出屏幕开始：在熟悉的应用软件里编辑典型的文档，在信息型的应用软件里查看典型的状态画面；在教育型的应用软件里开始一节典型的课程等。先做这个草图，可能让你有足够材料来思考架构提纲。一旦你知道主界面的外观该是怎样的，就很容易列出所需做的其他事情。
　　除此之外，你还可以随时画草图。对于项目过程中冒出的大多数问题，画点草图都会有好处。草图可以是含糊的，也可以是完整的，因情况而异。两个人站在白板前谈论某个界面的细节，交谈过程中可能会想出多个大致可行的方案。而其他人随后看到这个白板上的内容，也许搞不清楚它画的是什么。草图只是一种短暂的沟通辅助手段罢了。相比之下，架构草图应当足够清晰，你和别人可以参考这些草图，无需太多解释就能理解每个画面的思路。
　　设计从来不会遵循一条事先能预见的路径，原始提纲中描述的产品也不会恰好如你设想的那样变成现实。那是正常的。持续不断修改正是设计过程的一部分。在你不可避免地决定要添加或改变一项功能时，就要把它实现并画出草图，就像它一开始就在规划中那样。
　　一般来说，几乎每样东西都至少要画一次草图，也许画好多次草图才能定案。倘若你保存了先前的草图，则日后回顾这些草图，就会惊奇于哪些部分没有改变，回忆起那些可能还有些价值的过时想法，还会对你过去那些疯狂无知的主意感到好笑。
　　时刻记住这是iOS平台
　　如果你还没读过苹果开发者网站上的《iOS人机界面指导原则》（iOS Human Interface Guidelines），那么现在是该读这本书了。要想大体了解在这个平台上可做什么、能做什么，你要把这部书牢记于心。即使你已经用iOS的应用软件好几年了，并对其深有体会，也肯定有些你不知道的地方。例如，你知道模态视图的四种风格吗？每种风格适用于什么情况？
　　花时间熟悉你在iOS上可做什么的基础知识，这是很值得的：表格视图、导航控制器、分割视图、浮动框等。如果想了解更深入，可以参看本书第3章对《iOS人机界面指导原则》做的延伸和评述。
　　当然，在给iPhone或iPad画草图时，记住比例系数（即硬件屏幕的尺寸）是很关键的。记住在iPad上，所有草图要既能适用竖向放置（垂直），又能适用横向放置（水平）；而在iPhone上，可以容易地只用一种放置模式。同样，所有要输入文本的画面都应该容纳键盘，在某些语言中还要容纳出现在键盘上方的完成栏。
　　没有必要为每个想法画若干个草图，每个草图都包含放置模式和键盘的状态，但不要创作任何依赖某种放置模式而键盘一旦出现就会破坏整个效果的草图。现在就记住这些要考虑的因素，在第3章中会正式地探究它们。
　　2.6利用先例
　　对绝大多数设计来说，你的草图都不会是全新的概念。小说家在编写故事时，不会为每句话发明新的单词和短语（James Joyce是个例外）。他们利用先人的创新成果。你的大多数草图也没有必要彻头彻尾地原创。基于已有先例创作出新成果，才是更靠谱的做法。你所做的每个设计决策都在其他应用软件里有所反映，都使你自己的应用软件更令人熟悉，更像是iOS上的风格。
　　熟悉了iOS平台，你就可以使用常见的画面和交互方式来表达草图的图形了。无需从头开始，可以利用已有的东西，将其修改来满足任务需要。下面是些示例：
　　社交应用软件里的消息清单，可以模仿Mail里的消息清单。
　　模仿iBooks或播客（Podcasts）的媒体拾取方格。
　　让人一看就想到Voice Memos的音频录制界面。
　　要了解更多的先例、样式、格调和简略表达法，请参看第14章。
　　2.7应对唱反调
　　设想一下，在某个功能是否该包含到你的应用软件，或者某个功能该如何表现，你不赞同团队里某个成员的意见。许多时候最好的捍卫武器就是你画草图的能力。
　　把你倾向的想法和反对的意见都完完全全地画出来。实事求是。不要因为不赞成，就刻意把反对的想法复杂化，或者贬低其潜能。把两方面的主意都尽力表达出来。
　　如果你是对的，那么在你完成绘制自己想法时，就能显而易见地看出你的想法比反对意见更有吸引力。将它们视觉上并排放在一起指出相互的区别，是很好的辅助手段。“看，如果我们要包含这个功能，需要添加这个、那个控件，顶层画面就会变得拥挤不堪，因为我们必须分割不同种类的功能。”
　　倘若你是错的，反对意见根本没那么糟糕，你把它画出来就能领悟它的潜力。不管哪种方式，你对其中某个选项所发现的缺点，都会强化无此缺点的那个相反选项的吸引力。所以有些时候，B主意的草图会使A主意越来越像应该采纳的方法。
　　2.8绘制界面草图
　　最直接的草图就是字面上的界面：你实际在画大致iPad或iPhone尺寸的矩形，并填充以屏幕控件的大致形式。这有助于你看到每个屏幕的大体关系。每张草图都要解答一个问题。一张草图要能回答下列问题中的某些，但可能不会马上解答所有问题：
　　多少内容可以恰当地放到你拥有的空间里。
　　应该用什么样的标准元素：顶部工具栏、底部工具栏、页签栏等。
　　你想构建什么样的定制控件。
　　控件如何分组。
　　画面角落和边缘应该布置哪些控件到主要位置。
　　你有多少空间可用。
　　但草图不能解答下面这类问题：
　　实际的颜色、纹理等风格。
　　精确的尺寸。
　　确切的标签文字及说明性文字。
　　画界面草图的目的在于对特定画面外观有个初步的感觉。某页签会不会有太多的按钮？（苹果的《iOS人机界面指导原则》限制iPhone页签栏最多为5个按钮。）是否忘了提供回到前一屏幕的方法？草图只需要精确到能回答你的问题即可。所有具体的绘图都会在线框图阶段实现。你的架构草图更像是要列尽每个屏幕的所有内容，而其他草图则省略大部分的屏幕内容，只是关注于某个特定方面。
　　现在来看SnackLog的一些界面草图。原始提纲里的条目第一次将形状作为设计。在需求提纲里，我们想要迅速并且只需要一只手就可以输入购买记录。现在我们清楚可以达到的程度：拍照界面叠加输入价格的透明键盘，如图2.2右图所示。这个构思是在想出若干想法之后达到的，之所以选择这个方案，是因为它最好地实现了该类应用软件的需求。这个做法当然比那种乏味的只有两个输入栏、一个按钮的想法更好地体现了软件的思路。它独具特色，又有着显示数字键盘的界面，让人有种亲切感，因为用户熟悉iPhone的锁屏画面和Phone应用软件。
　　图2.2SnackLog的两种购买记录画面。左边是一种平淡的要求多次点击的方法；右边的方法则高效，结合拍照界面和数字键盘。这些图片是用草图绘制软件制作的，便于理解。如果是你自己画草图，就可以（也应该）画得再粗糙一些（就像图2.1所示的白板图那样）
　　我们单独保存购买清单，是为了让输入过程尽可能地顺畅（参看其草图，图2.3）。为保持设计这种基于照片的性质，每次购买都以图片而不是标题的形式标识（除非用户手工输入了标题）。整体设计遵从大量iPhone应用软件的表格视图先例（例如Mail、Contacts、Music等）。这些先例都用垂直分组单元的形式来表现数据清单。这种表现形式很好，因为它令人熟悉，且容易实现。没有必要重复发明车轮，可以另辟蹊径来表达按日期顺序排列的一组条目集合。
　　2.9画交互过程草图
　　有时你不仅需要描述静态画面，还要表现人们如何与此画面交互。按动这个按钮，会弹出这个框图。点这个单元格，会进入下一层，等等。这种从一个状态移动到下个状态对软件设计而言，其重要性至少不亚于单独的各个状态（而且当你在指望别人完成此工程工作时，将此明确化，就更
　　重要了）。