UX innovation in Africa: Culture and relevance

It’s rare to find black women working in technology. So, last week, I was delighted to find myself the only “pale male” on the panel at the Interact2013 UX in Africa discussion.

The other three panelists were women from Kenya engaged in different aspects of UX design.

The Interact2013 UX industry in Africa panel
Left to right… Susan Dray (Panel chair). Shikoh Gitau, who works for Google. Me, Phil Barrett. Kagonya Awari, a UX reseacher at iHub’s UX lab in Nairobi. Edna Chelule who manages design and UX at DSTV.

The panel discussed a couple of interesting points about UX in African Countries:

  1. Traditional culture in Kenya, and elsewhere in Africa, does not foster innovation.
  2. Poor people in Africa want what everyone else wants, but in more affordable formats/portions.

Traditional cultures and innovation

There was general agreement that traditionally, Kenyan culture maintains unquestioning respect for leaders and this can stifle innovation or prevent successful adoption of new ideas like user-centred design.

Shikoh, who has a PhD in HCI and computer science, talked about her experience of that ingrained respectfulness. When her opinion differs from that of a senior person in an organisation, she said, she’ll often have to check herself to make sure she doesn’t just stand down immediately out of deference to their seniority.

Mobolaji Ayoade, from the audience, described a similar issue in Nigeria. His strategy was to voice his opinion clearly and then bide his time. When the leader ignored his advice, and encountered problems, he was around to quietly say “Let’s try it this way instead.”

Kagonya described how the iHub has a very flat organisational structure and this causes amazement and admiration from Kenyans who visit, but it takes a bit of explaining.

Kagonya also told me she believes that respect for authority can cause people across Africa to withhold complaints or feedback about poor service. This is bad for them, but also bad for the growth of UX as a whole. It’s hard for organisations to appreciate a business need for an improved customer experience when no-one complains about the current experience.

Update from Kagonya, after reading this post…

Quick correction: I wouldn’t boldy say that traditional culture does not foster innovation in Kenya, but more specifically traditional office culture. The reason being that culturally, while all Kenyan tribes push for respect for elders, I do not think that this always and therefore results in the hindrance of new ideas. Most communities have avenues where the young can pass on their ideas to the old and by these channels create room for new ideas.

Similarly, “traditional culture in Kenya does not foster innovation” may perhaps be too broad a statement? Maybe, “traditional culture in Kenya and other Africa countries, may hinder innovation”.

Poor people in Africa want the normal stuff

Shikoh and Kagonya agreed that many efforts at seed funding African startups are misguided. Well meaning NGOs and investors want tech projects to tackle the “big” issues – like AIDS for example. But the target users of the technology aren’t interested in that. They tend to be interested in the same things everything else wants, like entertainment, beauty and communication.

Both Shikoh and Kagonya said (slightly flippantly) that they could get venture funding in minutes from well-meaning investment funds, just by putting together a powerpoint slide mentioning Kibera (Nairobi’s largest slum), AIDS and mobile apps. But the product that such a venture would deliver would have little or no impact because people wouldn’t make time for it in their lives – or space on their phones.

As an example of what poor people in emerging markets do want, Shikoh gave the example of Unilever. They market the same face creams to several different market segments. But they make the creams available in small sachets for customers on the tightest budgets.

We talked about South African companies that do an excellent job at making products and services available in formats and at price points that people can afford. PEP’s focus on minimising overhead lets them save several cents per rand on distribution costs relative to competitors. DSTV offers pay as you go pricing. And Mxit offers messaging and photo sharing with minimal data usage – something that its loyal customers really appreciate.

Black, South African UX designers

The panel was great fun and very informative. I just wish there were more black South African UX designers who could have participated. Perhaps South Africa’s newly emerging middle class prefers its young people to study law, medicine or engineering? A shame from my perspective, since design thinking in South Africa is just as likely as any of those disciplines to change life for the better.

