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 2x2 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.

Balsamiq is a tool for creating rapid interface sketches. Due to skilful social marketing, its reputation is spreading fast.  And at $79.99 it's a fairly cost effective bit of software.

Balsamiq has found a great niche. A growing group of folk in the web and software business understand that they should be sketching interfaces before implementation, but feel they "can't draw". So making a dedicated piece of software for them is a good idea. Integration with various enterprise collaboration tools makes another nice USP.

Sketch really fast

Balsamiq genuinely allows you to produce sketch interfaces faster then any other tool I've seen.  You can add a window, say, then instantly customize the thickness of the status bar, and title bar, and add or remove the maximize, minimize and close buttons. You can chuck in a tree control and quickly customize exactly how many folders it is showing and what each one is called.  Everything lines up automatically so it looks fairly neat.

You can also make scrolling pages and string them together into clickable demos. That means you can mock up a simple website clickthough in a few minutes. Balsamiq also captures some of the fun and creativity that makes sketching such a joy.  Clever!

But then what?

There are at least three good reasons to create interface sketches and prototypes:

1. To get new ideas and quickly explore and enhance them in design sessions with colleagues. Balsamiq is right at home here.
2. To usability test ideas with target users. Balsamiq is close to being very useful here.
3. To explain, persuade and demonstrate to other project stakeholders. Balsamiq needs quite a lot of work here.

As an interaction designer, I also need a tool to help me when interaction design projects get big and complex. Balsamiq isn't yet great at handling large, complex mockups and helping you to keep all the pages consistent and up to date.

Usability testing

Balsamiq mockups could be great for cost effective, early-stage usability testing. The interfaces are quick to create, and they look messy enough to allow users to give negative feedback if required. But usability testing a Balsamiq prototype has three problems:

1. Fullscreen mode features a giant blue mouse cursor that turns upside down and a giant hand cursor for hyperlinks. This is weird and distracting for a user to contend with during a usability test.
2. The giant blue cursor disappears when you try to touch a scrollbar, increasing the weirdness further.
3. Highly visible hotspots, that show user exactly where to click, and tooltips that tell you the name of the page you'll get if you do click.  These features "give the game away" in ways that are counter-productive in usability tests.

What I'd like:

• ordinary mouse cursors
• more normal scrollbar interaction in fullscreen mode
• an optional back button in fullscreen mode, for usability testing website mockups
• invisible hyperlink hotspots – let me define how obvious a link should be

Explaining, persuading and demonstrating

User experience design is at least 50% politics, if not 80%.  That means that an artful UX designer will use visual communication methods in different ways to get different results.  One result is the need to persuade. When you've collaborated and researched enough, and you're comfortable you've got a good solution, you need to persuade management and the dev team that your answer is right, and should be adhered to.

A good pen sketch has lots of credibility and style.  "Wow, I can't draw as well as that – you're clearly a pro."  But Balsamiq uses very rough lines and the dreaded comic sans font. As Andy Budd pointed out, Balsamiq's mickey-mouse/kindergarten style will call your credibility, competence and skill into question.

What I'd like: A range of widget sets – "artist", "wireframe" and "shiny" to match the different needs of an interaction designer at different stages of the design lifecycle.

Handling big, interactive prototypes

Interaction design is about making things that change over time, in response to user and system activity.  One way to model complex interaction is to create a lot of pages and look at them in a sequence - a storyboard.  Powerpoint is good at this.

Balsamiq recently added the ability to hold multiple pages of interface open at once, and create links between them.  That's a minimum requirement to be a genuine interaction design tool.  The trouble is, there is still too much overhead in creating new states/pages.  You have to create a new file, name it and save it before you can link to it.
What I'd like: The ability to create lots of pages in a single Balsamiq document and navigate and link between those pages using thumbnails, rather than having to give every page an explicit name.

You create many pages showing a particular complex control or layout, and then realize you need to update all instances of that control. It's a pain. Fireworks handles this quite well. You can create a library of your own objects. Then if you change the master, all instances of the object that you've used in your document are updated too.

What I'd like:  A way to create custom libraries of master objects, from which you can create instances that update when you change the master.

Taking it even further, I'd like to move away from a purely flat page approach.  If we could create prototypes with real interactive widgets, you could cut down on the number of flat pages you need to create.  Examples:  Axure.  Fireworks is also close.  And watch out for Silverlight 3 Sketchflow.

What I'd like eventually: Interactive widgets. Pull-down menus that can actually be pulled down, tabs that can actually be tabbed, etc.

Whither Balsamiq? 

Now of course, Balsamiq may decide it doesn't want to try to grow into the behemoth I've described.  It may be better for it to remain just a digital crayon for creating rough, disposable sketches, and with a few tweaks, very quick usability testing prototypes. That's a great niche with money to be made.

But professional interaction designers will probably be happier using more powerful tools, to support them support them through the politics and complexity of large projects.  That, and actual crayons.

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

First blade: Choose simple solutions

"Two interfaces - choose the simpler one." A no-brainer, right? Simple designs are easier to implement and maintain, and quicker for everyone to learn and use. But choosing a simple design when you see it is actually surprisingly hard. Organisations with lots of people, objectives and agendas will generate complexity faster than you can say "knife" (or indeed "razor").

