The initial project team (end users and developers) will then think about how the application will perform on the mobile device. Mobile devices may have a 1 by 1 inch screen, which makes 80 columns by 24 lines extremely difficult to see. Unique factors to consider for mobile devices are:

• Limited display size. Phones may be able to display 12 to 20 characters by 3 to 10 lines. PDA’s may have 30 to 60 characters by 10 to 18 lines. Use short, meaningful words and phrases.
• Monochrome with no graphics or limited graphics. On a phone, you may have 48 by 96 pixels, and a PDA 160 to 240 pixels limiting your graphic size and resolution. Graphics may be used to replace several lines of text, but do not assume your device will have graphic capability. Many of the web-enabled phones currently available, are text only.
• Difficult data entry. Choosing data from a list of choices, is much faster and less frustrating than pressing the "1" button three times to produce a "c" and so on. Do not ask the user to input a date, give them predefined data (the Use Cases will aid you in determining important dates or other fixed information).
• WAP Phones are telephones. (People sometimes forget that) The WAP protocol supports the ability to instruct the phone to dial a number. Instead of long text screens, think of having the content delivered via a phone call and integrate a voice response system or text-to-speech into your technology.
• Limited Interface. Menus should be limited to five to seven items, remember over three items will usually require the user to scroll down to view them.
• Inconsistent Interface. With WAP phones you can only really presume a single selection button will be available (the second, or OPTIONS button, may be designated for choosing the text entry modes). The reliance on more than one button will limit the devices that can be used.
• Segmented Input Screens. A wireless device may not present the items on the screen as you would expect. For example, Openwave (formally Phone.com) browsers present each input field on a separate screen, unable to see previous inputs or prompts. Some phones show a placeholder for input fields but do not show the content of the fields.

In practice, we have found it extremely useful to draw mock-ups of screens. Therefore, we designed a "flexible, rapid prototyping tool" that looks like a typical cell phone screen on "Post-It’s"(® of 3M Corp.) Using these "Stickies" while brainstorming with users is helpful in enabling everyone to visualize the layout of the application and aid in making the user interface more intuitive and useful to them.

Having the Mobile Device form factor in front of the users and developers is invaluable to change their "Desktop PC" mentality and help them realize the interface challenges that are associated with working with mobile devices.

Prototype screens are designed as required for each of the Use Cases. Some Use Cases will require multiple screens to illustrate their user interaction.