How to Create Demos of Secure Applications for Potential Customers and Clients

So, you’ve decided that you want a demo of your behind-the-login site or application… Great choice! Site demos allow sales people and potential consumers to observe the experience of a secure environment in the absence of an actual login. There are lots of reasons why creating a demo to simulate these sites is a good idea:

  1. Sales teams often don’t have access to an internet connection when they are demoing a site to a potential client. Our demos can be downloaded to their desktop and can work in the absence of an internet connection.
  2. Test environments are notoriously unreliable. Looking at broken functionality or a site that just won’t load is almost worse than not being able to connect to it at all.
  3. With all of the data and security requirements, developing new functionality within secure environments is time consuming and expensive. Demos can provide an excellent sandbox in which the value of potential features can be demonstrated at a relatively low cost.

Our experience designing complex behind-the-login applications makes us uniquely qualified to create demos of these experiences. In fact, we’ve written in the past about the value of demos and different ways to approach their development.

This article focuses on what we’ll need from you to ensure a smooth implementation of your demo and will provide some pro tips on things to consider before getting started.

Often our clients expect that because we are rebuilding something that already exists, that they we’ll be able to complete the work with little or no input from them. This is an assumption that has gotten us into trouble in the past. In this article, we get real about what it takes to create a demo of a behind-the-login site or application.

Time and attention

The most important resource that we will need from you as we develop a demo of your site is time.

First, there will be time invested in helping us determine the scope of the project. We don’t recreate every piece of content and functionality of the secure environment. Rather, we focus on key functions and content– the ones your potential customers will be most interested in viewing. We’ll need you to help us decide where to focus our efforts and exactly what should be built.

After the scope has been finalized, we will need continued access to our clients to ensure that we are proceeding according to plan. More often than not, we create demos of applications that we did not design. We require input from subject matter experts to answer questions that arise about how to handle a new scenario or situation. If you plan to spend time digging into the details with us throughout the course of the project, we can avoid delays that arise from a lack of input.


Access to a test environment

In order to create a high-fidelity demo that behaves like the real environment, the Crux Collaborative team is going to need access to that environment. There are three ways that this access can be provided.

  1. The least desirable way for us to build a demo is using static screen shots. We can stitch together a demo using screen grabs, but these images don’t flex to the size of the browser and often appear blurry due to low resolution. In addition, we are not able to easily scrub personal information or sensitive data from an image the way we can with selectable text in HTML. While it is not ideal to create a full demo using screen caps, we sometimes incorporate a few screen grabs just to show the experience of complex or interactive pages that would be cost prohibitive to fully recreate.
  2. A better way to create a demo is to get on a WebEx with the client or technical team. They login to the environment and we take control of the meeting. Using our magic code-capturing software, we are able to pull down the HTML and associated assets from the application. We can then rebuild the experience with generic customer information and details provided by our clients.
  3. The best way to build demos is with full access to a test environment. In these cases, we are lucky enough to be provided with a URL and a login to the actual environment. This is ideal because it allows the Crux Collaborative team unfettered access and the ability to continually login to cross check our work with the live environment. This can help lessen our need for input from the client team.

Its important to figure out how this access will be provided and we sometimes need a lot of lead time to get it setup. Our clients often need to coordinate with IT, risk management, or even HR to get us what we need to create demos.


Additional considerations

Often, there are different behind-the-login experiences for different users— additional features may be available to users that have a certain medical plan or who live in a specific part of the country. It’s important to remember that our demos are static and decisions will have to be made about what features and functionality we want to show. If you’re trying to incent potential customers to purchase additional products, then including optional features/functionality is a great idea. However, if you’re demonstrating a health-care management portal to potential customers, they will be disappointed if their experience differs from what they saw before signing up.

These situations are handled in one of two ways.

  • The first way is to create separate versions of the demo for different purposes and audiences. This is ideal, but each new version involves added scope and budget.
  • The second is to create a single version of the demo that shows the most typical feature set and includes the content that the majority of users will experience. In this scenario, we add a disclaimer to clarify that “this is a demonstration of the actual experience and may contain different functionality than your login…”

Like anything else worthwhile in life, creating demos requires time, energy, and attention to detail. Our experience has taught us that these demo products are well worth the investment. If you are thinking about creating a demo for your website or application, contact us. We’d be happy to walk you through our process.

Related Insights