Business application UI design

19 02 2010

Now this is my first post on this topic (I am sure many more will follow), and I want to talk about some fundamentals with user interfaces within business applications. More importantly, I want to distinguish between UI that looks great in a demonstration, and UI that is great to use…Trust me, they are not the same thing…

Traditional business UI and poor design – it’s not good

When presenting your business application, the first thing it is judged on is the way it looks. It’s a simple fact, if it looks awful then people just aren’t going to love your application even if it’s by far and away the best thing out there in terms of functionality. It’s also worth remembering, that a poor UI will slow down users actually using the system, which is never good – it leads to lost time, poor efficiency, poor views on the system and ultimately frustration.

Typically, business applications UI are functional, and nothing more. All the fields the user needs to access are shown (hopefully in logical places) and the screen is often that lovely grey colour. There is nothing “flash” about traditional business application UI, however, functionality is no excuse for not delivering a great end user experience. This is something that is becoming increasingly more important with business applications – and one of the reasons is probably because of the wide spread use of websites that look great…

UI that presents well, but is it great to use

With WPF and “richer” UI environments (we can include Silverlight in here), UI design for business applications can really add value to the user experience. Screens can become more user friendly, intuitive to use and give the user greater feedback and guidance. However, you can take a good thing too far – and this is something that I have started to see quite a bit of…

Because as designers and developers we have the tools to create something that really has “wow” factor, should we? There is a time and a place – and it is key here to remember what the actual use of the system is, how often users will be using the system (or just screens), how experienced users are and how quickly they can complete their tasks. Let’s look at a real basic example:

Let’s look at searching for a customer’s record. Now I have seen some great and out of the box ways in doing this. Some include browsing and dragging cabinets and records around to allow us to navigate our way to the record / search areas of a system. Others use carousels that act as a “wizard”, with each selection bringing a new set of carousel options (identifying customer type, then account type etc before providing a search screen)…These demonstrate great, they will knock the socks off of the directors and you are a winner….You have put together something different, something that’s intuitive, and something that looks great. Well done…

However, lets now look at this in the real world…I have a user who wants to search for a customer quickly; they may even have the customer on the end of the phone. So is dragging objects around to build a search, or navigate to a search a great idea? Or will they find this restrictive, slow and ultimately frustrating?

Just because we have the tools to build “wow” UI and animations – we shouldn’t feel we have to use them and businesses shouldn’t expect them to be included either…

UI that demonstrates well, but is great to use…

This is where we need to get to. UI that is operationally great – it allows users to work quickly and efficiently and the bells and whistles that are available with WPF, Silverlight etc used to aide in the user experience and bring real value to screens.

Let’s look at our customer record search. We could have a UI that contains a shortcut key to a search panel, which could be slid onto our screen from within any other screen / module. The user can enter some quick key information and be presented in a new tab with search results…The user has in a couple of key strokes called up a search, and found the customer. They can now get on with servicing the customer’s request and then back to whatever task they were working on before. Now this doesn’t look half as flash as our earlier UI, however, it looks good and the use of the “bells and whistles” has added to the system functionality wise – as well as to the user experience.



We have to remember how the user works when designing screens – something that can be lost when going through requirements and what could look / demonstrate great. If your user needs to work quickly, or spends a lot of time in certain screens, then you still can’t beat short-cut keys and use of a keyboard. Touch can help but ultimately, navigating through great graphical based interfaces can be slow and frustrating…Flash new developer and design tools are there to help, and should be used when needed, not for the sake of using them…

For business applications the design rules should still be, “what works quickly for the user” and then, “how can we make that look and feel better”…



2 responses

19 02 2010
Max J. Pucher

A GUI that is easy to use is one that the user can easily customize to his liking and needs himself. I am nto jsut tallking about fonts sizes or colors. A programmer will never understand or outhink all possible users.

So the problem is in the concept of GUI design and then PROGRAMMING it. Standardization and a one-size-fits-all process, app and GUI strategy has been the biggest productivity killer. It really does not matter at all if they are implemented in Java, Ajax, Flash or Silverlight. Or COBOL for that matter …

19 02 2010
Andrew Smith @onedegree

As lovely as that sounds that isnt practicle. You cant let users change the way basic structures work, such as navigating into a particular module, how a user moves through a particular screen or process. Customising screens is great, and yes, lets promote that and allow them to custimse “layout”, location of content and look and feel. But this should not be confused with how the user actually interacts with the screen to get their work done..This has to be put together at design time and is really what I am driving at with this post…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: