Mobile UX Design With Rachel Hinman

This week I attended Rachel Hinman’s day-long workshop on The Mobile Frontier at the UX Immersion 2012 conference. The conference, a new gathering arranged by User Interface Enginnering, featured deep dives on mobile and agile development. Here are my notes:

There are Many Similarities Between Mobile and Desktop UX Design

  • Many of the tools and techniques we use are the same.
  • We sketch.
  • We prototype.
  • We need to learn what our users need and want.

But There are Also Differences

  • A phone is not a computer.
  • There is no sense of having windows or UI depth.
  • There is a smaller screen for user input and new inputs based on context and device sensors.

How a UX Designer Transitions to the Mobile Mindset

  • Buy a device and integrate it into your life.
  • Know the medium and become mindful.
  • Participate in the experience.
  • Brace yourself for a fast and crazy ride.
  • This is an emergent area of user experience so nothing we do will be constant for long.
  • Embrace ambiguity, it’s fun and exciting.

Context is complex but is essential to great mobile experiences

  • The mobile context is about understanding the relations between people, places, and things.
  • Relationships between people, places, and things are spatial, temporal, social, and semantic.

Designing for Contexts

  • Design for inattention and interruption.
  • The mobile use experience is snorkling, the desktop user experience is scuba diving.
  • Reduce cognitive load at every step in the experience.
  • Ideate in the wild — you can’t innovate in mobile from behind your monitor.
  • Ruthlessly edit content and features down to what’s essential.


  • It’s a good way to develop ruthless editing skills.
  • You can change a design quickly at little cost.
  • No expert skills needed.


  • The exercise helps designers new to mobile who do not yet know the heuristics and constraints of the medium.
  • It’s essential for mobile UX because the medium is so new.
  • If you are prototyping for a desktop app and a mobile app, allocate to mobile triple the amount of time you devout to the desktop.
  • Prototyping helps you fail early and fast.
  • Because a mobile experience is so contextual and personal, explore techniques like body storming and storyboarding.
  • Prototyping is a great way to fail when it matters (and costs) the least.
  • Desktop prototyping is a luxury, mobile prototyping is essential.

Graphical User Interface vs. Natural User Interface

  • We are at a pivotal moment in the design of user experiences — the NUI/GUI chasm.
  • A GUI features heavy chrome, icons, buttons, affordances; what you see is what you get.
  • A NUI features a little chrome as possible and is fluid so content can be the star.
  • As UX designers we need to work to eliminate chrome, not make the chrome beautiful.

Motion as a Design Element

  • Animations and transitions can teach users how the information unfolds (see Flipboard).
  • Motion brings fun to the party, and who doesn’t want to have fun.

Rachel Hinman is the author of the forthcoming The Mobile Frontier. You can follow her on Twitter at @hinman

Book Review: Axure RP 6 Prototyping Essentials

Published: January 2012 (Packt Publishing)
Paperback: 446 pages

I just finished reading the first book I’ve ever seen devoted exclusively to user experience design using Axure RP 6. Axure RP 6 Prototyping Essentials by Ezra Schwartz takes readers through project examples with step-by-step instructions for creating highly realistic interactive prototypes without writing a single line of code.

Unlike other prototyping books that address multiple tools, this one is focused solely on Axure.

Axure RP 6 Prototyping Essentials
Axure RP 6 Prototyping Essentials

Annotated Screen Example
Annotated Screen Example

Schwartz’s book introduces using Axure to create simple website wireframes and prototypes before moving on to more advanced topics like:

  • Using session-persistent variables in simulations
  • Using raised events
  • Conditional logic and behaviors
  • Dynamic panels
  • And much more

The book even addresses topics like simulating keyboard shortcuts for desktop applications through a technique that leverages hidden form fields. It is full of clever and well-illustrated examples.

