A few decades ago, business software was typically housed in a mainframe computer so gigantic that it needed its own office. As smaller central processing units were developed in the 1990s, software systems migrated to desktop computers, each one representing an individual installation requiring periodic updates with floppy disks. Then came the Web, and everyone said, That’s it! A web browser is the way to distribute software—that will work! And it does.

Businesses are quickly adopting software as a service (SaaS)—software called down from the Internet on demand. Cloud computing can be a highly cost-effective way to license tools for basic business operations such as sales, accounting, and HR. But cloud-based systems can cause considerable confusion because many of these fluid new systems are organized in a way that’s as amorphous and as transitory as a cumulus formation.

Recently one of my clients and I had a conversation with a sales rep for an SaaS product who explained that since his company has moved its application to the cloud, all their concerns about design and usability have vanished. They reason that because they have the technology to make updates to the software’s user interface as frequently as they like, they can tweak the product as user complaints filter in, almost in real time. I keep thinking that this is like a homeowner who has just discovered a patching compound for his leaky roof—a product that allows him to quickly paint over a crack whenever a drip appears on the ceiling.

Back in the day, developers would ask their customers to evaluate their products, and when members of a user group reported that they disliked 20 different things about a system, developers would spend months monkeying with the system and guessing at what to deliver to the desktops as an upgrade. In the cloud, developers can tweak the software and issue a new release in a cycle of 24 hours. There’s almost nothing analogous to a product with such a fast production cycle.

But God help the users! What we have now are tools that are constantly being reshaped, often without rigorous testing or a comprehensive design to show how today’s update will affect tomorrow’s plan.  When I hear development shops say, We can update the software every day! I wonder, How can you possibly be producing a coherent product? Even with the world’s best coders, no software product will hang together in a cohesive way without a design that provides a framework to predict the impact of each modification.

Every software developer tests its products, sometimes by using other software and sometimes by having developers just bang against it to see if it works. The question is, How rigorous is the testing process, and what does it actually test? Does the test confirm that the update works, or does it confirm that the update will provide a better way for people to work?

Updates also need to be documented. Recording what was done, and why, is very important because an explanation of what was done last week enables you to understand that the way you feel about it this week may not be a good reason to change it. Documentation also prevents software from developing eccentricities that become inexplicable: Why was that change made? Why does this thing work this way? In the cloud, where there’s an opportunity for instant updates, there’s a temptation to write down fewer things because that slows the process.

For all the opportunities that this new platform affords technologists, there’s no escaping the need for a plan and the importance of design, testing, and documentation. A plan isn’t expensive and won’t defeat the flexibility of a system; in fact, it will make that flexibility more valuable because it provides it with a framework. When software is designed and built according to a plan, input from the field can be compared against models both current and future, threaded into the model as appropriate, and used to demonstrate the impact of updates before making those changes.

With every leap of technology we tend to believe that the innovation will create a better experience for the user, and in some sense this has happened—now I don’t need to sit at my desk and update software with floppy disks. Yet when it comes to the design of how one interacts with these “cloud” apps, things aren’t much better.

The ability to make constant changes to these products is no substitute for a designer’s planning process. Without that process, the result is just another unusable compilation of features and functions—but now these assemblages are being built in a matter of days rather than years. Talk about a missed opportunity for planning! But I guess that’s the risk when your head’s in the cloud.

Read about a few questions to ask vendors before you sign your next software license.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

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.