Catalyst Resources Blog

Although clients frequently asked, I generally don't recommend particular cloud computing platforms on which they should build their SaaS. The big 4: Amazon AWS, Google App Engine, Force.com, and Microsoft Azure, as well as many smaller players, all offer scalability, performance, security, and reliability. Some offer more comprehensive and targeted development environments then others. Which one you choose should be based on your own research through the lens or your development resources, estimates of growth and your unique SaaS life-cycle application strategy.

Since choice of platform is as much of a bet-the-farm decision, as designing the right user experience, you should be diligent in your research. To help, we've started a Cloud Computing section in our SaaS Application Design Resource Center, where we try to point you to useful articles. In particular check out this top four article or a more comprehensive list of top providers.

As for high-level recommendations, as you look through these articles and evaluate vendors, consider these issues carefully.

• Portability: Are you locked into the provider once you move your data? Is there an API to integrate with other applications offering value-add opportunities to "re-mix" applications? Is there a proprietary API that ties you to that platform and is the advantage that 'IDE-ness' worth the lock-in?
• Ramp-up time: Do your developers already know the basics of API or development language. If for example, you are a . NET shop already, then there are obvious advantages to working in a .NETplatform. If your developers live and breathe Python, then Google App Engine is worth a look.
• Flexibility: Will the service meet your needs after you roll out v1.0? Does it offer extensibility and integration with other services, enterprise mashups and data sharing? Plan for at least one full release in the future and re-evaluate the service from that angle.
• Multi-tenancy and metadata-based configurability: Do not overlook this. If you are moving to SaaS, you want an infrastructure that supports multi-tenancy - one code base that can be customized via meta-data. Multi-tenant may seem like a philosophical argument, but it is based on simple dollars and cents economics.
• Terms of Service: Can they expel you from their platform if they decide you are competitor or an "inappropriate" business?
• Service Level Agreements: What are their up-time and support guarantees?
• Track record: What is their track record with security? How have they responded to mistakes they have made in the past (and they have all made mistakes).
• User reports: What do other developers say? Other users will give you the lowdown on their experiences without the marketing hype. Use community.

The above list of questions is certainly not comprehensive, but it does give you a begining framework as you evaluate each of the offerings. Catalyst Resources' developers have designed SaaS applications that run on top of each of the major cloud platforms, so we know there is no right or wrong choice overall. It is always specific to your project and growth strategy.

Always keep in mind that the behind the scenes technological infrastructure is only one small part of your SaaS application. Your customers don't care about the underlying hardware or code. They are buying enhancement and improvement of their business, which means you need to focus on streamlining business processes, designing for high value scenarios, maximizing perceived control, and innovating to give people a reason to try your service in a crowded marketplace.

VCs are betting on SaaS

I recently attended a panel discussion "Why SaaS Makes Sense in 2009" with participants from two of the leading VC firms in the Valley, Hummer Winblad and Emergence Capilal. What was clear from the event is that VCs are betting on SaaS and Cloud Computing as the future. This is where the action will be. It mirrors what leading analyst Gartner reports as well as our own experience where more than 80% of all our engagements are now around SaaS strategy and application design.

So if you have an existing solution that uses on-premise software, do you need to replace it now with a SaaS and cloud infrastructure? Yes and No.

Big companies are not likely to re-write core applications any time soon

First lets define what what I mean when I use the term on-premise. In its most basic form this refers to desktop software that was distributed via a company servers using only company infrastructure for hosting, and delivery. Big companies have invested enormous resources in developing the necessary infrastructure and the core on-premise applications and they are not likely to rewrite these anytime soon.

Deliver new services using SaaS and the Cloud

However all companies are continually developing new applications or trying to extend the functionality of their existing services (e.g mobile). This is where they can more easily implement SaaS and take advantage of the cloud infrastructure. For some companies SaaS will supplement their current services, for others it can be the way to deliver completely new applications. On-premise software will continue to exist, but rate of development and deployment of SaaS applications will be higher.

