Modular Trading Terminal Design for Quickscope

Quickscope · Dynamic Interface interface collage

Tokens with no traditional utility (memecoins) have been part of crypto for years, but the category accelerated in 2024 with the launch of Pump.fun. These "token launchpads" made token creation as easy as a form-fill, with the possibility of life-changing upside. This shift demanded a new toolset to identify scams, track social context, and execute fast enough to catch spikes.

This shift leaned into crypto's ethos. Anyone could create a token and rally attention around it. Some launches were stunts, while others matured into serious projects. This openness also made it easier to launch copycats, mislead communities, and extract value from new buyers.

Products rushed in to capitalize on the space, launching tools targeted at meme traders. Despite the influx, workflows remained fragmented. No one had combined research, communication, and execution into a single effective experience.

Chart of memecoin launchpad growth through 2024, showing the surge in daily token creation following Pump.fun's launch

The traders driving most of the volume were not using one tool. They bounced between charts, holder details, rug checks, and social context, racing from credible alpha to trading terminals to maximize upside.

Our discovery interviews revealed that most traders who spent significant time evaluating memecoins used roughly 8 dedicated tabs and a variety of tools and workflows to go from token discovery to the conviction needed to make a buy. With launchpads spawning dozens of coins every minute, the time it took to fully audit a launch could be the difference between a 100× trade and losing half your capital.

Slide illustrating the fragmented trader workspace: research, charting, social, and execution scattered across separate tools and tabs

In interviews, we found that even when traders used similar tools, their research processes varied widely. Unlike traditional markets, there is no established playbook to base a strategy on. Next steps depended on confidence in the signal, risk tolerance, and background.

Several traders, including our team, were frustrated with rigid interfaces that centered chart behavior and order books, but missed what mattered in this market. Signals were often social, including how widely a coin spread across group chats, whether it launched before copycats, and the creator's track record.

A fixed layout worked for some traders. However, the market constantly spawned new launchpads, narratives, and coins. We needed an experience that could adapt without sacrificing familiarity.

Slide showing how trader research processes diverge: different tools, signals, and layouts for the same goal, with no single correct configuration

In order to meet the needs of a broad audience of traders, some with years of experience and others having recently set up their first wallet, we focused on creating a flexible trading experience that could mold to users' preferences. Not only would users be able to change the layout of the app, but they would be able to bring their own trading signals. They would be able to save wallets to track or highlight as holders on a token, read messages from group chats and quickly buy tokens without switching screens, and even forward tokens to friends as they discover them.

In a world where thousands of tokens were launching every day, we needed to cater to the users who wanted to view 10 charts simultaneously as well as the users who wanted to monitor 5 group chats and quickly buy whatever was sent.

As the Head of Product and Design for Quickscope, I started out our process by consolidating the research we had gathered alongside analysis of the existing market for trading terminals, token research tools and channels where the traders we interviewed were receiving the majority of their signal. Being a small team we had to prioritize which features we would launch with and what would be a fast follow. Based on the responses we had received there were two things that were a non-starter for most traders:

Lack of clear security

Slow transaction speeds

Given these two must-haves required a significant amount of backend engineering work, it limited what we would be able to do from a feature perspective at launch, leaving many more advanced trading features as fast-follows. Even still, we set out to craft an experience that would allow users to immediately gain value from Quickscope's modular interface and cut out 2–3 steps in their journey from token discovery to trading.

I set out to create a universal design system that supported extremely content-dense views and put emphasis on the tokens rather than the UI. As mentioned, thousands of new tokens showed up on our platform every day with different images, videos and stories in tow. Leaning on my experience in social media, I decided to ensure that the token media was the focus as it guaranteed a dynamic experience each time a user opened the app.

Every color decision in a trading terminal competes with price data, percentage changes, chart lines, and risk indicators. Adding decorative color is actively harmful, creating noise where traders want signal.

The system was built around depth layers. Backgrounds run from the deepest base through raised surfaces (panels, widgets) to interactive elements (buttons, selected states) to foreground text. Each step ensures the hierarchy reads without labels.

The single purple accent color appears only on actionable elements, positive state indicators and the few branded surfaces across the app. When the accent fires, something is live or something needs attention.

