A friend of mine has a problem - his team worked for months on a big system with great success, marvellous technical achievements and a very elegant architecture. However, the users don’t share his enthusiasm. They don’t appreciate the architecture, flexibility and openness to change. Somehow, they seem ‘blinded by the user interface’. Although the statement is completely correct, it’s hardly something that developers should be moaning about - on the end, ‘user interface’ is called like that because it is exactly what users see. Instead of complaining how users only see ‘the stupid UI’, we can embrace that fact and improve their feelings about our software.

Developers tend to over-emphasise functional aspects, underlying structure and technical achievements. But users are blind to that - they only see what the software does, not how. Most users are only concerned about how the software will help them get their regular job done, and how pleasant it will be to work with. For them, the underlying structure, service layers and database optimisations exist somewhere over the rainbow…

Restaurant chefs have learned this lesson a long time ago – a great meal tastes excellent, but it opens your appetite with the first look, not the first bite. Although the real value of the meal is in it’s taste, the visual impression is also very important. A tasty meal looking like a mess might even disgust me, and if it was not in a restaurant I know and respect, I might just get up and leave. On the other hand, I will surely take a few bites of a nice looking meal, but if the taste is not there, I’ll eat something else. A great meal has to have both components.

It’s the same with winning software solutions – they must have both the functions and the looks. It is incredible how much a few polishing touches can improve the customer’s perception of software and the team.

The image that sold the system

My first encounter with this phenomenon was six years ago, while I worked on an energy-trading software system. Electrical energy trading is somewhat strange, as the current goes where physical laws govern, but traders set their own abstractions for ‘transiting’ and ‘trade’. There is no warehousing, and if you are a middle-man, what you buy must match what you sell at any given time, and buy/sell contracts are coordinated and matched by various network operators on 15 or 60 minute levels. One of the key selling points of our software was automation of the transit planning – which would save our clients a lot of effort and money, because they were doing it manually at the time. It took us a few months just to come up with mathematical models for an optimisation algorithm, merging few existing network-flow optimisations and adding some ideas of our own. Then, we spent a month or two developing software which would read the trading plans and network limits, find the optimal transit plan and present it in a 15 minute breakdown table. Traders would then verify the plan and the software would send it to appropriate network operators. As a quick check tool, we developed a graphical display of suggested transit routes, and used it to see visually whether the optimised routes made sense. Just for the fun, we polished that code and added it to the GUI client, putting a map of Europe under the plotted lines. My boss, at the time, was complaining about how we were wasting time on silly eye-candy when we should be working on the real stuff.

When we presented the system to the clients, their top-management attended the meeting along with leading traders. Very proud of our new algorithm, both in terms of the mathematical model and light-speed implementation, we talked a lot about all the boring details (I’m pretty sure we could have given them a sedative and achieved the same effect, as they all were all sleeping). On the end, when I pushed the Optimise button, and Europe with red, blue and yellow lines came up on the screen, they all suddenly woke up with faces reminding me of a child getting a new toy. One of the leading traders shouted something like ‘This is great, it’s going to make my work so much easier!’. Like a fool, I thought that they were thrilled by how the process finished in a few seconds, and continued talking about the resulting table and the algorithm. But the trader interrupted me – ‘I’m not talking about the table – this map is fabulous… I’ve never been able to see my plans that way.’ Everything before and after that moment did not matter, they ‘loved it’. That single feature, developed in less that 8 hours, sold the software on the end, and we could have given them a faulty model with the same success.

Of course, the real value of the system was in the way it correctly and swiftly managed tons of data to produce an optimal transit map. But all they were talking about was the silly map. Imagine my anger - we could have spent those months playing games and I guarantee that the silly map would still sell the software (not that it would do much good later).

Improving the view

If the clients are not very technical, they will only see the GUI - so let’s give them something nice to see. If the GUI is not polished, from my experience it’s best to delay the project for a few days to clean it up, even if the clients are screaming to get it ASAP. It may sound against common sense, but in practice it works great. Sprinting to add raw, unpolished functionality almost never pays off, and it can blow up in your face. Putting a bit of eye-candy into the project can really help with first impressions, and it’s incredible how much a few days of polishing can improve the customer perception. I’ve worked with clients that have a very good understanding of what goes on under the hub, but these are an exception rather than a rule. Most cannot see trough the visual interface, so the functionality is really not that important to them as long as it does the job. And, even those with technical background will also appreciate a nice GUI, so polishing the user interface is time well spent in any case.

Even if you do not have the budget to pay professional designers, the software does not have to be grey and ugly.

On the end, as a technical person, I found that it’s best not to assume that I know what is pleasing to the eye – and there is a useful trick picked up - ask for examples instead. Especially if the layout is critical for the customers, ask them to find examples of similar applications or web sites they like on the Internet - beauty really is in the eye of the beholder.