Sketchcamp Chicago

Work faster, not harder.

That was the message last week at the inaugural Sketchcamp Chicago conference. The one-day event, attended by about 75 UX architects, designers, and strategists, focused on tips and techniques for using sketching as a lightweight tool for user experience design.

Greg Nudelman's Amazon Sketches
Greg Nudelman's Amazon Sketches

My Amazon iPhone App Sketch
My Amazon iPhone App Sketch

In an exercise lead by Greg Nudelman, author of Designing Search: UX Strategies for eCommerce Success, participants were shown wireframes sketched on 3″ x 5″ Post-it notes of a search path on Amazon’s iPhone app. Nudelman then had us spend a few minutes sketching our own approaches, which included carousels, a scrollable gallery of images representing product categories, list drilldowns, and free text searches àla Google.

By the end of the exercise at least 7 different approaches were identified, showing that sketching allows for the quick expression of ideas without the encumbrances of tools like Omnigraffle or Visio. Attached to this post are Nudelman’s Amazon sketches and my take on using a carousel to represent product categories. My approach was far from optimal, but that illustrates the theme of the conference — sketching allows you to get ideas out of your head and into the world where they can be explored, refined, or discarded.

Another speaker discussed storyboarding as a way to communicate customer value to business stakeholders.

Digital and industrial designer Craighton Berman showed how he uses storyboards to illustrate user engagement and benefits in ways that a standard business plan cannot. The strength of storyboards is their ability to visually show how a product could benefit consumers in real-world situations and how well-designed products can create an emotional attachment for the people using them. Try communicating that in a spreadsheet. If a picture is worth a 1,000 words, a good storyboard may be worth 10,000.

Here are a few resources I’ve used for sketching user experience design:

Happy Sketching.

Safari Reader Improves Mobile Browsing

One of the little-mentioned features in Apple’s new iOS 5 is the addition of Reader in Mobile Safari. Reader, which was introduced in desktop Safari last year, allows a user to click a button in the browser address bar to render a webpage in a user-friendly, text-only format.

Reader instantly turns mobile webpages that may be poorly designed or have small fonts into elegant and highly readable pages. All ads, photos, and graphics are stripped from the page. Reader also merges articles that may be spread across several pages on a mobile website into a single scrollable page. And as with all things Mac, the handling of typography is excellent.

Reader is based on technology licensed from Readability, which also created a bookmarklet version for desktop web browsers and is embedded in the Amazon Kindle and popular iPad applications like Flipboard and Reeder.

Below is an article from the Chicago Tribune using the normal Mobile Safari display and Reader. I know which one I’d rather read.

Mobile Safari Reader
Mobile Safari Reader

What Makes a Great Mobile App?

This week I heard Alan Wells, director of product development at Globant’s Mobile Studio, speak on what makes a great mobile app. Alan was speaking as part of the Globant Mobile Roadshow. Here are my high-level notes:

  • A great mobile app or site needs a delightful user experience. When people only have a few minutes to get to know your app, the experience better be rewarding and fun or they may never use it again.
  • You have to think about the different use cases and contexts that apply to mobile usage. Sessions will be shorter but possibly more frequent than with your website. Think about morning and evening commuters popping in and out of your app. Design experiences that deliver value that can be had in just a few minutes.
  • Use cases for tablets are different than for handheld devices. Sessions may be longer. People may be using your app in unusual places, like while reclining on their sofa. Don’t just think of a tablet as a smaller laptop.
  • Embrace the constraints and capabilities of mobile devices. Screens are limited in size, so use that constraint to simplify your app and strip away functions that don’t apply to the mobile context. Capabilities like goelocation and an accelerometer open your app up to functions you couldn’t have considered in the desktop version. Explore those to create those delightful experiences.
  • Higher resolution screens on newer high-end devices don’t change the basic needs of the touch target. Always design with the fingertip in mind.
  • Don’t just port a web app to mobile devices. Build for the mobile context from the start.
  • When creating a mobile companion to a full web app reuse or re-purpose the artistic elements when possible to create a consistent and cohesive experience.
  • Think carefully about whether your app is a companion app or needs full feature parity with the desktop version. Companion apps have an advantage in extending the desktop experience and increasing overall engagement with your brand, without you having to replicate every feature (many of which will never be used in the mobile context).
  • Weigh carefully whether you want your app connected to your website. A connected app will require more communication between development teams and more coordination of releases, but also can promote greater engagement and a seamless, cross-platform user experience.

