What does make CRM software user-friendly?

In almost all ITTs I have helped with, the client has asked that “the database software must be user-friendly”. But what does that really mean? Is it such a personal thing that no database package can ever be fully user-friendly for all users? And who should it be user-friendly for? Just the end-user or the database manager/technical staff as well? Can we really define user-friendly? Well, I’ve seen a few CRM packages in my time, the good, the bad and the really ugly, so these are my top requirements for user-friendly database software:

• Screen layout

o       This is generally what people think of when they mean user-friendly. Clearly, screens (forms) should not be too busy - don’t cram fields together on one screen, keep it ‘clean’, keep common fields together on one screen/tab, don’t use really small fonts. It’s all common sense but unfortunately it isn’t always that common.

o       Screens should ideally be customisable for different users/types of users. This can really help: why would the DM manager want to see the same fields or menu items as the volunteer assistant? And no end-user wants to see all the hundreds of icons which the database manager needs to see, so don’t display them to such users.

o       List columns can be changed by users using click-and-drag. A very specific point, but databases inevitably have lots of forms with lists of records and ‘one to many’ type entities (which when clicked on, show much more information behind them); so if a user themselves can simply change what is important to them on such lists, and continually change that if their requirements change, then that can really help user-acceptance.

o       Not a clunky look-and-feel. Okay, that’s hard to measure and a little obvious but I have seen some dreadfully clunky systems even in the last few years and there is nothing more off-putting as a first impression.

• Overall navigation

o       Standardisation and familiarisation. There is little reason not to use a standard approach for the look-and-feel of a package’s general navigation. Whether it’s the familiar Windows/Mac environment, an “Outlook look-and-feel” (e.g. MS CRM), the use of browser/hyperlinks, good use of double-clicks, and increasingly, the ability to click-and-drag a la Google maps/finance graphs etc.

o       Consistency across the whole package. Please!

o       The ability to add ‘bookmarks/favourites’ (as per web browsers) so that, rather than having to remember which 4 clicks are needed to get somewhere, common functions and records can be accessed from a user’s front/home screen – especially on feature-rich databases and those with multiple screens and icons.

• Customisable terminology. Users love to see terminology they are used to. They don’t want a field which says ‘region’ if their organisation uses ‘areas’. They don’t want a ‘donor analysis & performance report’ if they run weekly ‘donor update’ reports. There are limits, of course, and packages are still packages, but the more an organisation’s own terminology and language can be used, the more user-acceptance you are likely to get.

• Automation: automating tasks can be extremely beneficial. Mostly in processes (e.g. when sending a mailshot, the ability to do the mail merge and update the communication history on a donor’s record – all using one click), but also in terms of data integrity; if you enter ‘Mr’ on a supporter’s record, then surely the gender should be ‘Male’.

• Simplicity when creating queries/reports. This is one area where the trade-off between sophistication and simplicity may be difficult. It should be possible to use a GUI to create simple ‘list’ type reports, and I like the ability to make reports parameter-driven so that a user can learn how to use just one report but run it against multiple sets of records or for multiple scenarios. But when it comes to more sophisticated requirements, there is no getting away from the fact that a report needs to be created by an experienced/database-savvy individual – but hopefully they can make that available as a simple report for the end-users. No SQL for end-users, please.

• Intuitive. This is the second-most common request by organisations, that the software “must be intuitive”. But this is so different for different types of people, for different levels of skills, for people with different experience of databases and so on. I would say that if much of the above can be met, then the intuitiveness of the software should follow. But that doesn’t mean you won’t need training…

• Other points:

o       Simple integration with other packages: Word, Excel etc. Yes, great. One-click to make a report into a Word or PDF document; right-click to export to Excel.

o       Speed? A lightning fast database won’t make the software automatically user-friendly, but a slow database sure can make it feel unfriendly.

o       Easy to update. One for the technical guys and support staff (and implicitly the end-users): if software updates can be centrally deployed rather than having to go round each PC with a CD…

o       Small, specific features can really help. Just a few examples: the ability to drill-down in reports (to further levels of the report or even into supporter records), predictive text on drop-down fields, simple moving between records/opening multiple records at the same time, colour coding for specific records/statuses. I’m sure you can think of others. 

o       Help screens? Even better if they are customisable by a client. Good error messages?

It is interesting that when considering much of the above, one does need to consider the pay-off/difference of user friendliness for end-users as opposed to database managers/the technical staff. It may take a database manager some time to make the database terminology correct for their organisation but it will help the end-users enormously; they may need to create multiple versions of a form for different groups of users, but it should cut down on their support calls. 

And what of the future? Is the iPhone generation going to change the way CRM databases can be used? Is touch-screen the future? Or voice control?! Basically, if the software is simple (okay, that’s still subjective), customisable and follows standards then that’s a good start, and our desire to minimise everything to the size of a mobile phone should still reflect that.