South African websites repeatedly make basic usability mistakes. The results: frustrated customers, negative brand impact, reduced online sales, and poor return on investment for the whole web project.

The best advice for making an impact online is to Zig when others Zag. Stand out. Be amazing. Give a shit.

But if you work for a South African corporation, I’m sure you’ll feel much more comfortable following the herd. So here are five instructions for making sure your ecommerce site delivers industry-standard quantities of pain and frustration.

1. Let the programmers write the copy

Here’s an error message Flow discovered during a usability test for MWEB. If you choose the wrong kind of password, you get a message that says:

Oops indeed…

This kind of language is fine for programmers, but there are a lot of people who might want to buy an internet connection but are not sure what the word “alphanumeric” means.

So how about, “Please make sure there are both letters and numbers in the password you choose, to improve your online security.” Surely more people will understand what that means?

Usability recommendation for the inspired: You won’t ask a copywriter to program JavaScript. So don’t ask the programmers to write the copy.

2. Help users to lose their work (and their tempers)

I need to log into my Standard Bank account. I have to  type in a 16-digit card number, a five-digit PIN and a 10-digit password. I am then presented with two identical buttons: login, or reset.

Can you think of any scenario where someone would want to type in all those numbers, and then clear the form? No?

But can you think of a scenario where someone might type it all in, and then accidentally click on the wrong button, thereby losing all his work and getting very annoyed with Standard Bank? Yes, because it’s happened to you, hasn’t it?

Usability recommendation for the inspired: Just get rid of the reset/clear button on your form. It serves no useful purpose.

3. Assume your customers know as much as you do

Your customers don’t know how your business works, or understand the complexities of the products you sell. They don’t care either. They just want to buy something that works for them. The job of your website it to present your goods to the customer like a salesman, not like a telephone book.

Here’s a choice example from Vodacom. I go to their website to see how much airtime I can get for my budget. I click “browse packages”, and get the following:

Hey what? I want a contract, but how am I supposed to know the difference between Talk, Weekender and 4u? Is Yebo4Less going to give me better value than Per Second Plus? If you work for Vodacom, this page will make perfect sense to you. If you’re just an ordinary Joe, it’s a complete mystery.

So maybe I’ll try the link that says “Compare Packages”. Oh dear:

Hundreds of packages, each one more incomprehensible than the last. Should I choose Top Up 135 S or Top Up 135 Lite? No wonder South Africans prefer to buy face-to-face if this is what they get online.

Usability recommendation for the inspired: Create personas: realistic fictional characters that represent your target customers. Then walk through the site from their point of view and see how it looks.

Or, hang out at your call centre for a day and listen to what customers are asking and how the call centre staff explain things.

4. Make it impossible to buy

If your website is selling something, it is vital that people should be able to buy it. Am I stating the obvious? In practical terms, that means that your forms should be the most rigorously usability-tested part of your site. Take the example below from SAA. I thought I typed in a perfectly reasonable request – I wanted tickets from Cape Town to London…

This is what I got when I pressed the Continue button…

The Departure and Destination points are the same? But one says Cape Town and the other says London! (BTW, this isn’t a bug. This is caused by a weird field validation issue. Try it).

I’m sure SAA would have a perfectly legitimate technical explanation for what happened here. But from the user point of view, it just didn’t work. If I can’t even see the price, I certainly can’t buy the product. Not a good outcome for SAA.

Usability recommendation for the inspired: Watch your analytics after launch to see where people are getting error pages. You need to continuously improve your site – don’t just launch it and forget about it.

5. Create messy information architecture and crazy navigation

I went to the information desk at Absa because I wanted to change my daily withdrawal limit. The lady behind the counter told me that I needn’t have queued – I could just do it online. She then produced a handwritten and much-photocopied piece of paper, with instructions on how to do it. It’s not complicated, but it’s utterly obscure: you need to click on Service Information, then Registration, then Change Limits. I still have to look at the piece of paper every time I need to do this.

People find online information through something called Information Scent. It doesn’t matter if you have to click five times to get to the thing you want, as long as the “scent” is obvious. Clicking on “fresh produce”, and then “fruit” to get to bananas is a strong information scent.

Replicating such a strong scent for something complicated like banking terms requires careful design of your information architecture. But if you don’t do it, your customers will come and bother your customer service team. And that costs more.

Usability recommendation for the inspired: Try card sorting. Ask some of your customers to first name and then group the functions, by grouping little cards into piles. Then build a click-through and test some other customers to see if they can find things.