There are also entire chapters on generating specification documents, using the team collaboration features of Shared Projects, and creating custom UI widgets for shared pattern libraries. There also is a brief section on prototyping for mobile devices (an area of functionality that has been improved in the recent Axure 6.5 Beta).

Axure RP 6 Prototyping Essentials also addresses important areas of the prototype planning process like object naming conventions and other things to consider if you are building highly interactive prototypes or working on a team project. While developers will understand why you need naming conventions for your objects, it’s not something UX designers usually think about, especially if they are more experienced with producing static wireframes. The coverage of pre-planning activities is extremely useful if you are new to Axure.

The book is available in both e-book and printed formats and is a great starting point if you have little to no familiarity with Axure. You’ll quickly see why Axure is one of the most widely used software tools for user experience design. A word of warning — it is helpful if you are familiar with the user centered design methodology and its focus on iterative designing and testing, which is discussed in the first chapter.

Whether your skill level with Axure is novice, intermediate, or advanced, you’ll find valuable techniques and best practices in Axure RP 6 Prototyping Essentials.

Great New Features in Axure 6.5 Beta

The beta version of Axure 6.5 was released recently and includes some great new features for mobile prototyping, especially simulating iOS apps.

Axure 6.5 Beta Demo
Axure 6.5 Beta Demo

Some features I’ve already explored:

  • A home screen icon for iOS can be imported into a project as a PNG
  • A splash screen that displays when your “app” first loads also can be imported
  • Full-screen display mode for prototypes launched from the home screen icon
  • Dynamic panels can now be “pinned” to the browser to allow simulation of a fixed tab bar with content that scrolls from underneath it
  • Black or translucent status bar
  • An iOS-style arrow button shape
  • Support for drag and drop
  • Left and right swipe events

Your prototype is still created as HTML and displayed in Mobile Safari but the full-screen mode allows you to simulate a native app’s appearance. To test your design on anyone’s iPhone or iPad just place the files on a publicly available web server or Dropbox and access them with the browser. You have to add the app to the home screen to get the icon on the device and launch in full-screen mode.

The biggest problem I’ve had with the beta is that scrolling actions can pull the simulation away the browser’s edges. This is not a real problem for a prototype being used for usability testing or requirements demonstration, but fixing it would make your simulations seem even more native (it also may be possible already and I just haven’t got it yet).

All in all the new version of Axure is pretty exciting. It’s fast become the best tool short of HTML coding for mobile prototypes.

To learn more about the new 6.5 beta consider attending the Chicago IxDA monthly chapter meeting on Wednesday at Critical Mass. I’ll be giving a short talk on Axure for mobile prototyping.

To view my demo, a screenshot of which is included with this post, point your iOS browser over here.

You can also download my RP file, which was craeted in the build.

Happy prototyping!

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

Drop Shadows for Menus in iRise

Sometimes you just want your menus to have a drop shadow. So in an effort to push the fidelity of an iRise simulation to a higher level, I recently created a simple menu Master that uses sections to display the kind of drop shadow you’d normally handle with CSS3. It was a little more labor intensive than CSS, but fairly easy to do once the menu bar was laid out.

To make the menus as easy to maintain as possible, the drop shadows are applied in the Master and the shadow color is handled in the Style Manager. Mouse events are used to toggle the drop shadow sections on and off with their associated menus. The screen capture below shows everything you need to know to mimic the effect of CSS3 drop shadows. And if you wanted an even richer display using rounded corners and a gradient drop shadow (like Mac OS X) , a transparent PNG could be used.

Creating Menu Drop Shadows in iRise Studio for Mac
Creating Menu Drop Shadows in iRise Studio for Mac

iRise for Mac Alpha Testing

I recently started testing iRise’s Studio for Mac alpha release.

For the most part the interface is consistent with the Windows version. I was able to create projects in both Mac version 8.7 and Windows version 8.6 and open and modify them in each other. The Mac version has support for iBlocs, although the interactions for setting widget properties was a little wonky and unintuitive at first (at least for the iframe iBloc I tested). Datasheets, masters, and other functionality was working as expected.

