All Projects
UI/UX Design Web Development Portfolio Prototype 2024

Sprintex
Calculator

Interpolation-Driven Product Selection Engine

UI / UX Design Web Dev Systems Architecture 2024
Project type Independent portfolio prototype
Year 2024
Timeline 6 Weeks
Role UI/UX Designer & Developer
Request a walkthrough
TL;DR

I designed and built a browser-based portfolio prototype that turns flow-rate and pressure inputs into blower recommendations, interpolated operating estimates, performance charts, and downloadable reports. The prototype demonstrates the interaction and calculation model; it does not claim production analytics or collect lead data.

7 product configurations Two-stage spline interpolation <300ms design target Client-side calculation
7 Configurations in the
current JSON dataset
2D Pressure and flow
interpolation inputs
Target <300ms interaction goal;
benchmark pending
Demo No personal data is
collected or transmitted
01 — The Problem

From tables
to a guided
decision

Sprintex manufactures high-speed centrifugal air compressors with operating data organised by model, RPM, pressure, flow rate, and power. This independent portfolio prototype asks how a browser interface might help someone compare those conditions without working directly from several reference tables.

The challenge is not a simple product filter. Performance points sit at irregular intervals, and a requested pressure and flow can fall between recorded values. A useful interface therefore has to estimate between points, show how confident the match is, and keep the technical context visible enough to review.

The workflow is a design hypothesis rather than a measured production process. Its success criteria are deliberately practical: reduce manual comparison, return an understandable candidate, and carry the same result into a chart, cost scenario, and downloadable report.

Without user-research evidence, I treated the audience as a provisional mix of sales staff and technically informed buyers. That assumption led to a layered presentation: plain-language guidance first, operating values second, and calculation detail on demand. It also ruled out an interface that exposed the raw table as the primary view.

G.01

Guide the first decision

Turn flow and pressure inputs into a candidate model with enough operating context to begin a more informed technical conversation.

C.01

Be honest about estimates

Separate exact, interpolated, and close matches. Prototype estimates are never presented as engineering certification.

C.02

Work without a backend

Run selection, charting, savings, and PDF generation locally. The demo deliberately does not submit or retain personal data.

Reference-table and prototype workflow comparison

Workflow model — not a production time study

Reference-table flow
Interpret the requested conditionsmanual
Compare models and nearby data pointsmanual
Carry assumptions into the handoffmanual
Patternmulti-step
Prototype flow
Enter flow rate and pressuredirect
Inspect the match and performance curvein browser
Export the selected scenariolocal PDF
Patternguided
02 — Solution

A selector
that shows
its work

The user starts with two inputs: required flow rate and pressure. The selector evaluates the seven configurations in the prototype dataset, then returns an exact result, an interpolated estimate, or a nearby candidate when the request sits just outside a product envelope.

The result does not stop at a model name. It labels the match type, exposes estimated RPM and power, and plots the operating point against the available curve. This makes the recommendation easier to inspect and gives uncertainty a visible place in the interface.

The selected values then feed an optional energy-cost scenario and a client-side PDF. Because both read the same in-memory state as the result card, the user does not have to re-enter or reconcile values across separate steps.

Guidance is kept close to the action: units remain attached to inputs, invalid or unsupported values receive a specific response, and estimate language appears beside the recommendation rather than in a distant disclaimer. The chart supports the decision by showing context; it is not treated as decoration or proof of accuracy.

01 Search

Normalise the inputs, evaluate each operating envelope, and compute a candidate only when the data supports one.

02 Explain

Label the match type, surface RPM and power, and place the chosen point on the performance chart.

03 Carry forward

Reuse the selection in the savings scenario and local report so every output remains internally consistent.

Scope
UX strategy Interface design Data modelling Frontend development WordPress integration
Interface walkthrough

Three views of the same decision

These are schematic reconstructions of implemented states, not product screenshots. The example below uses a recorded point from the prototype dataset so the values remain traceable to the repository.

Verified dataset example

Input and result stay in one view

01 / 03

The operating point is present in data/prod.json. The schematic demonstrates hierarchy and state communication; its curve is illustrative rather than engineering data.

Result language

Four states, no false certainty