iPhone Stencils for Visio

I recently found a great set of stencils for wireframing iPhone apps and mobile websites in Visio. The stencil set was created by Jonathan Abbett of Beacon 16 and is available under a Creative Commons License.

The stencil shapes include:

  • iPhone
  • Navigation Bar
  • Search Bar
  • Browser Bar
  • Four and Five Button Tab Bars
  • Keyboard
  • Date Picker
  • More…

If you need a higher fidelity GUI design toolkit for iPhone and iPad, Speckyboy Design Magazine published a great list of resources last year. If you need to illustrate touch gestures in your wireframes, Luke Wroblewski maintains a Touch Gesture Reference Guide on his website.

iPhone Stencils for Visio
iPhone Stencils for Visio

Axure for Mobile Prototyping

I recently developed a small prototype for usability testing of some new mobile website functionality using Axure RP Version 6. Here are a few things I learned:

  • If possible, use Axure RP Version 6. It has mobile settings under the Generate Prototype menu that will save you from having to manually add to each page the HTML viewport meta tag every time you generate a new prototype. Screen shots of the settings panel are at the bottom of this post.
  • Generate separate viewport tags for iOS and Android browsers like below:
    1. iPhone: <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=2.0, user-scalable=yes"/>
    2. Android: <meta name="viewport" content="width=480, target-densityDpi=device-dpi"/>
  • For iPhone, you can design your prototype at 320 pixels wide for older devices. iPhone 4 will scale it up to 640 pixels wide so the prototype has the same appearance no matter what version of the iPhone your participant is using.
  • For Android smartphones, design the prototype at 480 pixels wide. Tablets are another story and my testing did not include them.
  • To create accordion effects on interface widgets, a common design pattern on mobile websites, you can use Dynamic Panels and Axure’s OnShow event with the Move action. See the advanced dynamic panel tutorial on Axure’s website.
  • If you are opening the prototype on an iPhone from a home screen icon and want to hide the URL bar, use this meta tag:  <meta name="apple-mobile-web-app-capable" content="yes"/>
  • Test on as many target Android devices as you can. The Android viewport tag worked on most devices I tested, but not all. The differences in Android pixel density and screen resolution necessitate more testing than is needed with Mobile Safari on the iPhone.
  • Keep in mind you are building a prototype. It doesn’t need to work perfectly on all devices if you can just ask the test participant to zoom in during the session if needed. You should be explaining that they are interacting with a prototype as part of the test script so this should not be a problem.

For more on the iOS viewport, see Apple’s iOS Developer Library.

For more on targeting different screens size on Android, see the Android Developers Site.

Axure Settings for iPhone
Axure Settings for iPhone

Axure Settings for Android
Axure Settings for Android

Touchscreen Design Best Practices

Saturday was Day 2 of the Mobile UX sessions at Nielsen Norman Group’s Usability Week in San Francisco. The focus was on designing for touchscreens. Here are my notes:

  • Allow Users To Go Back and Undo: Make sure users can compensate for accidental taps. Have them confirm any action that would delete their data, erase their work, or process a transaction.
  • Don’t Force Users To Change Device Orientation: Whether your app is a content app like the New York Times or a utility app like American Airlines make sure it can adjust its layout to however a person is holding their device.
  • Pad Those Links And Buttons: Padding a widget can improve people’s accuracy in clicking it. For example, if you display an product image and description in a list layout, make the whole row clickable, not just the image or the text.
  • Padding Can Prevent Errors, But Won’t Increase Efficiency: In cases where you have a clickable invisible padding area around an object, people will still slow the movement of their finger as it approaches the target. Because they don’t know the target is actually larger, they treat it like it is smaller. Fitts’ law is still on the books.
  • Pad Links On Your Wired Site If You Want It Used on Tablets: Many site managers have learned that iPad and other tablets owners are using their wired sites instead of the mobile versions that were designed with smartphones in mind. See Yahoo!’s tablet site for cues on how a wired site can be tweaked to work on a touchscreen tablet.
  • Avoid Localized Swipes: When a left or right swipe only changes one horizontal section of a screen, it confuses people as to what the gesture does. Localized swipes don’t match real world movement, in which pushing something moves the entire object, not a portion of it. Don’t make your app a stack of independent carousels.
  • Provide Cues To Unseen Functionality: Gestures are great for maximizing screen layout but can be undiscoverable by new users. The convention of pulling down on a screen to refresh content that Twitter and other mobile sites use is hidden from the view of new users. Provide cues to new users to help them learn these gestures.
  • Don’t Rely On The Accelerometer For Navigation: People who are new to more advanced mobile devices may not even know about “shaking” as a means for input. Others may find it clumsy or uncomfortable. It’s OK to use the accelerometer, but don’t make it to sole means for input. Urbanspoon’s iPhone app is a good example of an app that uses the accelerometer but also has a big red button.
  • Use Sliders With Caution: Sliders as interface controls are imprecise. Don’t use them if the person has to get to an exact value.
  • Tablets Are Not Smartphones: Don’t be afraid of rich interactions on iPads and other tablets. Tablet users are not “on the go” in the same way as smartphone users.
  • Design A Distinctive Home Screen Icon: Make your app’s icon distinct so it can be recognized on a crowded home screen. If people have to remember your app’s icon, they may never click it.
  • More Is Often Less: Adding features to your mobile app doesn’t always make it better, especially if they add too much complexity. Add features of they make sense in a mobile context, not just because they exist on your wired site.

