SaaS Design Principle: Easy to Use

This is the forth post in a series on SaaS design principles. This post follows on from the principle described here.

Let’s imagine the following scenario:

Sue is a corporate user of a corporate system to record soil samples for possible toxins. She’s happy that she can use the system now as it took the IT department 6 weeks to issue her with the login. But she’s in the field a lot collecting samples and can only access the application when she’s logged on to the corporate network. As such she makes a point of being in the office on at the end of the month so that she can update it using the data she took in the field. However, this always takes longer than expected as to find out where where the data should be entered is difficult. 

Her boss is also not happy, as her staff are late in entering the data and skip lots of the information that she needs for reporting. 

 Both of these would leap at chance to use a SaaS solution that was, for them, easy to use. This is usually seen as a threat to corporate IT (see this article as an example of this meme). But if you have a easy to use soil sample application (or can build one), this could be the opening of a new market (I have no idea if soil sampling has any market potential, but if you do this and think so then good luck).

The emphasis here is on “easy to use”. Over on this video, Micheal King talks about the implications of difficult to use applications and how this lowers the adoption rate. Although the focus is on BYOD and mobility, it also applies the same to any SaaS application you are trying to create (Bring Your Own App?). The difference is that you are now providing that service (rather than being an IT department threatened by it) and as such have the accept the market reality.

This leads us to our next principle:

The service provided should be easy to access and use over a number of devices.

For any business wanting to develop SaaS offering, careful thinking has to be given to how the user interface is designed from both the technical and usability aspects. This is often something that is not really done well when developing internal IT.

So what are the issues that need to considered?



Device characteristics. Architecting an easy to use SaaS application means that you have to take into account and use the standard user interface functionality provided by the end device. This could be a browser, a mobile browser or a device specific user interfaces (e.g. an App). The architect needs to make the decision if a standard based approach is adopted (e.g. HTML5) so that the user interface functions on a wide range of devices, or if the native user interfaces are used, giving the user a more familiar experience, but with the increased cost of developing and supporting a range of devices. The amount of device screen real estate available is also an important issue.. This goes up with bigger screens, down with smartphones, up again with tablets, down again with mini-tablets. You have to take them all into account.

Interaction Styles. You have to cater for a variety interaction style that the end devices use, e.g.

• Mouse vs. touch screens. How long this dichotomy will last I don’t know, but I have the suspicion that mouse based interfaces will take a long time to die out. 
• Navigation through the application. The typical paradigms used for navigating a smartphone app are different to those used for a desktop application. 

Diverse Users.Typically not considered in enterprise applications, but important for SaaS offerings is that users can be from anywhere on the planet. This potential cultural diversity has to be taken into account so that the SaaS offering remains easy to use no matter where the user comes from. On-Boarding. The principle also talks about easy access. Having a marvelous UI that you can’t get at defeats (literally) the principle. As such allowing users to quickly on-board is important. However, for business applications this is more than just allowing a login with, for instance a Google account and a credit card number. You need to have thought out (both in your business model and the SaaS architecture) how can let users be associated with organisations, especially as you need to consider the basic SaaS principle of multi-tenancy and also the collaboration ideas described in previous posts.

On-Boarding. The principle also talks about easy access. Having a marvelous UI that you can’t get at defeats (literally) the principle. As such allowing users to quickly on-board is important. However, for business applications this is more than just allowing a login with, for instance a Google account and a credit card number. You need to have thought out (both in your business model and the SaaS architecture) how can users be associated with organisations, especially as you need to consider the basic SaaS tenant of multi-tenancy.

Handling these different aspects without rewriting the whole user interface code for each type of device and user requires some nifty architectural design or you find a framework that can do this (or some of it) for you.