In the talk we discuss the unique constraints of designing a physical device, and walk through the research, design and testing process.

You can watch the video here: Matt Morphett & Shane Morris: Switching On My Ears

Nowadays apps can be open, closed, dormant and all sorts of states in between. When it comes to user experience it’s our job to understand how an app behaves in various states of open-ness, and how the user experience transfers between those states.

Between Closed and Open

By “half-open apps” I’m referring to apps that provide some “intermediate” states that are open, but not quite “fully open”. Let’s say that a “fully open” app is one that is providing access to all its functionality, using it’s “full” user interface (on a mobile platform that typically means “full screen”). An example of a “half-open” app might be a desktop widget that provides a limited “window” into the full application.

When an app posts a toast notification, or updates a live tile in Metro, we could say it is “a little bit” open. When an app is snapped to the side in Windows 8 we might say it is “mostly open”. An app might be fully opened when it is “full screen”.

Half-open Metro Apps

When we look at Microsoft’s Metro apps for Windows Phone and Windows 8, what we actually see is a continuum from closed to open. For Windows 8 Metro and desktop apps we see the following:

	NOT VERY OPEN
“Toast” Notification		Metro
Start Tile (both sides)		Metro
Snapped app		Metro
Open app		Metro
Desktop app	Office 15 Technical Preview – Metro Style from The Verge	Windows Desktop
	FULLY OPEN

Continuum between Metro apps and Desktop apps

I include Windows Desktop apps in the continuum because I predict there will be many Windows 8 Metro apps which will provide continuity with a “Full Service” traditional desktop application. For example, It would make sense for a Metro Photoshop app and a Desktop Photoshop to interact, presumably via “the cloud”. Many line of business apps will follow a similar approach: they will provide a predominantly “browse-y” experience in Metro (think dashboard), while requiring users to “drill” into a full desktop app to do intense transactional work.

(The reason for this could be simply to access the greater power and flexibility available on the Windows Desktop, or it might be to access the more powerful User Interface paradigms of the desktop. Don’t make the mistake of thinking that Metro has made the traditional Windows Graphical User Interface irrelevant.)

User Experience Design: Always Open

These days we talk a lot about designing services that follow people across different platforms (smart phone, web, call centre etc.) Particularly with Metro (but also with things like Android widgets) we also need to start thinking about designing services which follow people up and down the various states of “open-ness” within each platform.

So of course, when I say “app” above, I really mean “service”. A seamless service might well actually be delivered by several applications. The important thing is that people are not tripped up, or confused, by the transition between them.

I will be speaking at Microsoft’s “Campfire” event in Singapore on April 13. I will be talking about the role of prototyping throughout the project lifecycle, and also about working with the Metro design language on Windows Phone and Windows 8.

If you’re in Singapore come along and say “g’day”: Microsoft Campfire

Working with Readify and the team at Australia Post, we were able to quickly generate a striking user interface that I think provided a nice balance between Metro styling and Australia Post Branding. Congratulations to all involved.

Collaborators:

• Readify – development
• Australia Post, especially Adam Crapp – for visual design.

That’s the “UX Research Tax”.

Who are these people?

In a nutshell, we do up-front research to better understand:

• the people who will (we hope) use the product we are designing;
• what they are trying to achieve;
• how they will go about their tasks; and
• the broader context in which the product will be used.

In the early days of Human-Computer Interaction, up-front research was a given for every project. This was because we knew very little about how people would adapt computing products to their everyday tasks (which were almost always non-computerised at that point). So every project started with a large amount of research – predominantly “Contextual Inquiry”: basically observing users in their natural environment. (“Users in the Mist”, if you will.)

More recently, there is more debate about how much up-front user research is required. Of course, there are situations where we simply can’t begin without research, because the domain or users are completely foreign to us. (Matt Morphett pointed me to this article from a few years ago by Dan Saffer which sums this up well: Research Is a Method, Not a Methodology.)

Genius Design or “Seen it all” Design?

The term “Genius Design” (think Jony Ives) describes the idea that great designers “just know” what is required for the products they are designing. Somehow these design superstars just have an innate sense of what features a product needs, and how best to present them to gain user acceptance, even fanaticism. They don’t need to do research.

Jared Spool takes a more practical view of Genius Design, and I agree. Jared posits the term “Seen it all” design to describe the ability of a veteran designer to apply their overall body of experience of to a new design problem, without necessarily having to do new research.

Building a Body of Research Experience

All competent User Experience designers are dedicated students of human behaviour. They study human behaviour through formal research, and also through everyday curiosity about what people do, and why.

(They also study human behaviour through self-examination. Although many disapprove of using one’s self as a research subject, there are insights to be gained by introspection that simply aren’t possible by observing, or interviewing, other people.)

