UI

Follow fast

Wednesday, 14 April, 2010
By: marc

I’ll pick on a random industry. Let’s say you are an airline. Part of your digital strategy includes a refresh to your website (maybe you were inspired by this presentation I did a while ago on digital for airlines!). You’ve built a business case and secured funding for the project. First things first, you get a design agency in and set them to work.

Some sort of competitor analysis is performed that proabably includes features and functions that “we like”, (for example ‘the tactile sliders in kayak.com. We like! And an iPhone-like coverflow, got to have one of those…)

The information architect takes these ideas away and starts building wireframes and the creative team produce designs that bring these wires to life. The team come up with lots of new, innovative ideas. This is after all a ‘refresh’, and ‘innovation’ was probably one of the words in the brief. The creative is fresh and ‘of the moment’, the IA has developed some new interaction models that are unique and compelling. The business is sold on a new, innovative way of interacting with their customers, something that no one else does and will blow all their competitors away.

I’ve been bouncing ideas around with Luke Barrett (and because he doesn’t blog, I’ll write them down for him) around this approach; specifically the value of innovation against ‘follow fast’.

Luke reminded me of a project we worked on together many years ago. Before we started designing webpages we did usability testing. We did usability testing of the competitors, and of sites that were getting a lot of press as ‘innovative’. This was at a time that boo.com had just started and the client were talking about how cool an avatar would be on their site, just like boo. We put people in front of boo.com and watched them suffer. Clearly the avatar was an idea good on paper, terrible on execution. So we killed it. Not on our site.

We observed what worked and what didn’t on a multitude of sites with real users. Then, like magpies, we took what was good and worked. Nothing particularly innovative, (let other people do that), we took the best of what existed and delivered on that.

So back to our airline. How about a different approach where they start by usability testing their competitors. Ask participants to book tickets on competitor websites. Understand what interaction elements work, what don’t.

Those kayak sliders, cool for geeks (maybe), but how about the target audience that flies and buys online with you? It may not be cutting edge design, but Does a drop down work better?

The coverflow may be cool on your iPhone, but how successful is it for people seeking a holiday? A static list has worked for websites till now (and it wasn’t so long ago that horizontal scrolling was the Great Taboo), just because Apple do something that looks cool for a particular purpose on their products, doesn’t mean you have to follow by scrapping your navigation.

There are no prizies for (design) innovation (other than for some award that the design agency may covet). The only metric that counts is conversion rates and the ability of the website to deliver the business case. Leave others to do the crazy innovation stuff, let others go through the dip when they launch new features, make sure you have got the platform and expertise right and be ready to follow fast.

Who would turn off the wrong engine?

Thursday, 19 November, 2009
By: marc

In designing user interfaces there’s a lot we can learn from systems where failure to consider human factors has resulted in terrible consequences.

On 8th January 1989 British Midland Flight 92 crashed whilst attempting an emergency landing. There had been a fire on one of the engines which led to its malfunction. The captain reacted by shutting down the engine. Only he shut down the wrong engine. With no power, approaching East Midlands airport the captain manged to glide the Boeing 737-400 to avoid Kegworth village but crashed short of the runway. 47 people died.

The investigation into the Kegworth air disaster identified engine malfunction (the engine used in the aircraft was an upgrade of an existing engine and had not been field-tested) as causal factor, however the report concentrated upon the failure of the flight crew to respond accurately to the malfunction. Human error was the primary cause.

The truth is a little more complicated than that. Why does a captain with over 13,000 hours flying experience and a first officer with over 3,000 hours experience shut down the wrong engine?

A number of human factors contributed to the disaster including organisational issues (refer to this paper for discussion of the role of managerial failures in disasters) and cognitive overload. But of equal importance (and indeed buried in the appendices of the Investigation Report appendices) is the issue of design. Around 50% of accidents and incidents in the aircraft and nuclear industries have a root cause in design (source).

Take a look at the cockpit controls (taken from the investigation report). The left image is for the earlier 300 series and the right for the 400 series aircraft on which the captain had only 23 hours experience after a one day training course.

The actual cause of the engine malfunction was a broken turbine, itself the result of metal fatigue caused by excessive vibration (source). Had the Captain noticed the Vibration Warning display he probably would not have made the wrong decision.