Mobile Design Best Practices

Today was Day 1 of the Mobile UX sessions at Nielsen Norman Group’s Usability Week in San Francisco. Here are my notes:

  • Design For Interruptions: Since mobile usage is out “in the wild” you have to assume interruptions will happen. Support auto-save and user initiated saving of work. Remember what people type into form inputs and never make them type the same information twice.
  • Design For Continuous Experiences: If users can enter information or save things on your wired site, make sure they can access that information on your mobile app/site. And also let them save and add information on the mobile version that flows back to the wired site.
  • Reduce Interaction Cost: Anything you can do to remove typing reduces interaction cost. Even on the most advanced mobile device, typing is annoying at best (I know this because I’m writing this on an iPad). Whenever your design asks a person to type, ask yourself if there is another way to get this information other than the device keyboard.
  • Make Designs Self-Sufficient: Don’t make people have to leave your app/site to get a necessary piece of information. For example, if your site is a banking site that only processes transactions on business days, don’t offer a date picker that includes weekends or holidays. If someone has to get into their device calendar to check if June 19 is a weekend, they may not get back to the same place in the transaction and may have to start over.
  • Don’t Force People To Rely On Memory: Don’t send people an email with a cryptic promotion code and then send them to a site where they have to remember that code. Pass the code in on the URL if they click anything on the email and keep it in memory for the length of their session. If they have to go to their email when presented with a promo code input during checkout, they may never get back to complete the transaction.
  • Preserve Session State Throughout The Visit: Don’t let people click a Save to Favorites icon from a search results screen and then send them back to a screen where they have to reenter their search term(s) to get the same results list. Remember what they were doing and get them back intact when they go down alternative paths. And provide them a way to easily start a new search if indeed they are done with their previous search.
  • Remember People’s History: Don’t make people reenter information they already provided. If someone enters a zip code or selects a gender while shopping for shoes, persist that throughout their session (at a minimum). There’s little that’s more annoying than having to reenter information on a mobile keyboard.

Day 2 of Mobile UX is tomorrow. The focus is on touchscreens. You can follow the live tweets at #nnguw.

App Store Flow on iPhone Could Be Streamlined

Normally I love the iTunes App Store, but not so much today. I was trying to add Kayak’s travel app to my new iPhone and found the experience to be full of unnecessary and redundant tapping.

This was my screen flow:

  1. Launched the App Store
  2. Clicked Search
  3. Typed “kayak” and clicked the Search button
  4. Tapped Kayak’s app on the list screen
  5. Clicked the Free button
  6. Clicked the Install button
  7. Received a prompt for my password
  8. Entered my password and click the OK button
  9. Received a message asking me to confirm I wanted to download the app since Apple had detected this was a new device
  10. Clicked the Continue button
  11. Received a prompt for my password
  12. Entered my password and click the OK button
  13. Got directed to billing page with a request to confirm all information (since this was the first time using this device)
  14. Entered credit card security code without making any other changes and clicked the Done button
  15. Returned to the Kayak screen
  16. Clicked the Free button
  17. Clicked the Install button
  18. Done

