I attended my first usability conference about 5 years ago where I was confronted with the term user-centred design. Admittedly I was uncomfortable with the term, to me it was one of those touchy feely fuzzy terms used by designers who walked around with their head in the clouds. However, after witnessing the practical side of it, I’ve become a strong advocate and have not looked back.
For me, one of the understated positives of user-centred design, is that it takes the ‘ego’ out of the design. For a designer I imagine, there is nothing more humbling than to sit in on a usability session where a user struggles with overly complex navigation to a point where they admit defeat and abandon the application. User-centred design is a must for any application design and for mobility applications has to be nonnegotiable!
Most designers are passionate about their designs and become somewhat agitated when told that their design does not work for a particular technical reason – and I sympathise. The reality is that mobility at the moment has many factors working against it and most of these are centred around technology limitations. For a design to have a chance in mobilty these limitations must be understood and the designer pragmatic in their design approach.
To understand the importance of user-centred design lets first look at some of the practical differences between a typical J2EE in the PC office environment (sorry .Net guys) and that of a mobile application used in the field.
Environmental factors
Office settings provide a safe, often well controlled, established environment with which to work. Connectivity is guaranteed at an optimum level and environmental conditions, temperature and light are moderated (our office not so well at the moment but you get my point). Although application support is never perfect it can be provided on-site or remotely.
A Road Warrior on the other hand has varying experiences in a typical day. Our client at the moment has field workers who spend their day travelling, often long distances, on water. Their environmental challenges include varying degrees of light, glare - particularly off the water, sea spray and to top things off, motion. Their technical challenges range from poor battery life, signal stength and bandwidth fluctuations. Their applications cannot be designed with an expectation that connectivity can be achieved. Application support is limited and largely relies on self diagnosis and resolution and in some cases resulting in the worker returning to base.
Physical device limitations
Presently our water bound officers are using a PDA consisting of the following characteristics:
§ Smaller screen size and resolution - 3.5” screen, 240x320
§ Restricted processing power – 400 Mhz
§ Limited memory – 64 MB RAM (killer)
§ Cut down operating system - Windows Mobile 2003 se
§ Limited bandwidth – CDMA and EVDO. Due to remoteness of use, bandwidth is generally limited to CDMA network.
I understand that PDA devices have evolved somewhat, however they are still limited to a 3.5” screen or smaller with the current trend of manufacturers providing 2.8” as the new standard. There are some devices which provide 128 Mb RAM which is an improvement on the 64Mb generation 2 devices. Whilst the HSDPA network is available here in Australia this is little consolation to our workers who will be spending the majority of their day in areas out of coverage.
Type of Worker
To all the field workers I’ve met forgive me for what I’m about to say. The type of field workers that I have met are generally not
computer savvy and this needs to be taken into account when designing mobile applications. It should not matter, but it
does. Most mobile devices, be they a smartphone, PDA, UMPC, or Tablet require a higher level of user savviness than
required for a PC. Device input and turning on and off features are different, especially for those running a Pocket PC
operating system. Pocket PC devices have a different navigation model to a PC operating system and require higher levels of
user involvement. Look around as there are some great pieces of software out there which can make life easier for the
workers. Quick sidetrack, for those considering to deploy a mobile application I strongly urge you to look at a product called
Kiosk Engine made by Spb http://www.spbsoftwarehouse.com/products/kioskengine/?en.
Kiosk Engine allows you to control what applications are made available to your workers. When the device starts you are presented with one page which lists the applications that are available. The page effectively becomes a psuedo desktop. We’ve tried it, and feedback from the guys has been extremely positive. They like that similarly to the PC desktop paradigm, all their applications are located in the one spot and when they exit the application they are returned back to their desktop.
Paper Prototyping Is Not Good Enough
The reality is that paper protoyping although better than no protoyping, does not work for mobile applications. It can be used as a discussion point to validate the businesses requirements and as a starting point for a designer to work on a screen layout but that is where it ends. When it comes down to it, it loses its effectiveness as soon as you walk out the door. Paper prototyping cannot effectively represent some of the considerations mentioned earlier such as glare, varying lighting conditions, wind and water.
To properly exercise the different interaction and design of a mobile application to that of a PC, a higher fidelity more realistic prototype is required. Our team learnt this the hard way. We designed and refined a mobile application design using feedback received on a paper prototype. During testing of the application we took it out into the field to get some feedback and found some usability issues which affected how the officers interacted with the application. Some of the feedback included inadequate contrast of buttons to indicate sufficiently whether a button was active or inactive due to sun glare, to size of buttons and spacing between objects. It is important that the button and field controls are of sufficient target size for the user, particularly in our case when the context of use is on water where motion is involved. Where possible I would recommend to only show button controls if they are active and size them appropriately. Don’t be afraid to try different contrasts. We found that white text on a dark background where glare is involved can be more effective than black on a white background. The thought of this will probably send most designers into a fit, but they are not the ones who will be using the application…bring them out into the field and let the prototype do the talking!
Recent Comments