No matter how you cut it, an assembly of displays presenting data and application features represents a product. As a product, SaaS (Software as a Service) applications possess a certain physical form that either enhances or inhibits a human end user’s ability to perform a certain task.
A SaaS product is a piece of software that end users purchase access to, rather than purchase to install on their computer. A wildly successful example is Salesforce.com-a software tool that allows a company’s sales professionals access to Saleforces’ features and functions, and the company’s own sales data wherever there is an internet connection. This means salespeople who are on the road most of the time can update the company’s sales data real-time from the road. It also means that the company no longer has to wrestle with software upgrades and data integrity issues related to individual physical computers (e.g., salespeople updating files once they are back in the office).
“We’re running a SaaS model now, so changing the product’s user interface is a snap. We can change it every day if we need to. So we don’t have to worry about usability problems anymore.”
This evolutionary quality is a welcome change for software companies whose previous product release schedules were plagued by missed release dates and grandiose unveilings that often disappointed customers. SaaS applications can be updated incrementally and deliver new features and user interface designs to end users whenever they log in. This capability has given some folks in the SaaS world the impression that these products are immune from the usability and user adoption problems that plagued their browser-based and client-server predecessors. Unless design and design process drive the evolutionary changes of products, changes may keep genuine innovation and improvement from being a reality in this new world.
Once again, it sounds like a new technological capability is being mistaken for design and design process-things that are painfully rare in the software world.
August 27, 2009 at 9:32 am
Robert E. Bershad
One advantage to non-SaaS applications is that users are (presumably) notified of interface changes when they update their local drives or through unveilings.
That notice advantage is not inherent to SaaS applications because interface changes do not require individual user action.
Part of the SaaS design process should determine how best to notify the user of any interface changes, and how the changes affect the application’s functionality.
July 26, 2009 at 1:57 pm
Moti Levi
The difference between easily done and well done is indeed a critical one. Often, technical people (programmers, engineers, etc.) confuse the two as they think that if it easier to do something (change design) it necessarily means it is better (mistake 1) and leads to better design (mistake 2).
Mistake #1 is that making things easier does not automatically means things are better – it depends on the stakeholder, and the implications of ease of doing things. Sometimes, when changes are not easy, it means that spurious changes would be avoided. And from a user’s perspective, there’s a balance between size and frequency of change. The developer prefers gradual incremental changes but users may suffer from too many changes coming at them too fast.
Of course, the underlying assumption in “easier=better” is that changes are always better. But many instances have shown users to object and reject such “better” changes (e.g. facebook).
Therefore, ease of change requires even a stronger (better) design process because inherently it allows for less consideration in making changes.