Have you ever noticed how you selectively ignore car advertisements on TV except when you are thinking about getting a new car? As soon as you are in the new car shopping mode, you start paying attention to any kind of car-related information from TV ads to ads on your smartphone. 

This kind of selective attention is true for many things, including application design and UI. Most organizations know that problems with their current application architecture and UI is costing them clients and/or money.  However until an organization reaches a particular point in their development cycle, they do not allocate attention to these design pain points.  They just tune them out.

SaaS Design Pain Points Research

We decided to do some research to better understand this.  We've been running a study with our recent clients as well as new prospects who were  migrating to or already in-market with SaaS product. We asked the VP of Development or CIO to rate their software application on 36 SaaS application and UI design pain points and to identify where they were in their product development cycle.

Preliminary Results

The preliminary results from our research were remarkably consistent. Some of the highlights are summarized below.

Overwhelming, organizations begin paying attention to pain points related to application design and UI when their existing product is nearing a scheduled revision cycle. At other points they identify the pain points as valid, but they do not rate them as severe until they are entering a planned revision cycle.

Once they do enter revision mode, below are are the pain points that were most consistently ranked as moderate to severe. Of course every organization had their own unique issues as well, but these represent aggregate results.

Note: The number in parenthesis is the percentage of respondents who ranked this as a "need-to-deal-with" pain point.

• As a result of increasing costs including: development, marketing, sales and/or support, and/or declining revenues, the profitability of our current offering is unacceptable. (61%)
• We need to shorten our time to market for the next product release. (61%)
• We need help with UI development using RIA or mobile technologies e.g.  AJAX , Flex , Silverlight , HTML5, iOS, Android. (63%)
• The cost of installation, training or support for our products is higher than acceptable. (65%)
• We have an existing product we need to migrate to SaaS and don't know how to adapt the application. (72%)
• We don't have reliable in-house resources to specify, design and document all of the functionality and code up all of the UI so we can hand it off to our in-house or remote development team. (84%)
• Prospects are purchasing competitive SaaS offerings because of simpler contracts/pricing, ease-of-use, engaging test-drives, or other competitive user experience factors. (86%)
• Our target customers tell us they want different features or functionality than is offered by our current product.  (94%)
• Customers or internal staff have commented that the current UI feels "outdated", cumbersome, slow or difficult to use. (97%)
• Users of our current solution tell us they are dissatisfied with the time required to complete activities. (98%)

Do any of these results sound familiar to you and your organization? What other pain points related to SaaS design have you experienced? If you are interested in the study or want to help us understand your own pain points, I would definitely like to hear. Contact me and someone from Catalyst can take you through the survey and give you your results.

We will be extending and refining our study further, as well as publishing recommendations for each point. But I wanted to give you a taste of how a representative sample of CTOs and VPs of Development are thinking.

In a post back in October, I talked about how functional application design risks, if not identified and mitigated, could derail the successful delivery of any business-critical software or enterprise cloud computing project.

The ultimate objective of risk management is to give organizations confidence in the decisions they make, the applications they deliver, and the assurances they give

I recently wrote a bit more on this, identifying 8 of the most common risk factors.

Risk #1: Experience with applications

When selecting a team to design your application, ask what percentage of their experience comes from applications as opposed to web sites. As a simple rule of thumb, eliminate anyone that comes in under 75%.

Firms with most of their experience in web design are primarily visual designers. This is just one component (and not the most critical) of what is required to design enterprise applications.

Risk #2: No coded, clickable prototype

Creating visual mockups in a imaging or quick prototyping tool is adequate for the product definition cycle, delivering initial feedback, and giving a good sense of visual design. But this is not sufficient for complex application design.

Before your in-house or offshore teams begin coding a final application you want a working, clickable prototype of the primary design system, coded in your technology, linked to your backend, that will validate the end-to-end technical architecture and performance, as well as the visual design and user experience.

Risk #3: Screen-based design