4 ways to combat usability testing avoidance

Working with users during the design process will untie project knots and boost team productivity and focus. But there always seems to be an excuse for not testing. Here are 4 ways to counter the excuses and make usability testing happen.

Testing a paper prototype

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…

Read more

Three blades to Occam’s Razor

The principle of Occam’s Razor offers interaction designers three ways to keep complexity under control.

Razors - by Viscousplatypus. http://www.flickr.com/photos/pneumatic_transport/

Occam’s razor has been really useful to me on several projects recently. It’s nothing new. Occam was around in the 14th Century. And it wasn’t even his idea: it might well have been Aristotle’s. Perhaps that long history proves that it’s a great tool to have in your arsenal when designing user experiences.

The basic idea is something like:

“If you have two equivalent theories or explanations for observed facts, all other things being equal, use the simpler one.”

The user-centred design version might be:

“If you have two interfaces that both address user needs, go with the simpler one.”

But there are three different ways the idea gets expressed, and each form has something to offer interaction designers. Here they are:

  1. Choose simple solutions
  2. Keep merging features
  3. Don’t oversimplify

Read more

Telling stories

Christmas is a good time for sitting around a fire and telling stories. Practice your storytelling this Christmas, and hone your interaction design skills for 2009.

People love stories. But beyond that, stories are fundamental to the way we think as human beings. Salesmen tell persuasive stories about successful installations and satisfied customers. Social workers pass on complex case histories as stories. Just about every culture in the world passes on valuable knowledge to the next generation in the form of stories.

Christmas tree

When properly told, stories incorporate all the ingredients people need to think and learn: situation, actors, events, challenges, consequences… They help us gain a little of the benefit of direct experience, with much less of the pain.

So it makes sense that interaction designers need to be great story tellers. I’ve picked three kinds of storytelling used in interaction design…

  • Scenarios
  • Specification
  • Rationale

Scenarios: Invent a story

Because we’re not fundamentally good at imagining futures or situations different to the one we are in, we have to consciously and explicitly create stories to make sure we do things right. Interaction designers create personas (the characters in the stories), describe the context of use (situation and back story) and the personas’ goals.

Then we create scenarios. We try to tell a compelling and realistic story of how our personas will reach a happy ending by using the product. Because we’re all good at listening to stories, the team can spot the good ones, the implausible ones and the radical-amazing-breakthrough ones quite quickly.

A storyboard

Specification: Many stories

A specification – however sketchy or detailed – is a story. Actually it’s many stories, captured simultaneously. What will happen if the user goes here or there? A good specification has a lot in common with a Choose You Own Adventure story. (Did somebody say adventure? Now there’s some classic interaction.)

Choose your own adventure: Mystery of the Maya

The trick for a good interaction designer, though, is to make sure that the story of your product has no dead ends. So the best specs spend plenty of effort on handling error situations, as well as just the positive story.

Rationale: Meta-story

The importance of rationale is often underestimated. Rationale is the story of how and why a design decision has been made. “We’re doing it like this because…” When your storytelling has led you to a non-obvious (but demonstrably right) conclusion you don’t want your team and your stakeholders re-creating all the failed stories you’ve already told all over again. It takes too long.

Rationale also demonstrates how much effort has been put into reaching a conclusion, so that the team doesn’t forget how far they’ve come.

Pictures are not stories

A picture, in this context, doesn’t tell a story so much as beg for one. A beautifully drawn image of an interface, frozen in time, might look persuasive – and it might hint at past and future interaction. But it doesn’t answer many of the important questions: how do your users reach this point? Where do they want to go next? Will they know what button to choose? What will happen if they click that button? A picture on its own is open to misinterpretation by everyone who looks at it, from developer to CEO.

When you surround it with other pictures and information about the sequence they link in, then a story unfolds. And that’s what interaction design is all about.

Sideloading free content from the sneakernet