The Vibration Warning display on the new 400 series was in a different place to the 300 series, but more critically it was designed to be significantly smaller “the dial on the vibration meter was no bigger than a 20 pence piece and the LED needle went around the outside of the dial as opposed to the inside of the dial as in the previous 737 series aircraft” (Source: Wikipedia). Take a look at the arrow on the left hand image, the display dials on the 300 series use mechanical pointers. On the 400 series they were redesigned with short LEDs rotating around the numbers. These, as the investigation report noted “are much less conspicuous than mechanical pointers, acting more as scale markers, and providing less immediate directional information).

The report criticised the layout of the instrumentation and helpfully suggested an improved layout. The layout was (and as far as I can tell, remains in 737s) split into primary instruments and secondary instruments. The issue with this layout is that the dials are not spatially aligned with their associated power levers. If the pilot is focussing upon the primary instrumentation, the secondary instrumentation is in peripheral view. This layout will lead to attention based around specific instruments rather than engines.

Compare this to an alternative design that the report provides where the dials are aligned to their associated power levers. The report recognises the design trade-offs here but concludes that to break the left-right mental association with the engine position was probably not the most optimal solution.

This paper describes the issue well:

The 737 involved in the East Midlands crash had ﬂight deck engine information that lead to confusion under mental pressure. Placing the secondary information sets for both engines to the right of the primary set broke the implied rule set by all the other engine information, that the left engine had left hand controls and indicators (and vice versa). If one assumes that the optimum positioning of indicators is the one that requires the least mental processing then a simple symmetry about the aircraft centre line seems appropriate. The actual positions required a mental spatial transposition of one set of dials to the other side… The readability of the indicators had been reduced by the substitution of electro-mechanical readouts with electronic readouts, but which simulated the old design. Possibly the redesign to electronic readouts should have taken the opportunity to use a rather different layout, possibly with linear indicators rather than rotary ones.

OK, so lots of words, but what is the point of this to what I usaully blog about? The issue is one of design and layout and who’s responsibility is it. In designing user interfaces UCD is often seen as a luxury, developers believe that they can design a GUI as well as anyone, and stakeholders (especially on internal projects) will question the value that a UCD person can bring to the project. Does a developer or an engineer by training and instinct stop to ponder the human factor and the human consequences of the GUI layout? What are the consequences of this? As can be seen from Kegworth, seemingly minor changes to the control layout can have a signficant impact on the safety of a complex system.

Do customers want to customise your site?

Monday, 28 September, 2009
By: marc

Have you ever added a custom tool bar on your office set up? Have your non-techy friends and family changed the background image on their desktop or changed their screen saver. Is there a demand for customisation?

So here’s the question. Do people really want to make your homepage look the way they want it to? Is there a demand for iGoogle and netvibes customisation? They look cool and are attractive to the geeks in us, but do they have mass market appeal? Is there any research out there on the take up of user customisation?

“…back when Windows 95 was released, users could easily change My computer to something more personal. Apple users had been able to do this for many years, and many of them did name their computers. But few Windows users took the opportunity to do this, suggesting that they saw the computer as more of a tool than something with which they wanted to have a personalized relationship.” (David Malouf)

Just because we can doesn’t mean that we should. When you log into your bank account it could look like netvibes, complete with BBC news feeds and YouTube videos (you decide what you want). But should it?

Why should your customers see your website as something to have a personalized relationship with, especially if you don’t engage them with a personal relationship throguh your other channels?

A picture tells a thousand words. So prioritize pictures not words

Friday, 21 August, 2009
By: marc

Draw pictures to illustrate outcomes, design the user interface first and use that to prioritize requirements rather than working with written requirements.

In a single image you can convey a simple concept, an idea, a need or a desired outcome far quicker and more accurately than writing it in a sentence. This is especially so in developing software which more often than not is visually manifest as a user interface.

When we captured requirements in agile, we are effectively conveying a simple concept, idea, need or desired outcome as a requirement. And we do it in words. Those slippery things that are so often misunderstood. Things get really slippery when we try to prioritize those words against each other. Stories are laid out on the table and the team spend as much time discussing what each story actually means, as giving them priority. And because they are supposedly independent, you loose the inter-depedencies between them. Jeff Patton has written some great stuff on this.