Indicator colors function the way traders are accustomed to across other interfaces to reduce the learning curve: green/red for price direction, amber for warnings, muted grey for inactive.

Quickscope color system: the depth-layer background scale, the single purple accent and its use cases, and the green/red/amber/grey indicator set with hex values

Dense financial tables break standard typographic rules. Body copy hierarchy (display → body → caption) doesn't map to what a token table needs: ticker symbol, price, 24h change, volume, market cap, liquidity. Six data fields at small size in tight rows, all needing instant scalability.

To keep widget details legible at any size, we used Geist Sans across the app and Geist Mono for smaller text, where its consistent character spacing helped at tight sizes. For the most cramped widgets like token feeds and holder tables, we leaned on recognizable icons over text labels wherever we could.

Quickscope type system: Geist Sans and Geist Mono across the data size scale, showing label versus data roles for dense token tables

As a fully modular interface, the heart of Quickscope's UI was the widgets we made available to our users. Widgets are tiles: charts, tables, feeds, trade panels, group chats, etc. Upon sign-up users started out with 5 views which were part of the templates we pre-built as a team. The majority of templates reflected either commonly used layouts for trading terminals (i.e. Chart | Trading Box | Transactions Table) or widget combinations to highlight Quickscope's features and utility. Floating Widgets can follow a user across views pinned outside the grid for quick access at any time.

Every widget needed consistent behavior across six states before any edit work could happen.

Quickscope widget component sheet: widget headings and edit-mode affordances, control bars, wallet and token-list variants, exchange and filter dropdowns, and chat and holder list states

Data Control: Widget Columns

Data Control: Content Filtering

Widgets only paid off if traders could arrange them their own way. Each tab in the top nav held up to ten named views, independent canvases a trader could build for a specific job: scouting new launches, monitoring positions, watching Telegram. Related views grouped into folders, so a research setup and a trading setup stayed a click apart without crowding the nav.

To skip the blank grid, every view could start from a template. We shipped pre-built layouts for the jobs traders actually did, scanning new pairs, comparing charts side by side, reviewing a portfolio, running an all-in-one trading view, so a trader could load a working setup in one click and adjust from there.

Some tools a trader never wants to lose, whatever view they're on. Floating widgets are single-task panels (positions, a chart, a trade box, tracked wallets) that detach from the grid and hover above the workspace. They persist across every view, toggle open from a numbered bottom bar, and each keeps its own context, columns, and filters.

In my career as a designer I had become accustomed to spending hours tweaking layouts, fine tuning padding and margin, and making sure each screen size would give a user as good if not a better experience than my default 1440 px frame. Our desire to create a system that allowed for near full customization including the size of widgets, what information they contained, and even what pages they could exist on presented a unique challenge I hadn't yet dealt with in previous interfaces.

Quickscope launched with all the standard widgets you might see in a trading terminal such as Charts, Transactions Tables, and New Tokens to name a few. Generally when designing one page at a time it is relatively simple to understand what information will load into each of these widgets based on page context. For example if I am viewing FROG token, the chart will be for FROG token, the transactions table will show me transactions on FROG token and so on.

The Quickscope Figma canvas: the full library of widget components — charts, transactions tables, token feeds, trade panels, and group chats — that the modular interface was assembled from

However given the modular nature of our app, page context lost a lot of its meaning. A user could create a page with 4 charts and a discover table, or 4 transaction boxes and their token holdings. These views were extremely powerful for quickly comparing tokens or reacting as the market moved, but only worked if every widget knew which token to load. Each widget switched context as the user navigated, could be pinned to a fixed context like a Solana chart on every page, or defaulted to recently viewed tokens to fill repeats within the same view.

Settings allow for permanent context settings

Context can be changed on the fly with quick action tools

The majority of trading products generally feature 1–2 key elements per page, often a large table or chart that spans the majority of the view. In initially designing our widgets we used similar concepts, emphasizing legibility and ease of scanning when looking through hundreds of rows in a sitting. However, as we saw how users were using the product, we noticed that the majority of our power users weren't interested in a neat and spacious layout, instead opting to pack as much information into a view as possible. While this directly supported our premise of reducing the friction required to research tokens, it also meant that every widget needed to function properly whether sized to 100% or 20% of the screen.

