Watchlists, reimagined

The data was there. Understanding it took effort every time.

Bigdata's Watchlists let users track companies, products, locations, and people across billions of financial documents. Finding what mattered meant manually scanning dense tables, row by row, entity by entity. Everything the platform knew was technically accessible, but none of it surfaced itself.

My scope

Led the redesign from research to shipped product, working directly with the AI and engineering teams building the underlying assistant. That included navigating decisions about where the AI lives in the product, a structural call that shaped the backend architecture as much as the UI.

The first concept was wrong, and interviews proved it

The initial design split the experience into two screens: one for chat, one for the watchlist table. It was a reasonable first move. User interviews made clear it was the wrong one. People wanted to ask questions about the data they were already looking at, not navigate to a separate assistant to do it. The chat would need to live where the data lives, collapsed by default, opened in context when needed.

That structural call came from what users told us, not from a brief that said "add a chatbot." The brief set the direction. Research made the decision.

Making the structural case early

Anchoring the chat to the data table instead of a separate surface had real implications for how engineering built the assistant layer. I made that case before the backend architecture was set, because changing it after would have been significantly more expensive. Research gave me the argument. The engineering team confirmed the constraint.

From manual scanning to asking in plain language

Users can ask questions in plain language: "What's new with my Watchlist this week?" or "Are there any major alerts about Microsoft or Tesla?" The assistant responds with summaries, contextual charts, and deep links into the underlying data, instead of leaving people to find that themselves.

AI in my own process, not just in the product

Used Lovable to build interactive prototypes and put them in front of stakeholders early and often, compressing the feedback loop significantly. This is the second project where I've built AI tools into my own design process, not just designed AI features for someone else to use.

Shipped. No post-launch data. Here's what I can claim.

This shipped in May 2025. I don't have usage data from after launch to share, and I won't claim numbers I don't have. What's solid: an "add AI to this" brief that could have ended as a bolted-on chatbot became a structural decision about where the assistant lives relative to the data. That decision came from what users told us, not from what looked good on a roadmap slide.

What I take from this

"Make it conversational" is a direction, not a design. The interesting work was figuring out what conversational meant in a product where the data and the context are inseparable, because separating them into two screens would have answered the brief and missed the point entirely.

• Turned an open-ended brief into a specific structural decision, chat anchored to the table, not a separate surface, grounded in user interviews rather than assumption.
• Used AI in my own process: Lovable for fast, iterative prototyping that got real designs in front of stakeholders early.
• Honest about the gap between shipping and knowing: the feature went live, and I won't claim results I don't have data for.
• Made a structural product decision that affected engineering scope before the brief suggested one was needed. That's the difference between designing within a brief and shaping what the brief becomes.