Installment Buy.
A product war room.

Protecting time to understand the problem.

With such a short deadline, choosing the wrong problem would be expensive. Once development began, there would be little room to change direction.

We divided the window into one week for discovery and one week for design and development. Reserving half the time for discovery was a deliberate decision. We needed a reason to believe that what we built would matter to users.

We started with two questions:

• For people who had already traded on Walgold, what limited further purchases?
• For people who had registered but never traded, what prevented their first purchase?

We also observed that people who were already Wallex users traded more frequently on Walgold. That made trust a hypothesis worth exploring, although the association alone could not explain the difference.

To investigate, we divided users into four groups:

We began with short calls across the four groups, then used a survey to check the themes emerging from those conversations. To fit the research into the first week, we outsourced the survey work.

A funding barrier we could address.

We chose to focus on the amount of money users needed at the time of purchase. It connected a user constraint with our immediate business objectives: increasing purchasing activity and sales.

Our problem statement became:

People who want to buy gold for long-term savings may not have enough money available when they want to purchase. Concern about inflation and rising gold prices can make that delay feel consequential. How might we reduce the upfront funding barrier for these users?

This gave us a concrete way to evaluate ideas. A solution needed to address the gap between the amount users wanted to purchase and the money they had available at that moment.

We identified active users, monthly sales, and average order value as the measures we wanted to influence. These connected the proposed change to participation, overall purchasing activity, and purchase size.

A shared decision: let people pay over time.

At the end of the first week, we brought the team together to generate ideas and vote on a direction. The problem statement gave us a common basis for comparing the proposals.

Involving the whole team brought different perspectives into the decision. It also gave the people who would build the solution an opportunity to shape it before the delivery week began.

We selected gold installment buying. The proposition was to spread payments over time, reducing the amount of cash required upfront. It addressed the funding constraint directly enough to become the focus of our second week.

Existing infrastructure came with a delivery cost.

Saturday, the start of the second week, was devoted to working out how to deliver the feature.

Our first plan was to use lending technology already developed by another team within the holding company. Reusing it appeared to offer a shorter path to launch.

As we examined the integration, two concerns emerged. Fitting the existing product into Walgold's journey would compromise the experience we wanted to deliver. Coordination between the teams could also consume a significant part of the remaining week.

We decided to build the required functionality within our own team. We believed we had the technical capacity, and the decision gave us more control over the experience and the delivery dependencies.

With only the delivery week remaining, engineering needed to begin while the design was still in progress.

Give engineering enough clarity to start.

We benchmarked local online and offline installment purchase experiences to understand familiar patterns in the Iranian market. This gave us a starting point for the flow within a very compressed schedule.

By Sunday, I had designed the wireframes, secured agreement on the installment purchase flow, and handed it to the backend team so they could begin development.

At that stage, the flow was the most useful design artifact. It made the sequence of actions and the structure of the experience concrete while leaving room to finish the interface.

Frontend development also began before the complete design was ready. As I worked through the UI, I had to consider both development effort and the time left to implement it.

That overlap required close, continuous communication with the frontend team. Design decisions were moving into implementation quickly, so misunderstandings and changes needed to surface early. The work depended on keeping design and engineering aligned throughout the week.

Make the commitment visible before purchase.

The purchase screen brought the amount of gold and the repayment plan into one decision. Users could adjust the purchase amount, choose a three-, six-, or twelve-month period, and see the installment amount and total repayment before moving forward.

The confirmation screen then collected the credit amount, payment schedule, and fees in one review. It also explained that the purchased gold would remain frozen until repayment was complete. The restriction belonged in the purchase decision, as well as in the wallet afterward.

A successful purchase led to a receipt and a direct route to installment details. That next step mattered because the purchase was the beginning of an ongoing repayment journey.

The purchase continued in the wallet.

The gold purchased in installments stayed frozen until every installment had been paid. That condition made the wallet part of the purchase experience: the purchase flow had ended, but the gold still carried a restriction tied to repayment.

The wallet needed to make that status understandable after checkout. Showing the purchased gold as frozen kept the repayment condition connected to the asset users had bought. The details screen then brought together repayment progress, the current installment, and payment history.

Thirty days gave us a second delivery window.

We also had to decide how much of the repayment journey to include in the first release. The first users could encounter overdue or non-payment states only 30 days later. That gave us a way to sequence the work within our deadline.

To launch after one week of design and development, we deferred both the design and implementation of those states until after the installment purchase feature went live.

After launch, we began designing and implementing overdue and non-payment handling. The initial two-week project had taken us through discovery and the first release; work on the later part of the journey continued from there.

The later non-payment design shown below communicates a cancelled installment purchase, explains the resulting financial breakdown, and retains the installment history. It represents a different moment in the journey from the initial purchase and its confirmation.

What changed after launch.

We launched the first version within the two-week window. After release, the project reported growth across sales and user activity.

The movement in sales and activity was an encouraging signal for the direction we had chosen.

Speed depended on clarity.

The hardest part of the project was deciding where to spend two weeks. Competitive pressure made the deadline urgent, but it was the focus on a specific purchasing barrier that gave the team something concrete to build.

Discovery narrowed the opportunity. The problem statement gave us a way to choose. Early wireframes let engineering begin while I continued the interface design, and close collaboration helped us carry that decision through to release.

The timing of the user journey also shaped the order of delivery. Knowing when the first users could encounter a missed payment let us begin that work after the initial launch.

For me, the project showed how much delivery speed depends on clarity. Each decision needed to give the next person enough understanding to move forward.

Original Persian product screens from the previous Walgold version, with English annotations. Select any screen to enlarge it.