The very best way to boost usability

Top get change to happen, you have to persuade your colleagues that there’s a problem. Start with a usability test. Get 10 target customers, sit them down in front of your site, and record what they do. It’s the most vivid dose of reality your team or your boss is likely to get.

That’s the first step to building a site that sells more, with lower costs, to loyal, repeat customers. What a concept.

MWEB has launched affordable uncapped broadband in South Africa. Flow Interactive has been working with them on the interaction design for the launch website and the sign-up process. It’s been a complex but exciting project.

Working with Flow, MWEB took a user-centred design approach to this project. We started by doing a round of usability testing on their existing website earlier this year. This gave us many insights into how people buy ADSL. The most notable of these was that  people were almost utterly clueless about the terms that ISPs use on their sites. ADSL? HSDPA? Unshaped? Even the IT consultants we interviewed weren’t completely sure what it all meant.

MWEB's new ADSL pages

There was a second layer of complexity: there were so many variables to the choice. ADSL vs 3G. Three different line speeds. Multiple data caps that depended on the line speed you chose. Pricing that was affected by the choice of router.

Our mission then, was to make the process of choosing a broadband package a little simpler. Most ISP’s overwhelm people with huge tables of data, and MWEB was no exception:

Old style: large tables containing multiple variables

Making a choice about what you need from such a big table is difficult, particularly if you’re not sure what the difference is between 2GB and 4Mbps. Our interaction solution was to create an interface that showed people how the price changes, depending on your choice of line speed or package:

An interface that helps people to understand how line speed and package influence price

We also designed the interface to include contextual help information – meaning that the information is provided within the context of what you’re doing. So when you’re choosing your line speed, the info about what line speed means is easily at hand.

MWEB's contextual help information

Based on what we observed in usability testing, we think this interface will take the complexity out of choosing a broadband package. Not only has MWEB come up with a truly game-changing product, they made a very sensible choice in taking a UCD approach to their web development. Time (and stats) will tell just how much of an impact this design has made.

You can look forward to more innovation coming from MWEB. There are improvements to the total customer experience that are still to come, but we think this is a great start.

Testing a paper prototype

Excuse 1: “It’ll slow us down”

Finding users, building prototypes and working through hours of research takes time. Why not spend that effort on writing more code?

Counter argument. You say: “Our business objective is to reach profitability as quickly as possible. To do that, we need to understand what our customers really need and make sure we’re all agreed on the direction. A usability test might take some time in the short term, but it will help us reach our overall business goal quicker.“

Usability testing, like many UCD tactics, is an investment. You put in time and money, but you get back a product that sells better and costs less to support. But usability testing is also beneficial during the design process…

The managing director observes a usability test via a video link

1. Design the thing better, quicker: Trying to design a product for target users, without ever meeting any, is like pulling teeth. But if you just watch a few users using a prototype, a competitor product or their current system, they’ll tell you what you really need to know quickly, effectively and (comparatively) effortlessly.

2. Manage the politics more easily: Successful designs come from teams all pulling in the same direction. Usability testing results will reduce squabbles, give confidence to management and get people to focus on improvements rather than feature creep. Even the most sceptical team members can’t ignore videos of 5 or 10 real people battling with their software.

3. Get a team energy boost: Seeing ideas succeed makes the team feel positive. Seeing them fail motivates people to sort things out.

Excuse 2: “Our product is already perfect”

You and your team will become so deeply familiar with the product you’ve designed that you will think it is perfect.

Counter argument. You say: “We believe the product is perfectly easy and useful. But can we prove it? How many problems exist that we’re not aware of? What impact might they have? Developers may think their code has no bugs, but we still hire testers to prove it. What evidence do we have that our design is perfect first time?”

This behaviour is often referred to as “drinking your own Koolaid“. It means you’re doubly ignorant…

In a thought-provoking piece a few years back called The Five Orders of Ignorance, software engineering expert Philip G Armour says,

“The hard part of building systems is not building them, it’s knowing what to build — it’s in acquiring the necessary knowledge… A functioning system is the by-product of the activity of finding things out.”

Excuse 3: “We already have lots of feedback”

Listening to customer feedback via email, call centre or the web is vital. Analytics and search log analysis is great, too. And it can seem like you’re getting all the user input you need.

A group of developers watching usability testing video

