Sila: Admin Console
What is Sila?
Sila is a Banking, Digital Wallet & ACH Payments API for teams building financial products and services. Sila offers a simple, secure, and scalable banking API to make money programmable with built-in regulatory compliance. Sila’s banking APIs replace the need for integrating with legacy financial institutions, saving months of development time, and thousands in legal and regulatory expenses. With the use of SILAUSD, a U.S.-issued stablecoin pegged to the U.S. penny, a user can store value and transfer money from bank accounts to white-label wallets.
As the sole Product Designer at Sila, I have worked closely with the Engineering and Product teams to build internal and external tooling from the ground up, designed to scale.
The Challenge:
As Sila began to grow, the need for the CX team to manage customer and end-user data without involving the Engineering team became more and more apparent. I set out to design a massive set of administrative tools for the Customer Success team to help them with tasks such as editing user data, viewing transaction history, granting production access to users, submitting KYC evaluations, and much more. The biggest challenge for this Admin Console project was that it needed to be completely scalable. The structure of this console would be the blueprint for all future tooling, internal and external. It needed the ability to search and sort through data and apply changes to independent profiles.
Limitations:
Because I had to work within a design system that I had inherited, the structure and layout of this admin console were determined by the components and modules that already existed.
Scope was a big factor here. At this stage in the game, we did not have enough development power to bring in tools that would help visualize data. We had to start small and continuously iterate.
Here’s a screenshot of the original landing page style navigation for the Console. The “block” style component was prevalent in the design system.
An example of the basic structure of an info page and editable fields.
The main table component for the Console. This component has a big presence in the admin tooling!
My Role:
As the sole product designer, I was responsible for the entirety of this design project, including the initial discovery and research phase, design exploration and execution, and hand-off to developers.
The Team:
•UX Strategy and Design
•Front End and Back End Engineers
•Product Manager
Pain Points to Address:
To uncover the pain points our CX and Engineering teams were experiencing around customer data, I conducted a few internal interviews with the main stakeholders: our Director of CX, Director of Finance, members of the Customer Success team, as well as a few Engineers. Here’s what I discovered:
Customer Success agents needed to rely on engineering to look up and update customer data, making the process of managing customer information almost entirely reliant on engineering, and very slow.
Engineers had to context switch constantly as they helped out with these tasks. It also took up a lot of engineering resources.
Both the CX and Finance teams needed a way to view transaction history across the product, as well as KYC/B information. At the time, this information was scattered across multiple places.
Goals:
Design an Admin Console that could scale with the company, eliminate the need for engineers to intervene with trivial tasks, make transaction information available to internal stakeholders, and increase the efficiency of the task flow for CX agents to search for and review and edit the customer/end-user data.
Personas:
One of my ongoing projects at Sila was to develop internal and external personas for the product team to refer to. As I was working on the Admin Console, these 3 internal personas I used to help keep an empathetic lens on my users.
User Flow Exploration:
With initial sketches, I was exploring two different approaches: separate dashboards, or universal search functionality. For the original scope, we were focusing on customers, end-users, apps, and the transactions associated.
As the flows evolved, the universal search idea became a filterable universal search. These original plans centered around the concept that there would be a single source of truth for all of this data, and you could get as granular as you need by filtering down.
Lo-Fi Exploration - Search Functionality:
I explored various design options here to determine which ones would be the most scalable and useable. The main idea I was delving into was searching and filtering to discover a “profile,” whether that be an end-user, a customer, or an app. The questions I set out to answer were:
Do we use a universal search for everything, or separate these parameters into different dashboards? Which is more scalable?
Here I explored the idea of all information being searchable in one place. The “search all” button could be converted into a more granular search for apps, end-users, and more. This is great in theory, but this required a ton of information to display, and the concern from product and engineering was the backend being able to support such large queries.
With the tab approach, I was keeping the universal search bar, while introducing the concept of two different tabs for two different dashboards. From there, a user could toggle between transactions and end-user data, without having to leave the page. I also was exploring more granular filtering methods here. The problem with an approach like this is that it’s not ideal for scaling. If we wanted to add more dashboards in the future, the tab approach would quickly become an issue.
One design solution that solved both these issues is separate dashboards, accessed through a landing page. The landing page navigation design was already included within the console design system, so we would be using a familiar component. Separate dashboards allowed us to scale with as many dashboards as we needed and kept database search queries limited.
Lo-Fi Exploration - Profile Design:
When it came to the structure of the entity profile, I knew a lot of editable information needed to be housed here. The questions I set out to answer were:
How should the editable profile be arranged? All information on one page? Separated into sections? What do these approaches look like? Which one will be the most scalable?
I explored the idea of different tabs within a profile to house grouped information. While this looks nice and could function well for a while, it would not lend itself well to scaling. These tabs would quickly become cluttered if we added more in the future.
The dashboard-style profile was attractive from a UI perspective because we could house a lot of information in one place. However, it felt less connected to the previous dashboard because of its structure. The many components of a dashboard create a clunky look, and I was worried the admin user would feel lost arriving here from the searchable table.
The card style approach had the same problem, a user would find themselves on another landing page, needing to choose a card for a user profile. This approach felt disconnected and required more cognitive load from the admin user to find the data they were looking for, and introduced more navigation. While this could be scalable, it wasn’t a great user experience.
I landed on a left-rail navigation design, which solved both the issue of this profile needing to scale, while also feeling connected to the previous searchable table. This provided a way to group information related to each profile, in a highly scannable way. This was the direction we went with!
MVP Hi-Fi Designs
After several walkthroughs with the main stakeholders, the MVP designs were ready to be rolled out. With the first few releases of this admin console, the most critical administrative actions were prioritized, with plans to add additional functionality as time went on.
We were now confident that this admin console:
Eliminated the need to involve Engineering in trivial administrative tasks, decreasing the number weekly of escalation tickets significantly
Increased the efficiency and speed of the task workflow for the Customer Success team, allowing the team to get more done in less time
Provided a simple front-end solution to search through a database, without any coding experience needed
Transaction information and KYC/B information were now centralized in one place
Here is an example of the MVP version of the End-User Dashboard. As you can see, all dashboards are accessed through the Sila Admin landing page. The MVP version of the End-User dashboard housed all high-level end-user information in one tab, with various actions. Eventually, more tabs would be added to create a robust administrative profile. Users can filter each column of the table to find who they are looking for.
UI Upgrade: Navigation Bar
One minor UI upgrade I added down the road was an expandable/collapsable navigation bar. I wanted to provide more room in the content well for our dashboards and features. The original navigation bar took up about 25% of the screen. What a waste of space! A collapsable version of this helped to clean up the look of the Console while providing more width for our tables.
Here’s an example of how the navigation menu took up a prime amount of real estate, squishing the Transaction dashboard where breathing room was needed.
Much better! The upgrade to an expandable/collapsable navigation rail helped with the readability of our dashboards.
UX Upgrade: Filtering
The MVP design of our filtering system focused on filtering one data point at a time. A user could expand the filter under the column within the table and filter down from there. This allowed the user to get as granular as they wanted.
We liked this approach initially, however, as more columns were added to tables upon request, I wanted to reduce the clutter. Additionally, it seemed more efficient for a user to assign all the filters at once and have one query load, vs multiple queries in one session.
This updated design reduced the time it takes to filter on multiple data points and was a better solution for smaller devices. Now a user can select as many filters as they want and search under one query.
Notable Functionality: Transactions
The transaction dashboard allows users to filter by multiple data points to find the specific action they are looking for. A user can search by date range, transaction amount, transaction status, and so on. The transactions are sorted by the most recently created.
Once a transaction is selected, a user can discover everything they need to know within the profile with expandable/collapsable tables that house links to other profiles within the admin console. The left-hand rail leaves room for future functionality and houses a log of the transaction’s status changes.
Notable Functionality: Doc Upload and KYC/B Monitoring
Our end-user dashboard houses the most important information surrounding the end-users on our platform. From here, a CX agent can edit the end-user information, which will automatically update the database, they can upload personal documents that aid in identity verification, and can view verification records.
Notable Functionality: Limits
As we added more functionality to the admin console, the concept of managing transaction limits was added. These limits were tied to a specific sales tier, so the configuration lived within a sales tier profile. There are 3 different types of limits, each with its specific configurable variables. A sales tier can have as few or as many limits as necessary.
After multiple stakeholder interviews and prototype testing, I designed an editable table that enabled internal users to view all of the limits assigned to a tier at once, giving them the ability to add, delete, or edit as they please, while also being able to scan the list. I also added a filter to the table, which allowed them to narrow down the view to a specific limit type or endpoint.
Notable Functionality: Customer Onboarding Checklists
As time went on, the need for a centralized place for the CX, Sales, and Compliance teams to manage the onboarding of customers became critical. The onboarding process was happening across multiple platforms, and this created an unorganized mess. Team members shared their concerns about not knowing who was handling what, and what was happening next in the onboarding process for each customer. As you can imagine, this created pain points both internally and for our prospective customers!
There was a need to align all initiatives under one platform, so I set out to add the following functionality into the admin console:
The ability to track onboarding tasks and assign them to internal users
A central place to house all prospect information, including customer due diligence information
A central place for all onboarding documents to be located.
The checklist tab is the bread and butter of this onboarding profile. From here, a user can select a checklist template they wish to use (managed in a separate dashboard,) and begin assigning internal users tasks. Any time a user gets assigned a task, they will be alerted by email. An assigned and completed date keeps everyone up to date on the various statuses of the tasks. Additionally, you can disable a task from a checklist if it is not relevant. Templates were used to ensure consistency across onboarding and to limit various one-offs, hence the need for disabling. We do, however, provide the ability to add a task to the checklist that wasn’t originally provided in the template.
The customer info tab houses all relevant prospect information and tracks all Due Diligence info in the form of editable tables. The document upload tab provides a place for all important customer documents to be housed and uses the same UI from our End-User doc upload. Prospects would be imported into this dashboard from Pipedrive for this MVP release.
Notable Functionality: Permissions
Eventually, a permissions dashboard was added to the admin console to limit access to all of the sensitive information and critical actions that can be performed. I opted for a role-based system, which defines permissions by the role assigned to a user.
This grid solution allows users to scan the available actions per space, and choose the appropriate permissions for the role being created. Each row can be expanded or collapsed, to accommodate various screen sizes and to remove any unnecessary data from view. All actions are based on the ability to read, create, update, or delete.
Each internal user will be assigned a role, limiting them to whatever permissions have been assigned to that role.
If I had no limitations…
If I could remove limitations and update the design system a tad, I would love to update the landing page design from clunkier blocks to a useable dashboard with a slicker navigation bar.
The landing page would include beautiful data visualization that shows trends within a customer’s transactions, API requests, and return history. This data could be downloaded, and the landing page could be customized to an internal user’s preference!
Takeaways:
This project is the epitome of the saying “design is never done.” As we continued to add more functionality, we needed to make sure our original designs were evolving. I feel the admin console will always be in a constant state of flux, as it continues to become more and more robust.
When you’re designing a massive product such as this, it’s crucial to reuse components when you can. Sticking to a scalable design system will keep the engineers happy and will allow for design iterations to go faster in the future.
With a project this long-term, it can sometimes result in design debt. Occasionally, functionality that seemed useful a year ago no longer is now, or a one-off design choice can later become a pain in the side when it no longer feels cohesive. Its important design decisions are intentional and work within the design system, to reduce scenarios such as these.