The biggest bug I encountered was hidden fields not passing values in both Safari 5.0.5 and Firefox 4.0. This is a major bug for me because I frequently use hidden fields to pull datasheet values on to a page without displaying them and then pass them through to other pages on link or button clicks to maintain state within a simulation. Hopefully this one gets fixed soon. The other major functionality missing is no connectivity to the Definition Center, iRise’s central repository for shared projects. This is completely understandable as I imagine the development team is focused on getting Studio stable before tackling Definition Center.

All in all, I’m impressed with the alpha so far and am glad to see iRise finally adding support for the Mac.

iRise For Mac
iRise For Mac

The Right Tool at the Right Time

Someone on the Interaction Design Association’s LinkedIn group recently asked how other people were using wireframes at work. This inevitably led to the age-old question of what is “the best” wireframing tool. Not only is there no best tool, but it’s not really a good question to begin with. The question should be what tools are best for the different phases of a design project.

For example, I use iRise on my job at iRise is an extremely powerful prototyping tool that allows you to build dynamic prototypes with real data records behind them. It’s one of the best prototyping tools available, but it’s also time intensive to use and not geared toward the early exploration of ideas.

For early product ideation the good old sketch pad or white board still work best. Sketching is fast, cheap, easy, and accessible to your business partners so they can participate in design exercises.

Balsamiq is also great for rapid idea generation, but you need to have a computer handy with the software installed. And it won’t work for impromptu design sessions in a conference room or coffee shop. The mechanics of working with the program can get in the way of the creative design process.

OmniGraffle and Visio have their place when you need to create annotated wireframes that can be easily printed or shared electronically. Where wireframing fails is in showing interactivity. To demonstrate rich interactions using Ajax or HTML5, it’s probably best to code it in HTML or create a quick Flash prototype.

And, of course, time and financial constraints will also influence what tools you use. For a more comprehensive look at the many wireframing and prototyping tools available, see Holger Maassen’s recent post on

Axure: Mac to Windows and Back

I’ve recently been testing how well Axure RP handles project files that are moving back and forth between Mac and Windows.

The initial results have been pretty exciting. All the interactions and conditional layers added on one platform are preserved when editing the project file on the other platform.

Since Axure released version 5.6 for Mac in April this popular prototyping tool can now be used by teams that are split between Mac and Windows users — perfect for a team in which the visual designers use Macs while the UX folks and developers use Windows. Shared projects can be accessed by both platforms for file versioning and page check-in/check-out.

Below are screen grabs from Mac OS X 10.5 and Windows 7. These are from the Movable Web reference project I’m building that will attempt to implement as many of Axure’s features as possible on a fictitious website/blog focused on mobile applications. More on that later this summer.

Axure’s license is user based and allows two installs, which is how I use it on Mac and Windows 7. And the license includes a 30-day free trial so you can test drive it before committing to a purchase. If you are a student with at least a 3.0 GPA you can get a free license through Axure’s Good Student Program and UPA members also can get a discount.

Axure RP 5.6 for Mac
Axure RP 5.6 for Mac
Axure RP 5.6 for Windows
Axure RP 5.6 for Windows

iPad Prototyping Tool

Teehan+Lax, the awesome team that brought us the iPhone GUI prototyping PSD, has stepped up again with their iPad GUI PSD.

I used their iPhone GUI PSD about a year ago in an HCI graduate class project and was able to create some very polished comps that our project team used for medium-fidelity prototype testing once we glued the printouts of the app to iPhone shaped foamcore cutouts. I won’t be standing in line Saturday waiting for an iPad, but I know where I’ll be turning if the opportunity comes along for an iPad design project. Enjoy!


HCI 440: Usability Engineering