So prioritization with stories can be flawed, especially when you are working with a large volume of requirements, say at the outset of a programme of work, and what you really want to do is get an idea of what a first release should be.

Throw out the stories. It’s too early to be writing words. Muda. Create illustrations of widgets and features and functions. Sketch out on post-its illustrations of the simplest implementation of the concept, idea, need or desire. On flip chart paper create blank screens that illustrate the interfaces that the requirement will be manifest on. Identify the stakeholders who will interact with the requirements. For example the retail website, the operational support application, the finance system. Now ask the team to stick onto the screens the sketches.

The challenge is to strip back to the minimal functionality that they really need for that first release. Let them draw extra functionality if they like, but everything must be on post-it notes. Now pull the post-it notes off, one by one. What if we removed this? What would happen if it wasn’t there? Is there something simpler we could do? Something more elegant? Is an operational function required to make the website function work? The exercise may be extended with pictures of legacy applications and data elements, again, stripping them back to the bare necessities for that first release.

That didn’t take long did it, and it looks like an initial release candidate. We’ve defined our scope in a way that we do not believe we can cut any more. Any less functionality would not be a meaningful release. Now we can get down to writing the stories, focusing our effort on something we are agreed looks right. We’ve prioritized pictures, outcomes over words; Picture Driven Design.

A new page

Tuesday, 4 November, 2008
By: marc

This blog was getting tired in its design so I’ve given it an overhaul, including introducing some widgets. (What an awesome piece of software WordPress is). I’ve also added a new page with a bunch of published papers. some classics in there (if I do say so myself) such as “Heat stress in night clubs” and “Occupational disorders in Ghanaian Subsistence farmers” !!. The rest of the dancingmango site was not built using wordpress, so to update it all in one go would be time consuming and of little value. OK, so there is inconsistency across the site and as a UI guy that hurts, but it is one of the trade-offs that needs to be made.

How are you managing the change?

Thursday, 16 October, 2008
By: marc

To the development team ‘change’ relates to scope and requirements within the project, but change runs far deeper than that.

A question that I am often asked is how do you manage business change on agile projects. Release regular and often is an often quoted mantra, but what does that mean to the business where rolling new software across the large, multi-site organisation? How do you manage the piecemeal introduction of new technology, features and functions to hundreds or thousands of people, many levels removed from the project across remote offices and geographical locations? How do you ensure the recipients of the new technology rapidly adopt it and accept the change, even when change is occurring every few months.

What are the financial and human performance implications of each new release in terms of training, productivity and morale? What is the overall burden on people in frequent change?

The reality is that it is not unusual for projects deemed successful by IT and the immediate business team to ultimately fail when released to the broader organisation. Effective change management can be even more important when an organisation adopts agile software delivery.

An analogy as an example. If I expect a screwdriver and you only give me a cross-headed screwdriver when I really want a flat head one I am going to be unhappy. The core team may have prioritised the cross-headed one first for good reason, a flat headed one maybe coming just round the corner, but if you don’t deliver to my expectations I am going to be unhappy. Worse, I am likely to become resistant to future change and less likely willingly cooperate with the uptake of future releases, even if they do start to deliver to my needs.

Keep it on the shelf
The first point is that regular and often does not necessarily mean release to production for the entire organisation or marketplace. Running a number of internal releases, keeping them on the shelf until a complete and marketable product is ready is a strategy often employed. Significant value can be accrued by getting tested and working software into a pre-production environment and held “on the shelf” awaiting a full release. This maybe a UAT environment where a limited number of stakeholders test the functionality in an ‘as-live’ environment. Or it maybe a beta release to a small, selected number of interested people (e.g. a ‘friendly user trail’). This can often pay dividends with usability issues and minor gripes being picked up and addressed before a major roll-out.

