← All work FINTECH · MOBILE & WEB · TRADING

DeepVue

A trading platform for people who read market data faster than they read words. The design problem was density: traders need everything on screen, and everything on screen is unreadable.

Role
Product Designer, Intern
Platforms
Mobile, web, desktop
Timeline
Jan 2025 - May 2025
Scope
Interaction design, accessibility, design system
20+WCAG 2.1 AA components
15+Usability tests run
3Platforms, one system

The problem

01

Active traders work under time pressure with a lot of information at once - watchlists, price movements, alerts, charts. They aren't browsing. They're scanning for a specific signal and acting on it, often in seconds.

That makes conventional mobile design assumptions unreliable. Generous whitespace means less data per screen, which means more scrolling, which means slower. But density without structure is just noise. The design had to hold both.

It also had to hold across mobile, web and desktop without fragmenting - the same trader moves between devices during a single session and can't relearn the interface each time.

Key decisions

02
Decision 01

Using touch and pressure to carry information the screen couldn't

The tension: On mobile, every pixel spent on visual feedback is a pixel not spent on data. But traders still need confirmation that an action registered - and in a context where a mistaken tap has financial consequences.

I designed haptic and pressure-based interactions to carry part of that load. Feedback the user feels rather than reads doesn't compete for screen space, and it's faster to process than a visual confirmation the eye has to find.

The approach borrowed from physical interfaces - the way a mechanical switch tells you it engaged without you looking at it. Applied to a trading interface, it meant confirmation could happen in a channel that wasn't already saturated.

Decision 02

Building accessibility into the components, not onto the screens

The tension: Accessibility work on a dense, data-heavy interface is either structural or cosmetic. Auditing finished screens catches contrast failures but not the deeper problems - and there were a lot of screens.

I built the compliance into the component library instead: 20-plus components meeting WCAG 2.1 AA, covering contrast, touch target size, keyboard navigation and screen-reader annotation. Anything assembled from those parts inherited the compliance rather than needing its own audit.

This was the higher-leverage choice on a platform spanning three device types. Screen-by-screen auditing would have scaled linearly with surface area; component-level work scaled with the number of patterns, which is a much smaller number.

Outcome

03

The main deliverables were a redesigned watchlist supporting multi-group tracking with inline price data and quick actions, an alert system with per-symbol controls, and the component library underpinning both across all three platforms.

Over 15 usability sessions, one finding held consistently: traders chose speed over polish every time. Where a more considered interaction competed with a faster one, the faster one won - which became the tiebreaker for the rest of the design decisions.

What I'd do differently

04

The haptic work was the most interesting part of this project and the least validated. I designed the interactions and reasoned about why they should help, but didn't test whether traders actually registered the feedback under real time pressure - which is the only condition that matters for this product.

Designing a novel interaction and testing a novel interaction are different pieces of work. I did the first and assumed the second would follow.