Personalization in web applications (part 1)
All of them are willing to invest on re-building their traditional applications and re-launching them either with the same name (“web version now available”) or as a whole new product offering.
If you think hard enough you will find that there is a quite big list of things that you could do in order to provide personalization capabilities to the end user. Color schemes are a nice example: When an error occurs, you usually pop up a red error message, because red is the color that draws attention. Recently, though, I had a customer of mine saying “what is this red thing up there? Make it purple. Red is a very offensive color selection”. This guy had a clear view that the error messages should not appear so damn irritating to the end-users. It’s like yelling at them!
Put simple, I would like to be given the option to change my color schemes, depending on my mood of the minute. I must be given the opportunity to put my company’s logo at the web form, even if I’m working on a multi-tenant SaaS system. And that “Times Roman” font? I hate it!
I am sure that you (software developer) have thought very hard on how your application’s menus should be structured. But there is one thing that you don’t know, for sure. And this is my job. I have specific tasks to complete, executed in a specific order. When a problem arises I have a check list to follow and resolve the issue. And for that (and many more reasons) I would like to be given the opportunity to build my own menus. I’d like to have “new customer” and “new ticket” in my CRM, side by side.
Therefore, ability to customize menus and also include “fast paths” to some critical clicks is a nice feature.
Also, ability to preselect some options for myself is also a time-saver. If I operate in a cashier position, I use the “payment receipt” more often than anything else. So, prompt me this option as a default selection and save me some clicks…
Any business transaction includes a number (larger or smaller) of workflow steps. Modern perception of a business transaction is that one is not completed by its own self; a series of things must happen in order to complete a business transaction. Take for example the approval of a leave-of-absence: It is not enough to “enter” an absence application; it has to be pre-approved by your supervisor and then approved by your manager... I am sure that your company does not approve leaves of absence the same way that mine does… Therefore, a workflow must be customizable by the user. This is a statement that is often self-evident (take for example the loan application for a Banking institution. You cannot talk about an application system, if you don’t have a customizable workflow), but not always. You can find a number of business transactions that have been broken down to small pieces and nowadays they have been standardized (like, say, a warehouse purchase order). So, you may find a number of software packages that offer the “purchasing workflow” right out of the box. Still, again, in my humble opinion, there is no such thing as a workflow “written in stone”. There will always be a new case or an exception to the rule.
It is very probable that a user executes a large number of transactions every day. It is also logical to assume that he enters some “screens” of the system more often than others. If the business application that they are using is quite extensive, with lots of menus, clicks, icons etc. then it is probable that this “busy bee” is lost somewhere in the middle. I can say this for myself: I build applications for quite some time now and I always grant myself all authorities. I execute complex test scenarios and after a while I find myself lost in the series of actions that I executed. But in a web-based system, “all” actions are being done through web pages. Therefore, I would love to have a log of pages that I’ve recently visited. I didn’t have it (so I built it!).
A recent visits log can also be of great use to new, inexperienced users. If they lose their “way home”, they can use this feature to get back in track.
Let alone the fact that it can also serve as a tool for the Support Team to track a user’s path, in case of error handling or bug reporting…
A variant of that it the “fast path menu”, which is not a brand new idea. Older applications had a feature like this. It is also very common in web-banking applications. And it is always welcome. You will find it (usually at the top-right corner of the page!).
All of the above are features that will add points to your applications and to the end-user’s experience. Stay tuned for more examples and ideas, in the next post.