The Average Joe had already built something, a stock market newsletter with over 150,000 users who trusted the platform for clear, legit insights on stocks and financial markets and a personalised news feed that made it feel accessible for everyone with varying levels of knowledge.
The brief was a pivot: take an established newsletter, use thoughtful design strategies and a robust AI architecture to build a conversational platform to simplify finance and stock market analysis. Instead of waiting for the weekly newsletter, users can easily open the chat interface, ask about anything stocks or financial related, e.g. "How is AMZN doing right now?" and get a response: an overview, financials, charts, news, research breakdowns, all in one place. Tailored to them and adjustable based on how they choose to explore.
Role
Design Lead & Founding Product Designer
Responsibilities
Design Lead, Interaction Design, Generative UI, Async Handoff, Code Review, AI QA
Deliverables
Web Platform, Mobile Experience , Interactive Prototypes, Component System
Timeline
12 weeks (0 to launch)
Team
Dami / Product Designer
Victor / Founder
Fabio / Product Manager
Khel / Frontend
Niko / Backend
As Design Lead and Founding Product Designer, I had roughly twelve weeks to design this product from scratch, for an early stage launch aimed at generating buy-in from key stakeholders. No existing design system, no shipped product to reference, a distributed team across time zones, and AI at the core that was unpredictable, as expected.
My resolve was to design a platform flexible enough to handle what a multi-agent AI returned, and intuitive enough that an investor either beginner or experienced could immediately understand what to do with it.
Building a platform from scratch is one thing. Building one where the AI is the interface and its outputs are unpredictable by design is a different ballgame.
There were certain constraints that I identified that shaped the decisions I made on this project.
Non-determinism as a design surface: The platform's multi-agent AI pulled from multiple external sources, financial data providers, news platforms, market research tools, the same kinds of sources the newsletter's in-house writers used for research, now put together on the backend. Depending on what a user asked, the response could be a data table, a chart, a narrative summary, a comparison view, a set of links, or some combination of all of them. There was no fixed layout to design to. The UI had to be tailored around outputs that couldn't be fully anticipated. Every component, pattern, or interaction had to be flexible enough to cater to that variability without breaking the UX.
Designing for users with existing expectations: Subscribers already had a relationship with the company; its voice, quality, take on the market. Introducing a new product meant the experience had to be both functional and recognisable.
A distributed team with no room for back-and-forth: The team operated across time zones, this meant the regular design-engineering loop ie. share a Figma link, get questions, clarify in a meeting, iterate, wasn't viable. Communication had to be precise and async.
Zero to one under tight timelines: There was no existing system or established patterns. Every design decision like how the UI was laid out, how users moved along the interface, how data and charts were displayed were made from scratch.
Given the identifiable constraints, static Figma frames at handoff weren't going to be enough
For straightforward, basic response views, standard UI layouts. Figma was fine. But for the interactions that were hard to communicate design intent eg. how the artefacts section worked, how the charts and tables responded to user input, how the interface assembled itself around an AI response, I needed something closer to the real thing.
I used Figma's MCP integration alongside Cursor to build prototypes directly from the designs. My workflow was well thought out and deliberate: brainstorm the interactions, bring it into Cursor, and build a working clickable prototype that engineering could reference, during implementation or design reviews.
It was about bridging the gap between design intent and implementation not writing production ready code, especially for a team that couldn't address ambiguity in real time. The prototypes focused on the interactions that mattered most: the artefacts section where I used progressive disclosure patterns, the chart and table behaviours, the transitions that communicated how the interface should feel in use, and more.
The outcome was better than the typical handoff. Some of the code the those prototypes was reviewed and merged into the main branch as-is. It was amazing to know that what I built to communicate the experience became part of the product.
The hardest design problems on this project weren't visual. They were mostly structural, how do you build an interface that holds uncertainty, guides UX with little to no constraints, and scales without breaking?
Here are some of the decisions that shaped the platform’s design
Progressive disclosure as an interaction model: The default state of the platform was intentionally minimal using a single prompt bar. No dashboards or pre-loaded charts etc. Just a question "Start your research here" From that point, the interface assembled itself around the user input. As a user begins typing, a contextual dropdown will display suggestions which could range from stock tickers, query types, or guided prompts hereby reducing the cognitive load of open-ended AI interaction and steering users toward high-quality inputs without restriction. Once a response came back, the UI is expanded based on the input. For example, A portfolio-related question might show a comparison table, or a stock market question a chart or even a combination of both, with linked reference bubbles connecting out to external websites or resources. The UI didn't have a fixed layout waiting to be filled. I designed a system of components ready to assemble around whatever results came back like a stack of legos. This disclosure pattern solved two problems at once, first was keeping the entry point approachable for users unfamiliar with AI-native tools, and the second was giving the platform room to display complex outputs without overwhelming the user.
Designing for uncertainty using customisation: When an LLM returns output of unpredictable length, format, or complexity, designing a single fixed layout simply doesn’t work, something will always look off. My approach was to shift some of that control to the user. This meant building a layer of customisation that lets users adapt the interface to what they received. This could be collapsing or expanding the sidebar, the artefacts section and other view panels, expanding tables and charts into a focused view, saving or sharing specific outputs, leaving feedback within a response, etc. Giving users meaningful control and agency over density and focus without needing them to understand what the agents were doing on the backend. Users could also tailor how the LLM responded. Asking for a breakdown based on news, research, or financials as part of the conversation. The interface supported that experience naturally, so experienced investors could go deep in the direction they cared about while beginners could stay at a comfortable level without feeling confused. Working with Shadcn as the base component library gave us a system that was both structurally solid and adaptable.
The ticker shows major indices, trending stocks, and user watchlist items, letting users stay oriented without opening multiple tabs.
Users can select modes before asking or let the AI auto-detect based on query patterns. This made responses more predictable and relevant to intent.
When the AI generates charts, tables, or analysis, it was important for users to be able to reference them while continuing the conversation. Sidebar could be docked as well, adapting to different workflows, from casual viewing to in-depth analysis.
it was important to follow familiar patterns, the in-app feedback was one of them. it created an immediate feedback loop for the friends and family testing phase and beyond.
Contrary to popular belief, designing mobile experiences isn’t just shrinking the desktop view. It’s a different design problem and couldn't be solved by the same strategies that defined desktop UI.
The platform's core strategy works on desktop because space lets complexity breathe. Charts sit beside responses, expandable tables, comparison views, and more. On mobile, that same complexity shows up in a different context entirely, users in motion, life distractions, making quick decisions between tasks
Trade-offs were key to solving user problems. Does this give the user what they came for, in a clear, digestible format, regardless of their experience level?
On a fast-moving 0-1 team, the gap between a design decision and implementation can distort the UX and sometimes the UI. I’ve seen cases where interaction feels different in a browser than on Figma prototypes, especially in this case where results are running on real data and constraints.
Part of my role was staying really close to that gap and reducing the friction as much as possible while considering feasibility. I reviewed frontend code and gave documented feedback to engineers at the level of someone who understood both the design intent and enough of the implementation to articulate exactly where the two met (or didn’t).
That proximity to the code layer, in addition to the prototypes I built, meant design decisions didn't just live in Figma but informed and held up the UX.
Twelve weeks. End to End.
The platform shipped and on a 0-1 build with a distributed team, no existing design system, and an AI at the core that couldn't be fully anticipated, it's not a small win.
The prototypes became the product: Most of the prototypes built in Cursor were reviewed, refined where necessary, and merged into the main branch largely as-is. What started off as a communication tool to Red friction ended up as production code and user experience.
The interaction model scaled: The progressive disclosure pattern held up across both desktop and mobile handling the variability of multi-agent AI outputs without breaking. The same system served the target users because it was built to scale.
Design without traditional QA: Without access to real user testing during the project, I learned how to build an internal audit process using structured AI-assisted reviews. I used it to confirm consistency, accessibility, and possible edge cases behaviour across different AI response types.
Replicable workflow for AI-native teams: The good thing about the workflow I developed for this project is that it can serve for how to contribute meaningfully to products AI-native or not without waiting for engineering capacity. This means closing the gap between design intent and implementation reality in environments where speed and async collaboration are non-negotiable and beyond.
This project pushed me in ways I didn't expect and changed how I think about design.
Learning to speak AI natively: The biggest professional shift for me on this project wasn't just the deliverable. I got to understand how multi-agent AI systems actually worked, how they pulled information from different sources, and coordinate to produce a single (or multiple) response. This largely changed how I approached design decisions. I started approaching design as an a system with its own logic, and failures. That understanding is now foundational to me.
Strategy under constraint: Twelve weeks is not enough time to build everything but enough to build the important ones. The discipline this project demanded is something I carried out of this project as a sharper skill than I came in with. I learned to advocate clearly for UX decisions that weren't considered unimportant to non-design stakeholders but I knew could determine user adoption. This showed in the details eg status-aware input states, smart defaults, and guided prompts none of which felt like priorities until they were the reason the experience felt human-centred.
👁️ For optimal viewing, please view this case study on a larger screen.
This case study is not publicly available due to non-disclosure agreements. To request access, contact me for a password. Access is limited to recruiters and potential clients. Thank you for understanding.
Need access, request password reach out[email protected]Yaay! Speak soon! 😄