Jupiter trading interface: a wide chart anchoring the view with a fixed trade panel and holdings rail, the conventional one-or-two-large-elements layout

Quickscope's widgets had to flex without losing key info.

To handle this variation I created multiple versions of each of our widgets that typically did not render well under spatial constraints. The majority of components were made reactive, switching from the original size to a feed-like counterpart. While less rich in data, this allowed users to quickly view key information conveyed by the widget with no additional customization needed and further leverage the modularity of the platform to customize their ideal trading view.

Token listings widget across sizes: the full table and its reactive feed-like counterpart for tight layouts

Token mentions widget across sizes: the full view and its compact feed-like counterpart for tight layouts

On a small, fast-moving team, the customization system was exactly the kind of build where design drifts from spec. To keep that load off engineering, I leaned into design engineering and agentic workflows. Most of the planning happened in Notion with Claude. Prototyping moved between Figma Make, Cursor, and Claude Code, sometimes shipping features end to end like widget updates and landing pages, sometimes spec'ing them in working code like an AI trading analyst widget or the wallet login flow. That work took three forms.

Vibe-coding moves fast, and consistency is the first thing to slip. I gave Cursor a brand to work from, a set of skill docs it pulled from on every prompt, so prototypes came out on-system without me policing each detail.

The gap between a Figma frame and a live, resizable widget is where details slip. I built the fixes directly in Cursor: the breakpoint where a widget collapses to a feed, the edit handles that only appear when you need them, and checked they held in the browser before they reached engineering. Five more Cursor skills captured our front-end team's component patterns, API conventions, and commenting style, so the team could ship my changes after a quick review instead of rebuilding them.

Figma Make agent

Color system explorations

Custom emoji set

Rather than carry an idea through the full product → design → engineering loop before anyone could react to it, I could stand up a working version in Cursor and put it in front of the team the same day. Feedback came in hours, on something real instead of a mockup.

Exploration: Prediction Markets with Polymarket / Jupiter API

Exploration: Agentic Terminal Assistant with Anthropic API

We set up PostHog from launch to measure more than signups and trade volume. We wanted to see how users were interacting with the product: which widgets they opened, what data they filtered on, how they moved through the dashboard, where they were finding signal and where they were dropping off. A trading terminal lives or dies on whether the surfaces it offers are actually getting used.

Given the modular editor was one of the most unique parts of Quickscope, it was also the one we wanted the clearest read on. We tracked every editor open and save, so the numbers below are measured, not estimated.

Traders opened the editor 1,492 times in beta. 63.7% of those who tried it saved a layout. The traders who saved went on to trade dramatically more than those who never customized.

The lift made the case for customization clearly. Traders who used the editor became our most active users, building views around their workflows and trading more often because of it.

In only a few months of operation, a lean team drove real volume across the terminal and the Telegram bot.

Most users never found the key features that made Quickscope stand apart. Though we were able to reach thousands of users with our Telegram bot, we hesitated to pitch the product at onboarding in fear of adding complexity. Building it was one problem but getting users to adopt the features was the main source of friction.

Although we set out for maximum flexibility, constraints are what made the product usable. Most users say they desire full autonomy in a product experience, however, oftentimes they prefer a product they can pick up and use without thinking. Finding that balance will be key as more products opt for dynamic interfaces.

Unfortunately Quickscope was forced to shut down as memecoin activity dropped and the funding environment made it difficult to maintain the full team.

The directions I was most excited about all pushed the dynamic interface further rather than bolting separate products onto it. A few stood out.

The 7.5× lift from editors made it clear that customization was the moment users became power users. We would have built onboarding that pulled new traders straight into the editor, with templates and prompts tied to their goals, instead of treating customization as an advanced feature.

AI was already showing up in more traders' workflows, from summarizing token risk to drafting theses on a coin. We would have built an analyst widget that pulled social data, web scraping, and an LLM into a single panel beside the chart, plus a chat layer that could read the dashboard and generate bespoke views on request.

Prediction markets and perpetuals often move on the same news cycles and narratives that drive memecoins. The roadmap would have extended into venues like Polymarket and perp DEXs through their APIs, reusing the existing widgets so the modular system could expand without standing up a separate product.