Counter argument. You say: “We’re only getting feedback on major issues and from committed product users – lots of other people encounter our product and never feed back. So we’re getting a skewed perspective. Usability testing will let us observe and discuss all sorts of things that customers and non-customers would never actually feed back about. It will also explain what to do about the strange patterns we’re seeing in our web analytics. This extra insight will give us a competitive edge, because it’s not obvious stuff that our competitors also know.”

Excuse 4: “This concept is not ready to test yet.”

Ready for a usability test

It’s easy to tell yourself that you’re not ready to work with target users yet – that your ideas haven’t settled down to something stable and complete which users will approve of.

Counter argument. You say: “Don’t worry if it’s not ready. We’ll test what we’ve got, and won’t worry much about the areas where we know things aren’t finished. It can give us reassurance that we’re heading in the right direction and stop us from spending loads of time designing a blind alley.”

The truth is, your ideas will never be stable and complete until you’ve had the input from users. Until then, they are just hypotheses. Better to test your hypotheses when they are young and flexible, rather than when you’ve spent weeks on refining them, and publicly declared them as “finished and ready”.

How to run that test

Doing the perfect usability test is no doubt hard. But doing a useful test is really easy…

As Bruce Tog says, without iterative usability testing “you’re going to throw buckets of money down the drain”. So just get out there and test.

[Debre Barrett is my wife and also an excellent experience designer, with many years experience at BBC.co.uk. This a guest blog post by her...]

Something awful happens to babies at exactly 5pm every day. They cry, they niggle, they scream. They drive you nuts until you’ve bathed them, fed them, and put them to bed. Suicide Hour, is what a friend and mother of four calls it.

One evening last week, at 5.45pm, I was busy preparing a puréed meal for the baby, a proper meal for myself, and a meal where none of the ingredients touch each other for my older daughter. The baby was perched on my one hip, exploring the boundaries of Suicide Hour. The older one needed help working the DVD, and there was only 1 hour 15 minutes between me, a glass of red wine, and a sit-down with Twitter.

Then the phone rang. It was a friendly, middle-aged lady.

Lady: “Oh hello there Mrs Barrett. I’m just calling to congratulate you on the birth of your little one, they are such blessings aren’t they? What did you have, a little boy or a girl?”

She was calling from Pampers. And I gave her an earful.

In South Africa, as in the UK, you get a free bag of baby goodies at some point in your pregnancy, or just after the birth. This bag is filled with samples of breast pads, nappies, bum creams and other products that are entirely unfamiliar to the unsuspecting new parent. It is a clever marketing tool, because it reaches a potential customer at exactly the moment when she needs to make purchasing decisions about a whole range of products that she has never encountered, and possibly didn’t even know existed. (Breast pads being a case in point.)

All they want from you in exchange for this ‘free’ bag of delights, is your name, address and phone number. It seems a small price to pay.

This is called relationship marketing. This type of marketing seeks to establish a long-term ‘relationship’ between the vendor and the customer. In order to really foster the relationship, the vendor needs to know some vital information about the customer and be able to act on that information over a period of time.

Like Pampers knowing the birthday of my baby.

In the UK, with my first child, Pampers sent me a parcel about 3 or 4 times over the course of the first two years. Inside: a booklet about my child’s development, and a free nappy. Children grow at a very predictable rate, and these free nappies arrived at exactly the right times. When the baby was about a year old and refused to lie down to have her nappy changed, Pampers sent me a pull-up nappy in the post and I wasted no time getting to the shops for a whole bag of these. It was relationship marketing at its best, because it was relevant and unintrusive.

Compare the efforts of Pampers SA, who intruded on my day at such an inconvenient time that I didn’t even bother to find out what they were trying to sell me.

Subaru: Spamming me with no chance to opt out

If you want to do relationship marketing, you need:

• A good understanding of your customers. If Pampers had spent even a small amount of time talking to new mothers, they would have known not to call at the arse end of the day.
• A non-intrusive approach. Interruption-based advertising, like the ads that interrupt your favourite TV show, is fast losing favour in the modern world. A phone call to someone with a small baby is going to be intrusive at just about any time. (Oh that marketer who called and woke the napping baby! The swearing! The abuse!)
• A relevant message. So you know I’ve had a baby. Sending me a nappy is relevant. Offering a test drive of a bigger car is relevant. Information about childhood development, common illnesses, paediatricians in my area, different approaches to education… the list goes on.
• I am not your friend, I am your customer. I have no desire to chat on the phone with someone pretending we are best chums. Get to the point and sell me what you want to sell. Don’t try to pretend that our ‘relationship’ is anything other that that of a customer and a vendor.
• Don’t spam. The more emails you send, the less likely I am to read them. Send relevant emails at appropriate times. And for goodness’ sake, don’t sell my email address to others.
• Give me an opt out. South African marketers seem to think that bombarding potential customers with text messages will eventually get them a sale. No. All it will do is annoy the customer to the point of distraction. Make sure I can easily opt out of your sms and emails, before I start to really hate you.