Mobile devices are the primary experience of personal computing for most people in emerging markets. Accessing content at prices these users can afford is all but impossible. But using sideloading and sneakernet, content can spread for free.

I was lucky enough to watch a great talk by Gary Marsden at the recent SA UX meeting in Cape Town. He talked about many interesting things, but this one captured my imagination the most.

In developing markets, mobile devices have much greater market penetration the personal computers. In South Africa, for example, around 77% of the population have mobiles but only 12% get online with PCs. So for hundreds of millions worldwide, the main, everyday experience of digital technology is probably a phone. When a phone is one of the few pieces of technology you’ve got, it’s amazing what you will use it for. In emerging markets, mobile phones are becoming a primary mechanism for reading text, storing photo albums, watching video and listening to music.

Nokia has recently announced their $50 2323 phone, along with a suite of carefully targetted custom content to address this developing market demand.

Nokia lifetools promo extract

But nearer the “bottom of the pyramid” the the cost of mobile data services is too much for most people to afford more than a trickle of bytes. Typical data consumption for a young South African might cost them around R7 per week, which is around 50 pence. Downloading MP3s or ebooks isn’t realistic. So instead, some content is percolating across the community using bluetooth sideloading and sneakernet.

Sideloading sneakernet

Sideloading is a newish term, still ill-defined. But one meaning is that people can share content from one mobile device to the next, rather than downloading it from network servers.

Sneakernets are a venerable concept, still used by even the largest companies when the cost of electronic data transfer is too high. It just means that you carry data from A to B on a storage medium, instead of sending it over a wire. Google, for example, used blocks of disks to transfer 120 terabyte files.

If you put the two together you can transfer data to mobile devices for free, across any distance. Basically, one person sends a piece of content to another using bluetooth. The recepient can share their copy with more friends, and from them it can go on to more. The potential rate of distribution grows exponentially.

Riding the sneakernet

With only 6.6 degrees of separation between everyone on the planet, it’s not hard to see that this could let content percolate quite fast. But our daily face to face contact is with far fewer people than our total network, so content will percolate more slowly, really.

Targetting connectors will help. The Tipping Point tells us that a few people in the world are connectors – they know a lot of people. To get a message out over a sneakernet, it would make sense to ensure it gets to the connectors.

In reality, it may be that most content won’t hop quickly or reliably enough from user to user for many applications. So providing physical severs in public spaces to allow bluetooth content downloads looks like a more controlled option.

Bigboard, and one example content square

To do just that, Gary Marsden’s team at the University of Cape Town, along with Microsoft Research have invented Big Board. It’s a digital message board that allows people with ordinary, bluetooth-enabled phones to download text, images, audio and video for free. Most important, it requires no extra software on the handset at all – most phones can already receive mutimedia messages via bluetooth.

What content is worth distributing? For big board, community and local content make sense. Big board can also allow content to be uploaded to it, making it true, digital message board. Education and entertainment also fit well, and are good sneakernet fuel too. I’ve heard plans for using soap opera mobisodes to provide health education and AIDS awareness messages…

Further reading

Designing future happiness

Humans are not very good at predicting what will make us happy in the future. Designers need user centred design techniques to help them to overcome that limitation.

We don’t know what’s good for us

In Stumbling on Happiness, Harvard psychology professor Daniel Gilbert, describes recent research on “prospection” – the act of considering the future. Our ability to simulate future experiences is one of the things that makes us human. But our experience simulator (the pre frontal cortex) makes lots of mistakes. A key mistake is to imagine the future will be like the present.

Will people want to live in homes like these? Nope!

For example, past visions of the future included rocket cars and jet packs, but usually the people’s behaviour didn’t change a bit. Mom still hung out in the kitchen, even though the work was being done by machines. And people lived happily in high-rise, concrete complexes. Today, retro-futuristic visions are more a quaint commentary on the time when they were made than a relevant description of the present.

Yummy duck dinner. FotoosVanRobin: http://www.flickr.com/photos/fotoosvanrobin/

