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".....

A Tale of two Sites

Lately I've been contributing to charities using their websites to donate money directly - rather than hand money to a chap on the street. 
The experience has been interesting to say the least. As you would expect, some websites are poorly designed, unnecessarily complicated and make it very difficult to donate. One website I used was actually misleading - getting the user to set up a monthly subscription when the user thought they were going to make a one off payment (if you didn't see the check box with the small print..). 
Most website design guides focus on layout/composition, colour, texture, typography and imagery.  Modern web designs will have you focus on social aspects - such as design for sign-up, on-going participation, collective intelligence and sharing. I'm not going to dig into these topics (it's easy to look up) - but the good and the bad are exemplified in the two examples I've chosen to illustrate the experience.


I will apologise here for making an example of the bad (the Leukemia & Lymphoma Society) - but in doing so I hope this will be seen as constructive criticism that will have a material effect on direct website donations. 


Remember: my objective is to donate money, quickly.


The Bad:  Leukemia & Lymphoma Society


This site is confusing. The site serves 4 purposes - informs users,  get donations, get visitors involved and providing practical support for sufferers of blood cancers. 

I'll highlight some of the main issues

• Objective: the intentions of the site are hidden or downplayed.  The "Donate" and "Resource center" links do have a prominent place on the page - but are easy to miss and could be better promoted.
• Readability : small font, small controls, poor contrast and branding all affect the readability of the site. The multi-toned brown background with blue text serves no purpose and detracts from the readability of the text.  The tiny navigation controls are a challenge for anyone using a mouse (never mind a finger on a tablet or phone).
• Structure: there is no page structure and information is arranged haphazardly across the page. There are no clear regions on the page for the 4 objectives of the site. 
• Content: the content on the site is misplaced. First the "contact and information specialist" - sits in the middle of the page - (when on most sites it would be at the bottom) - and there is no clear indication of why you need to contact a specialist. The second issue is the news feed - that mixes up genuine news with requests for users to get involved.
• Social: Focus on sharing or communicating to others is a small icon bar at the foot of the page. 

Once you click the Donate link - you are navigated to a second page full of text and links. Unfortunately the donate page reads like a contract. 

True, there is more to giving than through an online donation - but how much do you lose by forcing the user to read through this and click again to donate? 

All that text makes the site less engaging. 

The Good : Water.org


By contrast, water.org is a much simpler and easier to use site.

• Objective: clearly identified with two large buttons on the top of the screen - "Donate" and "Get Involved". 
• Readability : big font, big controls make this site easy to read and navigate around. branding is kept to a minimum and does not dominate the page or style.
• Structure:The page cascades down giving you more information as you work down the page. The page is laid out like a tabloid - with the headline dominating the center of the page, and the lower half of the page being simply structured in 3 columns.   
• Content: the content on the site is well structured. The 3 columns have a clear purpose - facts, news and follow on actions.
• Social: The foot of the page is dedicated to sharing. the badge is large and difficult to miss. It boldly says "Follow Us" and asks you to engage.

When you click the "Donate" button on the page - you are taken to a page to capture your credit card details to make a donation. Simple. 
Instructions to donate by other methods are also displayed on the screen.

Design matters in everything. Whether the site is an internal intranet or a public site - take time to focus on the objectives of the site and try to incorporate the good elements of web page design. Don't try to inflict your personal or corporate style on others if that detracts from the objective of the site.

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