When we embarked on designing the new app, we aimed not only to improve on Tinlake, but also to add new capabilities (such as support for more tranches and loan types), offer more information (e.g. about assets), and allow issuers to manage their pools. The new app is for use with Pools on Centrifuge chain which will launch shortly and supersede Tinlake on Ethereum.
To create an outline of the scope, we compiled all required objects and capabilities. Albeit not a spec, this overview set the parameters for what the team sought to accomplish.
Since we needed a user interface to test the code audit, we cobbled together the minimum number of screens needed to support the required functionalities, like creating a pool and investing in a tranche token. The Proof of Concept (POC) was a preliminary app version – incomplete in scope and at a wireframe detail level.
This draft version contained a patchwork of views. Less than ideal, it showed that a single-page application layout might be the best solution for connecting all the different sections and detail views. This is why a vertical menu sidebar emerged as the main navigation element.
The open-source typeface Inter was chosen as the all-purpose font to provide the visual design foundation. And because credit financing is data heavy, we followed the design tenet of “content over chrome,” meaning that the content takes center stage against the backdrop of layout panels, like the menu, and the header.
The design concept defines how the user interface works. This involves defining the information architecture, the representation of information, and the task flows. It’s about shaping the activity which unfolds through the interaction between humans and machines.
Using the scope outline, the POC, and a crude concept map (a diagram defining the objects, attributes, and operations), we started creating a wireframe of every view. Each wireframe would define the content, and the components holding the information, like the menu, header, tab navigation, menu list, and table.
Like charting new territory, evolving the design was a messy process that took many iterations, including discussions, reshuffling content, and gradually refining the visual design. We kept iterating until we felt the app archetype stood solid and coherent across views. For example, while the read-only information of a given object detail is structured like a factsheet in the center column, the main actions (like “invest,” or “repay”) are situated in the column on the right.
To validate our design, we created clickable prototypes covering the main task flows of both investors and issuers:
- Investor: Screen, analyze, invest, redeem
- Issuer: Create and manage a pool, originate, finance, and repay assets
Witnessing a person try out your prototype for the first time is that magical, rewarding moment when you see how the design performs. We tested with 7 investors and 3 issuers, which demonstrated what worked and didn’t.
Testing with users allowed us to identify pain points before implementation: we found what was not understood, and which parts proved problematic because they caused erratic behavior in the majority of participants.
The findings were grouped and prioritized, and possible solutions were devised. Then we addressed the test findings by incorporating the action points into the design. For example, we merged token detail and pool detail, so that people would not have to navigate back and forth between two views or rely on their memory.
I trust this post gave you insight into our design process. But the story does not end here – we are still busy building and testing – and building more, and testing again.
Thanks for reading!