Principles of Mobile Interface Design


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Hi all! My name is Jonathan Stark and I’m speaking to you today from my home office in Providence RI. \n\nI’m obsessed with wireless computing and its effects on society, and because of that I spend an inordinate time thinking about mobile app development, training, and strategy. \n\nIt’s worth mentioning that my clients are typically large organization who need to reach large groups of customers and employees with their mobile initiatives, so my strengths skew toward cross-platform apps and mobile web. \n\nToday we’re going to talk about principles of mobile interface design. I think most are pretty self-explanatory on their own, but it’s a long list and it can be a bit overwhelming when taken together. I’m going to start with some big picture perspective, then run through ten subject areas, and finish with some advice about design process and take questions from the group. \n
  • \n
  • As designers and developers, we have to concern ourselves with issues on mobile that don’t really exist on the desktop.\n
  • I think because mobile devices are physically smaller than desktops and laptops, people tend to think of them as shrunken down “real” computers or somehow less powerful. But when you think about it, smartphones are actually more powerful than desktops in many ways. \n
  • Because of the differences between mobile and desktop, it’s imperative to get yourself into a mobile mindset before getting started. \n
  • You ARE going to have to leave stuff out. \n
  • Know what makes your app different and amplify it. There are lots of fish in the sea of mobile apps. If there’s nothing special about your app, why would anyone pick it? \n
  • Mobile devices are intensely personal. They are our constant companions. Apps that are friendly, reliable, and fun are a delight to use and people will become quite attached to the experience. \n
  • App developers too often focus on\n\n* what they want\n* what would be fun to develop\n* personal business goals\n\nThese are all good places to start, but you have to put yourself in your users shoes if you ever hope to create an engaging experience. \n
  • The image of the busy professional racing through the airport with a bag in one hand and smartphone in the other is what lots of people picture when they think about mobile computing context. But it would be a mistake to think that it’s the only one. \n\nTo begin to put ourselves in the shoes of our users, we need to consider three major mobile contexts, which I refer to as:\n* Bored\n* Busy\n* Lost\n\n
  • Immersive and delightful experience that picks up where user left off is important. \n\n* ebay sells multiple ferraris per MONTH on mobile. \n* personally, smartphones and tablets have completely replaced traditional television.\n* still, interruptions are highly likely so be sure to pick up where user left off.\n
  • Ability to accomplish micro-tasks incredibly quickly and reliably in a hectic environment is important.\n\n* Tunnel vision\n* Huge targets\n* Bold design\n
  • In transit, in unfamiliar surroundings, or in familiar surroundings but interested in something unknown. \nConnectivity and battery life are big concerns. \n
  • \n
  • I can’t stress this enough. \n
  • Because of the “constant companion” nature of our relationship to smartphones, paying a lot of attention to getting the little details perfect will be noticed and appreciated. I think of this like the “fit and finish” of a car. The engine might be powerful and the body style gorgeous, but if there’s a lot of road noise or rattling on the highway, the experience will begin to degrade for the commuter. \n
  • With the advent of touchscreen interfaces, everyone is always talking about “finger this” and “finger that”. In reality, the thumb is what we need to design for. Unless the user has her smartphone is using two hands, it’s almost impossible to get a finger on the screen. And even in a two handed grip, she’s likely to type with two thumbs. \n
  • 44px is the magic number\nDon’t put the Send button adjacent to the Backspace button\n
  • Let your content shine by minimizing chrome wherever possible. \n(Aside about fixed position headers and footers in web dev)\n\n
  • Think of an adding machine, a bathroom scale, or even a computer - the controls are beneath the display. And for good reason - if they weren’t, we wouldn’t be able to see what was going on with the content! \n\nContrast this real-world design consideration with traditional web or desktop software, where navigation and menu bars are virtually always at the top. This made sense because the mouse pointer is nearly invisible. Not so with the meat pointer.\n
  • I assure that that “below the fold” exists for mobile. Also, having a non-scrolling screen has a more solid and dependable “feel” than a scrolling view because it’s more predictable. Of course, certain screens have to scroll, but it’s good to avoid it where you can. Also nice to give visual clues that scrolling is possible by reverse animating into view. \n
  • If you are going to use one of the common nav models, be sure to pick the one that is makes the most sense for your app. \n
  • Weather app on iPhone\n
  • Music app on iPhone\n
  • Settings app on iPhone\n
  • \n
  • Minimize keyboard interaction where you can\n
  • There are a wide variety of keyboards and variations(ascii, numbers, keypad, email, url, etc..). Be sure to pull up the one that is best for each field. \n\n(Aside that Android Market allows people to install custom keyboards, so you can’t be 100% sure how much screen real-estate is being taken up)\n
  • Auto-correct, auto-capitalize, auto-complete. Consider each in the context of every input field in your app. \n\nSo annoying to have auto-correct or auto-caps on an email field. \n\n\n
  • Some people (cough-me-cough) have fat fingers and sometimes need the roomier key layout available in landscape mode. \n
  • \n
  • \n
  • \n
  • \n
  • A common vocabulary for gestures doesn’t exist yet so it’s too soon for most apps to skip visible controls that can be used with a single-finger. \n
  • \n
  • \n
  • \n
  • Consider adding an orientation lock for apps that invite long sessions\n
  • \n
  • * Provide instant visible feedback for every interaction\n* Except when you shouldn’t (tap highlights when scrolling)\n* Use spinners or progress bars to let users know that your app is working on it\n\n
  • * Only use alerts when something it truly borked\n* Keep language reassuring and friendly\n* Don't use modal alerts for "FYI" type information\n\n
  • * Confirmation dialogs should only be in response to user actions\n* "Safest" choice should be the default button in the confirmation \n\n
  • \n
  • \n
  • Gives the illusion of speed\n
  • If possible, launch screen should be a "content-less" image of your app \nAnything that looks interactive (buttons, links, icons, content) will create frustration\nBranded launch screens make user feel like they're sitting through an ad\n\n\n
  • \n
  • A polished icon suggests a polished app\nIcons live shoulder to shoulder with other icons\nTherefor, an icon is an ad (not an art piece)\nBe literal - show what your app does\nUse a strong silhouette\nDon't go overboard with text\nIt's usually not attractive to scale down large icon for smaller sizes\n\n
  • Simple apps should be self-explanatory\nComplex apps might require a "tips & tricks" overlay\nUI might need work if you are considering lots of help text\nAugment empty lists with helpful instructions\n
  • It can be tempting to jump right into code... DON’T! \n\nAs the saying goes: “Weeks of coding can save you hours of planning”\n
  • \n
  • \n
  • Simulators are not very useful because you can’t “feel” the app, it’s not the right size, and there might be bugs.\n
  • I am routinely shocked at people’s mental model of an app on first launch. Just the other day, a developer a work with built a screen that made perfect sense to her, but left me utterly confused. \n\nEven if you are the customer, get a second opinion. \n
  • \n
  • Principles of Mobile Interface Design

    2. 2. FIRST THINGS FIRSTprolly preaching to the choir, but here goes... 2
    3. 3. Mobile ≠ Desktop• Tiny screen • Expensive data• Battery powered • Limited storage• Spotty connection • Distracted user• Small pipe • Touch vs mouse 3
    4. 4. Mobile > Desktop• Personal • GPS• Always on • Accelerometer• Always with • Gyroscope• Usually connected • Magnometer• Directly • NFC? Addressable • Pico projector? 4
    5. 5. MOBILE MINDSETfirst, know thyself 5
    6. 6. BE FOCUSEDedit features ruthlessly 6
    7. 7. BE UNIQUEplay to your strengths 7
    8. 8. BE CHARMINGdevelop your personality 8
    9. 9. BE CONSIDERATEit is not about you 9
    10. 10. MOBILE CONTEXTSbored, busy, and lost 10
    11. 11. BOREDsocial, news, entertainment 11
    12. 12. BUSYemail, calendar, banking 12
    13. 13. LOSTattractions, directions, recommendations 13
    14. 14. GLOBAL GUIDELINESstuff that always matters 14
    15. 15. RESPONSIVENESSis absolutely critical 15
    16. 16. POLISHis extremely valuable 16
    17. 17. THUMBSare the default 17
    18. 18. TARGETSmust be finger friendly 18
    19. 19. CONTENTis king, minimize chrome 19
    20. 20. CONTROLSshould be beneath content 20
    21. 21. SCROLLINGshould be avoided when possible 21
    22. 22. NAVIGATION MODELSwhere the hell am i? 22
    23. 23. NONEsingle screen utility apps 23
    24. 24. TAB BARthree to six major categories 24
    25. 25. DRILL DOWNlist + detail content hierarchy 25
    26. 26. USER INPUTdamn you, autocorrect! 26
    27. 27. TYPING STINKSeven on the best mobile devices 27
    28. 28. KEYBOARDSshould be apropos for each field 28
    29. 29. AUTO-WHATEVERshould be apropos for each field 29
    30. 30. SUPPORT LANDSCAPEif your app invites lots of typing 30
    31. 31. GESTURESit’s the thought that counts 31
    32. 32. INVISIBLEdiscovery is an issue 32
    33. 33. TWO HANDSare required for multitouch 33
    34. 34. NICE TO HAVEsorta like keyboard shortcuts 34
    35. 35. NO REPLACEMENTfor visible controls and single-finger operation 35
    36. 36. ORIENTATIONnot just for freshman anymore 36
    37. 37. PORTRAIT RULESso optimize that first 37
    38. 38. LOT ‘O TYPINGmeans you should support landscape 38
    39. 39. DISORIENTATIONoccurs when change is unexpected 39
    40. 40. COMMUNICATIONSbeing polite is a good thing 40
    41. 41. PROVIDE FEEDBACKfor every user interaction 41
    42. 42. MODAL ALERTSare for total disasters 42
    43. 43. CONFIRMATIONSare for user actions 43
    44. 44. BADGES ARE GOODexcept when they are aren’t 44
    45. 45. LAUNCHINGsuspended animation 45
    46. 46. RESUME OPERATIONright where your user left off 46
    47. 47. LAUNCH SCREENshould be “content-less” background 47
    48. 48. FIRST IMPRESSIONSgetting acquainted 48
    49. 49. YOUR ICONis like a business card for your app 49
    50. 50. FIRST LAUNCHis a special situation 50
    51. 51. DESIGN PROCESSready, fire, aim! 51
    52. 52. PERSONASflesh out a few user archetypes 52
    53. 53. STORYBOARDendlessly on paper 53
    54. 54. PROTOTYPEon device as soon as possible 54
    55. 55. USER FEEDBACKis enormously helpful 55
    56. 56. QUESTIONS?ping me on twitter @jonathanstark 56