Building a working app and building a usable app are two different things. When I finished the first version of the NanoRich mobile app, it did everything it was supposed to do technically — Firebase data arrived in real time, the signal cards displayed correctly, AdMob ads loaded, push notifications worked. I showed it to my wife and asked her what she thought.
She looked at it for about thirty seconds, then asked: "What am I looking at?"
That question changed how I approached the rest of the design.
The Problem With Designing for Yourself
When you build an app for your own use, you understand everything about it before you open it. You know what "포착완료" means. You know what an A-grade signal represents. You know why the tick acceleration number matters. You know that 09:00 to 15:30 is the window when the data is live.
A new user knows none of this. They see a dark screen with colored cards, numbers in boxes, grade letters, and timestamps. Without context, it looks like a control panel for something they don't understand. The information density that makes the app useful to someone who knows the system is the same information density that makes it confusing to someone who doesn't.
This is the central UX challenge for any specialized dashboard app: how do you present complex, data-dense information in a way that's immediately comprehensible to a new user, without removing the depth that makes it useful to an experienced one?
The First Version — What Was Wrong With It
The first version of the app had several problems that I only saw clearly once I watched someone else try to use it.
The most immediate problem was the empty state. When someone opened the app outside of market hours — which is most of the time, since the Korean market only trades for six and a half hours a day — they saw a completely blank screen. No explanation, no context, no indication of what should appear there or when. A blank screen is one of the worst possible first impressions for an app, because users interpret it as either a loading failure or an app that doesn't work.
The second problem was the signal cards themselves. Each card showed the stock name, grade, stage, confirmation time, pullback depth, tick acceleration, and secondary signal data — all at once. For someone who knows what all of this means, the card is information-rich. For someone encountering it for the first time, it's a wall of numbers with no obvious hierarchy of importance.
The third problem was navigation. The app had a single screen. The signal card showed a summary, but there was no way to tap on a card and see more information about why that signal had fired, what the relevant price levels were, or what action (if any) the signal was suggesting. The app was showing output without providing any way to understand the input.
The fourth problem was that nothing explained what the app was for. There was no onboarding — no introductory screen, no tooltip, no explanatory text for someone opening the app for the first time. I had assumed users would read the app store description before downloading. In practice, almost nobody reads app store descriptions in detail before downloading a free app.
What I Changed — Empty State First
The empty state problem was the easiest to fix and arguably the most important. Instead of a blank screen, the app now shows a clear message when no signals are active: "Market closed — signal board will update during Korean market hours (09:00–15:30 KST)." Below this, a simple graphic shows the current time in Korea and counts down to the next session open.
This single change transformed the experience for users who open the app outside of market hours — which, given time zone differences, is most international users most of the time. Instead of a confusing blank screen, they get a clear explanation of why there's nothing to see and exactly when that will change. Several users mentioned this countdown in early feedback as one of the features they found most useful.
What I Changed — Card Hierarchy
The signal cards went through four redesign iterations before I was satisfied with the information hierarchy.
The key insight was that not all information on the card is equally important at a glance. The most important piece of information is the signal grade — is this an A, B, or C signal? The second most important is the stock name and the time the signal was confirmed. Everything else — pullback depth, tick acceleration, secondary signal data — is supporting detail that a user wants to see, but only after they've processed the primary information.
The redesigned card puts the grade prominently in the top right corner with a color coding that makes it immediately visible: green for A, yellow for B, gray for C. The stock name is in large type on the left. The confirmation time is directly below it. The detail metrics are collapsed into a smaller section at the bottom of the card, visually subordinate to the primary information.
The color coding turned out to be particularly important. In the original design, all cards were the same dark color regardless of grade. In the redesigned version, A-grade cards have a subtle green accent, B-grade cards have a yellow accent, and C-grade cards are visually muted. A user can now scan the signal list at a glance and immediately identify which signals are highest priority, without reading the grade letter on each card.
What I Changed — Tap for Detail
Adding a detail view for each signal card required more development work than the visual changes, but the impact on usability was significant.
When a user taps on a signal card, the app now expands to a full-screen detail view that shows several additional pieces of information the main card doesn't display: a text explanation of what each metric means in plain language, the price level at which the signal confirmed (so the user can look it up on their own chart), the stop-loss level (one tick below the valley low), and the approximate target level. There's also a section that explains, in one or two sentences, why this particular stock generated a signal — which stage transition it just completed and what the key indicators showed.
This plain-language explanation was the feature my wife had been asking for with her "what am I looking at" question. Adding it required writing descriptions in advance for each possible signal state and incorporating them into the signal data structure — a design decision that affected the Python backend, not just the Flutter frontend. But it fundamentally changed the app from a data display for insiders to an informational tool that new users could engage with.
What I Changed — Onboarding
The onboarding problem was solved simply: three screens that appear on first launch, before the user sees the main signal board.
Screen one explains what the app is in one sentence: "NanoRich shows real-time breakout signals detected by an algorithmic trading system monitoring the Korean stock market."
Screen two explains what the signals mean, with a simple visual showing an example A-grade signal card and labeling each element.
Screen three contains the disclaimer — that the app displays data for informational purposes, not as investment recommendations — which is legally important and which users need to acknowledge before proceeding.
These three screens take about thirty seconds to read through. After that, the user arrives at the main signal board with enough context to understand what they're looking at.
The Lesson About User Experience and Specialized Tools
The experience of watching my wife try to use the first version of the app taught me something about specialized tools in general: the expertise gap between the builder and the user is almost always larger than the builder assumes. Every term you use without thinking — "grade A signal," "valley low," "tick acceleration" — is a term that requires explanation for anyone who didn't build the system.
This doesn't mean you have to remove the terminology or dumb down the interface. It means you need to provide accessible paths into the terminology for users who are willing to learn, without blocking the experience for users who aren't yet familiar with it. The redesigned app uses the same terminology as before — because that terminology is precise and useful — but surrounds it with enough context that a new user can figure out what's happening without having read the entire series of posts that explain the system.
Today's Investing Insight — Why Dashboard Design Matters in Financial Technology
Professional financial dashboards — Bloomberg terminals, trading platforms, portfolio management systems — are notorious for their steep learning curves. The Bloomberg terminal, used by most major financial institutions, has so many features and such dense information display that new users typically require weeks of training before they can use it effectively. The argument for this complexity is that sophisticated users need sophisticated tools, and that simplifying the interface removes capabilities that professionals rely on. But there's a counter-argument that's gaining ground in financial technology: that excessive complexity creates cognitive load that degrades decision-making quality, particularly in high-stakes, time-sensitive situations. Research on decision fatigue suggests that forcing users to process too much information simultaneously reduces the quality of the decisions they make with that information. Good financial dashboard design isn't about simplifying the information — it's about presenting it in a way that puts the most decision-relevant information in front of the user's attention first, with supporting detail accessible but not demanding attention. The redesign described in this post is a small-scale application of that principle.
---
This post documents a personal journey of building a mobile application and reflects personal experience with user experience design. Design decisions described here are specific to this application and its user base, and may not be applicable to other contexts.
Comments
Post a Comment