Mobiles & usbaility

7,583 views

Published on

How does usability fit into mobile design!

Published in: Technology, Business

Mobiles & usbaility

  1. 1. Mobiles & Usability Nov 2005
  2. 2. Agenda <ul><ul><li>Introduction to Usability </li></ul></ul><ul><ul><li>Designing for the mobile – limitations & advantages </li></ul></ul><ul><ul><ul><li>User perception </li></ul></ul></ul><ul><ul><ul><li>Mobiles Vs. Web/desktop </li></ul></ul></ul><ul><ul><li>Design Guidelines </li></ul></ul><ul><ul><ul><li>Navigation </li></ul></ul></ul><ul><ul><ul><li>Use of the keypad </li></ul></ul></ul><ul><ul><ul><li>Page design </li></ul></ul></ul><ul><ul><ul><li>Consistency & predictability </li></ul></ul></ul><ul><ul><ul><li>Error prevention & recovery </li></ul></ul></ul><ul><ul><ul><li>Language & graphics </li></ul></ul></ul><ul><ul><li>Questions to ask </li></ul></ul>
  3. 3. Introduction to Usability <ul><ul><li>Learn-ability – Familiarity, Consistency, Generalizability, Transparency, Simplicity </li></ul></ul><ul><ul><li>Memory-ability – A user can leave a program and, when he or she returns to it, remember how to do things in it. </li></ul></ul><ul><ul><li>Efficiency – How fast a user accomplishes tasks once he or she has learned to use a system. </li></ul></ul><ul><ul><li>Error rate – The rate of successful completion of task or portions of a task. </li></ul></ul><ul><ul><li>Satisfaction – Describes a user’s subjective response when using the product. How he/she feels at the end of a session with the product. </li></ul></ul><ul><ul><li>Effort – The amount of mental or physical effort required to complete a task eg. Number of clicks to task completion, or number of decisions to take before task completion. </li></ul></ul><ul><ul><li>Jakob Nielsen describes usability as </li></ul></ul><ul><ul><li>“ ..a combination of Learnability, Errors, Satisfaction and Memorability..”. </li></ul></ul>
  4. 4. Advantages & Limitations of Mobile Design <ul><ul><li>&quot;It's easy to make things difficult, but difficult to make things easy&quot; </li></ul></ul>
  5. 5. User interaction <ul><li>(-) Small attention spans – Usually operated while doing something else. Attention span of the user is very small. Users are highly aware of the effort & time they spend on the application. </li></ul><ul><li>(+) Always available – Mobiles are generally available to the user 24 X 7 and the user can access an application at any time. </li></ul><ul><li>(-) Economic factors – Surfing on or using a mobile phone application that accesses the network is perceived as expensive. </li></ul><ul><li>(+) Highly personalized – Since mobiles are mainly single-user devices, a high degree of personalization is possible. </li></ul><ul><li>(-) Secondary function – On most mobile devices, using an application is secondary to its use as a communication device. </li></ul>Small screens, big advantages, bigger obstacles!
  6. 6. Mobile Vs. Web/Desktop <ul><li>(-) Resources – Bandwidth as well as memory resources are higher on desktop applications which access networks as compared to mobiles which have smaller memories and smaller bandwidths to call upon. </li></ul><ul><li>(-) Spatial ability – On the desktop, a user can navigate around the computer’s big screen in various ways, through various multi-capable input devices like the mouse, stylus, keyboard etc. while on the ‘small screened’ mobiles the spatial navigation styles are limited. </li></ul><ul><li>(+) Deeper penetration – There are more people with mobile phones and the capability to use them than there are computers and computer friendly people. </li></ul><ul><li>(-) Variety of Mobiles – There are no standard screen sizes, or display parameters. Fonts, graphics, & even pictures may look & act differently on different phones. </li></ul><ul><li>(+) Multi-tasking – On a desktop application it is possible to have many windows open and perform many functions at the same time, but on the mobile, the user is concentrated on the application at hand while he/she is interacting with the mobile. </li></ul>
  7. 7. Designing for Mobiles Nothing is more fun than seeing your Web page (or application) nestled nicely into a teeny tiny handheld screen; and nothing is more excruciatingly horrendous than trying to figure out how to get it there. Heidi Pollok (WebMonkey)
  8. 8. Navigation <ul><li>Global Navigation – There should always be a link back to the main menu or the home page and the TOP level page of the local section at the end of every interaction. </li></ul><ul><li>Same level navigation – It is also important to support navigation between different items within a certain area. Previous and next links attached to each item promote a smoother movement. </li></ul><ul><li>Cross linking – Remember to include links to other areas which might be of interest to the user at this point in navigation. Be very selective so as to not confuse the user. </li></ul><ul><li>Order of importance – The links should be given in the order of importance where the first & most important step is accentuated (perhaps capitalized?) and given first followed by the rest of the links. </li></ul><ul><li>Menus – A wide and shallow hierarchical structure is preferable to a narrow & deep one. Have the options ordered according to frequency of use. </li></ul><ul><ul><li>&quot;In mobile phone interface design, every click loses half of your users&quot;. </li></ul></ul><ul><ul><li>-Nick Knowles (Chief Technical Officer, KiZoom) </li></ul></ul>
  9. 9. Consistency & Predictability Labeling – The user should instinctively know what is going to happen when a link is clicked. Labels should be specific and transparent. For example instead of ‘OK’ a link should say ‘create’, ‘next’, continue, order etc System feedback – Actions by the system should be represented on the interface as far as possible e.g. Signing in, please wait… Navigation status - U ser should know how many items there are within a section and where he/she is. 4/10 would indicate; the fourth item out of ten or in search results “Showing 1-10 of 25” Familiarity – Users expect similar tasks to happen in a similar manner. Eg. CANCEL can mean ‘back to previous page without any action’ or ‘back to main menu without any action’. What the user expects is dependent on the pattern which the designer builds. <ul><ul><li>“ Users should not have to wonder whether different words, situations, </li></ul></ul><ul><ul><li>or actions mean the same thing. Follow platform conventions. “ </li></ul></ul>
  10. 10. Page design Headers – The terminology & the spelling on the header should be the exact same as on the link which led to the page. Sub-headers – If subheaders are used they need to be differentiated from content and menu items. Separation – If a page contains of a number of rows with just plain text and they are followed by a hyper link, separate the static field from the interactive area with a single dashed line. Fonts – For pages to be scan able, fonts should be clear. Avoid over decoration of fonts – only using decoration when attention is needed. Scrolling – Scroll only when necessary, as the user might not scroll if not prompted and might miss information at the bottom of the page. Clutter – Always try to keep the elements on a page as minimum as possible. The information available should not be too much for the user to process. Using a phone to surf the Internet means taking a huge leap away from the fixation with looks.
  11. 11. Error prevention & recovery <ul><li>Input areas – Help text should always be present where “heavy” interaction and text input occurs. All input areas should be clearly labeled to clearly indicate the input format. E.g. Mobile Number (+91) [………..] </li></ul><ul><li>Error messages – Error message should contain the actual problem of the error and the reason for it, in a language that a common user can understand. </li></ul><ul><li>Recoverability – I f possible also provide some hint for solving the problem that caused the error. This can be done through examples e.g. neo@hotmail.com or options like alternate user IDs etc. </li></ul><ul><li>Confirmation – Task confirmation should be supported so that the user does not go back and perform the same task again and again. </li></ul>
  12. 12. Use of the keypad Less is more – Users should not be forced to enter information in more than one field. Fields that can be should be drop downs or selection lists. To clear or not to clear – do not let the user clear the input fields herself if performing a new function i.e. new search. The system should clear the fields. And if the screen is a modification of the previous screen i.e. in case of errors – the system should remember the text put in by the user in the next screen also. Signing in – A user should be automatically signed in when possible. URLs – Should be fairly short. Search criteria – While entering search criteria, the system should support common abbreviations as far as possible. Numeric keys – The natural way of interaction with a phone is numeric so fields should be numeric if they can and use of the keypad when navigating through a particularly long page should be supported. Text input is difficult on a mobile phone considering the user relies on a set of numeric keys when writing.
  13. 13. Language & graphics Keep it simple – The need for simple language is even stronger in mobile design, because there is no room to explain non-standard terminology with effects or icons. Long words – Avoid long words as far as possible as small screens may wrap the word and push it out of the display area. Abbreviations – Never use abbreviations when naming links and headers. If using abbreviations in the body text is necessary use only the most common ones. Icons – Icons should be used in places where words do not suffice i.e. to support understating a certain term or link. Icons should not only decorate an interface. Case – Upper-case words are slower to read so they should be used for only important information, which needs more user concentration <ul><ul><li>“ Users should not have to wonder whether different words, situations, </li></ul></ul><ul><ul><li>or actions mean the same thing. Follow platform conventions. “ </li></ul></ul>
  14. 14. Questions to ask yourself <ul><li>What is the application’s focus? Do we know what the user wants to do here? </li></ul><ul><li>Is it possible to support every wish or will too many links blur the overview? </li></ul><ul><li>Have we thought of building a service that avoids unnecessary clicks and moving between different levels? </li></ul><ul><li>Does the user want to perform service A before service B? </li></ul><ul><li>Have we supported the other way round as well? </li></ul><ul><li>Have we thought of every possible user scenario? </li></ul><ul><li>Can we make the interaction and the information flow even more polished and usable? </li></ul>
  15. 15. Thank you

×