Communication
Let’s assume that the team wants to roll out the application early and often to the whole target population. Critical to the success of managing the business change is communication. It is important to manage expectations on a timely and appropriate manner. Explain what the upcoming release will do and more importantly what it will not do (and when it will do it). Keep all stakeholders informed of the project progress (setting up a project blog can be a cheap and easy way of letting interested people know of progress), yammer maybe another way of broadcasting updates and information. Having a release count-down can also prepare stakeholders for the change. The techniques can be googled, the important thing is to communicate and manage the expectations (and be ready for inbound questions and comment after go-live).

Adaptable user interface
It is not unusual for the core team to drive for as much functionality as possible in the first release, considering UI enhancements as ‘nice to haves’ and consigning them to later releases. This is a false economy. Consider the cost of training and lost productivity through a hard to use interface. Now multiply that across multiple releases that focus upon utility before usability. Delivering a first release that is self contained and compelling will go a long way to driving organisational buy-in of the new application and greater acceptance of future change. (Jeff Patton writes some great stuff on using story maps to explain what the system should do. Using these will help focus on complete and useful slices through the application rather than random features that are perceived to be of value but do not make a coherent product).

A new user interface, however well designed will inevitably take time to learn the first time it is used. The challenge is with each subsequent release to introduce funcitonality and interactions that leverages the users existing mental model of the application, building upon what has been already been learned. Starting with the end-state, wireframes that articulate the final application then trimming out features, feields and controls to represent each notional release can be a good way of ensuring a UI that will scale as new functionality is added.

Agile organisation
Ultimately the most successful way of introducing agile is to build a beta culture with everyone as agents of change across the whole organisaiton. More importantly change becomes a cycle of learning and continuous improvement. And here I’ll borrow this most excellent graphic from David Armano. David compares what he calls conventional and unconventional marketing but the parallel with software development is obvious. His iterative cycle is “plan-design-launch-measure” but that is not a million miles away from the lean philosophy of “plan-do-check-act”. And critical to the journey is the learning cycle between iterations.

Will corporate websites remain spotty teenagers or will they grow up to be beautiful?

Friday, 25 January, 2008
By: marc

In the corporate webspace most design is little more than mediocre. Interaction design has changed little since coporations first realised that this is a channel thery should exploit. Web 2.0 is slowly making in-roads with basic use of Ajax functionality, but there is nothing that is really breaking the mould. Despite its infancy (for most organisations ‘e’ is barely 10 years old, Amazon, the granddaddy of eBuisiness is only 13, born in 1995), conservatism rules; the corporate web is just not growing up. It would be easy to blame the technologists for being risk adverse- for having invested in architectures and frameworks that do not allow innovation. REST and all that declarative goodness may be great, but of little interst if you have invested in a propiertary framework that does not support it. But the business is also responsible for tardy innovation.

It doesn’t know what is possible. A miss-understanding of accesibility clobbers rich interactions; “no javascript” becomes the mantra, despite the guidance being “provide alternatives” and progressive enhancements making basic and rich interactions possible with the same code. And maybe as usability testing becomes the norm, and testing concepts with consumers throughout the product lifecycle is baked into the process, this is acutally the final nail in the creative coffin. Let me explain.

When you are developing new features or propositions it is only right that you should conduct market research, talk to your customers and get feedback to refine your ideas. But sometimes you need to ignore what you are being told and challenge the perceived wisdom. Imagine the scenario; you are developing a social networking site. You recruit a bunch of consumers to participate in user testing sessions. They match the socio-demographic profile of your target audience, they use the internet more than five hours a week. You let them loose on your concept boards and prototype. They like what they see, they like the blogs… but commenting? The feedback is that none of them would leave comments. So what do you do? Kill the commenting on the basis that the users who matched your “average” profile would not use this feature.

I’m not saying that if you are building a conventional, transactional experience; a retail shop, a financial services provider, you should not test the proposition with users that match the target profile. But beware that they will steer your thinking into the realm of the ordinary, the expected and the average. Try testing it with trend setters, gamers, teens, mybe even anti-personas to push the boundries and harvest real innovation insights.