It’s this body of knowledge – sometimes explicit observations, sometimes just a general sensibility – that allows designers to make “intuitive” design decisions day-to-day without referring to specific user research.

Which brings me to the UX Research Tax…

Some User Research in Every Project

When people starting out in User Experience design ask me how they can become better designers, I answer in two parts:

1. Sure, read all the books and blogs and other reference material
2. Do as much observing of users as possible: formally or informally.

I was lucky when I started out in this field that we were able to do a lot of user research and a lot of usability testing. If I am any good as a user experience designer, a large part of the credit goes to those many many hours watching people deal with interactive products and building a general sense of how people approach them.

For that reason, I suggest incorporating some user research into every project. Even though sometimes you will struggle to specifically explain how the research has contributed to specific design decisions, that piece of research is the tax every project pays towards making you a better designer, and making the designed world a better place.

There’s No Need to be Arrogant

It’s tempting to say we are such good designers we do not need research. Sometimes it’s an ego thing, sometimes it’s because stakeholders don’t see the need, sometimes it’s just because research is hard work and can be tedious. (My suggestion in the latter case is to think about how you can give a more junior designer a break by having them help out with the research – they need that experience more than you.)

Pay the UX Research Tax now in every project – and be a better user experience designer in the future.

The talk is entitled “The Metro Design Language and what it Means to you”. Microsoft’s “Metro” design language, currently focussed on Windows Phone, is moving to XBox, Windows 8 and beyond. I’ll be talking about what Metro actually is (Microsoft isn’t exactly clear), the challenges of applying it, its strengths and weaknesses and what it says about current interaction design trends.

Shane

Using the Hand as a Mouse

As you watch this demonstration, you’ll notice that the user interface relies heavily on the position of the user’s hand. What that means is that the user has to rely on visual feedback from the screen to know if they have their hand in the right position.

In other words, the user interface treats the operator’s hand like a mouse pointer.

The problem with this is that it requires the operator’s attention – they need to monitor the display to place their hand correctly. Now, this is not a great idea in general because our hands and arms are fairly imprecise – especially when dangling in mid-air – but you can see that this is even more of a problem when you are driving and supposed to be focused on the road.

Some Alternatives

A couple of alternative approaches come to mind:

1. Real Gestures
2. Physical Buttons (gasp!)

Real Gestures

Rather than relying on hand position, interpreting actual gestures would be a more effective approach. For example, different hand gestures (palm, fist, various numbers of fingers) could be used to represent different commands. (Maybe the system being used here just doesn’t have that level of fidelity.)

The advantage of using gestures is that they are independent of hand position. That means the operator can keep their eyes on the road, while simultaneously making gestures. The disadvantage of gestures is that they require the user to memorise them (except for maybe a few, more intuitive gestures – like palm for stop in many cultures).

Physical Buttons

Are physical buttons so bad in en environment like a car cockpit? Physical buttons have some particular advantages:

• You get physical feedback through your sense of touch to confirm you’ve selected the command.
• Once spotted visually, an operator can rely on spatial memory and proprioception (are sense of how our limbs are physically deployed) to select a button – they do not have to maintain attention.
• Once used a few times, muscle memory can kick in, thus negating the need for visual target acquisition (yes human factors folk refer to it as target acquisition).
• Most of the time a physical button has only one function which never changes. This allows for effective mental mapping.

When is a gesture not a gesture

To my mind, a gesture’s meaning is determined by the relative position or movement of limb and digits, not merely a position in space.

At the end of the day both approaches have their role in gesture-based products. Hand positions are best for new users, so long as they can be fully attentive. Gestures are better for situations where the operator’s attention is elsewhere – but they need to be learned.

In this image it says it is “Ready to perform category backup”. Good, coz I’m ready too. Now what? In fact, it will sit there a long time being “Ready to perform category backup”, and then, suddenly, it will perform category backup. (Turns out it’s waiting for me to go to bed.)

The Importance of Good Communication

Good software keeps you up to date with what’s going on, what’s about to happen and what you need to do (or, it reassures you that you don’t need to do anything).

We’ll be talking more about our experience designing hand-held devices for use by cochlear implant recipients and their carers.

More info here: Switching On My Ears

Thanks to Cochlear for allowing us to share our experiences. If you’ll be in Dublin for Interaction 12, get in touch!

If you look carefully you’ll see I’m wearing a shirt from Stamford Interactive. Way to promote the opposition Shane!

In the full talk I describe 5 benefits of prototyping throughout the software development lifecycle. Prototyping isn’t just for UX!

The full session is here: Prototypes, Prototypes and Prototypes, and the Difference Between Them

Shane.