At the point where a on-premise solution becomes technically irrelevant or simply too difficult for a new generation of customers to use or too costly for IT to maintain, companies will have the option to replace it with a cloud infrastructure-based solution and design their application user experience with the SaaS LifeCycle in mind. For some organizations the move will be fast, and for some it will be selective and incremental.

The process of buying a new car offers a good analogy. You aren't too likely to replace your 2007 Mini Cooper with a 2009 Prius. It just doesn't make economic sense. But if one of your family members now needs a car, or your Mini Cooper starts giving you problems, you buy the hybrid.

Don't abandon what works. But start now to extend existing apps.

So the real question is not whether should you abandon your on-premise solution, but rather how can you extend your current applications to take advantage of SaaS or develop new services that are designed as SaaS. Look at SaaS as way to supplement your existing solution, achieve scalability, increase productivity, broaden reach and create competitive differentiation. Just keep in mind that SaaS is more than just a technical delivery model for software; it includes a new business model oriented around service and user experience.

One interesting side-note: While the SaaS model is famously known for being hosted in the Cloud, it is not mandatory that these apps be hosted outside of the firewall. Several large companies are deploying SaaS in-house, gaining the benefits of the SaaS LifeCycle as well as a centrally managed low-power, high-efficiency infrastructure.

You can’t visit a technology or business-related website these days without running into the terms Software as a Service (SaaS ), Cloud Computing, Rich Internet Applications (RIA) or User Experience (Ux). The technologies and best practices that define these terms are evolving rapidly and it is difficult for our clients and potential clients to sift through the burgeoning literature and blogs and find SaaS and UX content that is not filtered through the lens of an infrastructure or service management provider. 

At Catalyst user experience, RIAs and SaaS application design is our full time job.  We routinely work with our clients to define the best strategy for SaaS within their own companies and are constantly following industry trends, learning about the latest technologies and looking out for good ideas.  Since we are tracking what is going on, I thought it would be valuable to our clients and potential clients if we started posting links to the interesting articles, blogs, whitepapers and guides we come across every week.  The SaaS Application Design Resource Center will be a unique place on the net. It is focused specifically on user experience and best practices for SaaS application design, as well as high level strategy and targeted references to cloud infrastructure, and enterprises migrating from on-premise software to SaaS .

We welcome any requests or suggestion you might have for relevant content that we might have missed, or comments about the content we have posted.  Please comment in our blog or send an email send an email

If you've read several of my previous posts, then you already know that one reason Catalyst is unique among SaaS and RIA providers is because of our extensive experience with developing modular and reusable UI. This is a key differentiator on which we hang our hats. We've been developing and refining this approach for more than a decade and have it down to an efficient, and reliable process with very clearly defined deliverables and outcomes.

So what do I mean by when I use the terms modular and reusable when referring to a Catalyst UI project? And why should you care?

Modular = integrated catalog of UI elements and patterns

Modularity refers to the relatively plug-and-play catalog of user-validated UI elements and patterns that are created for your particular application design. So for example, if you need a search component for your application, you would look in your UI catalog and pick out the search functional element. Built into this element is the conceptual model that defines how users understand what it does, the functional definition of what it achieves, the user interface elements, the visual design, and the interaction design.

From your perspective as the developer of the application or provider of the service, you recognize the need for a search element for your project - one that simply works (i.e. is already designed, branded, tested, and user-validated). You find it in your catalog and plug it into your application. You are assured it will achieve the goals of look and feel, intuitiveness and functionality. It's a bit more complicated than the new generations of Legos, but the principal is the same - select components with well-tested, pre-defined functionality that will fit together to build a project.

Levels of Modularity

Modular UI is actually built on several levels:

• Patterns - collections of screens
• Screens - collection of highly functional UI elements (that are themselves stand alone)
• UI controls - the UI elements that are specific to the underlying architecture and Rich Internet Application technology (e.g. Flex, Silverlight, Java, AJAX library)

