Design

Top 6 Help Design Patterns for iPhone Apps

10 Surefire Ways to Screw Up Your iPhone App

in addition to that

Indeed a good blog post; Its equally important for both designers and analysis team who directly interact with clients; These points should always keep in mind while designing the mockup and application flow for new projects; The points which really clicked me most are

1. Information Overload

Crowd is always irritating; No one like it whether it’s in streets or in mobile app; Putting many things on small screen of a handset will not pass a pleasant look to user, for sure; Instead we should distribute the information in different sections or even among different screens; Adding too much info on single screen with many UI control simply annoy the user; This design mistake is common with those who have web application background (for developers) and designers who has been working in print media domain; So while making mockup, keep the screens simple with only required data;

3. Registration Screens

It happen most of the time with me; Download an app, open it and a registration/login screen welcomes you; No other way to use the primitive feature of the app until you fill a form of 4 ,5 fields, choose a password and then you’ll be able to see dashboard of the app; And this thing really annoy the user believe me; So while sketching the mockups of new application, we should keep this factor in mind; Provide some basic screens/feature to user and then you can ask him to login or register; This thing really engage your user with your app and creates his interest if you allow him to jump directly into your product;

Our recent project Mealeo really fits here as an example; Any new user can access most of the application without being asked for registraion/login;

5. Breaking Conventions

Although we are allowed to customize the look & feel of default controls, but yes don’t change/break their conventional usage; If an action A1 is required and we have a default control C1 for this purpose, then always use C1 whenever we need action A1, and in reverse if you want to use control C1, then always use it for action A1; You can customize the look & feel (color scheme etc) of control C1 but don’t use/design another control C2 for the same purpose; Users are habbitual of using C1 whenever they want to do A1, so let them use your app they way as they are use to; Examples are UISwitch control which is mostly use to on/off a certain values; You can customize its color sceme with respect to your application’s theme but its better don’t prefer any other control whenever you want to to add on/off functionality on your screen;

One thing is important that these rules may offer some relaxation in case of tablet applications; Tablets have more room to accomodate information and UI controles; Hence these rules may not be applicable (in this form) for tablet devices but yes don’t ignore them at all;