Posts by: marc

Are you doing the simple things well?

  • Thursday, 10 May, 2007
  • By:

Anthony Bourdin in Kitchen Confidential writes “Good food is very often, even most often, simple food.  Some of the best cuisine in the world… is a matter of three or four ingredients.  Just make sure they’re good ingredients, and then garnish them.  How hard is that?”

How hard is that indeed.  There’s a lesson there for building out your product set.  Are you doing the simple stuff well?

Another meeting, another executive talks about the need for innovation and creative thinking and pushing the boat out and beating competitors with something new.  Meanwhile, doing the the simple “hygiene” things that will delight existing customers (reducing customer attition and churn) get lost with the innovation hyperbole foccused on “capturing market share”.

How quick can you jump on the trend?

  • Monday, 30 April, 2007
  • By:

Here’s a bunch of marketing trends for 2007, predicted in In December 2006.  A year is a short time period, we are already more than a quarter of the way through the year – how many of these trends are making inroads beyond the pure play eCommerce offerings.  How many are filtering through into FTSE 100?

Not many is my hunch.  How familiar is it for the marketing department to come up with an idea, only to have it disapear into the IT quagmire of architecturual incompatibility, budget constraints, change requests and innovation inertia?   And of the list of 7 trends, the one that will probably get most traction in the corporatesphere is contentcasting.  Trouble with that is, it is one thing to syndicate your content as RSS feeds, but who will consume it?

Need for speed

  • Tuesday, 24 April, 2007
  • By:

What a cool tool Firebug is.    It lets you get under the covers of web pages, to see what is going on.  One feature is the ability to measure the page size and that of individual components on the page.  This blog post comes in at 294kb.  If I think back to the early days, that number would make me shiver.  In the days of 56k dial up a page that size could take more than a minute to download.  Things are different now.  In the UK Broadband penetration is now greater than 72% (source [xls]) and the page appears almost instantaneously.

So do we still need to optimise our pages for size and speed of download?  Having run hundreds of usability sessions, the key gripe of the web used to be speed – slow download times could effectively kill a proposition. But that’s not such an issue with a fat connection.  Not unless it’s a hollywood movie you are downloading…

But what about the remaining 30% who still use dial-up – that is not an insignificant minority to exclude.  I assume that people who read this blog are more likely to be using a fast connection, so I don’t feel I am excluding anyone there.  But as large pages become acceptable, with rich content and streaming media, should we spare a thought for the dwindling dial-uppers?

The customer is not always right

  • Monday, 23 April, 2007
  • By:

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

Example of ugly user interface

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.

Swivel chair integration?

  • Wednesday, 18 April, 2007
  • By:

Liverpool Victoria website - quotes only available at selected times

One of the great promises of the eCommerce was that goods and services are always available, 24/7.  Not apparently at Liverpool Victoria whose online quotations are only available at selected times:

Please note that our online car insurance quotes are only available at selected times: 8am to 11.45pm Mon-Fri, 8am to 3.45pm Sat.

One can only assume that this is an issue with their integration of their website with their backend quotation engine.  Was the quotation engine built in the days of 9-5 business and is unavailable outside business hours?  Maybe it depends upon overnight batch processes that render it inoperational between 11.45 to 08:00 and from 3.45 on Saturdays to Monday morning?  Or is this swivel chair integration, some poor soul manually taking requests from the web site and entering them into the legacy system?  Someone who doesn’t work nights, Sundays and whose weekend starts at 3.45 on Saturday?

Match the context, not the pattern

  • Tuesday, 17 April, 2007
  • By:
Example of website requesting credit card details in a textual format

To my knowledge, all credit cards present their “valid from” and “expiry dates” as numerical dates, e.g. 02/06 – 02/09. So why do many transactional websites request the credit card validity in text date format, e.g. Feb 06? Most people will not know their credit card details – they arrive at the credit card details form, reach into their wallet, select the relevent card and work through the form referring to the card that they have placed near the keyboard. When they reach the date fields, additional cognitive processing is required, translating the number on the card to a month on the form. This interupts the process (do not assume that everybody can make the immediate leap from 02 to February. Spend time observing consumers on the task and it will not be long before you see fingers coming out to help with the counting).

So whilst using textual dates may be considered to be more “user friendly” and understandable, in the context of completing the credit card form, it adds complexity. UI guidelines, patterns, heuristics are all well and good, but ultimately you must consider the context of usage and design accordingly, even if it does at first glance result in something that is not immediately user friendly.

Tap on the plane: Engineering solution to an engineering problem

  • Monday, 16 April, 2007
  • By:

Sink on a boeing 747

Washing your hands is a two handed affair involving a pair of hands, soap and water. There are instructions on how to do it properly. I’ve not done any research on it, but my gut feel is that most people wet and rinse their hands under a running tap (faucet). With this presumption, the Boeing airline toilet wash area is not fit for purpose. I adapt my behaviour to suit the technology. I press the hot and cold buttons down with my thumbs and attempt to rinse the rest of my hands under the running water. I could fill the bowl up, but (a) that is not my habitual behaviour; (b) wouldn’t that mean rinsing in dirty water and (c) those bowls are not always the cleanest of things anyway.

Seems like the design on the airline faucet was an engineering solution to an engineering problem. You don’t want to have the tap left running. So let’s make it really difficult to use. Let’s demand our users have to learn a new technique to use it. If the designers had considered the human factor, the design would probably be quite different. If they’d prototyped and user-tested the design they would have seen that it was sub-optimal.