The Alternative to Modularity

The alternative (and more common) approach to UI design is custom screen-by-screen production. The designer builds screens as they are planned. It certainly is faster to prototype and demo this way. But when it comes to deployment of a scalable RIA or SaaS application that can can be quickly updated or reconfigured and that you know will automatically work, it is essential to spec, user validate, coordinate and develop a component-based interface system.

Reusable = plug the modular UI into new applications or services

If your application is static and what you design in version 1.0 is the way it is going to remain for a long time, then re-usability is not a big issue. But if you are in the SaaS market where release cycles are frequent and where you continually need to add new services and enhance user experience, or you have a suite of applications, then re-usability is of paramount importance.

Re-usabity means that you can take any of your modular elements and plug them into new applications or new screens. The custom-coded UI code and the way it interacts with the backend system is completely re-usable for new screens or functional units.

This re-usability can save development teams up to 85% in application front-end development cycles. For example, if your original service is a general ledger application and then you decide to expand and offer a billing module (because you acquired another company or because market forces moved you in this direction), you will be able to apply the modular UI to this new application without having to develop much if anything anew in term of UI.

Who needs modular and reusable?

Modular and reusable UI are essential components for enterprise applications and scalable SaaS. If you are developing a small, very simple application that is intended to be an unchanging, one-hit wonder, then it will be overkill for you. But if you see your business as eventually growing, expanding, adding new services, and adapting to market conditions, then it rapidly pays off both in terms of making your life easier, getting new products to market faster, and significantly increasing the probabiliy of successful market reception and penetration.

User experience designers all agree on the importance of user interface simplicity, consistency, and performance as keys to successful application design. This is particularly relevant for enterprise SaaS and RIA applications where expectations for "use without training" have been set high by consumer SaaS applications.

But one often overlooked attribute of good user experience design is perceived control. This is surprising because in many ways, a user's feeling of being in control is what defines their perception of simplicity, consistency, performance and even innovation.

Perceived control is a fundamental concept but rarely discussed and even more rarely do I see it implemented as a specific goal in SaaS application design. The basic idea is simple: the more a user feels in control of their software environment, the more satisfied they feel and the more likely they will become loyal repeat users. On the flip side, the more a user feels that they cannot control the software (because of a poorly designed or poorly validated UI), the more likely they will blame it on a "bad" application and seek alternatives.

Predictability, Simplicity, Performance, & Innovation

Designing for consistency is in large part just a way of creating predictability. Predictability is about controlling your environment. The user knows what will happen when they do something - even for the first time. It gives them a feeling of mastery and control, which is critically important to product use and loyalty.

Designing for simplicity is similarly about designing for control. Software feels simple, intuitive and easy to use when it matches a users conceptual model of the world.

Perceived performance is how responsive the computer feels to your actions. When an application forces you to wait for it to catch up (e.g. a spinning clock), you feel like you no longer have immediate control over the application and your environment. Low perceived performance can lead to low satisfaction and high customer churn, High perceived performance makes you feel in control and will result in high customer satisfaction and stability.

Innovation in UI is often in the form of discovering how to increase perceived control. Truly innovative software makes previously difficult tasks, easier to manage and complete.

Examples of applications/products that offer little perceived control: a Comcast digital remote control, Microsoft Word.
Examples of applications/products that offer high perceived control: the iPhone, Google search, many video games.

Design for Perceived Control from the Start

Levels of perceived control of course change as users gain experience with an application. But with SaaS, where it is easy for users to switch to a different service, a UI that creates the perception of control, right from the start, can reduce churn and keep customers coming back month after month.

At Catalyst we spend much of our initial design sprint developing and validating the right conceptual models that make software feel simple. We use RIAs in a way that we can optimize perceived performance. And as a company, we are uniquely focused on designing modular reusable UI which deliver consistency (as well as cutting development costs!). We recognize that perceived control is an essentail factor in user experience design and we regularly assess it in usability and user validation testing, quickly iterating to correct perceived "lack of control".