Seth Godin talks about all this in his book Meatball Sundae. The time for marketers to be disrespectful to customers is over. The time of interruption-based advertising is over. If you annoy me, our ‘relationship’ is over. And if you annoy me enough, I’ll blog and tweet about it and your foolishness will be broadcast to the big wide world.

An overview of my intro presentation

My talk covered the essentials of sketching for innovation: I’ve guest blogged it over on the 20Four labs blog.

We had a talk from Microsoft’s, Kath Roderick about Blend3 Sketchflow. I have to say – the tool really looks like it has merit.

• It’s primarily focussed on making fairly robust, clickable prototypes, so it may, be a bit more fiddly than a very early stage skecthing tool like Balsamiq. But it seems to make it easy to do a lot of the things that usually take ages during UX design.
• You can do data binding – to import sample data quickly into scrolly boxes.
• And you can make re-usable elements, like, say a universal navbar, and put them onto each page with ease.
• It also shows you your prototype pages as a network diagram rather than as a list (like say Fireworks or Dreamweaver does), which I think will make pages easier to find, organise and remember.
• Sketchflow lets you package up your prototype so you can put it on a website, and not worry about how to share the prototype. And the packaging mechanism includes a feedback tool so stakeholders can annotate and comment on it in their own time. Very clever.

Finally, we had a brilliant talk from Dennis Williams about how to make and use sketches even though you “can’t draw.”

Dennis presents at the SA|UX forum

Cape Town’s UX community is growing well. We had a turnout of more than 50 people.

Further reading:

• My sketching blog post…
• Microsoft Sketchflow product page
• Book: Sketching user experiences by Bill Buxton. This book really made a difference and is an enjoyable introduction to the power of sketching for non-designers.

A “dancing bear” is Alan Cooper’s term for a piece of technology that gets accepted because it does something valuable – not because it does something well. The miracle is that the bear dances. But if you needed a dancer, you wouldn’t hire a bear.

The Diamond RIO. It played music: Amazing! But it was a pain.

A classic example. The Diamond Rio: dancing bear. iPod: Prima ballerina.

Service design is another form of experience design. And it can have dancing bears too.

See the bear dance

So low are our expectations of South African mobile service providers, that we applaud when they manage the absolute basics of their business: connecting new customers to their service so they can make money out of them. A service provider that actually tried to provide a real customer experience? We can bearly imagine it.

The actual Vodacom experience (as braved by my wife, Debre):

• Folk in the Vodacom store didn’t seem to want to sell her anything and weren’t clear about how to port the numbers from Cell C.
• Folk at Cellucity were confused about which price plans were available, and what exactly you got for them. (But at least they were eager, and got us phones in 1 day.)
• We got telephone service, but they didn’t activate the 3G connection. Not too bright when you’re selling someone a smartphone.
• To activate the 3G connection, we had to call someone. He told us to use their automated menu system by stepping through a series of menus on the phone screen. The menu system told us that it had auto-detected our handset as an iPhone 3Gs, and that data services were not available for that kind of phone. So we called again and once we got through, they sorted the problem out by hand.
• Next morning, I got a text message telling me that my request to activate APN had been successful. I still don’t know what APN stands for.
• And finally, with my new iPhone standing proudly beside my bed, acting as alarm clock and ready to take emergency calls from Gran, they sent me a text message at 1:37 in the morning to tell me that they were going to debit my first payment. 1:37! Who scheduled that? And how was it supposed to create customer delight?

Vodacom communication - incomprehensible and inconsiderate

Improve service design: make more money

You think I’m a moaning Minnie? Well, here are three reasons why it matters.

1. Vodacom is wasting money. Shareholders money. Customers money.