Just finished the final session of my usability engineering course at DePaul, a course that provided a lot of insight into the UCD process and the compromises you make on a working project.

Overview: The main focus of the course was to design a mobile phone application over an 11-week period. To simulate some of the pressures and challenges of a real world situation, we had to work in teams and deliver each successive phase of the project (research, requirements, designs, prototypes) weekly. The final deliverables were a presentation of our business case and the market problem we solved along with completed Photoshop mockups of the three primary use cases.

Research: After deciding on the application we wanted to design (an iPhone app for fashion accessories), we conducted market research using a combination of online surveying and interviewing. We surveyed nearly 50 people who matched our intended target demographic and interviewed 10 people during a one-week period. As so often happens, we learned we made incorrect assumptions about what the target user wanted and missed some features they considered important to the application.

Requirements: After completing our research we developed a set of user goals and the necessary supporting functionality based on what we learned about the target consumers. Due to time constraints we had to skip development of traditional use cases and diagrams, and instead utilized a matrix that traced functionality back to user goals. We then developed the requirements to deliver those functions.

Prototype One: This was one of the most interesting and fun parts of the course. Several of our peer teams were developing prototype applications in Flash or HTML for testing on laptops. We chose a different route. Using the iPhone prototyping tool from Teehan+Lax we mocked up our prototype in Photoshop. We then printed the PSDs and glued them to foamcore cutouts to make interacting with the prototype a more tactile experience. While we lost some of the interactivity some our peer groups had, we gained an advantage by having test participants (drawn from the class) actually hold and touch our app. We gained useful insights by watching them respond to color, contrast, and visual cues while actually holding the prototype and viewing it from a realistic distance (though I admit we could not accurately mimic screen brightness and other settings that affect users in the real world). While one of us moderated the tests another played the role of the phone and handed out new screens in response to participants’ actions. In two hours we were able to test five people going through three main use scenarios while capturing our observations on recording forms. We followed each test by asking the participant to respond to five statements about their experience, which we asked them to rate using the Likert scale.

Evaluation: We analyzed the usability issues encountered in several ways. We looked at the frequency of the issue, the impact to the user’s ability to complete a task, and the criticality of the feature of the app where the issue occurred to overall business goals (in our case conversion).

Frequency was recorded as a simple count of the number of times an issue occurred. Impact to task completion was measured as high, medium, and low, with numeric values of 3, 2, and 1 respectively. Criticality also was measured as high, medium, and low, with numeric values of 3, 2, and 1 respectively. Criticality level was set by using the requirements matrix to see how the feature traced backed to user goals.

For example, the failure of two users to see a Buy Now button would be rated as Frequency=2, Impact to Task Completion=High, Criticality=High. This would be calculated as 2 x 3 x 3 = 18. This allowed us to prioritize the issues based on what fixes would have the biggest improvements to the app. In a business project, of course, time and cost would have been other dimensions to consider and some high ranking fixes might have been descoped due to time constraints.

Prototype Two: Based on the Evaluation phase we focused on enhancements to the search interface. Adjustments were made to search results interaction widgets and results list displays. Sorting by price/brand was originally deemed as out of scope but was added based on user feedback. People wanted ways to narrow results quickly, and price and brand seemed most natural to most participants. The refined prototype was part of final deliverable package.

Presentation: Our final presentation was organized around several key areas—user expectations for mobile applications based on the current products available, market need for the product we developed, business opportunities in satisfying those needs, and the iPhone application we designed to realize those opportunities. This exercise allowed us demonstrate that what we designed would be accepted by the market and could be profitable. In addition to our app we developed an affiliate program model that would partner with online fashion retailers to provide revenue to us for referred purchases.

This was a great learning experience because while the primary focus was designing an application following the UCD process it also challenged us to be concerned with satisfying business goals. A useful skill when your design work has to actually float the business.

Note: Screen designs and greater details were not shared because we are considering working with the university’s business school incubator to pursue a commercial application.