Usability Issues When Integrating Systems

Sometimes it is necessary for us to integrate our software with another system in order to offer its features to our customers, in fact a new class of applications has emerged where separate systems are created from integrating other products – the ‘mashup’. Allowing a user to take advantage of another system from within your application presents a number of problems that can impact on the usability of the software you deliver.

The other system was written by different team of people. Any team working towards a common goal becomes a microcosm and develops its own way of doing things. This is likely to differ from yours. Sometimes, the differences are small things such as international date conventions (dd/mm/yyyy vs. mm/dd/yyyy) or maybe your application saves a user’s work automatically whereas theirs requires a save button click to commit changes. Unfortunately, these seemingly minor inconsistencies add up and have a huge impact on the overall usability of the product.

If you tightly integrate the external system, your users will be unaware of where your product ends and the other starts. Actually, they wont care; they’ll just be angry that it behaves differently in different places and they keep making mistakes.

So, what can you do to mitigate these issues?

Don’t integrate the front end

When the opportunity presents itself, by far the best approach is to write a new user interface from scratch for the system you are integrating – following your own standard conventions. This gives you an opportunity to make the experience completely seamless; taking advantage of the other system’s tried and tested business logic without compromising the user’s experience. Of course, this is not always possible, you can’t easily replace the interface of something like Google Maps – it’s simply too visually focussed, alternatively, you simply may not have the skills in house to do so. In these cases one of the below approaches must suffice.

Act as a Portal

If rewriting is not an option, consider only partially integrating the systems. Perhaps you can connect behind the scenes to display some ‘totals’ or other summary information but defer to the other application for the detailed view or for making edits. For example, if you wanted your application to integrate with a finance system; rather than embedding ways to create orders and invoices etc. simply retrieve the totals so that this information is available in context, but then redirect to the finance system to view order line details or create new invoices. This approach has the following benefits:

  • It cuts down your work and reduces the chances that you’ll introduce any inconsistencies
  • It lets the user perform the external task quickly in a, possibly familiar, tool designed explicitly for the task
  • They won’t have to learn your implementation
  • You still get the benefits of showing some data in context with your application
  • You just integrate the features that really matter

You’re not in Kansas anymore

Sometimes you are stuck in the awkward position of not having the time or resources to rewrite the entire interface and a partial integration effort is not sufficient. Unless the external system fits in well with the rest of your application, the best approach is to not pretend that it is a part of a whole. Make the integrated features look like they came from somewhere else (maybe even going so far as to say so?). If the user is aware that the functionality they are using is from another vendor they will be much more forgiving of any inconsistencies – they will almost expect them.

If you take just one thing away from this, remember don’t integrate the look without the feel!

A Cautionary Note

Whenever you integrate another application’s functionality, by definition, you are expanding the scope of your own. Ask yourself if this is wise. Make sure the user will gain something from the integration – your application doesn’t need to do everything, it’s fine for them to go to another application! You will be positioning yourself as the focus of any bug reports and complaints for a component that you may have little or no control over.

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
This entry was posted in Tutorials and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *