Jan 31 2007
Blinded by the user interface
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.
- free (opensource) web layouts can be downloaded www.oswd.org or www.openwebdesign.org
- royalty-free photographs and images can be found on www.sxc.hu (check out this list of alternative sites with royalty-free pictures)
- Linux desktop projects like KDE and Gnome have libraries of free icons, and the Internet is full of sites offering free icon libraries (for example, a good free icon library can be downloaded from sweetie.sublink.ca or www.intersmash.com/300images) - just Google for free icons.
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 I 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.
Image credits: Danzo08 and JMDodge/SXC
Add to Del.Icio.Us bookmarks
Had a similar experience when doing a major redesign of the (large corporate) website I manage. We made major back-end changes that greatly automated content production; came up with a completely new information architecture; did a graphic redesign; and rewrote hundreds of pages of content. As an afterthought, I also decided to add a ‘font-size’ widget, allowing users to click ‘+’ and ‘-’ signs to change the font size.
Well, you can see how this one ends. I gave a presentation to our board of directors — mostly older people for whom small fonts on the web are a major irritant. They nodded politely through most of my presentation; but when I showed them the font widget, I got audible oohs and ahhs. That one minor feature “made” the redesign, as far as they were concerned, and they enthusiastically approved the whole shebang.
But I don’t think any of the thousands of hours of work we put into content, IA and back-end improvements really registered with them — it was that one little widget.
I maintain IconsReview.com, a large list of icon collections (both free, are commercial). The list is at:
http://www.iconsreview.com/
NOTE: I do NOT sell any of the icons myself, I just maintain the list.
As a programmer, I definitely find it frustrating when I have slaved for days and days over a complicated problem and finally created a feature that will make a task for the user much easier only to hear something like “why is there a blue line separating those paragraphs?”. I do understand the need for a user interface that is useful to the end user. I wish I had a good eye for design but I don’t so I try to keep things clean and simple. Easier said than done but I see so many websites cluttered up with so much data that you can’t find anything you need.
Just don’t go too far the wrong way. I’ve been in situations where people wanted to overdevelop the UI to the point where it would have been severely intrusive. People would not have been able to complete everyday tasks without enduring a series of flashing lights and animations. The look may well be what sells a product at first but the results are what makes a customer happy at the end of the day.
When developing our internal applications I always prototype the UI first. Once I have sign-off on the presented “functionality” I make it work. This is in part because our specs from project managers/proposers are typically nothing more then a few paragraphs and of no help. Regardless, I’ve found the process a very efficient way of determining what the users actually need before wasting time writing functionality they’ll never use.
As someone who has spent 18 years integrating Geographic Information Systems with business systems I can totally relate to your experience. One of my favourite memories however is of trying to rush through a 30 minute software presentation in five minutes because the client was late for another meeting. As he was getting up to leave I quickly brought up the unfinished splash screen to confirm the size and position of the logo. An hour later we were still sitting together modifying and perfecting this screen.
The arguments for and against prototyping screens early have been around for ever. Although I have always been a fan of the practise I have found it can also backfire because they focus everybody on screen design rather than required functionality. I still recommend UI prototyping however only after the required functionality has been established with Fit/FitNesse.
A guest lecturer one said: the UI prototype should be as ugly as possible. Make it look ugly. The worst you are drawing, the better. Why? because then people focus on things like where things should be, and if the navigation makes sense, instead of discussing for one hour if the button on the left should be blue or green, or maybe orange. When you show nice UI interfaces that look finished, people would focus on small, uninmportant (at this stage) details, and even worse, they will think that it’s almost finished (looks finished, right?) so they will expect to have it up and running in a few hours.
Rafa -
The UI prototype should be as ugly as possible? I don’t think that would work. If you’re at the stage where you’re scribbling on a whiteboard, that’s fine (i.e., you won’t *make* it ugly, but people won’t get hung up on the fonts and so on).
But once you are showing them a UI, they *will* focus on that. They will have trouble getting past the green/orange buttons, because they want to be sure the final application looks professional. Your really ugly mockup will just make them think you aren’t a good developer, unfortunately.
Basically, I tend to design initial navigation & layout based on research into their existing workflow and requirements, interviewing people *without* a real UI first (then only whiteboard drawings). Once I show them a UI, it will look good if at all possible, and we’ll go back to walking them through the use cases to tweak them and flush out more requirements.
Telling them not to focus on the UI simply doesn’t work — once it’s there, it’s by far the most tangible aspect of the application, and they’ll want to talk about it. (That, and somehow input validation and field sizes seem to take inordinately high priority…).
I agree that a “finished” looking UI will require you to adjust their expectations somewhat — you’ll have to spend some time going over the effort remaining, time estimates, etc. — but this is far easier than spending 2 hours talking about the buttons.