On an individual level, we’re bad at predicting what experiences will make us happy in our own future. After finishing a delicious roast duck dinner at a favourite restaurant, I will be full and I will have “habituated” to the duck. So future duck dinners will not seem so appealing to me. If asked to pre-order for my next visit in a month’s time, I’m more likely to choose something other than duck. But when I arrive at the restaurant a month later, I am more likely to actually choose the duck again. When I made the choice about my future, I assumed it would be like my present, where I’d had enough of the duck. But when the future came, I was actually hungry – a frame of mind that I did not predict.

Methods for predicting the future

On a straightforward level, designers need to make this prediction: “What will people want to do with this product?” For example…

  • Will people want to shop on my website by brand, price or by specification?
  • Will people want to devote full attention to this mobile device or just glance at it?
  • Will people want to watch a 30-second animated intro to my website?
  • Will people want to click a button to clear all the data from a web form ans start again?

In all these real-life situations, the designers had to imagine future usage of their product and make decisions accordingly. A lot of them got things wrong, because they imagined that when using the finished product in the future they would be in the same frame of mind as when they were designing it.

Bringing the future to the present in a usability test

Since we’re actually better at thinking about the present than the future, designers who want robust results need to bring the future into the present. In some respects, that’s what user centred design is.

  • Ethnographic studies: Since target users are (usually) human they can’t predict accurately what will make them happy in the future. So it’s best to watch what people do instead. Study what makes them happy, and what unhappy moments you can address with design.
  • Iterative prototyping: The future product isn’t finished yet. But make a mock-up of it and get target users to try it out. By simulating real usage, you’re simulating the future more accurately than you can imagine it.
  • Scenarios and cognitive walkthroughs: Be methodical and write down what people’s future situations might be. Then you’ve got a better chance of predicting their future behaviour.
  • Field trials: For particularly huge and life-changing ideas, your prototypes need to be a bit more solid. Leave them with a select few for a while and see what you get. For example, Microsoft’s SenseCam and whereabouts clock. Or Bill Gaver’s Flight tracker.

Field trial of the  Whereabouts clock in a  family kitchen

Making future happiness evident

Designers are often asked to design things that look desirable – that convince people to buy, rather than to deliver ongoing satisfaction. In a way, the user experience design movement has been about changing that: creating products that make people happy over time.

But since our customers can’t predict what will make them happy, they might buy the wrong thing. Something with lots of impressive-looking buttons, for example. So not only does the product have to make people happy, it has to look like it will make them happy.

One trick is to emphasise simplicity (which is what seems to make most people happy) as a feature. Sometimes it works.

Using the Microsoft Ribbon without anyone getting hurt

Designing an effective Microsoft Fluent/Ribbon toolbar is not for the faint of heart. You need to understand your users’ activity in detail and plan a consistent overall experience.

I’m working on two WPF applications at the moment. For both, we have to decide whether to use traditional File/Edit/View menus or an MS-Office-style ribbon. It’s not an easy decision…

MS Office Fluent Interface Ribbon
A piece of the Ribbon, from MS Excel 2007

Pro: It appears to be built on a sound theoretical basis and Microsoft tell us they’ve researched it to death with hordes of real users. They also say they’re planning to use it more widely.

Con: Key players on both the teams I’m working with are against the ribbon. They say “I use Office all the time and I really don’t want one of those things on MY software.”

Con: Jakob Nielsen raises an eyebrow that a number of the best new applications of the year use ribbons. He points out that Microsoft have not always come up with the best interface innovations in the past. Pro: But he grudgingly admits that maybe “the Ribbon has legs”.

Con: Some surfing around yields plenty of blogs posts from frustrated ribbon users.

Pro: The techsmith team implemented a ribbon on snagit 9 and say their research showed it worked well.