Did I really need to enter my password twice? The App Store should be smart enough to know I just entered a password when sending me to the billing information page. Normally I don’t mind having to authenticate when accessing billing information, but not when I just did it a moment ago and am finger tapping an iPhone.

Another redundant step was requiring me to tap the Free and Install buttons a second time after going through the setup screens. At that point I had gone through 36 taps, so I think I clearly expressed my desire to download the app (“Really, I do want it!”, I thought). The App Store should have just started the download.

A last unneeded step was asking me to update my payment information to download a free app. My guess is that was done to get my iPhone ready for seamless purchasing in the future, but that’s a business goal of Apple’s, not a user goal of mine. I just wanted to download a free app. Ask me to confirm my billing information when it’s really needed.

My entire Kayak download took 38 taps. Eliminating the second password prompt and the last two buttons would have cut it to 26, a 31% reduction in taps. That’s a lot in a mobile experience. Dropping the credit card setup for a free app would have removed four more taps. Luke Wroblewski stated it best in Web Form Design, don’t ask for data you don’t need to complete the user’s task at hand.

As I said before, I love the App Store. But its download flow needs some streamlining, especially in the mobile context. I’m surprised Apple missed this aspect of the store’s design given its usual laser-focus on all the small details. As Charles Eames said: “The details are not the details. They make the design.”

Design Tools for iPad

Apple’s iPad has been out only a few weeks and already clever software developers are building design tools for this amazing new platform.

The Omni Group, makes of the popular OmniGraffle wireframing tool, have released OmniGraphSketcher for iPad. Priced at $14.99 in the iTunes App Store, OmniGraphSketcher allows you to create attractive charts, graphs, and other data visualizations on the iPad.

And Endloop, a Canadian iPhone/iPad development company, has released iMockups, a wireframing and diagramming tool for the iPad. Available on iTunes for $9.99, the app allows designers to create Balsamiq-like wireframes using their fingers.

I haven’t used iMockups but Endloop says in its blog that upcoming features include snap-to grid lines, a border and background color picker for UI controls, improved customization of UI controls, additional UI controls, more icons, and the ability to export to email, XML, or PDF. iMockups gets a 3-and-half-star rating from users in the iTunes store and the few reviews there comment about the app not being 100% ready yet.

It will be interesting to see how OmniGraphSketcher, iMockups, and other diagramming apps for the iPad add to the collaborative design process. For now I’m still keeping my sketchbook handy, but this could be the first wave of exciting new additions to the interaction design toolbox.


iPad Misses on Several Key Points

The world got its first look at the long awaited iPad from Apple this week. And after digging into it bit I think I can wait a little longer to actually get one, though, as Apple has missed some key functionality.

iPad Home Screen

A few of the key features Apple missed are:

No camera: Video chat is impossible without a built in iSight camera. With the hardware as large as it is there is no reason not to have a camera, and one better than the 2.5 megapixel on the iPhone.

No multitasking: There’s no reason a more powerful processor couldn’t have been included so that Mac OS X could be supported. And that’s another miss in itself.

No Mac OS X: Limiting the iPad to the iPhone OS removes a lot of key functionality for mobile users. Unless someone is planning to use Google Docs and other cloud-based apps there is a lot you can’t do with Apple’s “magical” new machine. Business travelers and many other users will find themselves having to carry an iPad and laptop.

Battery not removable: The 10-hour life of the battery is a big improvement over iPhone, but for the cost of the iPad it should come with a removable battery so a heavy user could charge it and swap in a backup.

Lack of clarity on GPS: It’s not clear if the iPad has a dedicated GPS chip or if that will be available on all models. The tech specs indicate Assisted GPS will be used, but not a dedicated GPS chip like one would find on a Garmin. It’s hard to believe Apple wouldn’t match the quality of location-based services available to the 3GS so I suspect this is more of a marketing or semantic problem than a technical limitation of the iPad.

While the iPad is a big advance in multitouch technology and will provide a great mobile web surfing experience, it does not offer enough functionality to replace the laptop, which is what many people were expecting. This is likely a business decision by Apple to not cannibalize the market for their Macbooks. The iPad may have strong appeal to BlackBerry users who want some of the iPhone experience without having to give up their Berry. Only time will tell if Apple made the right calls in limiting what iPad can do.