Let's get into character

There's a classic line in Quentin Tarantino's "Pulp Fiction". Two hit men, Jules (Samuel L. Jackson) and Vincent (John Travolta), are on their way to a job where they could be dealing with as many as six guys.

Jules says to Vincent that they should “get into character,” indicating that they each play a part when they go on the job. The job of hit man is nothing more than a career choice and they don’t necessarily define themselves within those parameters.

That's great advice that every software developer and product manager should take note of. Put yourself in the position of the user and really role play the moment or the "day in the life". Better still - get out of the office and go on the road and sit with the user you think you are building software for. I say "think" because most people building software are kidding themselves that what they are building is good for the user. 

Think like a movie star. You really need to get inside of the head of the user. Only then will you start to realise that the user really doesn't want to use your application because it SUCKS! More to the point, the user is just a transient, using your software for a brief, fleeting moment to accomplish a task (e.g. make the hit) - and then they need to get out.

If the answer to any of the following is "yes" then you're in trouble.

• the user interface is dictated by the data model 
• you built the technology and are now looking for a use case
• the user is expected to remember the process steps
• the app has a lot of neat features that users "might" want
• executive management changed the design to suit themselves
• that's how the desktop version works
• "well it was good enough in my day"

Put simply - if the application doesn't do anything for the user - it sucks. The user won't use it again, unless forced to - and that itself is becoming an outdated, unworkable model.

Enterprise software vendors beware. If you hadn't noticed - users are walking with their feet - choosing to use other applications and devices. Put yourself in the shoes of the user and forget about your bias for one technical solution or another.

Of course technology matters because if you use the wrong tech or approach the performance or scalability will suffer and again the user won't use the software. Technology should be the second consideration, after you have nailed the user experience.

So the next time you sit down with your development team to knock out a new application or update an existing one - put on the white shirt, black tie and black suit, put "Misirlou" on the stereo and "get into character".....

Product Kaizen: Observing how users interact with products to drive future enhancements

I discovered two new things today. Not big things, mind you, but very helpful.

1. Typing '@' in a Facebook comment stream immediately brings up your friends list and starts filtering your text as you type

2. Selecting text from an error message in Adobe Flex and hitting right click brings up a menu that has 'search in google' as the first option.

Both are great examples of observing user behaviour after the product has shipped and using those observations to drive improvements to the product. Most user testing occurs during the design cycle (in agile) or after the code has been written (lets face it - in waterfall development) - but rarely post production.

In the Facebook example, people have been typing '@' to direct a comment towards a specific friend in a discussion thread. The use of '@' in this way carried over from Twitter, at least that's why I started doing it.
In the Adobe Flex example, people getting error messages would select the text from the error message, paste the message in a Google search, where they would most likely find a) other people who had the problem and b) solutions to the problem they encountered. (that's how I found the feature). It's not surprising, as most product documentation falls short on "problem diagnosis with corrective actions", so the user community fills the gap.

Both cases sound obvious at first, but you will be amazed at how these things get overlooked by traditional software companies. Web analytics, deployed to understand user behaviour in Enterprise Applications is still a novelty.
In these use cases, at some point, the product organisations observed a repeatable pattern occurring with the use of the product; they looked at the pattern and determined there was a way to optimise the product as a result.
But how did they recognise the pattern in the first place? Where did the pattern start?

We start by recognising events. An event is an occurrence within a system or domain. In our case, it is something that has happened within the application. Many events are beyond our scope of interest and do not require any reaction. The events that are of interest to us are called 'situations'. A situation is an event occurrence that we determine requires a reaction. Through observation we see that there are certain conditions in which the situation arises. It may take some time to determine what the conditions are, (some could be co-incidental) - so iterative testing is required to ensure that the conditions we will watch for are appropriate.
Finally we must determine what the appropriate behaviour, that is, the reaction, of the application to the situation; these are the actions. The actions need testing to ensure that they are appropriate and not a nuisance. Remember Microsoft Clippy?

Disclaimer: The following is just hypothetical. The description is how I would have determined the outcome and may or may not reflect what really happened.

Back to our Facebook use case. At some point, it was observed that there was a frequent use of the @ symbol (and not used in the context of a domain address). The Situation-Event-Condition-Action can be described as follows:

Situation: Significantly high use of @ symbol across all user comments.
Event: @ symbol is entered
Condition: user is entering comments in the comment box

Determining the action requires observation. We need to understand what the user does immediately after typing the '@' symbol in the comment box. In some cases there may be no action that you can predict with high probability. However in the Facebook case, at some point it would have become clear that users were typing the name of a friend after the '@' symbol. After some analysis, it would be recognised that the text typed after the @ symbol was data that was already stored in the friends object.

Action: display list of friends as the user is typing characters immediately after the @ symbol.

This would require some modification or addition of the relationship between the comments object type and the friends object type in Facebook. (I'm guessing that is how they have structured the objects in FB).
The end result is that the user has a much improved experience when typing a comment and addressing a specific friend. The enhancement enables the user to complete the task in a shorter time period. Additionally it reinforces the value of maintaining your friends list in Facebook.

This type of analysis is not limited to small user gestures - but can be applied to any interaction. Ask yourself this question, does your Enterprise Application help you or encourage you to manage or maintain your data in this way?
If you are looking for an asset in an ERP application or a contact in a CRM application - will the application provide hints, links or smarts to help you complete the task you are undertaking? Chances are you are looking for that asset because there's a fault (or an order) that needs addressing - or you are looking for a contact because you need to make a phone call or follow up on an inquiry. So did you have to carry out two steps or one to get the job done?

Looking beyond the screen : Text-to-speech and eyes-free interaction

Question:

How do you build a Touch screen application, on a device with no keyboard, for someone who has limited sight or just cannot look at the screen (they are driving) ?

I was fortunate enough to attend Google IO last year. (each year it just gets better and better - if you missed it - register now). Amongst some of the great sessions I attended was one that deals with two of my most favourite subjects - user interaction and voice technology. Presented by TV Raman and Charles L. Chen - they discuss the Eyes-Free Project : a project that aims to enable fluent eyes-free use of mobile devices running Android. Target uses range from eyes-busy environments like in-car use to users who can't or don't want to look at the visual display. When you watch the video you will see some of the UI innovations for taking advantage of the touch screen without needing to actually look at the screen. 

You can download the applications to your Android phone. It's great to see such innovation around user interactivity - especially on a mobile device. The mobile device has the ability to sense more about it's environment than your PC can.

You can download the presentation here

Going beyond the mobile use case, it does not take too much imagination to see the same principles being applied to the next generation of touch screen tablet devices or the humble trackpad on your existing laptop. Imagine a data capture or input mechanism being driven by your gestures and not just the final click - think about the journey and not just the final destination. Could you optimise an operation in such a way to make it is more intuitive and yet productive? Watch the video and find out...

The Eyes Free project is here