Insights from Behind the Login Experiences

A large percentage of our projects are behind the login web sites and applications. Our client’s business models and markets can be vastly different, but the layout of these interfaces and the business problems they attempt to solve are remarkably similar.

Over the last 3 years we have completed a large number of behind the login dashboard/portal redesign projects, and a many completely from scratch. In this article, we’ll take a look at some of the high-level themes that have emerged.

When the Application Already Exists

A high percentage of our dashboard/portal projects are redesigns. Clients generally surface an application, or more accurately, a collection of applications that have been around a while and need to be modernized. Typically we see a number of 3^rd party applications bolted together and the experience tends to be disjointed and both inefficient for the user and challenging for the technical team to maintain.

People are designed to resist change. When we start working on one of these projects, we often need to address some fear and concern that users will have trouble getting used to the new interface and the system will become even more inefficient, or that some functionality will be lost in the redesign process.

We find the best way to reduce the fear factor is to understand where the problems are from the user’s perspective by conducting some high-level baseline user research. Doing this helps us confirm trends that may be surfacing in site metrics and analytics reports. There is nothing more powerful than seeing your customers struggle to do business with you to build a case for change.

Another approach that we employ to manage the anxiety that can come with reworking a complex interface is to conduct a working session with members of our client team that support those who need to use the application to complete key tasks. In these sessions, we review and prioritize functionality that needs to be included in the interface. This helps us make sure we don’t miss or misunderstand the importance of any given piece of functionality in the system.

When It is Brand New

When we are approached to help one of our clients create a new application or product, we are often presented with some high-level business problems that the interface needs to solve.

Some of the most common ones we see are:

1. Reducing calls to the customer service center
2. Providing better communication between internal business groups
3. Giving customers a self-service option
4. Giving members the ability to interact directly with business to receive personal or confidential information
5. Modernization of an off-line software product

It’s not uncommon to discover that members of the client team and other project stakeholders often have different ideas about what the system will look like when all is said and done. It can be challenging to justify the budget and resources needed to create a new system. It’s critical to get all the stakeholders on board to collaborate and make sure the system provides business value and how it will be managed and maintained long-term.

Conducting some interviews with stakeholders, key customers, and employees who will use or manage the system helps establish priorities, uncover concerns, and generate new ideas that can help ensure the new system is providing value to the end users.

Checking in with stakeholder also creates an environment of inclusion and collaboration. We like to interview the most vocal people with the strongest opinions. It establishes buy-in, let’s them feel they are being heard, and are influencing the system. Doing this can help the project avoid the dreaded swoop and poop later.

Don’t forget to include your technical team. There is nothing more devastating to your timeline and budget than to have a beautiful design that can’t be implemented because your team wasn’t aware of the technical limitations and requirements. Additionally, the technical team will often surface ways that data can be displayed that your team was not aware of which can and often does lead to a better experience for the end user.

Roles and Users

One thing that all of these systems have in common is that they support many different roles, access privileges, and customizations. We’ve had clients claim they have up to 30 different user types who all need to use one application.

While we understand there tends to be many permutations and breakdowns of customer demographics, when we start digging in, the system actually supports a handful of user types or access groups that meet the needs of many of the roles that need to interact with the system.

We start this process by identifying the key tasks that users need to complete in the application. Once those are established, we look for opportunities where personalization, customization, and specialized functionality will have the biggest impact and address the largest groups of user types.

Edge Cases and Use Cases

At some point in our design process, someone will surface a use case that will affect 1% of system users. We call these edge cases. They are irrelevant at the beginning of the project because they pull an unreasonable amount of creative focus from the goal of defining the broad framework of the system. They can derail the ideation process by asking the team to consider the experience from a lens that is not relevant to most of the user base.

Instead, we work with our client teams to identify the key core use cases for the system and develop the experience from that vantage point. This allows us to make sure that the system makes the most frequent and important tasks easy and intuitive.

Once we have a solid foundation to work with, we work with our clients to make sure the edge cases are addressed.

Implementation

When we design complex data driven interfaces, our goal is to develop a comprehensive pattern library that is easy for the development team to implement. Ideally, these patterns will allow the system to handle all of the different data displays that the system will produce. However, situations arise that don’t fit neatly into the patterns that we’ve established.

It’s a common misconception that once implementation begins, the UX work is done. In fact, UX involvement during the implementation phase is the best way to address all those edge cases gracefully. Making use of UX resources during the implementation phase is critical to ensure that any additional functionality and content is incorporated in a consistent and strategic manner.

Long Term

Complex web applications are never really done. They must continue to evolve long after launch as technology and user behavior changes. One of the biggest mistakes we see is a company focusing only on the objectives of the business after launch and ignoring the users’ needs and goals. Don’t be tempted to add superficial features and content that may not be focused on the original core user goals and objectives in the hope to freshen up the site or application.

Your users’ needs change over time. Just because you checked in with them a year ago, doesn’t mean that they want the same exact functionality or content now. You may be missing out on a big business opportunity. Our most successful clients check in with their users regularly through research, surveys, and interviews. This effort can guide changes and enhancements that will produce the best return on investment.

Over the years we have designed and collaborated on hundreds of complex behind the login applications and dashboards. If you would like to learn more about our approach and methodology, we would love to chat.