Every VP of development knows the value of creating a shared library of commonly used functions.  Modularity and reuse are standard practices for most coders and absolutely mandatory for scalable application development. 

But the imperative for modularity in application user interface design (UI) is often overlooked. This is surprising because the presentation layer of any enterprise application is the most frequently updated and often one of the most time-intensive aspect of the development process.

In today’s market, services and software applications need to change as businesses and their competition evolve and shift. This is particularly true for SaaS which inherently is all about the ability to adapt quickly and come out with frequent updates. A Rich Internet Application UI with modular reusable components enables your development teams to implement changes faster and cleaner. This flexibility, simplicity, and adaptability translates to substantive ROI as well as faster time-to-market.

The alternative (and more common) approach to UI design is custom screen-by-screen production. A designer builds screens as they are planned - essentially PhotoShop comps are converted into individually-built Flash or HTML/JavaScript user screens. It certainly is faster to prototype and demo this way. But when it comes to deployment of a scalable SaaS application that can can be quickly reconfigured, it is essential to spec, user validate, coordinate and develop a component-based, modular user interface system.

Developing a modular UI obviously takes more time in the early stages. But the approach pays off very quickly both in time and dollars. A UI library of modular, reusable code, can save distributed development teams up to 85% in application front-end development cycles and makes it much easier to change directions then it would with customized screens. The added benefits include increased consistency of function across applications, a standardized look, easier adherence to regulatory compliance standards and reduced QA time.

For SasS in particular, modular reusable UI is an essential component to profitability and success.

As layoffs mount, consumer confidence drops, and businesses cut back spending, the market for Software as a Service (SaaS) is becoming hyper-competitive with demands for ever shrinking release cycles. It is survival of the fittest where good products can fail as easily as bad, and rapid adaptation is the key to survival.  For companies that offer a SaaS solution, this means focusing design and development on releases that add immediate and significant business value.

Innovating and optimizing user experience is one area where companies can add value without adding lengthy development cycles. SaaS application and UI design can offer enhanced performance, improved application productivity, increased customer engagement,  cost savings through business process reengineering, and enhanced customer loyalty.  At Catalyst we implement SaaS application and user experience design using an agile method with short time-limited sprints (weeks not months). The agile approach is especially relevant in today’s Darwinian-type economy.

What do we mean by Agile

Agile means many things to many people, but for organizations that deliver services through software, agile application design means designing, testing, and implementing iteratively and incrementally, with each stage providing a self-contained deliverable. By developing the application design incrementally, the usability, productivity and real business value of the application can be evaluated during the project rather than waiting until the very end of the project. Agile also implies a people-oriented process that requires working collaboratively with tight feedback loops.

Catalyst application design sprints

Catalyst typically works in sprints of 4-6 weeks.  Each sprint enhances the software application’s market value and adds an increment (sometimes large) in functionality and improvements that can be delivered to the customer. The relative shortness of the sprints improves the transparency of the process and gives the design and development team regular and achievable goals. The shortness also enables us to respond quickly to changing needs or requests from users, stakeholders, or external conditions such as the markets.

Our agile process generally fall into four sprints:

• Sprint 1 - design core modular, reusable UI system
• Sprint 2 - code the reusable elements into a high-fidelity prototype using the selected RIA technology (e.g. Flex, AJAX, Silverlight/.Net)
• Sprint 3 - derive, design and develop all of the application views with production-ready code snippets and a catalog of reusable UI elements
• Sprint 4 - integration support and adaptive refinement

The pressure felt by our clients in today’s market is palpable.  Whether a CIO, VP of development, or development manager,  each needs to justify any SaaS design project with early and frequent wins. A focus on user experience design using agile techniques achieves this with substantive, incremental deliverables and continuous refinement and integration. This methodology for SaaS application design enables companies to get out releases quicker, and be confident that those releases will be well received by existing and new customers.