User Experience Blog Posts

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.

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.

OK - I’ve a bit busy with client work and hence a bit lax on posting.  But today while taking a quick break over lunch to peruse my RSS feeds, I read this entertaining and informative post Why should only iPad owners get usable apps?.  I thought it was worth referencing and quoting.

From the post:

“The insurance company Aflac was bragging about how its new iPad app for salespeople boosted productivity because users just loved the app, whose UI was actually accessible—so much so that the company claimed an 18 percent in sales increase due to the adoption of iPads.”

The author then asks:

“Why did it take the introduction of the iPad for someone at Aflac to get a clue that it was time to redo the presentation in a user-friendly way? Why didn’t Aflac do a better app for its agents before the iPad? Godwin didn’t want to go there. But Aflac’s situation raises the question I believe every IT developer, IT manager, CIO, and businessperson should ask themselves: Why does it take the introduction of an iPad, an Android tablet, or some other new device for a company to worry about the basics of creating apps that are usable and effective? Why have most people decided that it’s OK if PC apps are difficult to work with?”

The question is one that we try to bring to the forefront in many situations.  User interface and user experience design, while of paramount importance for consumer apps, is often considered optional - a “if we have time and budget” for enterprise applications.  But contrary to traditional beliefs, great enterprise user experience design is not just a nicety, it is a bottom-line necessity.  Failure to understand users and optimize user experience, in addition to poor user adoption and high support costs, means failure to address inefficiencies, failure to increase productivity and failure to differentiate your product from the competition.

The user interface is the tangible part of business processes that underlie the application. Streamline and validate the user experience and you streamline and validate the business process. Users learn/work faster and are more accurate, thereby generating more productivity. Moreover they actually use the software, rather than find work arounds, thus avoiding one of the primary reason enterprise application projects fail.

If you are a senior executive responsible for delivering a commercial software solution or mission critical application, the odds are against you that you will achieve an unconditional success.

The average software project runs 222% late, 189% over budget and delivers only 61% of the expected business value and ROI. (Personal aside: I found the statistics to be very similar for a house remodel!)

Sobering statistics on software and services application projects

Software projects such as migrating an existing application to SaaS or designing a new software application, are about change and inevitably carry risk. But the industry statistics* on failed or low-ROI projects are enough to make a Vegas oddsmaker cringe:

• Only 16% of software projects are considered successful
• 51% are considered challenged (that is cost overruns, late to market or content deficiencies)
• 15% or more never get completed and end up abandoned (for large projects this bumps up to an even-money bet**)

The result globally is the loss of billions of dollars each year in project overruns, reworks, and IT re-orgs, as well as the opportunity costs including the new investments that can't be made.

Identify and manage risk

Many (most?) of these projects face challenges not because of technical mistakes, but rather from failures to identify risk and implement best practices to improve the quality and agility of application design decisions.

That's where we come in. One of our roles as specialists in user experience and SaaS application design, is risk intelligent management.

Downside protection, upside innovation

On one hand, we protect organizations from being blind-sided by projects that can't be designed, that miss mission-critical interdependencies, or that simply don't deliver value -- a kind of minimum cost downside protection.

On the other hand we improve the buy in, quality, resilience, agility and innovativeness of the final project -- think aggressive but informed risk taking that creates and sustain success.

3 examples of risk factors in software application design

I will elaborate more on specific risk factors in a future post, but below are a few examples of risk factors in application design and what we do to limit them:

Gain a competitive advantage through risk management

I have to admit, the idea that our firm was in the risk management business, was not actually my idea. I was talking to a CTO just after completing a project and he said something to the effect of "I have managed scores of software projects but this is the first one where I didn't feel like it was a black hole for IT resources or a crap shoot for success. Catalyst reduced my risk exposure across all levels."

And that is when it hit me: One of the primary reasons a company hires Catalyst to design their application is to manage risk and gain competitive advantage. 350+ application design projects, specific domain expertise, a proven application design methodology, and a few creative geniuses tempered by a love for empirical data, translates to mitigating the downside and optimizing the upside of risk for any SaaS or application design project.

Designing a SaaS application that can sustain growth, deliver new services, and establish on-going customer relationships, requires bringing together several levels of skills: experience, innovation/creative , and empirical/validation.

• Experience refers both to know-how regarding interface design and human behavior but also to understanding the unique demands of SaaS delivery and how it impacts the entire customer life cycle.
• Innovation is something I have touched on before.
• Empirical is about using data to understand how users/customers think and behave.

Empirical also means using data to build consensus and get beyond biases that we all bring to the table.

Biases that skew design priorities

One bias common to everyone, from UI architects and UI designers, to CEOs, product managers and development teams, is the availability heuristic - "if you can think of it, is must be important". Basically, stakeholders skew the importance of a feature/workflow scenario based on how easy it is to think of an example of someone (possibly themselves) who would use it.

The "typical user" we each know

It's common to be in meetings where the CEO of a company was just browsing a website that had feature X and so now thinks "users" of their application will need X. Or to find a product manager who clearly remembers an an email complaint about a product at his previous company and now makes the statement "users want Y". Or a UI architect who just worked on a mobile project and thinks that all "users" distract easily and can't focus on tasks. Or a visual designer that is really designing for one user they know really well - themselves.

The availability heuristic as a bias in application design is ubiquitous. One impact is that it can impede building consensus among stakeholders around what features to implement and the order in which to implement them. Fortunately there are a number of tools we use to reduce these biases and produce actionable information that maps to bottom-line profitability.

