Posts Tagged ‘functions’

Nice to have! Or not…

The purpose of software development should be increase the product value, in other words make it more useful and worth more to stakeholders. But in the urge to improve and to increase the number of features causes, as I guess everyone knows, usability problems. Microsoft Office is a typical example of this. Microsoft has struggled since the early 1990’s to get a decent UI for all these features that probably just a minority of the users really wants. Besides the problems with including these nice to have that a minority wants is that time is spent on this, instead of what people really need. In other words, a system can be very complicated and complex without solving the user’s problem.

An example of this was when a customer had a system with a very complex state machine. The users struggled with it, it created problems testing the system (since all the states needed testing in all clients and for all situations). When looking at the previous version, I could see that the state machine was very simple, so I asked why they’d made it so complicated. The reason was that they wanted to support that customer’s signed an order before invoicing, so the customer knew what they would be billed in advance. But  this is not possible with the current state machine. They’d spent all that money, made the system too complex for users and coming development and testing and the thing would still not do what the customer really wanted.

The picture below is worth thought:

Source: Windows Mobile – No Secret

Categories: Agile, Business Tags: ,

Graphical UI does not bring out the best in you?

Guides, wizard, drag and drop functionality. You can call it many things but the principle is a graphical guide which aid users to complete the process of completing a task. Most commonly, the tasks can be performed individually, but then the user need to know which functions to use and in which order the functions are used.

I guess you like those functionalities or you hate them. Two of the reasons for me avoiding guides (for example the Planning Wizard in Microsoft Project is the first thing I disable when working a new client) is mainly:

  • I hate dialog boxes and pop-ups and most implementations include those artifacts. I’m not really that good at reading the instructions so I do what I guess is a common thread in user interaction: I try to select the option which will get rid of the dialog boxes at the fastest pace.
  • Wizards and guides seldom works well with the UNDO command. If I select Undo, do I undo the last step in the guide or the complete process? Many applications solve this by disabling undo after a guide or wizard has been used.

Justin Etheredge points at another huge disadvantage: you will not really know how that process works, which steps are needed and why. This means that you cannot change or edit the things the guide helped you create. Justin uses programming as an example, or more correctly, he discusses the efficiency effects of using this kind of UI in programming. But the discussion is of course important in all systems: are you optimizing for the new user or the advanced? This is not a question which you can say that you should always build for the seasoned user. Being in the seldom buys business, there is a majority of users who buy once or twice a year. So, what they learned from their previous buy, they’ve probably forgotten by now. And chances are that the system has changed since their previous visit.


Clowns can be quite scary for “new users”. So, if you’re planning a party, are you aiming for the new users (the smallest), this might not give them a pleasing experience. Clowns are probably more suitable for the seasoned users (older kids). What about the advanced users (the parents)? Well that depend on how much they need to assist the less experienced users (Small, scared, screaming kids).

Categories: Usability Tags: ,