The most common approach to UI design is custom screen-by-screen production. The designer builds screens/pages as they are planned. It is certainly faster to prototype and demo this way. But when it comes to deployment of a Desktop, Cloud, or SaaS application that is scalable and can be easily extended, updated or reconfigured, it is essential to re-factor the screens into a modular, reusable UI design system.

Using modular, reusable UI, developers will work faster, interfaces will be consistent across the application(s) so users will learn faster, and designs will automatically scale when you add new services or features.

Risk #4: Failure to understand users

For enterprise software applications, in the battle of form vs. function, function has historically been the winner. Whether or not an application maps to how real users do work, let alone if users "like" the application, is typically not high on the priority list.

But understanding how users work and optimizing the user experience is not simply about form. 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.

Failure to understand users and design for them, in addition to poor user adoption and high support costs, means failure to address inefficiencies, streamline processes, and increase productivity.

Risk #5: Failure to focus on high value

Application developers often talk about designing software around use cases. But while most applications are based on 100s or even 1000s of use cases, there are typically less than 10 key high value user scenarios, from which users gain the most value.

Validating and building an application around high value scenarios translates to bottom line productivity and reduced support costs. Developers spend time coding and maintaining features that are actually used, rather than ‘what-if' use cases.

Risk #6 Wrong presentation layer technology

When you build complex business applications, there are many different technologies employed on the back end (both software and hardware) and many different requirements for transaction performance and front-end availability (web browser, desktop app, mobile phone and tablets).

Iterative prototyping with rapid application design tools can drive out and clarify these requirements. Too often though, due to the effort already spent on prototypes and the time pressure to turn them into the final system, developers use the prototyping development technology for production. The final deliverable then ends up incapable of meeting the full technical & design specifications.

To mitigate this risk, the application should be designed with high-speed prototyping tools that encourage revision until the definition and design is right, but do not lock in the final implementation. Before final coding, the design is re-factored into a modular, working UI kernel using the optimal presentation layer technology that maps to the technical architecture, levels of availability, and delivers the required performance.

Risk #7: No mobile strategy

In most organizations mobile has been an afterthought when designing enterprise applications. While business laptops and desktops remain the primary user platforms for in-office work, there is a growing shift to mobile phones and tablets for frontline workers, customers and work performed outside of the office.

Organizations need to design both mobile and browser-based versions of applications. Well-designed mobile apps extend and expand on the value of existing SaaS and enterprise web or desktop applications.

Risk #8: For SaaS, you design only the core application

With traditional on-premise enterprise applications, each touch-point where a user interacts with the product - e.g. signup, provisioning, training, etc. - is managed by sales and support staff. The software itself is designed to deliver the "core" usage functionality.

But with Software as a Service (SaaS) many of these touch-points can and should be exposed to users in software via automation and self-service. Depending on the underlying business model of your application, there can be fundamental cost and productivity advantages.

---

Businesses are always choosing what to do and how to spend their money, all while knowing these decisions carry risks. Identifying and managing the risks described above will improve the odds of delivering a software project that comes in on-time, on-budget, and on-value.

On the one hand you get protection from being blind-sided by projects that can't be designed, that miss functional requirements, that require rework, or in the worst case, that users simply don't use.

On the other hand, applications get to market faster and have greater functional impact, resilience, customer facing innovation, and competitiveness.

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.

 

 

Many financial services firms, particularly insurance and banking, are resistant to making the changes needed to enhance their competitiveness. They have made significant investments in legacy software/hardware and are wary of moving to Rich Internet Applications and cloud application services for reasons of security and performance. On top of this, most firms also have experience with big IT projects or on-premise software upgrades that have ended up absorbing large amounts of resources but not delivering business value.

Augment rather than replace

Rather than wholesale replacement of existing applications, a more manageable and risk aware approach is to design new RIAs that augment what is already in place. One of the advantages to RIAs is that they don't have to be used throughout the entire application. The richness and interactivity they provide can be applied in choice areas in order to augment the experience offered by the application as a whole.

Where to augment?

First insurers and bankers should examine the competitive factors that drive the need for application redesign. Then they work with an application design firm like Catalyst to incrementally support the most important or complex business issue. Examples factors to consider include:

