Toranj App — Insurance
The app guides people through choosing a plan, completing policy requirements, paying, and managing their investment after purchase.
Insurance and investment in one app
Rose Toranj combines insurance with gold-based investment. Afran combines insurance with a fixed-income fund.
The app covers choosing a plan, entering an amount, completing identity and address details, reviewing the proposal, paying, checking the policy, adding funds, withdrawing and managing bank accounts.
It was designed in Persian, from right to left, with mobile as the main screen size.
Keep the purchase short without hiding requirements
Buying either plan requires insurance, identity, financial and payment information. The challenge was to collect it without turning the journey into one long form.
The app also had to support what happens after payment: checking the policy and investment, adding funds and withdrawing money.
Product design from architecture to handoff
I worked as the Product Designer over a three-month period, collaborating with the Product Manager, Front-end Developer, and Back-end Developer.
- Information architecture
- User flows
- UX design
- UI design
- Design system
- Prototyping
- UX writing
- Design QA
- Developer collaboration and design handoff
Three parts: enter, buy and manage
I divided the app into three parts: entering the product, choosing and buying a plan, and managing it after purchase.
Identity and address requirements appear inside the purchase journey. Deposits and withdrawals stay attached to each policy, while profile and bank-account details remain available across the app.
- AuthenticationMobile numberOTP verificationAccount access or creation
- OnboardingPortfolio visibilityPlan introductionSecurity and control
- Home and discovery
- Rose ToranjGold-based investment
- AfranFixed-income investment
- AmountTerms
- IdentityNational IDBirth date
- Postal information
- Proposal reviewAmount editing
- Pending paymentExternal payment
- PortfolioAggregate valueBalance privacyPoliciesAdditional plan discovery
- Policy detailCurrent valueUnitsWithdrawable amountInsurance informationCosts and allocationDepositRedemption
- TransactionsPurchaseDepositRedemption
- Bank accountsRegistered accountsAdd accountIBAN validationBank identificationOwnership verification
- ProfilePersonal informationIdentity statusPostal informationBank accountsSupport and information
- System statesLoadingEmptyValidationWarningNetwork errorPendingSuccess
From plan discovery to an active policy
Plan discovery
Review Rose Toranj and Afran.
Select Rose or Afran
Load the relevant purchase state.
Enter investment amount
Format the value and show the minimum and estimated units.
Complete identity requirements
Validate national ID, birth date, and mobile ownership when required.
Complete postal requirements
Validate the ten-digit postal code and retrieve or update the address.
Review proposal
Review costs and amount, with the option to edit.
Prepare payment
Refresh payment details and obtain a reference.
External payment
Continue to the external payment gateway.
Active policy
After successful processing, the policy appears in the portfolio.
The interface validates the investment minimum, required identity information, and postal code before creating a proposal. A proposal awaiting payment remains editable, allowing the user to review its financial information or revise the amount before leaving for payment.
After activation, the policy becomes part of the portfolio and provides access to current value, policy information, deposits, redemption, and transactions.
Structure before surface
Seven low-fidelity screens show how the product was structured. These are retrospective documentation artifacts and are not presented as the project’s original wireframes.
Login + OTP
Plan discovery
Investment amount
Identity + postal
Portfolio dashboard
Two-stage redemption
Policy detail
Why the journey works this way
Identity and postal information appear when required for policy issuance instead of being presented as one long preliminary form.
Keeps plan selection and amount entry visible before requesting more demanding information.Users may not know every requirement at the beginning.Rose uses a burgundy visual identity and gold positioning. Afran uses blue and fixed-income positioning. Both follow the same purchasing and management structure.
Users can distinguish the plans without learning two different interfaces.Plan colors require clear boundaries from general account and system actions.Current value, payable amount, unit count, and withdrawable value receive greater emphasis than supporting metadata.
Decision-critical values are easier to scan.Detailed policy screens can still become dense.Identity, date selection, postal code, amount editing, deposit, redemption, and account creation use bottom drawers.
Users retain the context of the current plan or policy.Long tasks require careful control of drawer height and nesting.Redemption separates the number of units being sold from the destination-account decision.
Users can review the estimated value before selecting where the funds should be sent.The additional step increases interaction length.A registered, ownership-verified bank account is required for redemption.
Reduces the risk of transferring funds to an unrelated account.First-time redemption may require account setup.The interface checks minimum investment, maximum redeemable units, national-ID and postal-code formats, Iranian IBAN validity, issuing bank, duplicates, and account ownership.
Preventable errors are surfaced before a financial request is submitted.Persian content uses RTL structure while phone numbers, IBANs, dates, monetary values, and other identifiers retain appropriate numeric formatting.
The interface reads naturally in Persian without compromising the legibility of financial identifiers.One structure for two different plans
- Rose and Afran plan discovery
- Investment amount and proposal review
- Identity and postal requirements
- Pending payment
- Portfolio dashboard
- Rose and Afran policy details
- Deposit and redemption
- Profile and verified bank accounts
- Loading, error, empty, and success states
Key interactions
- 01
OTP entry, disabled state, and resend timing
- 02
Onboarding progression
- 03
Rose/Afran plan switching
- 04
Formatted investment-amount entry
- 05
Identity validation and Persian date selection
- 06
Proposal editing and payment preparation
- 07
Balance show/hide control
- 08
Transaction filtering
- 09
Deposit validation
- 10
Unit-based redemption with percentage shortcuts
- 11
Destination-account selection
- 12
Loading, error, and success feedback
Reusable product patterns
The product uses Peyda for Persian typography and a mobile content frame of up to 440px. Its main neutral surface is a light grey-blue, with white and muted surfaces used to group information.
General product and account actions use Toranj green. Rose introduces burgundy accents, while Afran uses blue. The plan theme continues through purchase, policy details, deposit, and redemption.
Peyda weights from Thin to ExtraBlack, supporting a clear and readable hierarchy across Persian interfaces.
#006B54Toranj greenGeneral actions#8E3F4CRose burgundyGold-plan identity#1769AAAfran blueFixed-income identity#E9EEF3Interface greySurfaces and data
More than the ideal purchase path
A concise evaluation of the final experience
Strengths
- Covers the full journey from purchase to ongoing policy management.
- Preserves clear differentiation between Rose and Afran.
- Exposes financial constraints and estimates before submission.
- Includes meaningful loading, validation, failure, pending, and success states.
- Uses reusable interaction patterns across both plans.
- Handles Persian RTL content and financial identifiers deliberately.
Opportunities
- Increase the size and contrast of secondary text.
- Separate summary values from technical policy details more clearly.
- Reduce variation between card and surface treatments.
- Apply a stricter rule to general versus plan-specific accent colors.
- Standardize small controls and icon containers.
Risks
- Dense policy information may be difficult to scan on smaller screens.
- Small filters and percentage shortcuts require touch-target validation.
- Mixed RTL/LTR information requires accessibility testing.
- Contrast, focus order, keyboard use, screen readers, and 200% zoom have not yet been formally validated.
Principles reinforced by the project
- Intermediate states are as important as the ideal start and success screens.
- Compliance requirements should be sequenced around the user’s primary task.
- Different financial products can retain distinct identities while sharing one interaction model.
- Mobile financial interfaces need a strict hierarchy between summary values and technical detail.
- Deposits and redemptions should expose limits and estimates before submission.
- Persian financial products require deliberate handling of RTL content and LTR identifiers.