Fifteen screens of onboarding, rebuilt as seven you can click through.
A working prototype, the decision behind every screen, and a fixed-price plan to ship it. Nothing on the phone below is a picture: every control validates, fails, recovers and carries its state to the final screen the way the shipped app should.
Shorter is the brief. Fewer decisions is the job.
Drop-off is rarely about screen count alone. It is about how many times a new user has to decide whether to keep going, and whether each ask comes with a visible reason.
01.1What you asked for
Your iOS app onboards new users through fifteen screens. You want it shorter, and you want it redesigned rather than trimmed. We have not seen the current flow yet, so the seven steps in this document reflect what fifteen-screen onboardings in this category usually contain: a value carousel, phone verification, identity checks spread over several screens, a suitability questionnaire, a funding step, permission prompts and a summary.
The first thing we do in week one is redraw this map against your actual screens.
01.2What we propose
Seven steps, each doing the work of two or three of today's screens. Verification, identity and funding stay, because regulation and your compliance team want them, but each becomes one screen with inline states instead of a chain of confirmations.
Every step is editable later from the final screen. Every “skip” lands the user in the app, never in a dead end. Permissions are asked for after the user has a reason to say yes.
01.3Why this shape
Seven decisions, each with a stated reason (“regulators require this before you can trade”), test better than fifteen small ones with none. The prototype in section 02 is the argument: click through it, break it, and watch the flow map and the decision log follow you.
The rest of this document is the plan to ship it: scope with explicit exclusions, a six-week schedule with payment tied to milestones, and the assumptions we are making so you can correct them while it is still cheap.
Seven steps, three views, one state.
Click any node in the flow map, or tap through the phone. The map, the phone and the decision log stay in sync. Use the ⓘ Spec button under the phone for each screen's layout tokens, states and events.
Sub-labels show how many of today's screens each step absorbs (illustrative).
Own the market on your terms.
Open an account, link your bank and place a first trade in about two minutes.
- Regulated brokerage. Your money stays yours.
- No minimums, no paperwork, no jargon.
- Everything you set up here can be changed later.
Takes about two minutes. Already have an account?
What's your mobile number?
We'll text a six-digit code. No password to remember.
Standard message rates may apply. We never call you.
Code sent to .
Prototype note: any six digits verify. 000000 shows the failure state.
Confirm who you are.
Regulators require it before you can trade. Two scans, about forty seconds.
- Front of documentNot scanned
- Back of documentNot scanned
Encrypted in transit, deleted from this device after verification. Prototype note: the first front scan shows the retake path.
How much movement can you live with?
This tunes what we suggest first. It never limits what you can buy.
Illustrative allocations, not advice. Your suitability rules decide what appears here.
Link the account you'll invest from.
Read-only check that the account is yours. You approve every transfer.
Twelve generic banks in this prototype. Try “union” or “credit”.
Start with a small amount.
Most people start with less than a dinner out. Change or cancel any time before it settles.
Turning alerts on shows the iOS permission prompt next. We ask here so you know why before iOS does.
You're set.
Set-up took 0:00 · everything below is editable
“Vantage” Would Like to Send You Notifications
Notifications may include alerts, sounds and icon badges. These can be configured in Settings.
Sample market data and generic bank names throughout. Nothing is sent anywhere.
The drop-off lives at identity and funding. So does the upside.
Illustrative figures for a fifteen-screen flow in this category, and what the seven-step flow is designed to do to them. Week one replaces both series with your analytics, and the projection becomes a target we sign against.
Users reaching each stage, % of installs
Show as a table
| Stage | Current % | Projected % | Change |
|---|
Four screens of capture and confirmation become one checklist.
Retake happens inline, in place, with the reason stated. Nothing to re-read, no modal to dismiss. This is the single biggest projected gain, and the one we would instrument first.
Funding stops being a gate.
Search-first bank picker with a manual fallback and an honest “skip for now”. A funded account is a retention metric; treating it as an onboarding gate throws away users who would have funded on day three.
How the projection is built.
Each stage gets a conservative lift from the specific change made there (fewer confirmations, inline error recovery, priming before permissions). We show the arithmetic in the week-one audit and revise it against your event data before anything is signed off as a target.
What is in, and what is deliberately out.
The right-hand column matters more than the left. This is where fixed-price scope risk actually lives, so it is written down here rather than discovered in week four.
| Workstream | In scope | Out of scope |
|---|---|---|
| 4.1Audit of the current flow | Heuristic review of all fifteen screens Read of your existing analytics, if any Consolidation map, 15 → 7, annotated | Recruiting and running moderated user tests (available as an add-on, see 06) |
| 4.2Flow and wireframes | Seven-step flow with every branch: OTP failure, document retake, bank unavailable, skip paths Low-fidelity wireframes for each state | Flows outside onboarding: portfolio, trading, watchlists, settings |
| 4.3High-fidelity screens, iOS | Light and dark appearance Dynamic Type at default, large and accessibility-large Every state named in the spec drawer: default, focus, loading, error, empty, success | Android, iPad and web layouts Marketing or App Store assets |
| 4.4Interactive prototype | Clickable Figma prototype This HTML prototype updated to the final design, for stakeholder and compliance review | Production Swift or SwiftUI code |
| 4.5Design system slice | Tokens (colour, type, spacing, radius, motion) as Figma variables Components used by onboarding, with variants and states | A full app-wide design system or migration of existing screens |
| 4.6UX copy | Every onboarding string: titles, helper text, error messages, permission priming | Legal, regulatory and disclosure copy. We place it; your compliance team writes and approves it |
| 4.7Handoff | Per-screen spec sheets (layout, tokens, states, motion) Event taxonomy for the onboarding funnel Two developer Q&A sessions and async questions through week six | Analytics implementation and QA of the shipped build beyond the acceptance review in milestone 5 |
Change is fine, silence is not. Anything that moves from the right column to the left is quoted as a separate line item before work starts on it, never absorbed quietly. Anything that moves the other way reduces the invoice for the milestone it belonged to.
Six weeks, five milestones, payment on acceptance.
Each milestone ends with a review and a deliverable you can hold on to even if we never speak again. The dashed weeks are your review windows; the diamonds are invoices.
Schedule and payments
One fixed price, itemised by milestone.
Fixed price means the risk of our estimate is ours. It holds while the assumptions in 08 hold. Add-ons are priced separately so the core number stays comparable.
| Ref | Milestone and deliverable | Timing | Amount (USD) |
|---|---|---|---|
| M1 | Audit and consolidation map. Annotated review of the current fifteen screens, funnel baseline from your analytics, the 15 → 7 map redrawn against your real screens. | Week 1 | 2,800 |
| M2 | Flow, wireframes and copy. Every branch and state in low fidelity, all onboarding strings drafted, event taxonomy proposed. | Week 2 | 3,600 |
| M3 | High-fidelity screens and prototype. Light and dark, three Dynamic Type sizes, Figma prototype plus this HTML prototype updated for compliance review. | Weeks 3–4 | 6,400 |
| M4 | Design system slice and handoff. Tokens as variables, onboarding components with variants, per-screen spec sheets, developer session one. | Week 5 | 3,200 |
| M5 | Build support and acceptance. Async design QA on the build, developer session two, acceptance review against the checklist in 09. | Week 6 | 2,000 |
| Total, fixed price | 18,000 |
| Ref | Optional add-on | Timing | Amount (USD) |
|---|---|---|---|
| A1 | Moderated usability test of the prototype with five recruited participants matching your target investor, with a findings memo and changes folded into M3. | Weeks 2–3 | 2,400 |
| A2 | Android adaptation of the seven screens, following Material conventions where they differ from iOS. | +2 weeks | 4,800 |
06.1Terms
Invoiced on acceptance of each milestone, payable within seven days through Upwork. No deposit. Milestone 1 is a natural exit: if the audit shows the flow needs something other than what this document proposes, you keep the audit and we re-scope or stop.
06.2Not a quote for
Engineering, analytics implementation, KYC vendor fees, App Store review, or design work outside onboarding. If any of these turn out to be needed, we will say so in the milestone review and price it separately before touching it.
Six things, flagged by when they bite.
The schedule assumes each of these arrives on time. Where one slips, the milestone that depends on it slips by the same number of days, and we tell you the day it happens.
- The current fifteen-screen flowbefore kickoff
Screenshots, a screen recording, or a TestFlight build. This is what M1 is redrawn against. - Whatever analytics exist for onboardingbefore kickoff
An export or dashboard access. If there is none, we baseline from the audit and say so in the projection. - Brand assets and any existing Figma filesbefore kickoff
Logo, type, colour, component library if one exists. We design inside your brand, not the one used in this document. - Compliance constraints for identity and fundingend of week 1
Which fields are mandatory, which disclosures must appear where, and the KYC provider's SDK states. These shape screens 03 and 05 directly. - A named engineering contactby week 3
For the two handoff sessions and async questions. Half a day of their time across weeks five and six. - Feedback within three working days of each milestone reviewthroughout
Consolidated in one place. Where a decision is contested, one named person breaks the tie.
Defaults we have taken where the brief was silent.
Each is cheap to change now and expensive to change in week three. Tell us which are wrong and we adjust the plan before kickoff, not the invoice after it.
- iOS only, English only. Localisation and Android are out of scope; the design system slice is built so both are additive later.
- Phone-first sign-in is acceptable to your compliance team. If email and password are required, screen 02 gains a second state, not a second screen.
- A KYC provider is already chosen and its SDK drives the capture. We design the surrounding states; we do not replace the vendor's camera view.
- Funding is not a hard gate. Users can enter the app unfunded. If regulation says otherwise, screen 05 loses its skip and the projection in 03 is revised down.
- No paywall or plan selection inside onboarding. If one exists today, we recommend moving it behind first value and will show the alternative.
- The risk profile is a preference signal, not the regulatory suitability assessment. The regulator's questions live in account review, where they can be long and precise.
- Sample data in the prototype is replaced by your real tickers, banks and copy in M3. Nothing here implies an integration exists.
- Review feedback arrives within three working days. The six-week schedule is built on that cadence.
Each milestone has a checklist. Acceptance is ticking it.
No “looks good” by email. The checklist is agreed at the start of the milestone, so both sides know what done means before the work begins.
09.1Acceptance
Every milestone opens with a written checklist derived from this document: which screens, which states, which appearances, which Dynamic Type sizes, which copy. At review, you tick each item or mark it with a change request. Two rounds of revision per milestone are included; a third is quoted. If we have not heard back five working days after a review, we treat the milestone as accepted so the schedule holds, and we say so in writing the day before.
09.2How we handle change
Anything that changes the scope table in 04 is written up as a one-paragraph change note with its effect on schedule and price, and only starts once you have agreed it. Small things inside a milestone are absorbed without ceremony. The distinction is simple: if it would move a row between the in and out columns, it is a change; if it would not, it is the work.
Confidentiality: your flow, analytics and brand materials are used only for this engagement and are deleted from our systems on request after acceptance of M5.