PROJECT NAME
Axecraft: Pricing Intelligence Suite + Website Design
HIGHLIGHT
90%
Target treasury quote adoption through Rate Intel
50%
Target reduction in quote response time vs baseline
2
Interconnected phases shipped under one design system
ROLE
Product Designer
Scope
Led end-to-end design for the Pricing Intelligence Suite and public website, spanning IA, system behaviour, and brand-to-product alignment.
TIMELINE
2 Months
TEAM
PM, QA, Frontend, Backend
OVERVIEW: What I owned, and what I was solving for
Axecraft is a fintech operating across African currency markets. Their treasury team quoted rates manually across WhatsApp, screenshots, and memory. I was brought in to design the Pricing Intelligence Suite: a two-phase internal tool giving treasury one reliable place to see, enter, and act on rates.
My scope covered the full product design surface for both phases: Rate Intel (Phase 1) and TagOps (Phase 2), including information architecture, system behaviour, dashboard design, form flows, role-based access, system states, and audit traceability. I led the design end-to-end and collaborated with engineering during implementation, ensuring the public website and internal admin system spoke the same language: trust through transparency.
Part 1: Pricing Intelligence Suite
THE CHALLENGE
Rates lived in scattered signals. Different team members quoted different prices. No one could answer "where did this rate come from?" or "why was it quoted this way?"
This created three failures:
Speed: Customers left before responses arrived
Consistency: Trust eroded when quotes varied
Safety: Underprice errors went undetected until margin was lost
Structuring the system
The Pricing Intelligent Suite was designed as a system with four core principles:
Every rate must be explainable: Rate Decision Record appears on every rate, showing signals, costs, and guardrails triggered
The system protects before it corrects: Guardrails clamp rates before output, with explicit "Clamped" messaging
Roles shape what you see: Role-Based Access Control (RBAC) with four distinct jobs (Super Admin, Operator, Compliance, Engineering), not hierarchy levels, different relationships to data
Freshness is a first-class signal: "Fresh/Stale" badges on every rate, never buried in settings
RATEBOARD: THE DECISION SURFACE
RateBoard is not a scoreboard. It is where treasury decides what to quote. The interface shows recommended rates with freshness status, but the core design is the Rate Decision Record — a live reference that appears when expanding any rate.
Key elements:
Currency pair with current recommended rate
Fresh/Stale/Clamped status badge
Expandable Decision Record showing: reference rate, total uplift, guardrails triggered, signal blend
RateBoard: Currency pairs with live rates, freshness badges, and expandable decision records for explainable quoting
RateDesk: Controlled Manual Entry
When automated signals fail or the treasury analyst has market context scrapers can't capture, RateDesk provides structured manual entry. The form captures not just the rate, but source evidence and notes, making entries defensible, not just logged.
Key elements:
Currency pair selector (dynamic, admin-managed)
Direction (Buy/Sell)
Rate input
Source/Evidence field (e.g., "Bybit P2P thread link")
Notes for context
RateDesk: Structured input capturing rate, direction, source evidence, and notes for defensible manual entries.
Partner Cost: Margin Protection
Before rates reach customers, Partner Cost configures the cost models and margin floors that protect the business. This is where the "machinery" of pricing is tuned.
Partner Cost: Cost model and margin floor settings protecting business viability before rates reach customers.
Pair Config: Dynamic Expansion
The pair-agnostic architecture means new currency corridors are configuration, not rebuilds. Pair Config manages which pairs are active, their signal sources, staleness thresholds, and deviation limits.
Pair Configuration: Dynamic corridor management enabling new pair activation through configuration, not rebuilds.
TagOps: Customer Intent Layer
TagOps bridges Rate Intel's market rates to customer-specific pricing. Rules adjust recommended rates by basis points (e.g., VIP −10 bps), scoped by pair and direction.
Key design constraints:
Single-tag enforcement per customer (MVP simplification for auditability)
Floor guard prevents any adjustment from breaching absolute margin limits
Rule versioning and full decision records
TagOps: Active customer tags with basis point adjustments, pair scoping, and versioning for intent-based pricing.
Audit Log: Cross-Surface Traceability
Every action across Treasury and Admin surfaces flows into a consistent audit schema: actor, action, entity, before, after, timestamp. Compliance doesn't need to know which screen something happened on.
Audit Log: Cross-surface action history with a consistent schema for compliance without screen-specific knowledge.
Part 2: Website Design
THE CHALLENGE
Axecraft needed to shift from "high-touch manual service" to "scalable institutional platform" without becoming faceless. The website had to signal serious business credibility while preserving the human reliability that built their customer base.
The Strategy: Confidence Through Mechanisms
Borrowing from global-grade OTC/FX players (Corpay, Thunes, StoneX, Payset), I designed around a specific pattern: sell confidence, then back it with mechanisms + proof. Not features. Not vibes.
Axecraft Website: Institutional landing page with 9-section flow from explanation to conversion, responsive across breakpoints.
OUTCOME: What the system was designed to produce
≥ 90%
Of treasury quotes for active pairs generated using Rate Intel
100%
Of tagged quotes with a full rule and tag decision record
<10s
Median time to produce a quote-ready rate after fresh signal ingestion
Beyond the metrics, the system removes a specific type of organizational risk: the person-dependent rate. When pricing lives in someone's memory or WhatsApp, a team member being unavailable is a quoting failure. When it lives in Rate Intel, the system holds the knowledge. Treasury operates at full capacity regardless of who is online.
REFLECTION
On the pricing intelligence suite, the hardest design decision was restraint. The temptation was to surface everything: every signal, every config value. But treasury only needs two answers: What should I quote? and Can I defend it? Every screen was structured around those questions. The Decision Record answers "defend it." The recommended rate card answers "quote it." Everything else exists to make those answers trustworthy.
On the website, it was the external expression of the same reliability architecture built into the pricing tools. The messaging structure (promise → proof → friction reducer → CTA) mirrors the system's behavior (signal → blend → guardrail → output). Trust is built when language and mechanics align.
What I'd validate earlier: The 60/30/10 signal weight split and staleness thresholds were designed in-product. These defaults shape first-week behavior and should be validated against how treasury actually values sources under different market conditions. The configuration surfaces exist to tune these, but defaults are design decisions too.
OTHER Case Studies