Unifying User Workflows in Administration

Building a new administrative experience from the ground up to help both internal and external users get the most out of their workflows.

A Broken System; Problem Statement

nCino’s admin space had suffered years of neglect and disorganization by the time I was tasked with overhauling the experience in 2023. The space was an information architecture nightmare; no navigational framework had ever been established so product teams were left to their own devices to decide where feature configurations and admin tools should live.

My goal for this project was to focus on reorganizing and updating the Feature Management space in order to aid in the overall ease of navigation in Administration, increase feature adoption, and give product teams an assigned space to add their feature configurations.

Personas for this project included both external customer administrators and internal nCino developers. It was critical to consider both sets of requirements in the redesign of the admin space in order to maintain full usability.

Desired Outcome

The new Feature Management space needed to be easily navigable, organized, and have quick actions to complete implementations and updates. 

  • Increasing update adoption rates was a large incentive. Customer admins were frequently unaware of feature updates due to lack of visibility.

  • The new framework needed to account for additional individual feature configurations.

  • Users had also expressed interest in new features, such as an activity log to track implementation events and a filter for available feature updates.

Challenges

Bad Architecture
Due to lack of direction, the previous admin space was disorganized, poorly labeled, and difficult to navigate. Product teams had often been confused about where to add new functionality. The entire information architecture needed to be rehauled.

Duplicate Features
After the implementation of Feature Versions, all installed versions of a Feature needed to be represented in the Feature List, leading to duplicate Feature names with different version numbers.

Lack of Patterns
Admin was not built on any sort of informational or navigational framework, meaning it contained a number of clashing patterns that users had simply gotten used to over time.

Density of Information
Due to the number of available features and all their possible configuration options, there was a large quantity of data to display across each feature.

Final discovery stage post-it board with insights gathered from both internal and external user interviews.

User Research

To gather insights I met with the admin development team, various internal nCino product teams, and external admin users over 15 user interviews.

  • The admin development team directed an audit of the redundant or broken functionality in Feature Management and offered direction on the technical limitations of the SalesForce platform.

  • Internal product teams said they had no clear direction on where configurations should be housed. This roadblock often led to these teams tossing their configurations on the main admin page, cluttering it up.

  • External admin users brought to light the need for easy access points into feature documentation. They also expressed a need for more visibility into their implementations, including actions previously taken and available updates.

Competitor Analysis; Activity Log

One of the new proposed tools for Feature Management was an activity log to track user-initiated events. The desired outcome of this tool was to aid customers in identifying errors while implementing or configuring features.

I researched activity logs for other enterprise applications, making note of the similarities in the types of information they each displayed.

Side-by-side visual competitor analysis for the Activity Log

Ideation

Wireframes; Feature List & Activity Log

There were several iterations of the main feature list. A pattern using standard data tables to consolidate information was considered before I switched to a more graphically detailed list view with the toggle action.

Solution Proposal

  • Working together closely with my PM and engineering, we decided on workflows for the three major use cases; enabling a feature, implementing available updates, and accessing feature pages.

  • The experience would consist of the main Feature Management hub page with individual offshoot pages for each feature. Most of the major actions would only be accessible through the Feature Pages due to technical limitations.

  • The new Available Updates and Activity Log functionality would live in tabs alongside the main feature list for easy access.

User Flow; Main Feature List

The main feature list would be the hub of activity for Feature Management. When engaging with any of the major use cases users must first access the feature list.

User Flow; Enabling a Feature

Enabling a feature was more tricky than simply turning it on and off. Toggles were introduced for visual simplicity but the series of events they kicked off were complex and opened up a variety of potential issues.

User Flow; Implementing Updates

A separate workflow was necessary for implementing new updates as this functionality hadn’t been developed in the previous version.

Wireframes; Feature Overlay

The concept of the Feature Overlay was meant to streamline the user flow for implementing sub features and feature processes. However, technical limitations narrowed the scope to only display a read-only view, letting the user view feature details directly from the main list.

Wireframes; Feature Page

The early versions of the Feature Page were more like a Feature Hub, with a two-column card layout. Eventually it became apparent that the functionality was too dense to contain in cards and tabs were introduced.

Unifying Feature Management; Solution

  • The end result of Feature Management combined all the major use cases into one seamless experience.

  • Due to technical limitations users would still need to access individual pages for configuring features, however the new framework organized all future and available configurations. From then on developers would always know where to put new functionality.

  • The new Available Updates and Action Log features allowed users more visibility into the implementation of features and gave them more control over their processes.

Feature List

  • Adding a search functionality made locating a feature significantly faster.

  • New and deprecated features were now labeled for easy identification.

  • Users could access high level feature details from an overlay panel on the main feature list.

Available Updates & Activity Log

  • Users could now access newly updated features from a tab on the main feature list. The tab automatically filtered the list down to unimplemented updates.

  • The activity log was also added to a tab on the main feature list. New events would be added every time a user took an action in Feature Management.

Feature Page

  • Feature Pages were introduced to give each feature its own hub to house feature processes, sub features, feature configuration, and available documentation related to the feature.

  • Feature pages left plenty of room for future development based on individual feature needs as they came up.

Impact

  • The improved Feature Management experience was soon made available to users in beta, with the option to toggle between old and new versions. We solicited feedback from users via a survey and received overall positive feedback, praising the organization and clarity of the new experience.

  • With Feature Management set as the benchmark, the admin team was now able to shift focus to the admin experience as a whole. Feature Management’s success paved the way for a much larger overhaul of admin down the road.