最直接的草图就是字面上的界面：你实际在画大致iPad或iPhone尺寸的矩形，并填充以屏幕控件的大致形式。这有助于你看到每个屏幕的大体关系。每张草图都要解答一个问题。一张草图要能回答下列问题中的某些，但可能不会马上解答所有问题：

多少内容可以恰当地放到你拥有的空间里。

应该用什么样的标准元素：顶部工具栏、底部工具栏、页签栏等。

你想构建什么样的定制控件。

控件如何分组。

画面角落和边缘应该布置哪些控件到主要位置。

你有多少空间可用。

但草图不能解答下面这类问题：

实际的颜色、纹理等风格。

精确的尺寸。

确切的标签文字及说明性文字。

画界面草图的目的在于对特定画面外观有个初步的感觉。某页签会不会有太多的按钮？（苹果的《iOS人机界面指导原则》限制iPhone页签栏最多为5个按钮。）是否忘了提供回到前一屏幕的方法？草图只需要精确到能回答你的问题即可。所有具体的绘图都会在线框图阶段实现。你的架构草图更像是要列尽每个屏幕的所有内容，而其他草图则省略大部分的屏幕内容，只是关注于某个特定方面。

现在来看SnackLog的一些界面草图。原始提纲里的条目第一次将形状作为设计。在需求提纲里，我们想要迅速并且只需要一只手就可以输入购买记录。现在我们清楚可以达到的程度：拍照界面叠加输入价格的透明键盘，如图2.2右图所示。这个构思是在想出若干想法之后达到的，之所以选择这个方案，是因为它最好地实现了该类应用软件的需求。这个做法当然比那种乏味的只有两个输入栏、一个按钮的想法更好地体现了软件的思路。它独具特色，又有着显示数字键盘的界面，让人有种亲切感，因为用户熟悉iPhone的锁屏画面和Phone应用软件。


 

我们单独保存购买清单，是为了让输入过程尽可能地顺畅（参看其草图，图2.3）。为保持设计这种基于照片的性质，每次购买都以图片而不是标题的形式标识（除非用户手工输入了标题）。整体设计遵从大量iPhone应用软件的表格视图先例（例如Mail、Contacts、Music等）。这些先例都用垂直分组单元的形式来表现数据清单。这种表现形式很好，因为它令人熟悉，且容易实现。没有必要重复发明车轮，可以另辟蹊径来表达按日期顺序排列的一组条目集合。