Distilling behavior patterns

Personas is one of these tools. In simplest terms, a persona is a distillation of a behavior pattern into an archetypal character. Personas tell you what people care about, what they do. Every SaaS application will likely have several personas. These might represent different demographics, different market segments, different work roles, different experience levels, or different conceptual models of how things work.

What a user wants to accomplish (behavior) and how they want to feel (emotion)

Personas are derived both by looking ethnographically at very objective behaviors and then seeing correlations that distill into a behavior pattern, as well as by observing how users "feel" (e.g. secure, confident, delighted, engaged, exploratory, etc.) and modeling these into a pattern. These data-derived behavior/motivational/emotional patterns are converted into characters, with a photo and name (e.g. Joe, Veronica) so that they can take on a life of their own, be empathized with and define the boundaries for the application design.

Disambiguity and prioritizing release cycles

Deriving personas is not some touchy-feely, creative writing exercise. but rather an effective way for design AND development teams to focus attention, remove bias and examine usage contexts and the opportunities they present. Instead of teams asking "How would I use the software" or "How would 'a user' use the software", they can ask "How would Joe use the software", "How would Veronica use the software". This reduces ambiguity and "squishy", "elastic" users. Proposed feature and design assertions can now be tested and validated against more closely defined user characteristics and goals.

We put these personas to work in scenarios in order to elicit key requirements that serve as the initial roadmap for application functionality and design. We can also plan priorities for SaaS release cycles. For example we might say: "Here is management's presumed list of 10 must-have features. But the personas that are the most important to our market, won't really care about features 3,7, and 9. So maybe we delay these features until the next release cycle."

Personas are just one in a toolbox of UX tools we use to remove bias, build consensus, identify functionality/design opportunities and tailor the SaaS environment to various user distinctions where the differences will have a meaningful effect on services and where service differentiation makes financial sense.

Remember David Byrne from the rock band Talking Heads? I recently listened to a talk he gave at the Ted conference, on how architecture helped music to evolve. Byrne's premise was eloquently simple. Artists create a style of music that works for the environment in which it will be heard.

Artists evolve musical styles to fit the playback environment

Byrne gives the example how West African music, with its intricate rhythms works outdoors in the open, but would be a disaster in a Gothic cathedral where reverberation would confuse everything. On the other hand, music that works in a Gothic cathedral (long notes, little rhythm) sounds flattened in outdoor environments.

Bach wrote music for playback in a room that was smaller and not as vaulted as a Gothic cathedral. Consequently his work could be more intricate and could change keys without risking large dissonances. His music was an evolution from previous styles, but also something completely new, designed to fit the context of the room.

Opera houses like La Scala, helped evolve yet another kind of music. Two hundred years ago, opera patrons did not listen in hushed silence. Instead they would eat, drink and yell out to people on stage and to each other. The dramatic and repeating melodies of operatic music evolved in response to this opera experience.

Today's music reflects the environment very clearly. Microphones enable soft personal sounds and complex inflections. Pop music is written for the MP3 player, capable of extreme detail but a limited dynamic range (too much dynamics could blow out your eardrums or at least force you to adjust the volume).

All of these examples illustrate the point that the context for playback determines the kinds of music that works and that evolves.

UI Design firms evolve information & tasks to fit the presentation environment

Now love of music aside, why did this all interest me?

Potential clients often approach us about developing mobile apps for the iPhone/Android phones or for the iPad. This is a high growth area for us. Most of these requests are from clients who already provide desktop or Web-based SaaS solutions and now want to scale this experience to a smaller screen and capture a slice of a very fast growing market.

Many UI firms quote the mantra "simplicity, consistency and usability are the keys to great mobile applications". While this is indeed true, it is not sufficient. Like music that evolves to fit its playback context, the user experience must evolve to fit its presentation context. This means looking at what people do in that environment and changing the very nature of the application and UI so that it takes advantage of the context.

Mobile application design as extensions to existing apps, not stand-ins

Good mobile UI design is not just about creating simpler and more streamlined interfaces (such as virtual keyboards that change depending on the kind of data you are entering), it is also about understanding how the context changes what makes for effective activities.

For example, on mobile devices, people are in extreme multi-task mode. The UI design needs to shift from being entirely focused on linear task completion (as in traditional desktop applications), to applications that are easy to enter and exist. They need to keep the user's mental and physical attention by being clear, visually rich and integrating gesture, touch and sound into the interface.

Mobile devices also provide unique behavioral and sense information such as motion and orientation via accelerometers, GPS data (location awareness), and the physicality of gestures. These can be used to refine the experience, anticipate needs and deliver options that are contextually relevant.

The most effective mobile applications act as extensions to existing web or desktop apps, not as stand-ins until the user can get back to a "real" computer.

The music of Mozart was not a stand-in for Gregorian Chants

So back to the David Byrne Ted talk; the music of Mozart was not a stand-in for Gregorian Chants performed in Gothic cathedrals. The musical styles were completely different to take advantage of the unique aspects afforded by the context.

The same is true with user experience design across different devices. The interface enables unique and valuable behaviors that can engage users in completely different ways. Whether it is a fit-in-the-palm-of-your-hand smartphone, a gesture-based tablet like the iPad, an instrument control interface like a fuel gauge, a desktop SaaS application or a speech-recognition-controlled security system, each context offers unique opportunities and the user interface should evolve accordingly.