One of the most common challenges faced by our clients looking for companion mobile solutions is whether to develop a native, mobile web or hybrid app. The decision has a significant impact on the scheduling, cost and adoption of the mobile solution.
Much has been written on the arguments for and against one development path over another. Rather than rehash existing arguments, I want to give our viewpoint on best practices for delivering the optimal user experience balanced with ROI.
Native
Native apps deliver the best specialized and empowered experience, the highest performance (online and offline), the best access to the device APIs (camera, address book, gyroscope, magnetometer, phone, maps, location-based services, special transition effects, etc.) and typically stronger user engagement.
The problem with native development is that is fragmented between the four distinct mobile platforms (iOS, Android, Windows Phone and yes, even BlackBerry). Few companies have the resources to build and then to maintain a complex app across all platforms. If you do intend to release a native app for more than one platform (or even more than one variation of Android), a good rule of thumb is to budget 150% to 200% higher than for just one platform.
When to Go Native
Native apps almost always make the most sense for resource intensive programs that require more use of the hardware (e.g. 3D & data visualization, camera/video input, special FX, transitions) and system integration (notifications, contacts).
For other solutions that would benefit from a native app, the first question to ask is whether you need a native app for all platforms or can identify one or two native platforms that particularly suit the personality and demographics of your key market? In many case, rather than trying to cut development costs by shoehorning a web app into a mobile device, it makes more sense to target your highest value audience and platform and build a flagship app that offers an exceptional and polished native user experience.
Going native is particularly valuable for SaaS companion mobile apps where you want to use the app to maximize "addiction" to your service. You want the familiarity and fit to existing mental models and you want to tap into users' existing (sometime militant) bias to that particular mobile OS.
Mobile Web using HTML5 & Javascript
Web browsers are ubiquitous and on mobile they are relatively consistent and offer acceptable support for modern Javascript and CSS standards. The promise of mobile web apps is to reduce the cost of creating multi platform applications by using a single code base that runs on mobile devices differing in OS, user interface style, input mechanisms, display form factor, size, and resolution. A single mobile web app can reach multiple platforms at once while a native app is tied to only a single platform.
Drawbacks to the Mobile Web
There are however several disadvantages to designing for the mobile web:
- Unlike a dedicated app, users need to use a web browser or bookmark to get to the site. Depending on bandwidth, this can mean delays to complete failure (i.e. down in the subway)
- Javascript still does not achieve the performance level of native code. Poor performance is rarely, if ever, tolerated by users, especially if alternatives are available.
- Offline performance/caches and storage is limited or poorly implemented so dependability is limited
- Perhaps most importantly, most web apps are designed for desktop browsing. If you try to shoehorn your existing SaaS web experience into an mobile device the result will be a poorly defined, poorly received service. Anyone who has tried to use a SaaS application (designed for the desktop) on a smartphone or tablet knows the experience can range from annoying to quit-and-never-return frustrating. Complex SaaS web applications are rarely suited (without redesign) for smaller displays, touch interactions, or low 3G bandwidth.
If you do decide to develop your app as a mobile web site/app, don't be lulled into a sense of complacency: designing a truly engaging and effective mobile web app is just as difficult as creating a native app - perhaps more so, with its own set of complications. But the advantage of a successful design is that it will perform the same or similarly across all mobile devices.
Mobile Web UI Design Caveats
If you decide your application is a good fit for a web-like application whose usability wouldn't suffer from not being able to use certain native UI elements or features:
- Design the mobile web app using responsive design (see Design Responsively below).
- Don't try to fake the UI of a native app. If it looks native, but does not behave native (performance, UI), users will be confused and worse, irritated.
- Understand and validate use cases for functions in the device context where the application will be used. A complex web application on a smartphone or tablet will may need to limit features that make sense on the desktop, or add features that make sense in a mobile context.
Blended Development With Hybrid apps
Hybrid mobile apps attempt to strike a compromise between native and mobile web. They use HTML5 + CSS3 + JavaScript along with a wrapper/development framework like Sencha, PhoneGap or Titanium to give the app access to native device capabilities.
Basically a hybrid app is a native, downloadable app, that runs all or some of its user interface in an embedded browser component. To the user it can be indistinguishable from a native app. But to a developer, it means at least some of the application code can be written in HTML, CSS and JavaScript, and leveraged across devices and mobile OSs.
Sometimes the Best of Both Worlds
The hybrid app model, although not suitable for all app development needs, provides a best of both worlds solution for a very wide range of downloadable apps. It is the approach we often take and recommend if the client does not explicitly need the polish and performance of a native app.
Hybrid apps are not however, a panacea. The same caveats apply as described for mobile web apps. This brings me to the topic of responsive design.
Design Responsively
So what is responsive design? It is a web design philosophy on how to deliver solid, adaptive user experiences for an every growing number of web-technology-enabled devices - smartphones, tablets, laptops, desktops, TVs and more. There are volumes written on this subject. Here I will only briefly cover a few best-practices observations.
In it simplest form, the goal of response web design is to make each web application (or hybrid app) appear as if it were designed specifically for the device on which it's displayed (screen height, width, aspect ratio, resolution, orientation, OS conventions).
Responsive layouts
Responsive web implementations rely on the use of media queries, CSS and JavaScript to adapt the presentation of content to devices, as opposed to the user having to scroll, magnify or otherwise change their behavior to view the content. (See this simple interactive demo of what responsive layouts do).
For example, for a recent point of care clinical tablet app we designed, using responsive design, multicolumn layouts reformatted to a single column layout when the device switched from landscape to portrait mode. The same reformatting rule would apply anytime the screen size, resolution or orientation become too small to support multiple columns.
Responsive thumb zones
Responsive design also means being mindful of how people hold their devices, what icons they're used to seeing, and so on and so forth. For example, for iPhones, responsive design means designing navigation inputs for the screen-bottom bias of the thumb (where the thumb naturally rests on the phone screen). This will be different then screen-top and left-edge bias of a tablet. And of course different than the input experience with a desktop web browser.
Responsive content
Content should also be responsive. On smartphones, content should lead with primary navigation moving to screen bottom or tucked away to a side. Content itself also needs to adapt. Reorganizing content on the page may not be sufficient for the brief and focused interactions on some smartphones. Responsive design would selectively display summaries with links to full content on separate pages. Images should also scale or selectively display cropped versions appropriate to the display.
Responsive design can and should be applied to native, mobile web or hybrid apps. The differences are the tools and technologies to implement the design.
Other posts in the series: Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering
- Understand the competitive landscape, profile target users & define ROI
- Bring in a user experience design team at the start of a mobile project
- Validate core functionality and design up front for all platforms
- Fit mobile contexts: device, location, mobility, immediacy, communication
- Design mobile as a companion solution
- Choosing Native, Mobile Web, or Hybrid Responsive Designs
Next Steps:
If you have an existing SaaS /mobile app, contact us to see an example of a diagnostic user experience assessment. If you are launching a new product, ask about a fast track proof of concept.
This is #5 in the series of posts on: "Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering"
In a previous post I talked about companies with existing web-based or SaaS solutions, needing to resist adding in too many features to their mobile version. The most successful mobile apps focus on doing a few things incredibly well, rather than doing many things adequately. The services are designed specifically with mobile interactions in mind. Flipboard for example, could be delivered as a web-based product, but the experience would not be as compelling (or as addictive) as it is on mobile.
Mobile should not be a "dumbed down" version of your web-based SaaS
Too often new clients come to us thinking that their mobile offering should be a a "lite" version of their web or SaaS software. They envision some kind of "dumbed down" version constrained by screen real estate, but still squeezing in as much functionality from their web version, as possible.
Another common approach, that is more user savvy but still not optimal, is to define the mobile app as a narrow subset of features and UI from their web-based SaaS solution.
Defining the what before the why
The difficulty with both the "dumbed down" and "subset" approaches is that you are starting with a feature set and then trying to reverse engineer the user experience. You have a solution (the what) before you have even determined the problem (the why) that needs to be solved in the mobile context.
90+% of the time, what users want to do on they mobile device is very different from what they want to when sitting at their desktop. Most interactions on mobile will last less than a minute and almost all less than 10 minutes. The challenge we address is creating experiences that users actually value and will use within this mobile context. This may overlap but will not be the same or offer the same experience as what they want to do on their desktop web version.
What users ask for vs what users want
Importantly, what user ask for and what they really want and will actually use can differ significantly. Focus group research and tech support reports may tell you one thing. But their is no substitute for user studies, user validation and data metrics/observation to reveal what users actually do. We design the user experience for these validated scenarios.
Start basic and build a track record
As a general rule, we advise clients to start with limited, extremely well designed services, rather than expansive, complicated offerings. Determine which activities will be done by a typical user 90 percent of the time, and then make those tasks perfect. Limited-function, high value services that are specific to the mobile context and become part of a user's daily routine can be used to establish a track record, build trust, engender attachment and encourage recommendation. You can subsequently add refinements, additional innovation and new features based on user data/requests later, when you push updates. But simplicity and focus always remains a priority.
Side note: There is a Ted podcast How to make choosing easier, about the negative impact of offering people too many choices and options. This is very relevant to keep in mind when designing any application, but in particular mobile apps.
Companion vs duplication
If you have an existing SaaS or web-based solution, design your mobile app to be a companion solution that distributes the application appropriately to the mobile context rather than duplicating the web version. In many cases, because of the GPS, accelerometer, camera and other hardware, there are opportunities to add content and features to mobile experiences beyond what is available in the web version. In other cases you may just design a mobile-centric approach to get at or communicate information that could also be obtained from a web version. In either case, the mobile app will use the same backend services, but the user experience should be tailored to mobile so that offers companion functionality, providing a service that feel unique from the web-based service.
Other posts in the series: Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering
- Understand the competitive landscape, profile target users & define ROI
- Bring in a user experience design team at the start of a mobile project
- Validate core functionality and design up front for all platforms
- Fit mobile contexts: device, location, mobility, immediacy, communication
- Design mobile as a companion solution
- Choosing Native, Mobile Web, or Hybrid Responsive Designs
Next Steps:
If you have an existing SaaS /mobile app, contact us to see an example of a diagnostic user experience assessment. If you are launching a new product, ask about a fast track proof of concept.
This is #4 in the series of posts on: "Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering"
The user experience on mobile is very different than what one gets via a web-app or a desktop app. It is essential to design the user experience to fit within the bounds of the user's focus and the mobile context.
Device
Smartphones and tablets have limited screen real estate compared to the desktop web environment. You can't (successfully) cram a full desktop web experience into a mobile device. HTML 5 is not a panacea in this regard.
Location and Mobility
By definition, mobile users are not confined to a fixed location like a desk. Rather they are out of the office, in transit and on the go, using their mobile application during a free moment away from doing something else. (75% of smartphone users report they conduct business on their phone in the bathroom, which, as others point out, means 25% of smartphone users are liars.)
Location, such as at a customers site, can be very relevant to the kinds of interactions, alerts and services the application user values.
Immediacy
On average mobile users spend less than 1 minute using any one app. There is not a lot of opportunity for "lean-back" kinds of interactions. User experience and functionality need to be designed to support and enhance these quick in-and-out interactions.
Communication/Social
The always-on, anytime-ness, Â anywhere-ness of mobility fosters an individuals sense that they are the center of the social web. Much of their focus is spent receiving or disseminating information. Mobile apps will be more successful when they support social interaction/sharing and reinforce the sense of being at the center of things.
Design Guidelines for the Mobile Context
The above five characteristics of the mobile context help define several design guidelines:
- Enable users to act quickly on time-sensitive information. Reduce clutter, reduce distractions, eliminate complex forms or typing
- Add location-specific context
- Alert users to take action (such as when their bank balance drops and they are about to trigger a fee)
- Make it easy to communicate and share information (visually, via social media, email, video)
- Build in features/activities that can fit into the micro-moments of everyday life adding on-the-go value
- Identify other daily repetitive activities or exiting mobile workflows and piggy-back on to these
- Define defaults that insightfully map to real user user behaviors
- Design for simplicity and easy visualization regardless of the interaction
- Differentiate by refining the user experience rather than piling on the features
- Focus on several very tightly defined high-value scenarios and implement these well
In general you want to define functionality makes sense to complement existing desktop or web functionality (as opposed to duplicate functionality). Take advantage of the action-oriented, anytime, anywhere nature of mobile.
Many companies make a costly mistake in assuming they can design their website using HTML5 and then have identical functionality available on the web or tablet or smartphone. Having one code base and making all functionality available on all devices is a recipe for disaster.
Meet and study users to determine the mobile functionality that will be meaningful and highly valuable in a mobile setting for 80% of the targeted users. The best mobile applications cut down the functionality to just what makes the users successful and want to return often.
Other posts in the series: Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering
- Understand the competitive landscape, profile target users & define ROI
- Bring in a user experience design team at the start of a mobile project
- Validate core functionality and design up front for all platforms
- Fit mobile contexts: device, location, mobility, immediacy, communication
- Design mobile as a companion solution
- Choosing Native, Mobile Web, or Hybrid Responsive Designs
Next Steps:
If you have an existing SaaS /mobile app, contact us to see an example of a diagnostic user experience assessment. If you are launching a new product, ask about a fast track proof of concept.
This is #3 in the series of posts on: "Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering"
If you are in the planning stages for a new software release (new product or update to existing product), now is the time to design for how that application will behave across desktop, web and mobile form factors. You may not be ready to release a mobile product or you may be planning to to roll out different device solutions at different times. Regardless, you should begin designing with mobility and mobile form factors as key initial parameters to build against.
You can't shoehorn a Core i5 quad-core processor with 16 GB RAM into an iPad
My desktop machine has a 3.1 GHz quad-core processor, 16 GB of RAM and 27 inch HD display. My peers who are gamers, have significantly more powerful systems. The high level of baseline hardware specs on modern desktops/laptops means users can run some incredibly sophisticated and computationally powerful applications. However if you target desktop systems as your starting point for a new software release, you will invariably design applications that take advantage of this level of pure horsepower. If you then later try to design for mobile you will spend a significant amount of effort trying to shoehorn the high performance desktop design into a mobile device.
For example, if you design your web application to view detailed 3D environments using an Active-X or Flash plug-in, you are going to struggle when you try to provide some kind of viewing solution on an Android tablet or iPad.
In contrast, if you begin your strategic planning/design with cross-device development in mind and in fact optimize the application with a mobile component in mind, the application will always have mobility as part of its core DNA. The high performance using limited hardware, precise user definition, laser-focused workflows and clean design that are the hallmarks of successful mobile user experience, can also greatly inform the design of desktop apps. It is much easier to add features and functionality to take advantage of more horsepower and more screen real estate on the desktop, then it is to pare down an existing resource-demanding application to deliver a successful experience on a mobile device.
Design for distributed experiences across multiple device touch points - not duplication
I will cover the concept of companion functionality in more detail in an upcoming guideline but for now I want to emphasize that when you strategically plan for your next software release, focus on providing users a continuous, distributed experience that delivers what is appropriate and most valuable for a given device context. The functionality of your mobile app should not and probably cannot duplicate the functionality of your web app. Instead as a user moves from desktop web browser to mobile they should feel the experience is continuous, intelligently adapting to the context they are in at the moment.
For example, a smartphone is well suited to quickly checking an account balance or receiving an alert when your low bank balance is about to trigger a fee. However, paying bills is much easier online using a desktop/laptop computer with its full keyboard and multiple windows for display. The design for each environment should take into account both the device constraints as well as an understanding of what users are likely to be doing when using the app (e.g. sitting in a chair at a desk vs running to catch the underground). By designing for desktop, web and mobile at the same time, you can create the experience of a smooth and continuous flow between devices, both visually and contextually.
The take away guideline
During the strategic planning and design phase for a new software release, complete and validate initial core designs (4-8 views) across each platform (desktop, web and mobile) that will be part of your ecosystem. User validate the functionality to be included on each platform across user experience, availability, performance, scalability adaptability, security, and ROI. Follow this methodology even if applications on each platform will be release at different times.
Avoid making the mistake that you can design for one platform, say for example a desktop web browser, and then retrofit for other platforms like a tablet or smartphone at some point in the future. The way in which you implement your mobile solution should direct your application strategy and design decisions for desktop and web solutions - everything from architecture, functionality and visual design to presentation layer technology.
Other posts in the series: Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering
- Understand the competitive landscape, profile target users & define ROI
- Bring in a user experience design team at the start of a mobile project
- Validate core functionality and design up front for all platforms
- Fit mobile contexts: device, location, mobility, immediacy, communication
- Design mobile as a companion solution
- Choosing Native, Mobile Web, or Hybrid Responsive Designs
Next Steps:
If you have an existing SaaS /mobile app, contact us to see an example of a diagnostic user experience assessment. If you are launching a new product, ask about a fast track proof of concept.
This is #2 in the series of posts on: “Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering”
Why do so many mobile products fail?
One key reason is that the product strategy and functionality is defined early on based solely on input from product managers, software engineers, or marketing/sales. If user experience specialists are brought in at all, it is only after the product had been defined.
If you want to improve the odds of success for your mobile solution, you need to bring in a user experience design team to the brainstorming process as early as possible. Use them to drive design at both a strategic and product level. Ideally you should engage a user experience team even before you issue a requirements document or RFP.
This “pre-RFP” team can help your product managers/marketers to evaluate the competition (hint: its not about features), model & segment your users, uncover unmet desires, define metrics for success and discover missed opportunities. They can also help your engineers resist adding in too many features, enabling them to “get it right” by knowing what to leave out. The end goal of this collaborative enagement is to come up with a product definition for experiences users will want and and functionality they will use, rather than just an app they will download and then let “collect dust”.
A UX team can also help you look at your product strategy as a whole to help define a mobile app that continues and extends functionality to the mobile context rather than duplicating existing desktop, web or in-store touchpoints. This lets you step back from your own thinking and look through the eyes of your users, learning about their experience and expectations.
Once a user experience design team has worked with you to define an innovative product and the product life cycle, then you can issue an RFP to have a UX firm actually design, iteratively validate and develop the mobile application.
Even if it is not possible to bring in a user experience design team before the requirements document has been created, bring them in to the project as early as possible. Work with them interactively to challenge and extend their designs while iteratively testing with users. The user validation will provide specific and actionable information into what customers and users actually need - not just what they say they want or what the company thinks they want.
As a note: when I refer to a user experience design team, I am referring to a team of specialists collaborating across several design disciplines. At a minimum you need a Ux architect, interaction designer/visual designer and technology architect. Each of these disciplines is sufficiently unique from the others that one jack of all trades will not be able to do the job. This is particularly true with mobile. You can try building your own 3-5 person team in house, hire an external user experience firm or even hire contract part-time specialists in each discipline.
Other posts in the series: Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering
- Understand the competitive landscape, profile target users & define ROI
- Bring in a user experience design team at the start of a mobile project
- Validate core functionality and design up front for all platforms
- Fit mobile contexts: device, location, mobility, immediacy, communication
- Design mobile as a companion solution
- Choosing Native, Mobile Web, or Hybrid Responsive Designs
Next Steps:
If you have an existing SaaS /mobile app, contact us to see an example of a diagnostic user experience assessment. If you are launching a new product, ask about a fast track proof of concept.
If you haven't already developed a mobile solution as part of your SaaS offering, then you probably will soon. If you have already developed one, then you probably need to make it better. This statement is the motivation behind this series of posts on Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering.
Each post will share some of the insights for cross-device UI and application design that Catalyst has gained in our work with hundreds of clients facing similar challenges on how to optimize the user experience and functionality across desktop/laptop and mobile applications as part of their SaaS solution ecosystem.
This first guideline in the series addresses the critical "getting started" issues of understanding your competition, profiling users and defining what qualifies as success.
Survey your competition
With companies in every industry rushing to develop mobile solutions, it is imperative that you survey your competitors to understand the features and user experience that they bring to the market. Superior design requires on-going awareness of the competition and its customers (insider tip: check social networking sites to find out what users say about your competition).
Once you understand your target users' tasks and scenarios (I'll address this in a future post), you need to test those same tasks/scenarios against competitive alternatives. You don't want to launch an "also ran" product. Plan again to revisit the competition after your product launches. This will enable you to run a head-to-head benchmark assessment against the competition, evaluate benchmark assessment data, and target changes for future releases
Segment your users
While doing competitive research it is also imperative to define and segment your user population. This will help you come up with the users most important to your business or where you think you can have the biggest impact through a mobile product.
The goal of this segmentation is to narrow the scope of your population before you perform deeper user research, real-world observations and define user personas. Is your market task workers? Information workers? Wannabes? Super-connecteds? Or is it more specific such as sales executives in Pharma? Or is it existing users who generate the most profit in your current application?
Your mobile solution does not have to elicit want and desire from everyone who sees it. But it does need to be relevant and desirable to mobile users with the demographics and needs it is intended to meet.
Also try to determine how many users do you actually need to reach to justify each new iteration of your application? Is the number of user predictable? Is there an upper limit?
Define ROI metrics
The critical final piece of this first guideline is to clearly define what metrics you want to track in the software and what will define measures of success. In other words, what will you define as successful ROI.
Many VPs of Development or C-level executives are accustomed to thinking of UI and app design as something subjective - a matter of opinion. But when it comes to mobile where the user experience and the application are one in the same, how you design the user experience design is not at all a matter of taste or personal intuition. The impact of the design has measurable and repeatable financial ROI. Think of mobile UI design a performance center on equal footing with marketing, R&D, advertising and sales.
Coming up with these measures (and designing software to measure them successfully) is not always easy. But it is imperative to define user experience metrics (qualitative and quantitative) that demonstrate strategic and financial value within the context of your business. Examples:
- Performance latency - how quickly does the app and navigation react to user actions
- User productivity - accomplish specific tasks faster, with less steps and fewer errors than competition or existing apps
- Scenario or conversion analysis for specific tasks
- Analyze leakage points and completion rates
- Recommendability - would you recommend this app to a friend or colleague
- User surveys - e.g. compared to other websites (across industries) how does the app meet your expectations
- Web analytics for traffic or downloads
- Conversion / acquisition
- Retention / churn
- Discoverability of features
- Reduction in support costs / training
- Increased sales / signups
Once you have determined the metrics then:
- Define how you measure the metrics
- Define what are considered levels of success
- Establish a baseline measure of user experience metrics prior to going live (competitive analysis an existing app, or a mobile web site app)
- Define a timeframe for when you measure metrics in testing and post launch
- Measure and evaluate
Other posts in the series: Design Guidelines for Incorporating Mobile Apps into Your SaaS Offering
- Understand the competitive landscape, profile target users & define ROI
- Bring in a user experience design team at the start of a mobile project
- Validate core functionality and design up front for all platforms
- Fit mobile contexts: device, location, mobility, immediacy, communication
- Design mobile as a companion solution
- Choosing Native, Mobile Web, or Hybrid Responsive Designs
Next Steps:
If you have an existing SaaS /mobile app, contact us to see an example of a diagnostic user experience assessment. If you are launching a new product, ask about a fast track proof of concept.
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.
Looking for more information?
If you have an existing sustainability application or are thinking about developing a companion mobile solution, contact us about a 21-day user experience assessment for sustainability applications.
