Who are the users?What do you know about them?What type of behavior can you assume or predict aboutthe users?What is happening?What are the circumstances in which the users will bestabsorb the content you intend to present?
FEATURE WHAT IT DOES EXAMPLE APP OR FEATURECamera Takes photos & often Too many to list! video.GPS Provides the phone’s Maps location.Accelerometer Detects the phone’s Determines when to orientation. switch from portrait to landscape viewMagnetometer Detects the phone’s Compass direction.Gyroscope Detects 3-axis angular Gaming acceleration around the X, Y and Z axes.Proximity sensor Detects proximity of user Cue to dim screen when to phone. user speaking on phone.Light sensor Determines how much Adjusts screen brightness light is available in the to area surrounding the conserve battery. phone
How can food joints use mobiledevices to improve their customerexperience?
Identifying Needs – 30 mins1. Divide into groups2. Head to the nearest food joint3. Observe mobile users in a mobile context4. Develop a list of customer needs based on your observations
Ideating the Context – 30 mins1. Brainstorm with the team2. Create 2-3 unique concepts based on the needs your team identified3. Give your concept a name4. Create user profiles
Presenting Concepts1. Each team would present a 10 minute introduction to their app which would include 1. Elevator Pitch: What your app does 2. User Profiles: Who your app is targeting and why 3. User Research Summary: What you learned in the user research/observation study conducted
Because of thedifferences betweenmobile and desktop,it’s imperative to getyourself into amobile mindsetbefore gettingstarted.
Be focused: More is not bePer. Edit your features 1 ruthlessly. You are going to have to leave stuﬀ out
2 Be unique: Know what makes your app diﬀerent and amplify it. There are lots of ﬁsh in the sea of mobile apps. If there’s nothing special about your app, why would anyone pick it?
3 Be charming: 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 aPached to the experience.
Be considerate: App developers too o]en focus on what 4 would be fun to develop, their own mental model of the app or their personal business goals. These are good places to start, but you have to put yourself in your user’s shoes if you ever hope to create an engaging experience.
It is certainly one context, but it’s not the only one.
To begin to put ourselves in the shoes of our users, we need to consider three major mobile contexts
There are a lot of people using their smartphones on the couch at home. In this context, immersive and deligh_ul experiences geared toward a longer usage session are a great ﬁt. S`ll, interrup`ons are highly likely, so be sure your app can pick up where your user le] oﬀ. Examples: Facebook, TwiPer, Angry Birds, web browser.
This is the running though the airport scenario. The ability to accomplish micro-‐tasks quickly and reliably with one hand in a hec`c environment is cri`cal. Remember that the user will have tunnel vision in this context, so huge targets and bold design are important. Examples: TripIt, email, calendar, banking.
Users who are in transit, in unfamiliar surroundings, or in familiar surroundings but interested in something unknown around fall into the lost category. In this context, sketchy connec`vity and baPery life are big concerns, so you should oﬀer some level of oﬄine support and be sparing with your use of geoloca`on and other baPery hogs. Typical examples: Maps, Yelp, Foursquare.
Provide instant feedback for every interac`on. If you don’t, the user will wonder if the app has frozen up, or if they missed the target they were trying to hit. The feedback could be tac`le (like the Android ‘thump’ vibra`on), or visual (highligh`ng a tapped buPon, for instance).
Modal alerts are extremely pushy and intrusive to the user’s ﬂow, so you should only use them when something is seriously wrong. Even then, try to mi`gate the intensity by keeping language reassuring and friendly. Remember not to use modal alerts for FYI type informa`on.
When you have to ask a user to conﬁrm an ac`on, it’s acceptable to display a modal conﬁrma`on dialog (such as Are you sure you want to delete this dra]?). Conﬁrma`ons are less intrusive than alerts because they are in response to a user ac`on and therefore in context and perhaps even expected.
Diﬀerent apps call for diﬀerent approaches, designs and techniques. The inherent nature of a pocket-‐sized touchscreen device suggests several global guidelines; ie, the stuﬀ that always maPers.
Responsiveness is absolutely cri`cal. If your user does something, your app needs to acknowledge the interac`on instantly. It’s OK if certain opera`ons take `me. Just make sure you let the user know you’re working on it.
Polish is extremely valuable. Because of the constant companion nature of our rela`onship to smartphones, paying a lot of aPen`on to gekng the liPle details perfect will be no`ced and appreciated.
With the advent of touchscreen interfaces, everyone is always talking about ﬁnger this and ﬁnger that. In reality, the thumb is what we need to design for.
The revolu`on of touch interfaces is that they enable us to interact directly with our content. This removes abstrac`ons (such as mouse and trackpad) and is more in line with how our brains are wired. Leverage the intui`ve power of touch UI by minimising interface chrome (buPons, tab bars, checkboxes, sliders and so on) wherever possible and pukng your content front and centre.
Avoid scrolling. 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.
Typing s`nks even on the best devices, so you should do what you can to make it easier for your users.
If your app invites a lot of typing, you should ensure you support landscape orienta`on.
There are many keyboard varia`ons on popular smartphones (text, number, email, URL and so on). Consider each of your input ﬁelds and be sure to display the keyboard that will be most useful for the data entry being done.
One of the most iconic aspects of modern touch interfaces is that they support gesture-‐based user interac`on.
Gestures are invisible, so discovery is an issue. You have to decide how to reveal their existence to the user.
Mul`-‐touch gestures require two-‐handed opera`on. EXAMPLE in the na`ve Maps app on iOS which uses a pinch open gesture to zoom out. When I’m traveling in a foreign city with a coﬀee in one hand and my phone in the other, this is an annoying limita`on. Android addresses this issue by including zoom in/out buPons overlaid on the map
Discover Understand and iden`fy the core problems ﬁrst
STORYBOARDING Storyboarding – 60 mins1. Based on your previous activities, Identify the central idea(s) you are trying to communicate.2. Storyboard one scenario using the templates provided.3. Remember to identify the key issues the character faces and rough out the complete story before filling in details.4. Present a small demo of your storyboard concept
MOBILE PROTOTYPING ESSENTIALS2 ACTIVITES - DESIGNING FOR MOBILITY QUIZ Need Analysis DESIGNING AND TESTING PAPER PROTOTYPES Ideating
MOBILE PROTOTYPING ESSENTIALS3 ACTIVITES - DESIGNING FOR MOBILITY IN DEVICE INTERACTIVE PROTOTYPES Need Analysis MOBILE BROWSER PROTOTYPE MOBILE PROTOTYPE USING PRESENTATION SOFTWARE Ideating
Best suited for design explorations where: 1 You are working on a “broader” mobile project. Target mobile hardware and software 2 scope is unknown (perhaps being created). 3 The design space is relatively unchartered.
TESTING INTERFACES • Intelligibility -‐ can you read or interpret this? • Trackability -‐ can you follow this? • Fumble factor -‐ can you make this work?
PRESENTING INTERFACE IDEAS • To UI designers -‐ looking at all parts of the interface • To programmers -‐ implemen`ng the interface • To marke`ng and management -‐ determining applica`on features • To users -‐ gekng early feedback
TACTICAL P ROTOTYPING 1 Sketching 2 Paper Prototyping 3 Interac`ve On-‐Device Prototyping
Quick itera+ons Paper prototypes enable you to rapidly iterate and experiment with many ideas. The modest `me investment makes it easier to throw away less promising direc`ons.
Inexpensive Ordinary oﬃce supplies can be used for paper prototypes: Sharpies, Pos`ts, printer paper. Most important, these up-‐front paper itera`ons can reduce costly changes on the development end.
Collabora+ve Paper prototypes do not require any technical skills; thus everyone (users, too!) can par`cipate.
Easy to edit You or your users can edit paper prototypes on the & y (e.g., change labels, add screens, add buPons)
PAPER P ROTOTYPE C HALLENGES Paper prototypes are less suitable for reﬁning low-‐level interac`ons such as transi`ons, scrolling, and swiping.
PAPER P ROTOTYPE C HALLENGES Less useful for certain classes of apps, such as musical instruments, videos, and games.
User experience issues o]en explored with paper prototypes include
App concept -‐ Do users understand your app’s central 1 concept? 2 Workﬂows -‐ Is the overall naviga`on clear? Are there too many steps to complete tasks? 3 Informa`on organiza`on -‐ Does the current organiza`on match users expecta`ons? Terminology -‐ Are the labels on tabs, screens, and 4 buPons clear?
At some point your designs will have to match the PHONE screen dimensions—320 × 480 pixels (640 × 960 for iPhone 4)—but paper prototypes can be less exact. Using a larger form factor will make it easier for others to interact with the design (e.g., rearrange the layout and write in text Fields)
Your prototype will include a background, the screens, and the user interface controls.
RECAPHow can food joints use mobiledevices to improve their customerexperience?
PAPER P ROTOTYPE Create Paper Prototype – 60 mins1. Create a paper prototype that illustrates 3 major tasks for your interface / interaction design, likely (but not necessarily) based on your storyboards.2. The prototype should be complete enough to "run" a new user through each task.
PAPER P ROTOTYPE Test Paper Prototype – 60 mins1. Prepare for testing your paper prototype2. Identify a participant as user, provide him a test script3. Identify and make notes of your finding
TACTICAL P ROTOTYPING 1 Sketching 2 Paper Prototyping 3 Interac`ve On-‐Device Prototyping
Interac`ve On-‐Device Prototyping includes: 1 In-‐screen mobile prototype 2 Mobile browser prototype 3 Mobile prototype using presenta`on so]ware 4 Pla_orm speciﬁc prototype 4
Pros and Cons of Common On-‐Device Prototyping Tools Level of Level of Level of Complexity/ Interac+vity Programming Diﬃculty to Create Required In-‐Screen Prototype Low Low None Browser Prototype Medium Low Low Keynote/ Medium Medium None Powerpoint Prototype Pla_orm-‐Speciﬁc High High High Prototype (example: XCode for the Apple pla_orm)
Interac`ve On-‐Device Prototyping Given the limita`ons of sta`c image prototypes, Interac`ve On-‐Device Prototyping are interac`ve prototyping techniques.
ISSUES TO EXPLORE You can explore almost any aspect of the user experience. In contrast to sta`c image prototypes, you can provide forms, transi`ons, and scrolling content.
CHALLENGES Although interac`ve prototypes are powerful, there are s`ll some aspects that diﬀeren`ate them from the “real” experience. In par`cular, you will s`ll likely need to fake the current loca`on informa`on, live data feeds, and the handling of interrup`ons (what happens when the connec`on is lost or disrupted?).
In-‐screen mobile prototype The idea behind this technique is simple: place the paper prototype of the mobile applica`on inside the mobile device.
In-‐screen mobile prototype This prototyping technique is prac`cal since it leverages prototypes that are likely to have been previously made for tes`ng.
In-‐screen mobile prototype If a designer has sketched a number of paper prototypes to conduct a usability test or a heuris`c evalua`on, these can be easily turned into paper-‐in-‐screen prototypes.
IN-‐SCREEN P ROTOTYPE In-Screen Prototype – 60 mins1. Identify one of the scenarios/flows from your previous exercise2. Create a quick paper version of the prototype3. Take pictures from your camera, upload it, optimize it and test it
MOBILE B ROWSER P ROTOTYPE 1 For those less familiar with extensive markup, you can easily upload a series of linked image maps of screen layouts and view them through your phone’s browser.
MOBILE B ROWSER P ROTOTYPE BENEFITS Mobile Browser Prototypes are medium ﬁdelity, very interac`ve and hence can be tested with full interac`ons
MOBILE B ROWSER P ROTOTYPE Mobile Browser Prototype – 30 mins1. Identify one of the scenarios/flows from your previous exercises2. Create a click through version of your App3. Test it in mobile browser or emulators
MOBILE PROTOTYPE USING PRESENTATION SOFTWARE Crea`ng prototypes using presenta`on so]ware such as Apple Keynote or Microso] PowerPoint is an eﬃcient way to prototype interac`vity and transi`ons on a mobile device.
MOBILE PROTOTYPE USING PRESENTATION SOFTWARE You can easily download pla_orm components from the Web, build your prototype using the presenta`on so]ware, ﬁne-‐tune the interac`ons and transi`ons included in the so]ware, and download the ﬁle to your mobile device.
MOBILE PROTOTYPE USING PRESENTATION SOFTWARE While designers use various types of tools to document their wireframe ideas, presenta`on so]ware is emerging as a favorite tool in the mobile UX realm.
MOBILE PROTOTYPE USING PRESENTATION SOFTWARE -‐ BENEFITS In addi`on to specifying the placement of design elements on a screen, presenta`on so]ware enables designers to turn their work into low-‐ ﬁdelity on-‐device prototypes.
MOBILE PROTOTYPE USING PRESENTATION SOFTWARE -‐ BENEFITS Instead of ﬂat, sta`c documents, presenta`on so]ware oﬀers designers the ability to experiment with transi`ons and interac`vity.
MOBILE PROTOTYPE USING PRESENTATION SOFTWARE -‐ HOW TO
MOBILE P ROTOTYPING Mobile Prototyping – 30 mins1. Identify one of the scenarios/flows from your previous exercises2. Create a click through prototype using power point or keynote3. Upload your design file into mobile device4. Test it on device