The shift in technology design
“If you want simplicity, if you want to be seen as an innovator, then it’s the mainstream customers you should be aiming at” is a fundamental shift in technology design
Phones and Accessibility
When the iPhone was first announced in 2007, the one aspect I thought could be a bad idea for at least one group of people was the lack of any keypad. The all glass interface seemed most unfriendly in terms of not being able to feel the keys – at the time, an essential method for people with poor or no sight.
But there have been other developments in that time too. Below is an amazing video of a blind person using his iPhone to take pictures and post them to Facebook. Keypad interaction not required. But what’s most beautiful is the comment ‘I never had a camera before’. It’s a great example of how technology can be a great leveller and bring equality in so many different ways.
Video source: Kottke org – How blind people use Instagram
Intranet design for aesthetics vs function
Whilst presenting earlier this year, I caused a mini-storm amongst some members of an audience by saying that branding of intranets is a vanity project. Some read this to be against visual design. It wasn’t. Designing to improve usability can lead to significant business benefits and should be part of any Intranet project. Corporate branding is about making a visual statement. In my opinion, that makes it a vanity project.
Vanity projects are not bad, I just get concerned when they take priority. I’ve been in meetings where people have wanted to create a bespoke design for the Intranet just so that ‘it doesn’t look like <insert product name>’, regardless of the costs or benefits and showing little interest in the purpose or content of the Intranet. This most often occurs when someone in the room fancies themselves as an amateur Steve Jobs.
Today I stumbled across a post by the wonderful Kevin Kelly from April 2011. It wasn’t the post so much that reminded me of this debate, but a rather brilliant comment:
As someone solely responsible for maintaining a very large hotel, here are a few other other things I’ve noticed about the nature of maintenance — There are mostly two types of maintenance — interior systems (plumbing, HVAC, electrical, lockware, audiovisual, web access) and exterior surfaces (carpet, paint, wallpaper, tile, upholstery) Maintaining interior systems requires special technical knowledge while exterior surface repair emphasizes craftsmanship. Interior systems speak to convenience and comfort while exterior surfaces address aesthetic desirability. In terms of the individuals who carry out these repairs, it is a rare soul who is equally skilled in the interior and exterior, as most seem to specialize in one or the other, i.e. with regards to expertise, there is seldom overlap.
If you look at just about every device, virtual or physical, this observation rings true.
Great products have thought through both the interior and exterior design. Good products usually have a strong interior let down by a clunky exterior, or over-complicate the interior, but ‘good enough’ may be sufficient if the desired outcomes are achieved. The label ‘lipstick on a pig’ is reserved for those with great aesthetics masking empty promises. Desirability is only possible if convenience and comfort are satisfied.
Image used in this post via Flickr, courtesy of Michael Hanscom
Think Beyond not Post PC
For 99% of people, keyboard-input is becoming less relevant since devices got all interactive and touchy-feely. The design of the typical workplace and business software needs to catch-up…
Practical design tips for web sites
Some examples based on various presentations and templates I have used with customers to help guide their designs for intranets, extranets and collaborative web sites… Read More
Why design means compromise
Catching up on podcasts, I was recently listening to ‘An hour with Bill Buxton’ recorded at Microsoft’s Mix conference in 2010. Bill Buxton is Principle Researcher at Microsoft Research and an early pioneer in human-computer interaction
Simple usability
I’m currently living inside Gmail for all email as a problem with my ISP settings is giving Outlook some headaches and it can’t send/receive email for the moment.
I clicked Send on an email to a client this morning, and up cropped the above message. Yes, I had indeed talked about attaching a file and not actually attached it. Hardly the first time for me 🙂 But that’s the first time an email client has stepped in to help. The feature may have been around for years for all I know, I normally send attachments via Outlook.
Today, by simply having a trigger that checks the content of an an email and if it includes the words ‘find attached’ then the email should also have a file attached, Gmail saved my butt from another ‘Yikes, did I forget to attach the file…?’ moment.
Usability isn’t just about going ‘oo’ and ‘ah’ over a more intuitive interface with touches and swipes or a beautiful design that makes you stop and stare. It’s about technology being a help rather than a hindrance, often in ways you don’t (need to) know about until the right time or situation occurs.
Design flaws and why best practices fail
Just before Christmas, I was having lunch with a friend and former colleague (no prizes for guessing where from). As per usual, out came the gadgets. Including my iPod and his Zune.
Let’s rewind back to when I first got an iPod. It seemed obvious how to scroll through the menus – move your finger around the wheel. Less obvious was how to adjust the volume when playing music. It took a couple of attempts at prodding the forward and rewind buttons, despite the labels telling me they were not the volume controls, before realising that the same action to scroll through menus applied to adjusting the volume.
The iPod
No manual required and all pretty logical really. The colour and texture help guide your finger around the wheel. You immediately discover that the centre of the wheel is the button you click to select. And the remaining actions are clearly labeled – press menu to get the menu, forward to go forward, rewind to go backwards and play/pause to play or pause.
So fast forward to the present and the Zune. My friend hands over the Zune and then sighs as I attempt to use it like an iPod. The Zune looks vaguely like an iPod but isn’t an iPod.
The Zune
The big button in the middle isn’t quite a circle but is a long way from being a rectangle with rounded edges so we will refer to it as the circle for the rest of this post. Net result. I try moving my thumb in a circular motion to scroll through the menu. That doesn’t work. You press the top of the circle to go up the menu and the bottom of the circle to go down the menu. Once shown how, you can also swipe up and down to accelerate through the menu. There are two other buttons. One has the familiar play/pause icon. The other has an arrow. Can’t remember what it does but would assume it’s simliar to the MENU on an iPod.
The reason the iPod wheel is so easy to use is that the shape is logical to the action. The reason the Zune is so confusing is because the shape does not match the action. Compare the two images below.
On the left is how the iPod works. 6 possible actions all contained on a single wheel: 5 buttons and a circular sliding motion. Your thumb is guided around the wheel by using a different texture for the wheel than the rest of the iPod (including the centre of the wheel). The circular motion works both clockwise and anti-clockwise, as you would expect. Four buttons at North, South, East and West and a fifth button in the middle.
On the right is how the Zune works. 8 possible actions: On the circle there are 5 buttons and two sliding motions. There are 2 additional buttons either side of the circle. The sliding motions are up/down and left/right, not that you would know from the look and feel of the circle. The motions do not match the shape. And you have to assume that there are buttons on the circle, because there is no indication icon-wise.
Why did Microsoft choose to use a circle on the Zune?
I have zero formal design or usability qualifications. But if I were given the spec of designing a large ‘button’ interface that you press at the top to go up, the bottom to go down, and can stroke up or down to accelerate (and similar applies for left and right), I would have used a shape that matched the action. Something like this:
My version of the Zune
And it’s a small point, but if you can’t fit the word ‘menu’ on a button and you are Microsoft, why wouldn’t you just use the same icon you use on Windows? Most people would figure out what it means… They certainly wouldn’t mistake it for the rewind button.
There’s an ironic twist to this. Two years ago, a YouTube video appeared – What if Microsoft designed the iPod packaging? It is hilarious and embedded at the end of this post in case you’ve not seen it. It was later revealed that the video came from within Microsoft. When the Zune launched, it shipped in a simple box.
So why did Microsoft choose to use a circle on the Zune? Was it to make it look like the iPod? A daft decision when the form does not match the function.
This is a common mistake and not just confined to design or usability. How many organisations implement a ‘best practice’ on the basis it worked for a similar organisation, and yet fail? It is rare to find a perfect match in terms of context and conditions. Instead, it is better to apply lessons learned but adjust them to your own situation, not bend your situation to fit the lesson. Apple’s lesson was that form and function should be as simple as possible and align. Microsoft followed the form but changed the function. Wrong.
If Microsoft designed the iPod packaging
World Usability Day
World Usability Day was held during November and this year’s theme was Healthcare. Microsoft took part and hosted a day of sessions that were recorded on their Live Meeting virtual conferencing service. You can access the presentations (available for download, at the time of writing) here – Best Practices for Creating “People-Ready” Solutions
To find out more about World Usability day, visit the web site and/or community blog.
Filed under: Usability
Technorati tags: Usability; User Experience
How buildings learn
I had come across several recommendations to read ‘How Buildings Learn‘, by Stewart Brand, during the past year and finally picked up a copy of the book. Here are some snippets to (hopefully) help explain the valuable lessons this book can teach the IT industry, particularly the newer architect-style roles that are cropping up (enterprise-, solution-, software-, system-, information- etc.):
“…Almost no buildings adapt well. They’re designed not to adapt… But all buildings (except monuments) adapt anyway, however poorly, because the usages in and around them are changing constantly… Architecture, we imagine, is permanent. And so our buildings thwart us.”
The book describes the concept of time layering and its relevance to buildings. The six layers (simplified here): SITE (geographical setting, duration: eternal); STRUCTURE (foundations and load-bearing elements, duration: 30 – 300 years); SKIN (exterior surfaces, duration: 2o years); SERVICES (inner workings of the building – wiring, elevators, etc., duration: 7 – 15 years); SPACE PLAN (interior layout, duration: 3+ years); STUFF (furniture and movable items, duration: mobile).
“…Ecosystems could be better understood by observing the rate of change of different components. Hummingbirds and flowers are quick, redwood trees are slow and whole redwood forests even slower. Most interaction is within the same pace level. The dynamics of the system will be dominated by the slow components… The same goes with buildings. Site dominates structure (location determines foundations), which dominates skin, which dominates services etc.”
Interestingly, the reverse becomes true in extreme situations.
“Ecologist Buzz Holling points out that it is at times of major change in a system that the quick processes can most influence the slow.”
New ‘stuff’ (e.g. replacing desktop computers with laptops, wireless technologies, switching from individual working in cubicles to group collaboration in open plan environments) may demand adjustments to space plans and services. And the need to change services can even result in the premature demolition of buildings. This issue leads on to some interesting comments that IT solution architects should consider:
“An adaptive building has to allow slippage between the differently-paced systems of site, structure, skin, services, space plan and stuff. Otherwise the slow systems block the flow of the quick ones, and the quick ones tear up the slow ones with their constant change. Embedding the systems together may look efficient at first, but over time it is the opposite… and destructive as well.”
The book recommends an alternate approach to traditional building methods: the use of scenarios:
The benefits of scenario-planning are simple – design a building/system to accomodate multiple different possible outcomes. This can help avoid the problems that occur when the designers idea of expected use does not match the actual use.
There is another book that follows this theme, applying it to the design of everyday things and how we conform to, or adapt, their purpose: ‘Thoughtless Acts?‘ by Jane Fulton Suri + IDEO
Joining Dots 