SaaS Blog Posts

In Part I of this two part blog series, I talked about the need to look for climate change energy adaptation technology that can reduce demand for electricity while we bring (or in lieu of bringing) replacement clean energy technology online. There are a number of very viable solutions that address this on a technological level including:

• Energy management and reporting software to identify and prioritize energy management issues, operate critical energy endpoints at optimal efficiency levels and validate investment decisions
• Building information management (BIM) systems to design for and monitor energy efficiency/maintenance
• Demand Response control system that optimize visibility into and analysis of mission-critical energy information along with reporting interfaces that communicate the need for load shedding to customers, turn kilowatt reductions into actionable price information and verify compliance.

But hardware and software are not enough. While control equipment and sophisticated application software determines how electricity demands are regulated, people still make the decisions on whether to invest in these systems and continue to use them. That's where user experience design comes in.

Principles of Design for Climate Change Energy Adaption Applications

In this post, I want to give a sampling of key principles that are needed for the design of successful climate change energy adaptation applications, particularly those delivered as SaaS or on mobile. These principles are just a few selected best practices we have developed from work on just under 400 applications (desktop, web/SaaS, and mobile). Also see our "Principles of SaaS Design" white paper for general guidelines that apply to any SaaS implementation.

Design for non-technical users

Energy management firms (I'm including Demand Response and BIM in this grouping, along with "traditional" energy management firms like Hara) tend to think of the users of their systems as technically savvy. They design their applications for functionality and create UI using generic patterns like spreadsheets, lists, dashboards and grid views to get the data onto a screen.

But the reality is that when you deliver any application as SaaS or mobile, you immediately democratize the technology. Users tend to be far less technical and more relevantly, have far less time to devote to learning and using an application then developers anticipate. If you design an interface like a spreadsheet or a jet dashboard, users will find it too complex and will either not use or will use only when absolutely necessary. It hurts their pride and productivity because it does not aid in making sense of complex information. This translates to a low level of commitment and emotional engagement.

Instead you want to design your energy management application to replace generic data patterns with custom dynamic visualization based on user-validated use cases. Eliminate redundant information and provide predictable patterns of use that lets the user feel in charge. For "power" users, you can add additional complexity through modules or custom UI that lets them drill down. But keep the default design targeted on instant sophisticated use by anyone without the need for manuals or help desks.

Design for richness and interaction

Rich interactions let users manipulate data or objects using intuitive actions. Data manipulation and visualization is managed within panels of functionality that are integrated on a single screen. So for example, instead of entering numbers and clicking a submit button, a user drags a slider and the information updates dynamically. This kind of rich interaction is particularly important for energy management applications where the information can be complex and needs to be manipulated.

Richness improves the interest level and depth of commitment to the interaction the applications and features offer. User interact for longer periods and at a deeper level and are far more likely to share that interaction collaboratively with others.

Design brandable solutions

It may seem trivial, but to bind people to your product, you want to give them the ability to customize the look and feel of their administration, analysis and reporting screens. Personalization creates loyalty. A well designed SaaS energy management solution should allow for customizability both at the branding/co-banding level as well as customization of what panels or data fields are displayed.

The key is to design the UI so that brand and feature customization does not require separate code bases.

Build in radically simplified self-service across the entire SaaS customer life cycle

Your application is not just about managing energy. It is just as much about how people sign up for it, get support for it, provision it and even get billed for it - the entire customer life cycle. Designing the user experience for the customer life cycle is as important as designing the user experience of the core application. This approach is essential to reduce barriers to adoption as well as reduce costs.

Begin by systematically identifying all of the points in a SaaS application where the software or staff will touch the customer (e.g. early sales, marketing, demos, provisioning, configuration, billing, monitoring, renewals, support etc.). Then evaluate which of these touch points can and should be migrated online and be built into the SaaS application as self-service.

The optimal approach is to use automation and radically simplified self-service to do the tasks that would otherwise require support staff to service. User should be able to easily do these tasks on their own, right within the software without a human gatekeeper. When customer life cycle is implemented correctly in software, the cost of acquiring and supporting 1000 customers should be just marginally higher than for 1 customer.

Use mobile to build loyalty and provide additional functionality

Don't overlook and don't hold off on releasing a mobile app. But don't try to reproduce the functionality of the full desktop or SaaS application. Instead focus on companion functionality that specifically takes advantage of location, mobility, collaboration and always-on/always available functionality.

With the mobile app, focus less on designing for usability and focus more on designing for rapid learnability and discoverability. You want to deliver a compelling user experience that makes novices into experts with every interaction. This will be one of several factors that engenders "intimacy".

Embed analytics into SaaS and mobile apps

SaaS applications offer the ability to monitor when and how the software is being used, or perhaps more importantly, when and where the customer gets distracted, makes mistakes or stops using the software. Not only can you monitor how the customer uses the "primary" energy management application, but you can monitor where a user succeeds (i.e. good user experience) or fails (i.e. potential for dropout) in all of the other parts of the customer life cycle. Monitoring should also be built into companion mobile solutions.

This clearly enables you to learn how clients use energy management applications and therefore prioritize your R&D more effectively as to what capabilities to expand or where to refine the user experience.

I have only briefly touched on a few of the design principles for energy management/DR/BIM applications. Sustainability is really an exciting and rewarding area for Catalyst to work in. The integration of demand response, BIM and energy efficiency solutions has the potential to reduce demand for electricity by as much as 20 percent below projected peak levels. That will save big dollars and and go a long way to reducing greenhouse gas emissions. But that potential is completely dependent on the design of user experience for both the control and customer applications.

Climate change is real and humans are indisputably a driver of the change. The magnitude of the problem is daunting and can feel overwhelming. This drives many people to focus on simple-to-grasp solutions.

For some the simple solution is to dispute the science and deny the problem exists. For others it is to fixate on fossil fuels as the cause and search for clean energy replacements as the solution.

Climate changes is more than a clean energy generation problem

The approach of denying the reality of climate change is not something I will comment on. But the approach that focuses on clean energy replacements is. While we do need clean energy, if we look at climate changes as nothing more than a clean energy generation problem we are just setting ourselves up for failure, at least in the short term.

Reality is that we don't have the technology or the political and economic will to replace fossil fuels and still maintain current levels of energy consumption. When you add in the rapidly growing energy demands of China, India and the developing world, the problem becomes even more acute. It would take unbelievable amounts of energy (clean or otherwise) to provide 8 billion people on the planet with the same energy consumed per person that is standard in the U.S. That amount of clean energy is just not going to happen in the next few decades (and maybe never). We need to look at other climate change energy adaptation measures as well.

Venture capital shifts clean technology strategy

I'm not alone in this assessment. Venture capitalists here in Silicon Valley are shifting their clean technology investment strategy. They're focusing less on new innovative clean energy technologies and more on ideas that could have a faster payoff but a smaller impact, such as software for monitoring and reducing energy consumption or demand response management systems that enable commercial and industrial clients (and consumers) to manage load and maintain economic control.

User experience design will determine the success of energy management and adaptation technologies

Now what does all of this have to do with user experience and application design? Even though control equipment and sophisticated application software determines how electricity demands are regulated, people still make the decisions on whether to invest in these systems and continue to use them.

That's where Catalyst comes in. We design the user experience and application interfaces for sustainability and energy management applications that make it intuitive, engaging, informative and compelling to use and audit these tools.

Our targets in sustainability currently focus on three areas:

• Energy management and reporting software to identify and prioritize energy management issues, operate critical energy endpoints at optimal efficiency levels and validate investment decisions
• Building information management (BIM) systems to design for and monitor energy efficiency/maintenance
• Demand response control systems that optimize visibility into and analysis of mission-critical energy information along with reporting interfaces that communicate to customers the need for load shedding, represent kilowatt reductions as actionable price information and verify compliance.

SaaS and mobile

We design climate adaptation applications for delivery as high-performance, scalable SaaS solutions. In addition we typically recommend and design companion mobile apps for in-the-field data collection and event-driven communication and collaboration.

Demand Response, Energy Management & BIM application design guidelines

In the upcoming part II of this post I will discuss some specific guidelines for designing Demand Response, BIM and Energy Management SaaS applications.

One of my team members is very involved with software vendors in AEC (Architecture, Engineering and Construction), CAD (Computer Aided Design), BIM (Building Information Management) and PLM (project lifecycle management).  He sees collaboration and document management using software-as-a-service (SaaS) and mobile as playing an increasingly important role in these markets. Based on some of our recent projects and a growing number of inquires, I have to agree.

Collaboration, accountabilty & transparency

As with other industries, AEC/CAD/BIM ISVs find their users want to be more collaborative, using SaaS and mobile to connect all project team members and provide greater accountability and transparency in real time to all project participants (including operations, insurance and finance). A well-designed and user-validated collaborative SaaS solution can support digital prototyping, BIM-based project work as well as conventional 2D DWG-based collaboration. Project teams can centralize and securely exchange project-related information, assets and documentation whether in the office or in the field.

User experience defines the success of SaaS

We have worked on many collaboration, visualization and document management solutions delivered as high-performance SaaS for the web, tablets and smartphones. The key is to identify high value user scenarios for each delivery platform and user persona, model the software around well-accepted real-world conceptual models, simplify workflows, and then create fully testable prototypes that can be user-validated and quickly updated. As with any SaaS, it is important to identify and manage the full customer life cycle in software . This will enable automation and self-service for a scalable solution with quick provisioning, customization and deployment to geographically dispersed project supply chains. Teams won't need to worry about installing software, providing training and support, or imposing costs on subcontractors.

Modularity in UI design

Customers come to a SaaS with varying degrees of sophistication and immediate need. If there are pieces of functionality that customers don't want or don't understand, then you don't want them to have to deal with it. Modular, reusable design lets you build a standard SaaS collaboration and workflow solution and then expose additional services add-ons based on identified customer value, authorized role, or need. Modularity also makes it easier and less costly to release regular updates on a 3-6 month cycle.

SaaS UI as the competitive differentiator

Collaboration SaaS and mobile solutions will define the competitive landscape for both the solicitation and operation of AEC/CAD/BIM projects and contracts. The true differentiator and what users are demanding is the ability to get out of software what they need, anywhere, anytime, on any device. ISVs offering innovative, productive and great user experiences on both browser-based and mobile SaaS collaborative solutions will quickly establish the lead in the market.

Recently a colleague asked me about our view on what is happening in the the world of sustainability and environmental / energy management. Catalyst has completed several SaaS and mobile projects in fuel management, carbon accounting and energy management so they wanted to get our thoughts on why the luster seems to have dulled in an industry that looked so bright and rapidly growing only a year ago.

Well first off, based on our experience, the sustainability, energy and environmental management industry is still very much alive. But it is no longer the high-profile media darling du jour.

Silicon Valley investors and media were attracted to the vision of dramatic shifts in clean technology solving previous intractable problems. Wind, solar, geothermal, algae-produced biofuels, laser-powered nuclear fusion, or Bloom Fuel Cells garnered the attention. The influx of government stimulus money did little to temper this.

New cleantech takes time to develop and root

The problem of course, is that these new technology solutions take time to develop, time to test and then even more time to take root and become widespread outside of niche environments. Even then there is an uphill battle to replace incumbent solutions (observe how electric cars are faring in the face of higher mileage standards from internal combustions engines).

Applications that can be used today

Less glamorous sustainability solutions - like using SaaS and cloud applications to reduce the complexity (and thus resource use) of the supply chain - do not get the hype or coverage. But SaaS solutions that use web and mobile applications to help optimize and manage existing energy and waste/resource management technology, continue to advance at a steady pace.

In the short term (and I suspect the long term as well), the sustainability firms that will have the greatest impact and the best chances for economic survival are those that use software applications to enable companies/individuals to plan and manage their own response to reach energy efficiency and emissions goals. This will include SaaS apps that help companies pinpoint opportunities for cost-effective energy efficiency improvements, as well as mobile apps for in-field response and management.

With energy management apps, design is not subjective. There is clearly measurable ROI

Demand Response is one example of this type of solution. Rather than build new solar power plants, develop a new smart grid, or turn trash into electricity, Demand Response gives customers favorable electricity prices in return for reduced usage (e.g. dimming lights or adjusting air-conditioning) during peak demand periods. EnerNOC is one company in the U.S. supplying this service (full disclosure, they are not a client). EnerNOC does not provide some revolutionary technology. Instead, they tap existing IT and present it in a way that make it easer for companies or individuals to monitor and manage energy usage in order to impact the bottom line.

EnerNOC represents a model for the kind of energy management clients that interest us. With many software applications, development executives are accustomed to thinking that the design of the application user experience is subjective. But with energy management the issues of design and application flow are not a matter of opinion. The design translates directly to measurable ROI-able observation and behaviors. The more effective and better designed/validated the user experience, the greater the participation and resulting energy management and savings.

Many enterprises and ISVs with on-premise applications have made the decision to migrate their offering to SaaS. They do the research and come up with a solid technical and business transition plan. They select the right hosting platform. They determine whether to spin instances up on virtual servers or recode as multi-tenant. They plan for a shift in business culture, etc. They avoid the common missteps and do everything right to get their software into the cloud, with one exception. They try to port all of the functionality and user experience of their on-premise application into the first version of their SaaS offering.

The bad news

Porting an existing on-premise software application to SaaS point-by-point is a recipe for failure. But it will be a slow, lingering death. You will burn through a lot more money then what you really needed to spend. It will take a lot longer than was necessary to get to market. And most importantly, you will end up with software that is far too complex for a SaaS implementation and that customers simply will not use. That's the bad news.

The good news

The good news is that in SaaS, users will accept and embrace applications that provide smaller areas of functionality as long as they work very well. On-demand customers have a different set of expectations in terms of the features and functionality than on-premise users. So a key part of the process in designing a SaaS solution is to engage with customers who are going to use the SaaS and evaluate what functionality is of most immediate value and what can be pushed off into future releases. Based on these user studies along with user-validated prototype testing, you come out with a release 1.0 that offers a limited set of high value functionality that meets immediate user needs. This is delivered on time and on budget. Then every 90 to 120 days you add in additional functionality or offer carefully designed upsell packages for specific business scenarios.

Avoiding cannibalization

Designing your initial SaaS releases with targeted, but limited functionality rather than as a full port, has another advantage. It avoids or delays revenue cannibalization of your existing on-premise product. The on-demand SaaS does not immediately serve as a replacement for your on-premise app. It addresses an ancillary market that may not need the full set of functionality in your on-premise version. Many organizations even start a separate business unit specifically to address this ancillary SaaS-targeted market.

Data driven growth

Another key advantage of starting with a limited release focused on the highest value functionality is that you can add on additional services based on actual customer feature usage data and usage patterns. Unlike on-premise applications, which are generally black holes when it comes to information about customer behavior, with SaaS, the application can monitor almost everything the customer does. You can identify and correct drop out points, incrementally try features and explicitly test what functionality has the greatest customer value. So you design your SaaS based on empirical data rather than historical convention or marketing checklists.

Now at some point you may add in all of the functionality of your on-premise application. But from our experience with more than 60 SaaS engagements, this scenario is unlikely. Instead user monitoring enables you to design a less complex base application, then develop and offer additional functionality bundled into different purchase scenarios for different customer groups.

Leave the past behind

SaaS offers a unique opportunity to reinvent your business. It is not just a technical product migration exercise. It is a way to use your domain expertise to design a new set of targeted solutions that will surprise and delight your customers (internal, b2b or b2c), as well as drive new revenue and productivity.

Migrating an application to SaaS (Software as a Service) means rethinking and redesigning the software in several fundamental ways including changing the hosting model from single to multi-tenant, the business model from perpetual license to subscriptions and the update cycle from years to months.

The customer life cycle:  Put as much effort into designing the service as designing the application

But in our experience having designed over 60 SaaS applications, one of the most significant changes is in the management of the customer life cycle. Customer life cycle refers to the full progression of steps a customer goes through when discovering, purchasing, using, getting support, billing and upgrading a product or service. With SaaS you build some or all of these steps directly into the software. This is a dramatic shift in software design but is essential to meet modern user expectations as well as achieve scalability and profitability. Let me detail this out further.

On-premise software customer life cycle (traditional)

With traditional on-premise software, the customer life cycle is handled by many departments and individuals. There is a large upfront sales effort with a protracted sales cycle, from a large team (pre-sales, account manager, marketing, advertising) that “manages” the buyer through the sales process. A purchase cannot even move forward without engaging with the sales team. Installation/setup including customization and provisioning requires a systems engineer or consultant. Training and a post-sales support staff manage the usage and on-going maintenance phases. A person in finance handles renewals. At every customer life cycle “touch point”, the buyer must engage with a human gatekeeper that is outside of their everyday use of the “core” application (e.g. the CRM or ERP).

SaaS customer life cycle

With SaaS, the above “high touch” model falls to pieces due to economics and user expectations. When you migrate to SaaS you still have your core application as the center of focus, but then you systematically identify all of the points in a SaaS application where the software or staff will touch the customer (e.g. early sales, marketing, demos, provisioning, configuration, billing, monitoring, renewals, support etc.). Based on your specific business, customer and technology dimensions, you evaluate which of these touch points can and should be migrated online and be built into the SaaS application.


Put in very broad buckets these touch points address:

• Purchasing & Deployment
• Configuration & Provisioning
• Usage

• Monitoring & Upsell

Designing for buyer self-service

In a pure SaaS model, the underlying economics mandate that almost all of the touch points in the customer life cycle be designed, delivered and managed via the SaaS application. So in addition to delivering the core application, the software is designed to use automation and self-service do the tasks that would otherwise require support staff to service. Buyers can do these tasks on their own, right within the software. This is essential to achieve economies of scale, rapid iterations, and broad market appeal. When implemented correctly, the cost of acquiring and supporting 100 customers should be just marginally higher than for 1 customer.

Of course, pure SaaS is not appropriate to all business models. The underlying business value of a piece of software may require unique customer processes, or complex integration tasks that can’t be automated. The steps in the SaaS life cycle framework are however still appropriate for developing a roadmap on how to design your SaaS. Examine the touch points in the life cycle of your own organization and your product to determine the appropriate combination of self-service and high-touch services interacting with one another.

In some cases you may need to offer enhanced customization, additional sales support, or on-site professional services, and the premium you charge for this will cover the cost hit you take by not being able to scale via automation or self-service. But even in these cases, don’t fall back on traditional on-premise software approaches. You should still thoroughly examine all points in the customer life cycle and determine the fundamental cost advantages of addressing each component in software vs. with sales and support staff. This will help you to align your business model with the underlying economics of how the core application and supporting services are exposed to users.

A real world example

We worked with one of the leading SaaS CRM providers on a problem they had with losing more than 20% of the people who initially signed up for the service. Because SaaS makes it possible to track online activities, we were able to determine where users were dropping out. The company had assumed the problem was in their core application, but it was actually in the customer life cycle during the provisioning and customization process (that at this point was still being managed by support staff). Once we knew where to work, we were able to move these touch points into the application to create a smooth and simple user experience to allow self-provisioning and customization. This very effectively reduced the dropout rate.

A visual model

The below diagram explains the SaaS customer life cycle visually.

On the left is a traditional on premise solution. This inside area is the part of the software that the customers touch i.e. the core application. Around this on the outside are all of the touch points of the application that are not built into the software. Someone has to come in to sell it. Someone has to come into provision it. Someone has to come in to customize. Someone has to come onsite to do training. Etc. So there are many touch points that are not part of the design of the software.

On the right is a SaaS application. You still have the core application in the middle that users touch. But there are many points around the core application but still inside the circle (the lifecycle of that product) that users can touch. This includes things like trial software, purchasing, configuration, provisioning etc. Buyers have an expectation they can do these things on their own without the need to interact with a sales or support person. Consequently the implementation and user experience needs to be simple, easy and effective.

As an organization you need to understand the life cycle touch points that surrounds your product. If a touch point is inside the circle it means buyers are going to touch it as part of the software. If outside the circle it means that aspect will not be built into the software.

 

I cannot overstate the importance of modular design system for application UI and functionality.

UI design and development typically take between 65 - 80% of the overall development time in any enterprise application redesign/redevelopment project. As I’ve written in several posts, modular, reusable UI design systems significantly reduce this time.

Modular design for SaaS is a key to greater profitability

For SaaS (Software as a Service), modular design plays an even more critical role. It can enable orders of magnitude increases in profitably.

Let me give an example: A company we work with had a very compelling piece of software for transportation asset management. However, all functionality in the application was bolted together. All configuration was in one area, all reports were in one area, all routing & logistics were in one area, etc. This meant the company was limited to selling their SaaS offerings as a single product at a single subscription price.

When the sum of the parts is more than the whole

Ideally with SaaS however, you want is to be able to break your functionality into pieces that can be sold separately. The modular pieces become separate profit streams that sum to more than the profit from a single monolithic SaaS. In the transportation asset management SaaS, for example, after redesigning the software using modular UI and functionality, the potential subscription revenue from the lowest standard plan to the highest modular plan for advanced business scenarios, could be 10:1 or greater.

Keep it simple to start

A second value of modular SaaS design is simplicity. Customers come to a SaaS with varying degrees of sophistication and immediate need. If there are pieces of functionality that customers don’t want or don’t understand, then you don’t want them to have to deal with it.  You also don’t want customers to feel like they are being charged for features they don’t use. SaaS customers that are inundated with too many features simply say “Oh this is just too complicated.  I can’t deal with it. I will look for a different solution which that offers only the features I need and costs less”.  In other words, you end up with customer churn.

Modular design for SaaS based on use case scenarios

Building your SaaS as modular pieces of functionality addresses both creating multiple profit streams and keeping it simple. You design the standard SaaS using the lowest common denominator of high value services (this version might be your trial version) and then offer additional services add-ons based on identified customer value.

On one end of the modularity continuum you can sell everything as a catalog of mix and match components. On the other end (what we recommend) you can sell carefully designed packages for specific business scenarios that are determined from user studies and customer monitoring.

If the customer has the need, and your modules provide value and are exposed/discovered at the right time, you will coax customers up the revenue ramp to increase average recurring revenue without increasing average recurring cost of service. The end result is you are more profitable and customers are more satisfied/stable.

Modular design means faster introduction of new services and upgraded features

A third value of modular design is upgradability Once you are delivering a solution as SaaS, you should be operating in a 90-120 day release cycle (as opposed to a 1-3 yr release cycle for on-premise or web applications). You need to maintain that rhythm to keep users engaged and keep your application competitive. Modular, reusable design lets you introduce new features very quickly. It also makes it possible to upgrade just select services or packages in the SaaS without having to impact other parts of the software.