• Need to increase customer intimacy, interactivity & loyalty
• Need to be where the customers or workers are: on the web, on mobile
• Need to accommodate a workforce that has grown up with on-demand, easy to use applications
• Growing demand for real-time access to information and information sharing
• Automating and streamlining business processes
• Need for consistent UI across applications due to Mergers & Acquisitions
• Need to move away from paper-driven processes & reduce duplication of effort and transcription errors
• Growing number of users per application
• Increasing transaction volumes requiring higher performance & better visualization
• Need to do business with a larger set of partners across the supply chain

Customer-facing applications

We have worked with many insurance and banking firms facing these challenges and often the most "bang for the buck" is to focus first on redesigning customer-facing applications.

Customer-facing applications provide direct access to tools for in-house decision makers, agents, sales teams and call center staff, from their web browser or increasingly, their mobile devices. External customers, the end consumer, can also use self-serve tools and navigate on their own. The customer should be in control, by adding a flexible user experience layer on top of your existing IT infrastructure.

Agile design process for substantive short- & long- term wins

Initially, the focus is on delivering the applications to support the highest value scenarios with simplicity, accessibility and convenience. It is also essential that these design address scalability, modularization, dependency management and performance tuning. The delivery process should be lightweight— with a delivery of usable production quality software every few weeks, so that end user feedback may be obtained for quick refinement of the solution.

The end results of the new application design improves customer interaction and increases agent loyalty. Modular design systems improves time to market for new add-on services. Delivery via the cloud increases availability and reduces costs.

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:

Risk Factor	Description	Impact on Project	Guideline to Reduce Risk
Failure to focus on high value scenarios	While most applications are based on 100s or even 1000s of use cases, there are typically less than 10 key user scenarios, from which users gain the most value (the primary centers of mission critical activity). Developers often design software to do everything for everyone, and do not focus on and maximize the accessibility and performance of the high value scenarios.	You spend time coding and maintaining features that will rarely be used. Users will not have the tools to easily and efficiently achieve their goals resulting in poor user adoption. Rework will be needed.	Workflow streamlining. High value scenario analysis. User-validation testing. Deep domain expertise (financial services, SaaS, Biotech, sustainability) so we already understand what matters.
Inaccurate understanding of work	Developers typically design and build applications without fully understanding what real users do and how an application will be managed on an on-going basis.	Mission-critical interdependencies are not caught, eliminating margins for irregularities or errors. Software does not solve a problem or streamline workflow. High maintenance costs by IT rather than users. Poor user adoption (i.e. failure).	Deep domain expertise in financial services, biotech, and sustainability so we understand what users do and the issues they face. User studies and user modeling. On-going user validation throughout the design iterations It’s much more cost- effective to fix problems early in the lifecycle and before deployment.
Inappropriate UI resources	Typically a good coder is not a good UI designer or information architect, but companies often have their backend coding developers try to design the architecture, the visual design and the presentation technology. Or they hire a web design firm for the UI not knowing that designing a website is not the same as designing an application.	IT resources are taken up on efforts where they do not not offer speed or expertise, pulling them away from other strategic projects. The underlying code has been produced for speedy availability rather than robustness but there is resistance to change the presentation layer technologies because of the amount of effort already spent on prototypes and the pressure to turn it into the final system. Consequently the end product cannot meet the full technical & design specifications. Product is not modular and/or resuable so it cannot be easily extended or applied to future apps . Poor performance and scalability. Late to market. Increased development costs.	Multi-disciplinary teams with expertise in information architecture, visual design and UI presentation layer technologies work with the organizations backend developers. Design with high-speed prototype tools that encourage revision until the design is right, but do not lock in the final implementation technology. Design all UI components as modular and reusable. Development of a UI kernel to validate end-to-end technical architecture.

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.

* From 2005 Standish Group report. The figures remain similar (2005, 2008) in other reports. ** Jones 1991