Yet it is easy to criticise. (There is one good thing about it, it is clear which is hot and cold – assuming you know that red = hot and blue = cold). How could it be better? Maybe a foot control or infra-red sensor. But inevitably such solutions are costly to implement and costly to maintain. Why not a spring-loaded press button that gives a timed flow of water (not fail safe?) In designing solutions there are always trade-offs and compromises and maybe other more user friendly options were considered but discounted on the grounds of cost to implement or maintain. And as a customer in coach, a little hassle in washing my hands is an acceptable price to pay. But that is not going to stop me grumbling every time I struggle with the tap on the plane. (Oh dear, am I sounding rather obsessed?)

Is a Singapore Sling at Raffles a cliché?

  • Wednesday, 11 April, 2007
  • By:
Singapore Sling at Raffles

I used to consider myself a travel snob. Certainly not a tourist and even back-backing was beneath me. I went for the authentic experience; small holdall with only the bare necessities, travelling and staying with the locals, keeping off the beaten track. So when I was in Singapore recently the question of whether to go to Raffles for a Singapore Sling agonised me. My old self would have shuddered at the idea. What a tourist cliché! I’d find a smoky café in the Arab area and drink thick coffee and puff on a hookah. What is worse, I’d preach against any way but my way- if you’d been to Singapore and stayed at Raffles you hadn’t really been to Singapore. Unless you’d eaten from street stalls and slept under a fan you were just a (spit) tourist.

But I’m in Singapore on business and I’m older and wiser and I hit the Long Bar in Raffles and like almost everyone else, I do the tourist thing and order the Sling. And the experience was appropriate to my circumstances.

Sometimes I wonder if this snobbery rears its head in my professional world. We choose Firefox over IE, Ubuntu over Vista, agile over waterfall. Ruby on Rails is our passion, anything else is just beneath us. Commercial success is to be looked down upon; “selling out.” Bob Dylan sold out when he went electric, right! There’s a thin line between passion, pragmatism and snobbery. The thing is to know the set, setting and circumstances. Who are you working with, what’s the context and why are you there. Keep those questions in mind and the appropriate level of snobbery you may revel in should become clear.

Ring pull on a bottle

  • Tuesday, 10 April, 2007
  • By:
ringpull on a bottle

OK, so not the finest photo in the world, but it is the innovation that is important. Problem: crown-caps on bottles require bottle openers. No bottle opener = improvisation = damaged furniture / cutlery / hand / teeth. And here’s an elegent solution, a ring-pull crown-cap. Same bottle experience only easier to access. Nice.

Software Dams and recipient participation

  • Wednesday, 4 April, 2007
  • By:

There once was a time that international development was all about big capital projects, building dams and the likes. Times change, now the focus is on eliminating poverty; DFID “focus [their] aid on the poorest countries and those most in need”. There is a realisation that those big projects did very little to address poverty, indeed they kept countries poor forcing them into debt (read Confessions of an Economic Hit Man for a cynical view of this). And besides, dam projects are rarely successful and before you know it they silt up.

A focus on reducing poverty requires a new approach. It requires an understanding of the root problems, it means spending time with the poor to understand their circumstances to be able to create appropriate and sustainable solutions rather than prescribed programmes that develop and maintain a dependency culture.

There are parallels here with the IT industry. Much of the IT game remains focussed upon those big projects. Software dams that can be launched with great fanfare but do little sustainable good to those most in need. The customer.

Before I wound up in IT I worked in international development. My PhD. “Ergonomics tool and methods for use in Industrially Developing Countries” was based on working with farmers in Sub Saharan Africa, looking at how technology is transferred and how it can be made more appropriate, sustainable and usable. Many of the tools and techniques I used in the bush I apply with the corporations I work with today. These came under the umbrella of “Participatory Technology Development” and “Participatory Rural Appraisal”.

Rather than the delivering the white elephants of expensive machinery that you see littered around Africa, Participatory Technology Development is an approach for developing simple low cost innovative solutions that have the ownership of the community who work with researchers to build them. The PTD framework starts with gaining a shared understanding problems and opportunities. This is followed by defining priority problems then experimentation. Experimentation is collaborative with options derived from indigenous knowledge and support from the researchers experience and expertise. The farmers own the experiments and the results. This leads to the next step of the framework; sharing the results with farmer led extension. (Traditionally dissemination of agricultural advice is done by agricultural extension officers – government employees who despite their best intentions preach too the farmers, sharing centrally defined agricultural advice rather than the more appropriate, locally developed technologies that the farming community have developed themselves). The final step to the process is the researchers withdrawing, leaving the community with the capacity to continue the process of change.

(Sounding like agile?)

If PTD is a framework, then PRA is a basket of tools and techniques that can be used to support it. These can be broken down into nine categories:

  • Secondary data reviews – reviewing existing sources of information
  • Workshops – getting key stakeholders round the table (or more appropriately under the banyan tree)
  • Semi-structured interviewing – talking to people with a loose conversation direction
  • Ranking and classification techniques – identifying “things” and ordering them according to different criteria. (Often this will involve moving pebbles around boxes drawn in the sand).
  • Diagramming, illustrations and graphics – pictures to convey ideas and concepts, through “boxes and arrows”, Venn diagrams and charting to cartoons and imagery
  • Mapping – drawings or models that represent the local environment
  • Structured observation – watching people doing
  • Timelines – What happens when, for example seasonal calendars, a line in the sand and people put pebbles down against the time to show when crops are sown, harvested, how the price fluctuates, labour migration etc.
  • Community meetings – meeting the whole community rather than just the immediate stakeholders who participate in stakeholders. Showcases?

Are you building a Software Dam? Or are you focussing your aid on those most in need? PTD and PRA are approaches that have developed to help introduce appropriate, sustainable improvements to the life and wellbeing of subsistence farmers. Much of their content can be transferred to IT projects, helping introduce appropriate, sustainable improvements to the life and wellbeing of customers / users.

24 of 38
202122232425262728