SILA: SDK DEMO
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 stable coin 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:
When I started at Sila, the employee count had barely entered the double-digits, and the SDK demo was in very early stages. At that point, the demo had been built by a few developers, and it lacked the front-end experience needed for our prospective customers to truly stay engaged and understand the offering.
The main challenge here was to design a user experience that could cater to the two types of prospective customers: the developer and the business person. Additionally, it needed to be a seamless experience so our Sales team could effectively use this demo during their sales pitches.
Original Demo:
Here are some screenshots of the original demo, and what I started with. As you can see, the demo lacked a clear hierarchy that would give a user an idea of what the first and next steps should be. There is also a need to update the demo to match the company's brand identity.
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 surrounding the existing demo, I conducted a few internal interviews with the main stakeholders: our sales team, including the VP of Growth, and our customer success team, including our Director of CX. Here’s what I discovered:
This demo was built by engineers, and it catered to engineers. However, the majority of the time, our sales team was pitching the demo to CEOs and Founders. This revealed a need for a front-end experience that catered to prospects who did not code, while also exposing our API endpoints to dev teams who would potentially be integrating our product into theirs.
The demo did not have a clear hierarchy of actions. The original layout did not provide an obvious flow from start to finish. This could be confusing for customers who wanted to explore the demo independently.
There were still plenty of endpoints that needed to be added to the demo over time. The structure of the demo needed to be scalable and accommodate various flows. The current solution had not taken that into account.
Overall, the interface needed a facelift, as this was the main tool being used to help the sales team close deals. It lacked polish and refinement.
Goals:
Design an SDK demo that catered to both CEOs and developers, while making it digestible and easy to follow for the sales team and customers alike.
Personas:
Prior to this project, I had done many customer interviews to create personas for the product and engineering teams to refer to during big product initiatives. For this project, I referred to the Developer external persona as well as the Founder external persona to keep an empathetic lens.
User Flow Overview:
For MVP, we focused on refining the already existing user flow of signing up an individual end-user onto our platform. This includes a user signing up with a handle, and providing personal information to pass KYC (Know Your Customer.) From there, the user needs to check to see if they passed KYC, which allows them to link a bank account to their digital wallet, and transact by issuing, transferring, and redeeming Sila!
Ultimately, we needed to capture the entire onboarding process of a customer’s end-user from start to finish, while making sure each endpoint was represented.
Lo-Fi Design Concepts:
I explored many different ways we could structure this demo, and weighed the pros and cons of each potential solution. What I wanted to stress with each design, was the ease of use and the seamless integration of an API response panel. I presented each design to the stakeholders and we debated which best fit our needs. Here are a few of the options:
With the “Walkthrough” approach, I liked how:
• It was great for forms and questionnaires, without the need for scrolling
• The timeline-style navigation was a great way to visualize progress
• This approach guides a user naturally through the flow
• It’s a good structure to scale as the product does
The only downside I considered for this approach, is that a user can’t see all of the information at once. However, I wasn’t convinced that was necessary.
With the “Accordion” approach, there were a few pros:
• If the accordion drawers were left open, all information would be visible to the user at once
• The top-down workflow is an obvious hierarchy of actions
• This setup allows users to easily go back and forth between steps
The two concerns I had for this structure were the likely need for a lot of scrolling, especially as we added more endpoints, and the fact that it wasn’t ideal for longer-form questionnaires.
With the “Timeline” approach, there were a few pros:
• The timeline provided a clear step-by-step workflow and allowed users to navigate back and forth between steps
• The wide interface left room for forms and questionnaires
However, there were a few cons to this structure. I didn’t like that a user couldn’t see both the interface and the API response at the same time. Additionally, the response center would only show the API responses for each step, requiring a user to go back to a specific step to see the API response they were looking for.
Solution and Lo-Fi Wireframes:
After reviewing these options with the stakeholders, we opted to go with a combo of the Walkthrough and the Timeline. With these two solutions, a user could simultaneously view their progression in the flow and the various API responses they have received as they’ve completed their actions. The left side of the screen shows a true front-end experience for our business users, and the API response panel satisfies the needs of our developers by displaying each endpoint that they’ve encountered.
Below are some screenshots of the various steps I built out:
To use this demo, a user would need to provide their app credentials, which they could set up on the Sila Console.
For the MVP version of the demo, we only mocked out the full KYC requirements. Down the road, we would add various KYC levels.
Transacting was the last step in the demo, where a user could issue Sila to their digital wallet, redeem Sila to their bank account, or transfer Sila to another digital wallet.
An overview of the various steps being mapped out for the MVP version of the demo.
Hi-Fi Designs:
After many walkthroughs of designs and prototypes with Product, Engineering, and my main stakeholders, we felt we had a solid design that solved all of our initial pain points, and we knew we could keep building off this solution. We now had a demo that:
Catered to two different types of customers: Developers and CEOs
Was intuitive to use and helped users understand our product better, which made us confident customers could explore this on their own time
Matched our branding and felt more polished
Was easy to navigate and engaging for sales pitches
The release of this demo directly correlated to an increase in signed deals post demo presentation! It became a crucial tool for explaining our APIs to prospective customers. Additionally, independent use of this demo by our customers increased dramatically, based on our findings in hotjar!
Hi-fi of the original KYC registration screen.
Hi-fi of the original bank account linking screen, where a user could demo our Plaid integration or manually enter an account and routing number to connect a bank.
This demonstrates our integration with Plaid, which allows users to instantly connect their bank accounts by logging in to their banks with their credentials.
The MVP version of the Transaction page allowed users to choose a bank account to issue Sila from, and allowed users to transfer Sila to other users on the demo by entering their handle in the destination.
Further Design Iterations:
As more people began using the demo, including our sales team and prospective customers, we needed to add more endpoints and scale this demo further. While I added more functionality, I updated a few design features for a slicker interface to cater to our customer's needs, based on survey findings:
• Customers wanted the ability to easily refer back to their API responses
• Customers wanted more references to our docs and helpful content
As time went on, the original navigation bar felt limited and like it was taking up too much room in the content well. The horizontal nature of the original bar didn’t work well with scaling. I updated it to an expandable/collapsable vertical bar to save some space. This upgrade allows us to add more steps within the timeline without crowding the component.
I also added the ability to expand and collapse previous API responses, so developers could go back and see all responses over time.
Further along, I added more links to our customer-facing docs, helpful modals, and a tip section to give users more context into what was happening on the screen and why. More and more customers began referring to this SDK demo as they were integrating with our product, and we wanted to provide them with a quick way to reference external resources without having to search on their own.
The transactions screen received a design upgrade, I created a tabular system to separate Issue, Transfer, and Redeem to save space.
The addition of KYB:
Eventually, we added KYB (Know Your Business) into our demo, which represents business onboarding, a much bigger beast than KYC. This was a complicated flow to add to the demo, and my approach was to make it as straightforward as possible.
The registration screen for KYB Standard, which is one of the few KYB levels you can choose from in this demo to register your business under.
With business onboarding, information about the Controlling Officers and Beneficial Owners of the business had to be collected, along with general business information. Each business member needed to pass KYC, in addition to the business passing KYB and being certified.
Every business needs an administrator to be registered, here we collect all the necessary information to register this type of business member. I added the ability to link an existing user that was previously registered during a KYC session, to save the sales team time as they were presenting.
Once the business information and the business member information has been collected, they can request KYB. Both the business and the business members will undergo an identity verification process in the background.
Takeaways:
Scalability should be at the forefront of design decisions when building a product like this. Knowing that this demo was meant to accommodate dozens of endpoints, it was crucial to communicate to stakeholders the importance of scalability when presenting them with solutions.
Adding useful tips, industry terminology, and external resources into the demo empowered users to answer their questions without having to look too far or waste valuable time trying to uncover the answer. The demo shouldn’t leave its users with more questions than they had when they arrived!
Good design is never done! What worked for the MVP might not be the best solution for future iterations of the product. It’s important to keep the design evolving as the business needs evolve as well.