Digital Trading Playbook

Foundation & Constraints

The brief was personal: replace scattered notes and spreadsheets with a single, credible, offline-first system for managing trading strategies — the kind of "institutional-grade" interface that makes the work feel as serious as the market discipline it supports.

Non-negotiable constraints: Data stays on device. PIN is experience-level gating, not bank-grade authentication. The Electron Windows build had to avoid toolchains that fail on symlink/code-sign archive extraction — which meant choosing electron-packager over electron-builder for reliable output on this machine.

Early structural priorities: One scannable library (search + sort + filters + grid/list), a single deep editor for the play record, and clear save feedback — because silent failure is unacceptable when you're documenting live trading rules.

Establishing Look & Feel: Dual Fidelity

Brand intent: Credible and institutional when traders are working — high contrast, predictable controls, badge-based metadata. But capable of a second read that feels futuristic and demo-ready, without replacing the CRM-like clarity of the primary library.

The two modes share every data store, routing logic, and business component — the only fork is the shell wrapper and its CSS animation layer. This ensures mode switching never causes a data inconsistency and the futuristic experience never needs its own maintenance path.

Mini Case Study: Finding the Right Play Fast

The hardest daily task for a trader with a large library isn't creating a play — it's finding the right one quickly before or during a trade. This is the feature where friction has real cost.

Requirements

• Narrow hundreds of plays to a shortlist without hunting — from one control surface.
• Filtering must compose: text search + asset type + strategy type + sort (modified date, created date, name, win rate) all active simultaneously.
• Switching grid vs list must preserve the current query — no disorienting reset.

First Exploration — What Broke

• Too many equal-weight controls: Search, filters, and view toggles competed for attention; first-time users hesitated on order of operations.
• Filter discoverability: Advanced constraints were easy to miss when collapsed or visually grouped near sort controls.
• Scan cost in list mode: Without consistent metadata columns, list view didn't beat grid for comparison — so it felt like a worse grid, not a different tool.

Iteration — What Changed

• Stabilized a single control band: Search + filter + sort as one horizontal system — visual hierarchy established left-to-right by use frequency.
• Badges on cards: Asset, timeframe, strategy, and tags surfaced before opening — reduces unnecessary plays being opened just to check metadata.
• Virtualized rendering: react-window for large libraries reduces paint cost when hundreds of cards exist; scroll stays smooth.
• Debounced persistence for preferences: Sort/filter/view state is saved so the dashboard doesn't reset between sessions — eliminating "why did my filters disappear?" friction.
• Keyboard shortcut access: Power users can trigger search, sort, and view mode without reaching for the mouse.

Heuristic Evaluation (Find & Filter Flow)

I evaluated the flow against three primary tasks using heuristic analysis and extended self-testing across a realistic play library. Each finding drove a direct design or implementation change.

Creating a New Play

The play editor needed to be structured enough to enforce consistency across entries, but flexible enough for different strategy types. The form is grouped into logical blocks: identity (name, asset, strategy), rules and logic, risk parameters, notes, and tags. Destructive actions (delete, archive) are gated behind confirmation dialogs.

Design System

The implementation maps visual intent to theme variables and shared CSS, composed with Tailwind utilities. React context propagates theme, UI style (classic vs futuristic), and typography globally — so changing mode never requires a page reload or re-initialization.

Outcome

Digital Trading Playbook shipped as a complete, interactive system — not a mock — with persistent storage (localStorage plus IndexedDB for larger datasets and file metadata), virtualized lists for scale, and a deliberate split between information-dense trading workflows and a show-floor visual mode for demos and brand presence.

The project demonstrates the design-to-delivery arc that defines my work: product thinking (what belongs in a personal knowledge management system for traders), UX decisions (filter architecture, session lifecycle, dual-mode design), visual craft (institutional density vs immersive brand), and front-end engineering (React context, IndexedDB, virtualization, Electron packaging).

Reflection — What I'd do next

Next priorities:

• Optional encrypted backup with device-keyed encryption (beyond PIN-level gating).
• Formal analytics on strategy performance — win rate, expectancy, drawdown — linked to play records.
• Expanded export formats (PDF report, CSV, structured JSON) for trading journal integration.
• Automated tests for storage migration logic — currently manual verification only.
• Cross-device sync consideration if the use case evolves beyond single-device operation.

What I learned:

• Designing two visual modes without forking business logic requires discipline in the component boundary — the shell and the data layer must be genuinely independent.
• Offline-first storage (IndexedDB at scale) requires explicit error boundaries and migration hooks from the start — retrofitting them is painful.
• Density vs delight is context-dependent: the same user wants institutional clarity during work and brand energy during a demo. Both are correct, just not simultaneously.