And maybe testing the proposition is not needed at all. But don’t leave the design to the comittee or the accountants. Sometimes it is more important to have a real visionary driving the product development. Apple is a great example of this, no more so than with the iPhone bounce. When you scroll down a list, when you come to the end, the last item “bounces”. Where’s the “business value” in this? Isn’t this gold plating in the extreme? The development of this bounce will not have been for free, it will have come at a cost. This could have been a financial (more development effort) it could have been at the expense of another feature, or it could have been time. In most organisations this would not get get through the design by commitee. Apple can do such great things with their UI because they’ve got a visionary at the helm who understands the importance of good design and is passionate about it, and their customers become to expect it.

Let the UI drive the requirements

Thursday, 24 May, 2007
By: marc

Conventional approaches to building software applications start with a Big Idea. Someone needs (to define an application) “a program that gives a computer instructions that provide the user with tools to accomplish a task“.

Someone picks up the big idea and breaks it down into a smaller list of “requirements”, things that the application must do to fulfil the Big Idea. In conventional waterfall development Business Analysts will spend a while documenting the list of requirements in some detail – in agile approaches they will do it as they go in a far more “lightweight” manner. Maybe a technical architect will draw up a blueprint design of the solution. Regardless, soon the developers will start writing code. With either agile or waterfall the user interface usually only starts to emerge at this stage. Until then, everything is coded in words (and maybe some boxes and arrows showing flow). Only late in the process does the UI emerge.

Returning to that definition of an application, IT development seems to spend most of its time in the “a program that gives a computer instructions” world, and often looses sight of “provid[ing] the user with tools to accomplish a task”.

How about a different focus. Start with the user interface. Take the Big Idea and illustrate it. Draw pictures of what the tools will look like, how the user will interact with them. Sketch storyboards, wireframes, lo-fi prototypes, paper mock-ups, call them what you will. Use this as the primary requirements document, supported by explanatory text and detail where we required. These may be stories or use cases, but let the visual representation of the big idea drive the requirements rather than it being almost an afterthought. Start with the UI and specify the functionality from that rather than the other way round. After all, it will be the UI that the user uses to accomplish their task, not the computer instructions.

The customer is not always right

Monday, 23 April, 2007
By: marc

I was recently working with a financial services client, rationalising their systems to have a “single view of the customer”. This demanded a single user interface rather than the 13 or so current UIs that they use in their daily business. As we were coming up with ideas one of the consumers of the new system showed us an old system – “make it look like this” she said, “that’s what we want”.

My initial reaction to a screen like that is a nervous twitch. Eugchhhhhhhh!! Hold my breath. Count to ten. Repeat the mantra “RANA”. Relax, be Aware, be Non-judgemental, and Allow… RANA, RANA, RANA.

OK.

So when a customer asks you for something that in your gut feels wrong; if it feels wrong, it might just be wrong. The challenge is to get the customer to feel your feeling. Do not to just do as the customer says but probe and question and ask why.

This UI was built by developers to manifest data from the database. Not something we wanted to repeat. So we started by asking what is it about that UI that she likes? Some gentle probing uncovers that she likes the ability to have everything in one place. She can rapidly perform searches and see the results in the same place. Taking this as our cue, we probed what information on the screen was important to her and what was not – in the context of her usage. If we took each individual field one by one and asked “is this important”, she would answer “yes”. By asking about frequency of use, criticality and importance we were able to discount most of the fields. At the same time we were able to identify a number of fields that were critical and frequently used, but not displayed on this screen. We soon had a framework for a new search / results screen. Then we broached implementation.

Talk of a browser based solution filled her with fear and loathing. She perceived this to mean having to enter a search criterion, and then wait for the page to refresh / results to return. She’d experienced this with other applications and did not want to go there again. She was pointing at the Fugly screen again. “Build me that” she says, pointing at the screen shot. Yes but….

In an enterprise solution, performance, speed and accuracy are the most important criteria. Yet the Web 1.0 paradigm of query – response via a refreshed page is just not fit for purpose. AJAX overcomes this. She could have her cake an eat it.

The result was nothing like what the customer had asked for. We’d listened to her (and others like her) and probed her on her goals. We used scenarios to talk through the context of usage and came up with something that was fit for purpose and IMHO delighted her. The take away is this. Don’t always believe what the customer says, often they are constrained by their narrow view of the world and their current reality. If we are doing our jobs properly we are opening them up to the art of the possible. To a new reality a world apart.