I found yet another entrant for the mouse gymnastics the other day. Before the animal rescue league gets on to me, I should clarify that by mouse gymnastics I mean interfaces that require a high degree of dexterity and mouse control. As you will see, mouse gymnastics is not a good thing.
I was working on a borrowed machine. One of the start-up applications threw up (I chose my words carefully) the following interface:
Where’s the problem? Well when you move towards the close button (X), if you do anything other than approach it from the top or right, the interface expands as follows:
It turns quiting the application into a test of mouse skills. By the time I finally hovered my mouse over the close button it was a good 100 pixels higher on the screen. If at any time I overshot or moved out of the hover zone, the expander shrunk back and I had to move my mouse 100 pixels down the page to start again.
Why oh why would anyone ever design an interface in such as way? I can only guess that they saw the Apple Dock and thought that this was a good idea. But there is one key difference between this and the Apple Dock. The Apple Dock is centred and thus when magnified and expands in two directions.
Oh just to prove I did eventually pass the gymnastic test, here’s proof!
All this is before I get started on the idiosyncratic icons – Bluetooth as a CD?
Leisa Reichelt’s post On documentation (or lack thereof) rang a lot of bells for me. Until my most recent engagement, it had been many years since I’d produced a specification collating together a range of information architecture deliverables into a single formal project deliverable that was then handed over to developers for implementation.
Like Leisa, I would categorise the documentation I have produced over the last 5 or so years as “just enough” followed up with lots of collaboration. By this I mean the antithesis of thorough documentation of every aspect of an interface. Instead I would produce a series of interim materials that are enough to get other members of a project team all working towards a shared goal, and support that through face-to-face communication. (By this I mean exemplar wireframes, templates, interface rules, etc).
I think this non-formal specification approach is more in the spirit of user-centred design as it demands collaboration and facilitates iteration without the requirement to continually go back and update the documentation (surely a bugbear of more than just this IA).
To summarise, I prefer a documentation light approach because:
- It encourages and enables you to keep on iterating far later in the project.
- It makes more parties (i.e. developers) creatively engaged in the project.
- It ensures that the designers (i.e. IAs) maintain involvement in the project while it is being coded.
- It removes the temptation of focussing on your deliverable rather than the user experience of the final product. You will not be able to point at the spec and say “they didn’t implement it right”.
- It requires communication and collaboration.
- It is the antithesis of the waterfall development approach!
I am not saying no documentation, but all too often documentation is something we hide behind. Try existing with less documentation and you will have a far more collaborative project.
I recently travelled from Australia to the UK with Singapore Airlines. The Sydney to Singapore leg of the journey was on the new A380, the second part was on an older plane from Singapore Airlines fleet.
I have flown with Singapore Airlines many times before and have always been impressed by all aspects of the travel experience from the leg-room, to the entertainment systems, the food quality and beyond. But this time the contrast between the newness and luxury of the A380 and the other Singapore Airlines plane was stark. To be frank the experience of the second flight seemed simply average by comparison.
Having redefined my expectations for airline travel, Singapore have set high standards that their other planes don’t yet meet. I have heard that they will be refitting many of their other planes to match the quality of the A380 – I hope this is true and that they do it soon.
Think beyond individual products and services
This highlighted to me the importance of thinking beyond individual products and services. Organisations need to consider the holistic brand experience offered by the range of products and services customers encounter in a single interaction. Why make one product a market leader without plans to improve related products and services?
Organisations need to develop holistic customer experience strategies rather than thinking about products in isolation – after all it is rare that a customer will interact with one aspect of an organisation without the need to interact with other aspects of the organisation.
I was amused by this while at Ellesmere Visitor Centre:
Both my wife and I felt compelled to give it a go. Just goes to show an interactive exhibit can be created on any budget!