TawfiqFit Case Study - Youssef Tawfik

The Process

Wireframe → Built

Every screen went from sketch to shipped. Left side shows the wireframe intent; right side shows the built result. Click any image to zoom.

Flow 1

Onboarding

Wireframe

Built

Splash sets the promise — point your camera, AI does the rest

Wireframe

Built

Personalisation complete — Tawfiq calibrated before a single account detail is entered.

Wireframe

Built

Empty home prompts the first action — Tawfiq speaks, zero stats don't

Flow 2

Camera Logging

Wireframe

Built

Camera viewfinder — the entire logging flow starts with one tap

Wireframe

Built

AI identifies the machine — confidence score shown, corrections available

Wireframe

Built

Set-by-set logger with running weight and rep totals

Wireframe

Built

Active session lives in the home tab — navigate freely without losing context

Flow 3

AI Coach & Progress

Wireframe

Built

Coach chat — interactive, context-aware, AI-ready

Wireframe

Built

Progress — three KPIs, one goal bar, one chart. Nothing more.

Wireframe

Built

Profile — your plan first, app settings second

Visual Identity

Brand System

Designed before a single component was built. Every colour, typeface, and mark is intentional — and lives in one file.

Implementation — Tokens & Imports

tokens.css

:root {
  /* Surfaces */
  --tf-paper:  #FAF9F7;
  --tf-bone:   #E5DFD2;
  --tf-char:   #1A1714;
  --tf-ink:    #14110F;
  --tf-stone:  #6B6660;

  /* Brand */
  --tf-clay:   #6B2417;
  --tf-clay-2: #8C3A2B;
  --tf-ochre:  #B8924A;
}

Fonts & stacks

--tf-font-display: "Newsreader", Georgia, serif;
--tf-font-body:    "Geist", ui-sans-serif, sans-serif;
--tf-font-mono:    "Geist Mono", ui-monospace, Menlo, monospace;

Delivered files

assets/
  tokens.css
  wordmark-dark.svg
  wordmark-light.svg
  mark.svg
  mark-dark.svg
  favicon-32.png
  favicon-16.png

Design Thinking

Key UX Decisions

Ten moments where the obvious path was wrong — and why the less obvious one shipped instead.

Eliminated Dedicated "Session Complete" Screens

Before: 2 confirmation screens users had to tap through after every session

Before — 2 extra screens

After — toast + inline summary

Why: Two screens forcing users to acknowledge completion added 0 value — the data was already saved. Toast + bottom sheet delivers the same information with zero extra taps and zero navigation cost.

Alternatives Expand In-Place, Not a Separate Route

Before: "See alternatives" navigated to a new page, losing the identified exercise card

Why: Navigating away creates cognitive overhead — users lose the identified exercise context while browsing alternatives. A bottom sheet expands below without replacing what's already confirmed.

The alternatives list is a component rendered inside the same screen via a local showAlternatives state flag — no routing, no back-button fragility.

Camera Back Button is Context-Aware

Same screen, different exit destinations based on entry point

Why: From a session → back returns to the session. From home → back returns to home. Implemented via { from: 'session' } route state — no duplicate routes needed.

Account Creation Deferred Past Value Demo

Users see the product before being asked to sign up

Why: Asking for an account before demonstrating value is a conversion killer. Users select their goal, pick their activity level, and see the camera flow — signup then becomes a natural commitment rather than a gate.

Repeat Session Flow Cut — Deferred to Backend Phase

Originally wireframed and designed; removed before a single line was written

Wireframes that were cut

Why it was cut

"Repeat last session" requires real historical session data from a database to be meaningful. Building a mock version would create a fake interaction that cannot be verified for actual user value. Complexity without proportional benefit — moved to the backend roadmap where it belongs.

Cutting a designed feature before it ships is one of the hardest UX calls. Shipping an interaction built on fake data is always worse than shipping less.

Honest AI Architecture — Only 2 Features Use Real AI

Every "smart" feature was audited: is this actually AI, or just a query?

Camera identification

✓ Real AI

What the user sees: Exercise name + confidence score

What actually runs: Vision-capable AI model — image encoded and sent to model API

Tawfiq coach chat

✓ Real AI

What the user sees: Personalised coaching advice

What actually runs: AI language model — prompt includes session history + goals

Exercise history recall

DB query

What the user sees: "You did 3×12 last week"

What actually runs: Database query + string template

Progress stats

SQL

What the user sees: Streak, volume, weekly delta

What actually runs: SQL aggregates

Rest timer

JS timer

What the user sees: Countdown between sets

What actually runs: setTimeout()