02 / 03
Recorded pointDirect dataset match
Exact
Estimated pointBetween supported values
Explain
Nearby candidateInside the 20% prototype band
Warn
No supported matchOutside the available range
Recover
Shared selection state

One result feeds every follow-up view

03 / 03
Interface reconstruction based on implemented calculator states and verified prototype data.
03 — Design Decisions

Three choices that shaped the experience

Decision 01

Treat interpolation as an estimate, not an answer

A lookup would fail between recorded points, while a single-axis calculation would ignore part of the operating condition. The prototype instead interpolates across pressure at fixed RPMs, then across the resulting flow values. That produces a more useful candidate, but the interface explicitly identifies it as estimated and leaves engineering review as a production requirement. This choice favours continuity and explanation over false precision: the result can support exploration, but it cannot replace approved product selection rules or a specialist's judgement.

Decision 02

Make the fallback visible and bounded

A silent empty state makes users question whether the tool worked. When no direct match is available, the selector can surface a candidate within a defined 20% proximity band and explain which input is outside the normal range. Requests beyond that band receive a clear no-match state instead of a fabricated recommendation. The threshold is an implementation default, not a validated engineering tolerance. In production it should be owned, reviewed, and potentially varied by product family rather than remaining a hidden global constant.

Decision 03

Keep the portfolio demo local-first

Selection, charting, the cost scenario, and PDF export run in the browser. That keeps the prototype easy to inspect and avoids pretending that a production CRM or data pipeline exists. A real release would still need a secured backend, consent language, retention rules, analytics, and ownership for product-data updates. Local execution is therefore a good prototype constraint, not the final architecture recommendation. It protects the credibility of the case study by keeping demonstrated behaviour separate from roadmap assumptions.

Optional detail

Technical appendix

The main case study stays focused on the product decisions. Implementation detail is available here for readers who want to inspect the mechanics.

How the interpolation flow works

Product points are grouped by RPM and sorted by pressure. For each RPM tier, cubic-spline interpolation estimates flow and power at the requested pressure. A second interpolation then estimates RPM and power at the requested flow. The code clamps calculations to supported bounds and returns no estimate when there are too few valid points.

How data becomes a visible result

A static JSON file contains seven model records with operating limits and performance points. The same selected-state object feeds the result card, Chart.js curve, savings inputs, and jsPDF report. Centralising that state reduces duplicated wiring and makes conflicting outputs easier to diagnose.

What production would add

The current form is intentionally non-submitting. A production version would need server-side validation, a secure inquiry endpoint, explicit consent and retention policies, product-data governance, measured performance budgets, accessibility testing, and engineer-approved tolerances. Those are release requirements, not implied capabilities of this demo.

Figma
Vanilla JavaScript
Chart.js
Numeric.js
WordPress
jsPDF
04 — Validation

What was checked, and what remains

Validation is split into three levels so implementation checks are not confused with user evidence. The first confirms that the prototype behaves consistently. The second checks that every public claim is supported by the repository. The third defines the research and engineering work required before the concept could be described as effective or production-ready. A usability round should measure whether participants choose valid inputs, understand the difference between a match and an estimate, recover from an unsupported request, and explain the result in their own words. Those observations matter more than asking whether the screen simply looks clear.

01 Functional review

Checked boundary and empty inputs, near matches, unit changes, model switching, chart updates, scenario calculations, and PDF generation.

02 Evidence review

Verified the seven-record dataset and client-side behaviour in code. Removed unsupported claims about production usage, conversion, speed, and time saved.

03 Next iteration

Test with intended users, benchmark representative devices, review estimated outputs with an engineer, and define production inquiry requirements.

05 — Reflection

Useful now.
Unproven yet.

The strongest part of the concept is not the calculation alone. It is the way the interface makes the result inspectable: match type, operating values, curve context, scenario assumptions, and report output all stay connected.

Its biggest limitation is evidence. The workflow, performance target, estimate tolerances, and business value still need validation with intended users and engineers. That boundary is part of the case study rather than something the presentation tries to hide.

If the next round shows that people can understand why a model was suggested, recover from an unsupported request, and carry the result into a conversation without rechecking the source tables, the concept will have earned its next investment. Until then, the outcome is a coherent prototype and a clear validation plan—not a claimed business result.

Request a prototype walkthrough
All Projects
Next Project See All Work UI/UX Design · Web Development · App Design