• If the products are too complex for the staff to sell effectively, every sale takes longer – and costs more – than it should. Reduced margin.
• Every call to the customer support line costs money. In the UK, when I worked on projects for Vodafone, we noted that a single helpline call could easily wipe out a months profit from a customer – a month’s revenue in some cases. Reduced margin again. The calls in the story above were “error induced”. That means that we, the customers had to make them to recity the mistakes that Vodacom had made. That means they are avoidable.

2. Vodacom is wasting opportunity. There are three players in the RSA market. They are all equally shoddy. If Vodacom got service right customers would stay longer. They might even buy more. They might tell their friends. The marketer’s holy grail follows: loyalty. Loyalty reduces customer acquisition cost, increase business stability and boosts growth.

3. Mediocrity does not generate prosperity. If we continue to accept bungling service, shoddy workmanship and faulty products, we are allowing South Africa to get away with being second rate. I’m sitting down here in the Silicon Cape, helping companies take on global markets and global competition. For them, second rate won’t cut it. They can’t afford it.

It can be done

In the UK, O2 has become market leader by focussing on customer experience. In a recent Financial Times article, Ronan Dunne, chief executive of O2 UK says “My day-to-day focus, unequivocally, is kicking the hell out of the competition in the UK and giving a great experience to the customers.”

It has taken years of work and difficult culture change [PDF], but it is paying off: O2 gained 0.6% in Q1 2009 to achieve a market share of 28.3%, second placed Vodafone loses 0.1% to settle at 25.3%. (In Q1 2008, they were neck and neck.)

Service design

Mobile service provider complaints on helloPeter

Vodacom is neck-and-neck with Cell C on complaints on HelloPeter. If they want to climb the league table, here’s a suggested approach:

• Research the customer experience. Go be a customer and try doing all of the major customer activities, all round the country, online and via the call centre. Note the hard errors, and the soft let-downs.
• Envision the ideal customer experience. If all the worries about systems and processes and people were removed, what would you *really* want the customer experience to be like? Map out key journeys. What should happen to the customer at each stage? What opportunities are there to create customer joy?
• Design the customer experience. After that, you can think about how you can make it happen. In detail. Systems, processes, people. It will require lateral thinking and a determination not to take no for an answer.
• Create a culture of improvement. You’ll never get the whole thing right in one go. You need to put in place systems that help you listen to customers and *act on what they tell you*.

And and more lesson from Apple: Narrow your product range.

Apple has very few products really. Because they know that getting any product designed right is very tricky. They also know that once you’ve got it right, you’ll get a very big reward.

“Stakeholders” are business managers, developers, marketers, visual designers – anyone with a vested interest in the success of the product. Their involvement in the creation of the product is essential – without them, there’s no product. But when you’re doing user experience design, you’ll often find that these essential team members will boo your designs off, mess them up or just ignore them. Here are just a few reasons why…

• People don’t understand your design ideas.

• They can’t remember them.

• They don’t know they exist.

• They can’t find them.

• Business reality means they can’t afford to implement them.

• People don’t know what alternatives were considered.

• They don’t know what evidence supports them.

• They don’t know what criteria the designs are supposed to satisfy (what the product has to actually do).

• They don’t know why the user experience matters.

• People think the ideas are too difficult to implement.

• They think their idea was better.

• Their idea actually was better.

To help deal with these issues, think about the user experience you’re offering stakeholders. Could you design a better one that helps them do their jobs more easily, and participate in UX projects more constructively. I’m not advocating a huge meta-design effort.  But applying some of your experience design expertise in a fairly quick and dirty way seems to make sense. Here are some tactics to consider…

8 tactics for designing the stakeholder experience

Run a buzz campaign. Stick your work up on the walls of a war room. Yes, this lets you immerse yourself in user research and design ideas. But it also shows nearby stakeholders that you’re doing something. Something quite big and complicated and interesting. If people can see tantalising glimpses through war room windows, they’ll often invite themselves in to take a look at what you’re up to. Great.

Involve stakeholders in concept design. Start early in the design process. Let stakeholders voice their requirements, ideas and constraints in workshops where other stakeholders can hear them. Then everyone discovers the problem landscape together and sees the conflicting issues that will need to be resolved. The interaction designer becomes the facilitator (hooray), rather than the go-between (ouch). To make sure every stakeholder knows they have been heard, write each point on a sticky note and file it in the right place on the wall.

Listen. Developers have lots of wonderful ideas, often very pragmatic. Sales people and support people know your target customers. Marketers excel at articulating the vision for the product. Involving them all in concept design helps them to understand what you’re trying to do, and provides you with new perspectives on how to do it.

