Akulaku is a fintech unicorn in Southeast Asia, offering consumer credit, digital banking, wealth management, and insurance brokerage across Indonesia, the Philippines, Thailand, and Malaysia. Its digital bank, OwnBank, aims to be a one-stop platform for payments, savings, and wealth management.
This design focuses on "Own Wish," which helps users set savings goals and build a saving habit, while expanding OwnBank's wealth management offerings and market position.
Initial prototype
Challenges & Solutions
Solution 1— Splitting the main user flow
In the original flow, users had to set a savings goal, understand the Wish Tracker rules, and make a decision on the same page, which created a high information load.
Therefore, the user flow was redesigned to make goal creation the main flow, while Wish Tracker became a separate optional flow. New and returning users were given different entry paths. New users completed product education through a Feature Landing Page, while returning users could go directly to the Own Wish Dashboard.
The flow was simplified using Progressive Disclosure, so information was shown only when it was needed, reducing cognitive load and making the journey easier to follow.
A Feature Landing Page was added before the setup flow—shown to users only once—to completely separate product education from the savings process. The overall experience followed the framework of Emotion → Solution → Reward → Action.
Solution 2— Emotional design
Solution 3— Restructuring the information architecture
Main page actions were reduced from 7 steps to 3, with the interface clearly split into a display area and a setup area.
UI Design
Reflection
The most valuable part of this project was building a complete information architecture and user flow, and using storytelling to turn long-term saving into a journey around future life goals. However, the biggest lesson was not delivering a new savings feature. It was developing a deeper understanding of what design should solve, and recognizing that the understanding of product strategy was still limited at the time.
Initially, the product team was inspired by Commitment Devices used in fitness and language learning products. The goal was to increase the completion rate of long-term savings plans through Commitment Deposits and Loss Aversion. This idea seemed convincing because it had worked in other behavior-change products. Therefore, the problem was treated mainly as a UX problem: the flow was too long, there were too many actions, and the information load was too high. The design focused on interface-level improvements, such as simplifying the flow, reducing steps, improving hierarchy, and adding emotional design. The assumption was that users would accept the mechanism if the rules were explained clearly.
However, the review showed that the real challenge was not the interface, but the mechanism itself. Users had to decide how much to save and for how long, while also understanding what the Commitment Deposit was, why it had to be paid in advance, when it would be refunded, why it could be deducted, and how the bonus pool worked. More importantly, if the deposit was actually deducted, users were likely to question whether the platform was fair and whether the rules were transparent. In other words, the mechanism increased not only information complexity, but also the cost of building trust. The design reduced operational effort, but it did not reduce decision effort or psychological overload.
But a more important question was whether this incentive mechanism matched the users of this product?
This project showed that a mechanism should not be evaluated only by whether it is theoretically sound. It also needs to match users' expectations of the product. Previously, most attention was given to interface and flow, with the assumption that a clear interface could solve most problems. However, this project showed that problems exist at different levels: some come from information architecture, some from interaction flow, and some from the product mechanism itself. When a feature tries to achieve too many product and business goals at the same time, interface design can reduce the learning cost, but it cannot resolve conflicts within the strategy.
If this project were redesigned today, much more time would be spent on product strategy before interface design. The focus would be on deciding which goals should be solved by the mechanism, which should be solved by operations or business strategy, and whether the mechanism truly matched user needs. This became the most important lesson from the project.