• Some stakeholders can be left feeling short-changed by simple designs that do what customers and users really want. One cry that's very familiar to website designers is "but I want my product/service/department promoted on the homepage too". And that leads to tragedy.
• Other stakeholders will obsess about edge-cases - things that logically can happen, but very rarely will. Catering for all of these ties your design up in knots.
• And some people seem to gain a sense of importance from fiddling with a good design - turning it, step by step, into a disastrous mess. This video about the design of the stop sign says it beautifully.

All these kinds of events will conspire to push an unwary interaction designer off course. Remembering Occam's razor, and quoting it to your clients, team and stakeholders, can help to keep you focussed and change other people's points of view.

Second blade: Keep merging features

Another common phrasing of Occam's razor is:

"Entities are not to be multiplied without necessity."

In interaction design terms I like to phrase it as:

"Whenever you see two things that seem to do something similar, see if you can turn them into just one thing."

"We've got the 'picker' over here, for choosing widgets from a long list in alphabetical order. And the 'chooser' which sits over there for choosing widgets from a categorised short list. Then there's the 'finder' up here which is for finding widgets which might be in either list. And the 'selector' over there which pops open when you need to select a widget from the full database."

You get the idea. If you find yourself having conversations like that you should take a breath, and realise that you've multiplied your entities beyond necessity. Chances are you need one tool for selecting widgets, not four.

For example, Google has taken the merge blade to their Chrome web browser. They've merged the search box and the URL box into one. Those are two very different boxes. But from most people's point of view having one box where you type in what you want is great. No tricky decisions to make.

So as you go along, be on the lookout for ways to merge multiple separate components in your design into one. You'll end up with a design containing a few flexible items, instead of many small, inflexible ones. Typically that means less to learn, and a more elegant user experience.

Third blade: Don't oversimplify

Knowing when something is simple enough can be tricky. Trying to oversimplify something that is inherently complex can be a waste of time. How do you know when to stop?

Einstein's phrasing of the rule helps us here:

"Make everything as simple as possible, but not simpler."

The UCD version is, perhaps:

"Understand what people really need to do and make sure that your simplest design really does all those things."

That's why UCD stresses that you need to go out and observe your target users in action. It's the only way to find out what they really need.

A single button mouse is a great example. Apple hung onto the idea for years, and with good reason. It really is way easier to learn than a two button mouse. Watch a young child using a two-button mouse and see how many errors they make by pressing the right button intead of the left. But in the end, the multibutton mouse has won. Why? For the applications people were running in the early nineties, one button was often sufficient. But people's needs and expectations have grown, and now a single button mouse can't provide convenient access to the wide range of features people expect, and know how to use. A two button mouse, plus scroll wheel, lets people do more of the things that they really want to do, more quickly.

But this does beg a question, though. With a complex piece of software like MS Word 2007, people want to do hundreds of different things. How can you ever make something like that simple?

Alan Kay to the rescue:

"Make simple things easy and difficult things possible."

In other words make sure that you prioritise your design. Put the most commonly used features within easy reach and tuck away the more specialised and advanced ones.

The deadline sharpens the blades

It's easy to get tangled up. What MUST users have? What would they like a lot? What do we think they should want? Can we just squeeze this element in? What would happen if they tried to do that other thing? Luckily, Occam's razor suddenly gains power when you are faced with looming deadlines and limited resources. Those force you to really use the razor and they have the power to silence the most tangled corporate debates.

And when you're forced to use it, something amazing happens. All the "what about if" cases drop away, leaving you with the "all users will want to" cases. And following close behind that you typically find a clean, simple interface. Simple because it doesn't have to solve all the world's problems, just a manageable and intelligible subset.

So:

• Quote Occam's razor to help you fight for simple interfaces when you see them
• Look for interface elements which you can merge into a single element
• Understand what target users are really trying to do, so that you know exactly how complex things have to be
• Prioritise features so that the most popular are visible and the advanced ones are tucked away
• Use the power of the deadline to force yourself or your team to stop adding complexity and start fighting your way towards simplicty.

And remember Antoine de Saint-Exupery, author of "The Little Prince":

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

I don't usually post straight pointers to other people's work, but this one is a beauty.

The 10 things user experience design is NOT…

1. …user interface design
2. …a step in the process
3. …about technology
4. …just about usability
5. …just about the user
6. …expensive
7. …easy
8. …the role of one person or department
9. …a single discipline
10. …a choice

Organisations and teams that understand this will stand a much better chance of generating a good user experience, happy customers, and a profit. Here's the full post...

I got a 22 inch Samsung with a resolution of 1680x1050. This was a mistake: To really boost productivity I should have bought a bigger one. 1920x1200 seems to be the sweet spot.

But what really struck me is that I seemed to spend a lot of time shuffling windows around to get the applications I wanted displayed next to each other. If anything, I felt less productive.

A tidy desktop, organised with Winsplit Revolution

I found a piece of software called Winsplit Revolution, courtesy of LifeHacker. It lets you get windows into predefined sizes and positions quickly. Configuring the positions is still a confusing and manual process but it's worth it.  With intuitive key combinations I can now snap windows to top, bottom, right or left, and toggle through 66%, 50% or 25% sizes.  This means I can get practical window layouts easily.

Looks like this kind of idea is included in the Windows 7 window manager.  I suspect OS X users could benefit from something like this too, although Spaces might also act as a a solution to this problem.

See also...

• XP/Vista Virtual Desktop Manager 
• Aerosnap

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.

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.

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

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.

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.

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.

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

• One Laptop per child: A formal sneakernet proposal for the OLPC initiative
• Wired: The real action in music sharing isn't online. It's on foot.

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.

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.

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.

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.

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.