Communicate in digestible terms. Most people working on software projects are control freaks. Developers are among the worst offenders (right up there with interaction designers). It’s hard for a control freak to absorb complex, multi-part ideas, because they are tempted to dissect each component idea before the gestalt becomes apparent. The component ideas work together to make the user experience concept. Picking them off as they are mentioned means the big idea is shot to pieces before anyone can see it in its entirety.

You can prevent this from happening by communicating in the right order. When presenting formally or informally, always start with the 60,000ft view – what’s the big idea and what are the user needs that support it. Then go back over the ground in increasing detail, until you reach individual features. It’s only polite, really: your presentation should not be a mystery tour.

Improve findability with a UX wiki. Lists of files on a shared drive don’t cut it, because file names can’t contain enough information scent to make the right document easy to find. A wiki is quick to build, and can lay out the available information in a much more human-readable format. A wiki is also nice and searchable, and a decent wiki that supports tagging (or multiple categorisation) gives you semi-automatic cross referencing of pages.

Wiki IA: Start with foundation pages including business needs, competitor products, personas, goals, key scenarios and design drivers. Next create pages to address the interaction framework and style guide, plus visual style guide. Finally pick off interaction design feature by feature (following the structure of your storymap, perhaps) and cross reference back to the foundations and the style guides elements. Pages should have comment threads linked to them so that people can discuss and evolve the ideas they see and so that the discussion can be preserved forever, rather than being lost in people’s mailboxes.

Help stakeholders to recall complex information. Rationale is the “reason why” a design decision was made. At the time a decision is made, the reasons behind it (should) seem clear. But it’s amazing how much the whole stakeholder group will forget, as the project rolls on. And so will you. Write down the why for every major decision, and keep a record of any rejected ideas that got drawn/written up. Revisiting old ground is inevitable, but make it quick and you will save days of time and lots of repetitive arguments. You’ll also look very impressive and well prepared when you bring out the rationale document at the right moment.

Create the right conditions for developers to solve difficult problems. “It can’t be done!” is the understandable cry of many a developer when first faced with the challenges that a user-centred design project inevitably brings. Typically this means, “I haven’t yet worked out how to do it.” Try to re-frame the statement as question and to encourage people to believe there is a solution (go from “It can’t be done” to “How could it be done?”). Imply that whoever could find such a solution would earn their colleagues undying respect. Then leave the topic open for a few days. Developers love to solve problems – that’s why they chose the job. More often than not, they’ll come up with an answer.

Allow for instructive failure. If stakeholders insist on doing things in a way that you believe will fail, step aside gracefully. Document what you think the right solution is and make sure you are on record saying that you disagree with the chosen direction. Then wait. If things go wrong, later, you are in a position to pick up the pieces, and earn some respect in the process. This one works well on agile projects, where there are usually opportunities to change things later. On waterfall projects it can take years.

More please

Experience design is about working with human behaviour to get favourable outcomes. You’ll get better results and a happier team if you can apply those principles internally to projects too.

What other UX design principles do you apply to the stakeholder experience? I’m collecting ideas so please post a comment.

As we use wi-fi networks, satellite TV, mobile phones, we don’t give a thought to the antennas that makes them work. But designing antennas is hard. It’s almost as much an art as a science, takes lots of knowledge, dedication and experience… and months.

Antenna Magus is a new piece of software which cuts weeks off the antenna design process. It represents a revolution in antenna design. (If you want to know what it actually does, your best bet is to watch their chuckle-provoking video).

The Magus team wanted the software to be useful and quick to use. They wanted it to be “awesome” (with tongues slightly in cheeks). Most of all, they wanted it to be exportable globally and generate significant revenue, in a shortish time frame. So they asked me to help get them there.

During 2008 and 2009 I consulted on version 1 of the Antenna Magus project, with Carien Fouche, their newly-appointed, in-house UX designer. CEO Sam Clarke had already done some initial context studies and concept work – it really helps when the CEO “gets” user-centred design. From there we did a full UCD process, including personas, scenarios, prototypes and usability testing. But there were a few things that made the project special.

Paper and PowerPoint prototypes of Antennas Magus, for usability testing and discussion.

Challenge 1: I don’t understand antennas

As any user centred designer knows – this doesn’t actually matter much. User-centred design is really about trying to understand user goals and tasks, regardless of how much you may already know, or not, about the domain. Techniques like ethnography, personas, and usability testing are all about that. In fact, being quite clear that you don’t understand the domain can be an advantage: you’re not tempted to make personal assumptions about user needs.