Con: And a couple of bits of software that allow you to replace the ribbon in MS Office 2007 with a more traditional menu bar. That’s a sign that there’s a potential market of people desperate enough to pay to get rid of the ribbon.

So what’s going on?

Good if used with UCD

My analysis: The ribbon is a decent piece of interface, but like most things in UX, it’s hard to design it well. And to design it well you really have to understand your users’ needs, behaviours and work practices.

That’s because the ribbon tries to show commands grouped together based on what users are most likely to want to do. So in Word 2007, for example, there’s a tab for mail-merge, and one for page layout and one for referencing, whereas in Word 2003 those features are pushed lower down in a more generic menu structure. If you get the groupings right, your users will always find the selection of controls they need right there in the ribbon. But if you misunderstand what they need to do, they’ll get an irrelevant list and you’ll get complaints.

Microsoft have got a lot of it right, but a bit of it wrong.  And with Office’s massive user base, an angry, vocal minority is still a million people or more.

Three ways to get Ribbon design wrong

  1. Choose groupings that don’t mirror real-world workflow. If you group menu options together in ways that don’t reflect the way that people really work in the real world you’ll cause frustration.  PowerPoint 2007 Beta 2 had some problems with this.
  2. Make groups the wrong size. If a group isn’t properly broken down it could end up displaying too many icons on the ribbon at once, making the ribbon hard to scan. Making groups too small means people might have to hunt through have too many tabs with not much on each.
  3. Options that move about too much. If the same control appears in different areas of the Ribbon for different tabs, it becomes hard to know where to look to find what you want. For example, in PowerPoint 2007, the shapes gallery appears on several tabs in different places. If I’m in format mode, I’ll find my shapes on the left. But on the home tab, I’ll find them on the right. This makes the core activity of drawing a shape surprisingly hard to engage in. I think this sort of thing is what makes some people complain that they “can never find anything” in Office 2007.

Powerpoint ribbon: Same controls, radically different locations depending on context
The shapes gallery appears on the left of the format ribbon and the right of the home ribbon. This makes it a lot more effort to locate a key feature in PowerPoint 2007

This last point is, I think, the key issue that makes me feel uneasy about the Ribbon. As humans, we’re not very good at remembering which mode or state a machine is in. We need to look at indicators and control panels to see it. But we are quite good at remembering where a given resource or tool sits in our environment. This is because of the way things behave in the real world. Our frying pan doesn’t magically reposition itself on the hob just because we pick up some bacon. It stays put in the cupboard and we know where to find it.

So with interfaces, we might well expect that the controls we want will be in a fixed place. Remembering what mode a piece of software is in, and remembering a different control layout for each mode, is just too much. If we look up at the Ribbon and (fail to) see controls in unexpected places, it causes cognitive friction.

Update: guidelines from Microsoft

I’ve discovered some updated guidelines from Microsoft that really help. Along with other nuggets, this one addresses dockable palettes issue below…

Ribbons must be used in place of menu bars and toolbars. However, a Ribbon may be combined with palette windows and navigation elements, such as Back and Forward buttons and an Address bar.

The opposite of dockable palettes?

Dockable windows or palettes are by definition always there, regardless of what mode the application is in. That’s very different from the spirit of the Ribbon, which is supposed to be all about contextual relevance. Can the two co-exist?

Snag-It 9 seems to have included dockable windows in their interface. And even Powerpoint does actually have a few non-modal dialogs (windows you can leave open all the time while you’re doing other things) – the format shape dialog, for example. So perhaps it’s ok.

Proceeding with caution

I think I’ll suggest using a Ribbon for the applications I’m working on. We’ll need to look carefully at sensible task groupings, and make sure that features don’t jump around too much. Then usability test it a lot.

If I find any specific reasons why the Ribbon doesn’t work, I’ll post.

New facebook design confirms a drift to the right (nav)

Facebook’s homepage moves more of the navigation to the right – a signal that the convention of left navigation bars is shifting.

