Project » Paper Prototype
Now that you've determined what your app is going to do (via requirements analysis), you must give some thought to the form and function of your user interface. Regardless of what wonderful things your app is capable of doing, no one's going to touch it if the user experience is marred by an obnoxious interface.
It's tempting to jump right into Xcode to start assembling your nib files and writing backing code. A bit of advice: design via coding is akin to architecture via brick-laying. Don't do it! The turnaround time for mocking up an idea is unacceptably long if you have to code everything, and you're also going to be creatively hampered by what you can or cannot easily accomplish with the tools at hand. Or worse: your design may be influenced by the underlying structure of your implementation. The horror!
So for this next project deliverable I'm asking you to put aside the computer and force yourself to sketch your app's user interface out by hand. Specifically:
For every root-level view (typically managed by a standalone view controller), you should draw all subviews (controls, input elements, tabs, etc.). Subviews should be labeled with callouts/arrows (unless their purpose is clear).
If certain controls/actions would result in a new view being presented, you should make that transition clear — use an arrow with a label or textual description — just treat your prototype as a big state transition diagram.
If you plan on supporting shakes/gestures/multitouch, you should treat these as controls and document how they affect the UI. Will elements slide off the screen? Will images be magnified? Use before/after sketches to illustrate.
If there are dynamic elements to a given view (say, for the primary view in a game of pong), then sketch at least a half dozen separate static views that demonstrate the gist of what is going on. Show it to a friend to make sure your drawings convey what is in your head. Err on the side of too many drawings — they're cheap to produce!
I expect that most app ideas I've seen will require between 10 and 30 sketches (of root-level views) to properly prototype.
Some things to keep in mind:
You are designing for a touch interface, for use with clumsy human pointing devices ("fingers"). Keep your controls large and forgiving, and keep in mind how the device will be oriented with respect to the user's hand when placing your controls. For most iOS devices, the most common controls are probably best placed near the edges of the device, arguably at the bottom.
Be sure that your common use cases are documented and, preferably, optimized. If you're writing a productivity app, what are the tasks the user will carry out most frequently, and how many taps/inputs are needed to accomplish it? If you're writing a game, how does one start a game? What happens when it is over? Is there a save screen?
If your sketches constitute a large state transition diagram, then be sure you understand (and convey) where the entry points are. I.e., when your app is started/re-started, to what screen is the user taken?
If there are user-settable preferences that impact your UI, sketch variations that demonstrate these preferences. For your first version you may want to forgo supporting too many settings — less is more: just focus on getting your core app to work right.
Most sketches should match the aspect ratio of the device you're designing for (3:2 for the iPod Touch/iPhone, 4:3 for the iPad), but if you have views that are scrollable or dynamic, you might want to sketch the full "virtual" view to help orient yourself, then separately figure out how the device's screen — the viewport — factors in.
Gestures and shakes are cool, but are typically hard to discover (and not everyone likes them). Most actions that can be accomplished using a gesture/shake should have an interface alternative. A good example is the swipe-to-delete gesture supported by tableviews; you can usually hit the "Edit" button and tap to delete, too.
Here's the rubric I'll be using to score your work:
(4 points) Are your sketches tidy and legible? (Use a ruler!)
(4 points) Is it clear how each view is arrived at (i.e., are the state transitions documented)? Are starting views identified?
(4 points) Is every UI control on each root view clearly labeled and its purpose identified?
(4 points) For dynamic views, are there before/after sketches that make the interaction and associated animation(s) clear?
Please note that your submission should be in paper, at the beginning of class on the due date. No electronic submissions for this one!