There is a lot of confusion and FUD around the meaning of cloud computing, cloud applications and SaaS. It's understandable given all of the acronyms (SaaS, PaaS, IaaS) and the fact that many "experts" and marketing types are simply using cloud buzzwords as a way to freshen their message.

Cloud computing is a general term describing anything that involves delivering scalable, hosted services (infrastructure, development platforms or end-user applications) over the Internet. The promise of the cloud is new economies of scale, more rapid and flexible deployment of applications and the ability to connect otherwise incompatible infrastructures. Some simple definitions:

Infrastructure-as-a-Service (IaaS) is the foundation layer of cloud computing delivering shared, massively scalable infrastructure on-demand, like a utility. This includes raw storage, CPU power, backup, internet bandwidth and network services, databases, and security. Examples include Amazon Web Services and Rackspace Cloud Servers.

Platform-as-a-Service (PaaS) is an integrated platform available over the internet, to build, test, and deploy custom applications. It is delivered on-demand typically on a subscription basis. Depending on the vendor, it can range from a programming environment with a RIA front end (think MS Visual Studio) to a solution intended to mash-up SaaS's. A PaaS may include online APIs, development tools, databases, ready-made components (e.g. single log-in widgets), project management tools, mashup-able services and storage (IaaS). PaaS can be used to deliver custom applications (client-server style but where the enterprise does not actually invest in the IT staff or infrastructure to run the servers) or as multi-tenant SaaS. Examples include Force.com, Google App Engine, MicroSoft Azure, and even the Facebook platform. (as a note: when selecting a PaaS provider, critically look at your need for portability)

Software-as-a-Service (SaaS) is the end-user applications delivered through a web browser, RIA or mobile app in a "pay-as-you-go" model. Typically these are vertically-integrated, self-contained applications, following a one-to-many model based on a multi-tenant architecture. It falls under the cloud computing umbrella of massively scalable, and available anytime and anywhere over the internet. SaaS is a viable, and increasingly preferred, delivery and acquisition model for enterprise software. It offers a quantifiable cost savings while increasing agility and scalability. Examples of SaaS applications familiar to everyone include Gmail, Google Docs, Salesforce.com.

User experience in SaaS

The challenge for applications delivered via the cloud (i.e. SaaS) is to move from simply delivering services, to delivering experience. User experience is the real economic value in any software offering (this is true for PaaS for developers as well as SaaS for end-users). This is where Catalyst comes in. We design SaaS application functionality and user interfaces. This includes everything the user experiences, from the way users signup for and provision software, to how the application behaves and delivers functionality, to how the user gets support to how user behavior is monitored. We design the entire SaaS user experience life cycle, as well as evaluate and design how to streamline and integrate business processes and systems. We have deep, real world experience designing for many PaaS platforms, complex integrations and large scale enterprise deployments.

The future of SaaS is modular integration

Historically (an ironic word to use to describe SaaS!) SaaS applications have been built as vertically-integrated standalone solutions. But the growth trend for SaaS is to design applications that leverage the cloud (specifically PaaS) to couple together best-of-breed components and that dynamically deliver on-demand, flexible "mashup" application - a SaaS of SaaS's. In other words, you don't have to build everything yourself. You just have to bring everything together in a cohesive manner that delivers a compelling and productive user experience.

Catalyst specializes in developing modular and reusable UI for SaaS applications. A UI library of modular, reusable code, can save distributed development teams up to 85% in application front-end development cycles. By definition it also makes it easier to expand, add new services, and adapt more quickly to changing market conditions.

Modular and reusable UI also gives organizations a leg up on the modular "mashup" direction cloud application services are moving. Your SaaS offering for example, could add a location services or a billing component that is provided by another vendor (or by integrating data and apps from behind your own firewall) . Your UI component library can be used to ingest the service and provide a user experience consistent and integrated with the rest of your SaaS application.

For most organizations, today your top concern is just designing and deploying a standalone SaaS application (or transitioning a legacy on-premise application to SaaS). But if you design using modular reusable UI components, not only do you gain flexibility and faster ROI now, you will also be ready to quickly add component assets (your or other vendors) as you need them.

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.