Facebook navigation
Facebook’s welcome page – lots of functionality has moved to the right.

When I first saw a left hand navbar in 1995, I was amazed at the idea of dividing the page up into zones, and dedicating one of them to this cryptic concept called “navigation”. I never stopped to wonder whether putting it on the left was a good idea. Fundamentally, I don’t think it is.

Left to right

In the west, we read from left to right. Eye tracking studies generally indicate the the top left area of the page is the place where everyone looks. But when we arrive on a page, we first want to assess if it brings us closer to our goal. Getting closer to our goals makes us happy. So content, not navigation should go in the prime, left-side spot.

At worst, a navbar says “Are you sure you wanted to be on this page? Why not try a different one?” And because it is there on every page, the question is quite incessant. It’s like having the store guide in a department store follow you around on wheels. Or the table of contents appear on every page of a newspaper.

Long left nav
Long left navbars: Do we really need to be able to navigate from anywhere to everywhere else?

Breaking with convention

Mercifully, around 3-4 years ago, left navs started disappearing. Maybe it was eye tracking studies that did it.

Blogs were among the first to shift- the standard templates didn’t feature left navs. The changes were a difficult decision for interaction designers. So deep rooted was the left-nav habit, that angst-ridden designers posted on lists asking, “Is it ok to put my nav on the right?”

Some debate ensued. Wasn’t convention the most important thing for ease of use? Convention said navbars went on the left. Right was for cross-links, bits and pieces. But a study showed that actually, it didn’t make a significant difference. People could complete key tasks with no training with pretty much the same levels of efficiency and effectiveness, with both right and with left navbars.

What we think while we navigate

I like putting the navigation on the right. Here’s why. I think people conceptualise their navigation through a website taxonomy like this…

Web navigation: a mental model

This comes from watching people during a lot of usability tests. If you think about web navigation like that, then right equals forward and left equals backward (just like in a book). People like going forward, making progress towards their goals. So if interaction designers can ensure there is always an interesting place to go forward to, left navigation becomes much less important. You can collapse it into top menus or push it into a rather lovely bottom navbar.
(The other key form of navigation, probably most effective of all, is inline links. But that’s another post).

Facebook is moving the emphasis to the right with its redesign. It hasn’t given up on the left navbar yet, but I think it will over time, and so will most other websites. Because overall, I think content on the left and onward links on the right suits the way we think.

What makes us productive and what makes us stupid

Your working environment has a big impact on your productivity, creativity and happiness. And good user experiences follow the same rules.

The interruptions caused by email and other digital communications reduce your IQ by up to 10 points, and cost large corporations UD$1m in revenue per annum. They also make people unhappy. Among many corporations, Intel has been running a “quiet time” initiative, where every Tuesday morning is set aside for quiet thinking only. No email, no IM, no phone calls, even.

On the flip side, I found interesting research about how corporate environments that provide clear goals, facilitate progress and praise success make people happier, more creative and more productive.

It struck me that most of this is linked to the concept of Flow, proposed by Mihály Csíkszentmihályi. Flow is a state of optimal experience (very closely linked to happiness). If you’ve ever looked up at the clock and realised that an hour or two has rushed past unexpectedly, chances are you were in a state of Flow.

Mihaly Csikszentmihalyi proposed the idea of Flow

Flow is frequently caused by having clear and worthwhile goals, making visible progress towards those goals, and being appropriately challenged as you go. Almost exactly like that description of the happy and productive working environment.

But how many times have you sat down at your desk expecting to make rewarding progress, only to realise that you have a pile of unread email? Suddenly you’re wading through unexpected issues and problems, and your original goal for the day is pushed further away. That’s a recipe for no flow, and a feeling of frustration. No wonder the Intel pilot group look forward to Tuesday mornings.

Happy interaction

So, if you’re a manager, you need to be shaping your team or organisation to work in a Flow-inducing way.

