Inktavo — UI/UX case study.
Card management and dashboards rebuilt inside a print-commerce platform — the money layer of a product people open to run a business, not to do banking.
- Client
- Inktavo
- Role
- Product / UX design
- Sector
- Fintech — embedded payments
- Surface
- Web dashboard and mobile app
Context
Inktavo is a platform for print and decorated-apparel businesses. The card management module sits inside it: issuing, controlling and reconciling spend for shops whose staff are not finance people.
That is the constraint that shapes everything. This is embedded fintech, so the money screens have to feel native to a production tool while carrying the precision that anything touching a card has to have.
What the design had to do
Make spend legible at a glance
A dashboard that answers “where did the money go” before anyone opens a report.
Keep control obvious
Freezing a card or changing a limit is high-stakes — it cannot be buried or ambiguous.
Work on the shop floor
Approvals happen away from a desk, so the mobile app carries real weight, not a cut-down view.
Replace this with the brief in Inktavo’s own words, plus the one constraint that shaped the most decisions — timeline, tech, compliance, an existing design system, or a stakeholder. This is the part a hiring manager reads first.
Process
Embedded fintech has an unusual constraint: the module has to feel like part of the host product while holding a much higher bar for precision. Every step below was pulled between those two.
Understand
Learn the host product first — Inktavo’s existing patterns set the ceiling for how different a money module is allowed to look.
Research
Understand who actually holds the cards: shop staff and owners, not a finance team, doing this between production jobs.
Wireframe
Lay out the dashboard around the two questions asked most — current balance and recent spend — and demote everything else.
Visual design
Numeric hierarchy above decoration: tabular figures, clear states, and colour reserved for status rather than styling.
Prototype
Test the destructive actions specifically — freezing, limits, reissuing — where a misread costs real money.
Handoff & support
Component specs covering every card state, so engineering isn’t inventing edge cases at build time.
The steps above describe what each stage had to solve on Inktavo. What turns that into a case study is the evidence — add, for any two or three of them:
- Who you spoke to, and the one finding that changed the design
- A decision you made, and the option you rejected
- Something that tested badly, and what you did about it
- A wireframe or screen — before and after beats a finished shot
Outcome
Financial tooling justifies itself by removing manual work, so the measures are about effort saved rather than screens shipped.
Time to complete a common card action, before and after
Support tickets about spend or card status
Share of card actions completed on mobile
Adoption of the module among existing Inktavo accounts
Put real figures against the four above, or strike the ones you can’t evidence. If Inktavo never shared numbers, a single sentence from the client about what changed is still worth more than a blank. Right now no project on the site states an outcome, and that is the biggest gap in the portfolio.
Working on something like this?
Available for full-time and contract work across fintech, healthcare and SaaS.