Feature	What the user sees	What actually runs	Real AI?
Camera identification	Exercise name + confidence score	Vision-capable AI model — image encoded and sent to model API	✓ Real AI
Tawfiq coach chat	Personalised coaching advice	AI language model — prompt includes session history + goals	✓ Real AI
Exercise history recall	"You did 3×12 last week"	Database query + string template	DB query
Progress stats	Streak, volume, weekly delta	SQL aggregates	SQL
Rest timer	Countdown between sets	setTimeout()	JS timer

Why: Labelling a database query as "AI" is dishonest and creates wrong expectations. If a deterministic function handles a feature well, AI is the wrong tool. This audit also keeps API costs near zero — only the 2 genuinely intelligent features ever hit the model.

Show the Vision Honestly, Validate Before Building

The wearables feature is shown as 'coming soon' — and asks users which to build first

Why: Device sync (Fitbit, Apple Watch, Garmin) is a v1.1 feature, not built yet. Rather than hide it or fake it, the Connect screen presents it honestly as 'coming soon' and asks 'which matters most to you?' — turning a placeholder into a way to learn which integration users actually want first. Commit to the vision, but let real demand decide the roadmap.

Design Token Architecture — No CSS Framework

Every visual decision lives in one file

/* tokens.css */

:root {

--color-primary: #7c3aed;

--color-surface: #1a1a2e;

--radius-card: 1rem;

--space-section: 2rem;

}

Why: No Tailwind, no Bootstrap — every color, radius, and spacing is a CSS custom property. Global theme changes are one-line edits. Each component's styles reference tokens directly via .module.css files.

The Coach Keeps Improving Without Disruption

The AI behind the coach can be upgraded anytime — the user never notices

Why: AI services change fast — they get better, cheaper, or occasionally go down. The coach was built so a better AI can be swapped in at any time, and the user never notices a thing: same chat, just smarter answers over time. The user gets continuity; the product keeps improving without a rebuild.

Exercise Detail — 4 States Designed Up-Front

Default · Edit · Delete confirmation · Post-delete return to home

Default view

Delete confirm

Why: Happy-path-only UX breaks in production. Delete is destructive — a confirmation bottom sheet is mandatory. The undo toast after deletion provides a safety net without blocking the action. All 4 states were designed in wireframes before a line of code was written.

Roadmap

What's Next

The frontend is complete — 17+ screens, all flows built, PWA manifest live. The backend phase turns the prototype into a real product.

🔐

Authentication

▸ Google OAuth — primary signup path, lowest friction for mobile users
▸ Email / password — fallback for users who prefer not to link Google
◦ Apple Sign In — deferred; requires Apple Developer account, lower priority for an Android-first PWA

🗄️

PostgreSQL Data Model

Users goals, activity level, streak, created_at

Sessions user_id, date, duration, volume_total

Exercises session_id, name, muscle_groups, ai_identified

Sets exercise_id, reps, weight_kg, set_number

Photos exercise_id, storage_url, ai_confidence, raw_response

🤖

AI Integration

▸ Camera ID — a vision-capable model identifies the machine from the photo; confidence score read from the response
▸ Coach chat — the configured AI model, prompted with the user's goals, last 3 sessions, and any flagged complaints
– Everything else — DB queries + string templates; no AI needed, no AI used

📊

Data Calculations

▸ Streak — consecutive calendar days with a logged session
▸ Volume — Σ(sets × reps × weight) per session and per week
▸ Weekly delta — % change in volume vs the same day last week
▸ Progressive overload — suggest +2.5% weight when user hits 3 target sets in a row
▸ Muscle groups — frequency heatmap from tagged exercises over a 7-day window

Current status

Frontend complete — Backend in planning

All 17+ screens built, all flows functional with mocked data, PWA manifest installed. Backend architecture finalised; implementation begins next sprint.

Frontend · Complete

Backend · In planning

AI integration · Queued

TawfiqFit

Why this exists

My Role

Stack

Phase

Screens built

Photo-log workouts

AI coach in your pocket

Track real progress

Wireframe → Built

Onboarding

Camera Logging

AI Coach & Progress

Brand System

Implementation — Tokens & Imports

Key UX Decisions

Eliminated Dedicated "Session Complete" Screens

Alternatives Expand In-Place, Not a Separate Route

Camera Back Button is Context-Aware

Account Creation Deferred Past Value Demo

Repeat Session Flow Cut — Deferred to Backend Phase

Honest AI Architecture — Only 2 Features Use Real AI

Show the Vision Honestly, Validate Before Building

Design Token Architecture — No CSS Framework

The Coach Keeps Improving Without Disruption

Exercise Detail — 4 States Designed Up-Front

What's Next

Authentication

PostgreSQL Data Model

AI Integration

Data Calculations

Frontend complete — Backend in planning