If you’re an interaction designer, you need to design interfaces to help your users experience Flow. Three fairly plain lessons:

  • Don’t interrupt your users. People using computers are goal directed – they’re online to get a task done. Excessive confirmation dialogs cause frustration. Interstitial and pop-up ads are worse. Flash intros are, mercifully, a thing of the past.  And perhaps the cardinal sin is emailing your customers too much. Why any brand would want to be associated with these negative, frustration-causing events is a mystery to me. “Are users stupid?” some unenlightened designers have been heard to ask. Well, if you keep interrupting them, you’re reducing their IQ.
  • Help your users to accept new ideas. Innovation is a hot topic for corporations looking for an edge. Helping your customers to innovate makes them happy too. Blogger.com helps new users understand blogging and create a blog in astoundingly simple steps. Google Adwords suggests new products and services that are specifically selected to be relevant to the user’s goal. Amazon does the same, and also keeps many of it recommendations for after you’ve made some productive steps towards your goal – it recommends most stuff when you add to basket and when you complete a purchase.
  • Help your users to think creatively. A lot of Web2.0, and the latest thinking in UCD, is about helping people to express themselves by building or creating something. Myspace and Facebook pages and relationships are a labour of love for some. Family trees are loving crafted in Geni. Photobox lets you craft beautiful paper photo albums using custom software. All Flow activities, where users make clear progress towards desirable goals, and learn something on the way.

To be effective interaction designers, we need to be happiness experts. And because the organisation behind the interface will always show through, we need to be happy and work in happy places. Now that’s a goal worth working towards.

Why did Apple launch a bad phone?

If if the 1st Gen iPhone was so “bad” – what was Apple thinking when they launched it?

Lots of people are excited about the new iPhone because they think it will address many of the annoyances present in the first one. (Well – not all of those issues are getting addressed, in fact. But some are.)

There was much complaining about the iPhone 1.0. And vocal user complaints are not usually a great recipe for a popular product and strong sales. In fact often, companies that rush products out to be “first to market” end up having their lunch eaten by products that arrive a little later, but offer a better UX. Apple themselves demonstrated with the ipod that late-comers can steal the the show by being “best-to-market.”

Here are 5 reasons I can think of why Apple launched a “bad” product, braved all that negative publicity, and gave companies like Samsung and HTC a chance to take a shot at them.

1. Launch simple products first.

Apple like everyone else had to launch a version 1.0. Business reality and human psychology demand it. At some point you have to get something out the door becfore you run out of cash or go insane. iPhone 1.0 was a product of controlled project scope.

iphone 3g

2. Get feedback from beta testers

Getting live market feedback works well – but mostly with early adopters. So perhaps Apple didn’t want go mainstream yet. Did they elect to keep sales constrained and stay with the iPhone *BETA crowd until they had perfected the product?

3. Move the focus to UX

The iPhone caused a stir because it moved the focus to a different aspect of the mobile UX. Were Apple deliberately saying “it’s not about hardware. Stop competing on hardware. This new phone is all about the user experience.” So in a way, the hardware shortcomings drew attention to the UX. People complaining about missing hardware could be accused of “missing the point/having no vision” – and frequently were.

4. No competitors stand a chance anyway

Apple decided it didn’t matter if their prodcut wasn’t perfect, because they were confident that none of the existing mobile manufacturers could get their act together to compete on Apple’s UX turf nearly fast enough. Efforts from HTC and Samsung were hardly mind-blowing. Nokia’s device is still in development.

And realistically, that wasn’t hard to predict. For traditional electronics companies try to squeeze into the Apple mold seems to be all but impossible. So Apple put their money where their mouth was and went first to market with an incomplete product. They knew they would get a way with it.

5. And now they can generate more buzz by launching version 2.

All publicity is good publicity.

Are people going to buy iPhone2? Some more will. That I suspect that question doesn’t matter to Apple too much. We’re still, arguably, in beta 2. One more release and it’s going to get interesting.