Quickscope · Dynamic Interface
- RoleRole
- Founder
- FocusFocus
- Product/Design Engineer
- YearYear
- 2025
- CompanyCompany
- Quickscope
A modular interface built to consolidate what used to require 5 tabs into a single flexible trading tool.
A New Paradigm for Trading
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.
A Fragmented Trading Experience
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.
There Is No "Correct" Layout in a Quickly Evolving Market.
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.
Even when traders used similar tools, their research processes varied.
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.
A Customizable Trading Experience
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.
We focused on creating a flexible trading experience that could mold to users' preferences.
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.
Roadmap · Prioritizing User Needs at Launch
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.
Design System
Color system, typography, component library
Modular Core
Widget system, templates and saved Views, Edit Mode
Social & Rewards
Telegram bot, PNL share cards, referral rewards
Activation
Onboarding flow, fast trading
Trading Depth
Limit orders
Design System
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.
We put emphasis on the tokens media rather than the UI.
Color System
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.
Typography for Data
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.
The Widget System: Shared Components Before Anything Else.
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.
- 01Default
Live and usable, with no extra affordance showing. The widget displays its content without any edit chrome.
- 02Data Control
On pointer hover, the widget reveals contextual controls, quiet enough that they don't compete with the underlying data.
- 03Edit Mode
Widgets can be moved, resized, replaced, or reconfigured. Drag handles at the corners, resize handles on the edges.
- 04Floating
A widget pinned outside the grid that follows the trader between tabs. Activated and deactivated with hotkeys.
- 05Empty
A widget with no content selected yet. When empty, the trader is prompted to fill its context.
The Canvas
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.
Personalized dashboards for any trading workflow.
Templates
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.
Easy onboarding with 1-click working layouts.
Floating Widgets
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.
Bring your favorite widgets with you on every view.
Challenges: Creating a Flexible Trading Experience
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.
Our desire for full customization created unique challenges in widget legibility.
Challenge #1: Context Switching for Widgets
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.
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.
Challenge #2: Widgets That Adjust for Spatial Constraints
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.
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.
Agentic Workflows for Faster Development
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.
Claude
Figma
Cursor
Codex
Skills for Consistent Design
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.
Bridging Design and Engineering
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.
Scoping New Features
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.
Dynamic Experiences Drive More Usage
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.
Average Trade Activity Per User
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.
Total Activity Generated on Quickscope Terminal
Doing More with Dynamic Interfaces
Distribution Is the Most Important Feature.
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.
Personalization Requires Strict Rules Underneath.
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.
What Else We Could've Done
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.
Onboarding Into Customization
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.
An AI Layer for Research and Editing
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.
New Markets, Same System
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.