Usability testing paper prototype with Antenna engineers

Challenge 2: The users are far, far away

A lot of South African software projects suffer from this problem. They’re designing for global export, which means their target users are literally thousands of miles away.

Solutions:

• Find some local users who are as similar to target users as possible. Antenna Magus had a group of local antenna engineers they could work with, locally.
• Simulate target users with personas and mental models. Having well thought-through personas stuck on the wall always helps.
• Be the users. Since there were several antenna engineers on the team, we had good insight on tap.
• Piggy back user testing/research on other trips. Sales and investment meetings, and training sessions overseas can get one of your team members into the right countries. Then you just need to train them how to bring back new user insights.

A 2×2 matrix of personas gave a quick summary of persona goals and behaviours

Mental models: Trying to understand how engineers want to work through the antenna design process

Challenge 3: Agile

Actually, agile projects are a joy, not a challenge. (At least, this one was, because it was a no-nonsense affair piloted by development manager Brian Woods). You acknowledge the fact that you can’t really perfect a complex user experience until you have working code to play with. You only design the detail of things you actually need, as you actually need them.

We started the project with a 2-day UCD training course for CEO, product manager, UX designer and lead developer.

But you need some solid concept design up front. The design team have to have a good understanding of the target users and their needs, a vision for a coherent product, and a good head start designing the navigation and interaction framework. On Magus, we had 3 months (!) of this “sprint zero” time, while the developers continued with back-end work. It was excellent.

Results

Antenna Magus is in release 1.0 and selling. Thousands of copies have been downloaded for evaluation.

Feedback on the software’s user experience has been good. We’ve seen a couple of small interaction bugs, and lots of new ideas for features. But the results are startlingly good for a 1.0 release.

The feedback that sums it all up for me actually was actually on a discussion forum in Russian. It refers to the minimalist user manual (just one page) supplied with the software:

A rather modest manual [...] as we have found opportunities in the program are not very many, and their use is almost obvious.

If Russians can use this first release in English and find it “almost obvious”, we must have done something right.

Credits. I got to work with a really impressive team that have a made a truly innovative product. CEO: Sam Clarke. Development manager: Brian Woods. User experience designer: Carien Fouche. Marketing (including the video): Robert Kellerman. Development: Sean Snyders, Christo Zeitsman and Leo Herselman. Plus a team of super-smart antenna engineers whose distilled expertise is what makes the product unique: Dan Barnard, Konrad Brand, Evan Knox-Davies, Neilen Marais and Thomas Sickle.

I’m too busy coding to work out whether people will want the product I am trying to deliver.

I’m too busy fighting fires to make sure we have a reliable process and happy staff.

I’m too busy thinking up new features to focus on what people really need.

I’m too busy trying to push the product to think about how to make people choose to buy it.

These are the underlying thought and behavior patterns behind some very expensive mistakes.

At the end of May, there was a free one day conference about South African, digital entrepreneurship: Net Prophet. Andrew Smith, a director of South Africa’s most delightful e-commerce site, YuppieChef, gave a great talk about e-commerce in South Africa. It was called E-commerce is not a technology problem.

Andrew covered user experience and customer experience in a completely jargon-free way. And he offered a great summary of the themes that an e-commerce operations needs to consider.

Of course e-commerce is not primarily a technology problem. But when you meet organisations starting e-commerce operations, you still need to spell it out every time. A great example from Andrew:  Pick and Pay’s website is high on technology and short on selling. The search engine returns results, sure, but if you search for milk, you get milk stout and milky bar buttons coming up first. Surely cartons of milk would make better sense.

(My limited experience of talking to the Sainsbury’s and Occado teams in the UK tells me that getting supermarket IA right takes about 2 years, or four iterations. So don’t give up, Pick and Pay).

Andrew also offers some great checklists for what it takes to run a successful e-commerce operation.

• Product: Hard to find, trusted brands, easy to deliver
• Marketing: Offline credibility, word of mouth, community
• Customer service: Real people, in touch, full time

It’s a great introduction.  But what’s really intriguing is that online trust-building and persuasion tactics don’t seem to be enough. Andrew is convinced that in South Africa, you have to establish trust via telephone calls and offline marketing. Like I said: if you can build a successful e-commerce business in South Africa, you can do it anywhere.