Turning a broad idea into a product the team could test

BlockSensai was a crypto intelligence product for institutional teams at 21Shares. I led discovery and design in 2025, working with six engineers, three data scientists and a product manager from the first concept through the alpha. We classified and scored governance proposals and news, then used that structure in dashboards, an intelligence feed and a later LLM experience.

The first data structure followed crypto forums and technical pipelines, but the institutional users I interviewed described their work in different terms. News also did not fit the governance-first model, and overlapping labels made the generated summaries and metrics harder to understand. Before refining the interface, I needed to help the team agree on what the product was describing and how those parts related.

Research that changed the data model

I interviewed people from MetaMask, Crypto.com, Messari and other crypto companies across five institutional roles. I combined those conversations with workshops and concept walkthroughs, then turned the findings into insight summaries, a value canvas and a weighted priority list. The research showed where people needed role-specific information, visible provenance and confidence, and a clear separation between proposal impact and the effect of events or news.

I replaced the governance-first terminology with a taxonomy and glossary covering proposals and news, and worked with the team on the segmentation and classification behind it. I also helped define the expected structure of the LLM summaries and a likelihood-of-approval signal used in proposal analysis. I led the product model, the workflow and how those outputs appeared in the interface, while the data scientists and engineers remained responsible for their specialist parts.

Narrowing the first release to one proposal journey

We worked in six-week cycles, moving from role-based research into a defined scope, usability sessions and implementation with engineering. For the proof of concept, I narrowed the idea to the information someone needed to judge a proposal. We combined repeated event information in one proposal view, and role-based risk and impact metrics made the event type and user perspective clear. Modular sections kept the first release manageable without closing off the longer-term direction.

We also challenged an assumption in the original model. Price-sensitive news could affect the market as soon as it appeared, while the impact of a governance proposal might depend on whether it passed. Separating those cases changed the classification model as well as what the interface needed to explain, so we resolved the distinction before designing how it would appear on screen.

Keeping the alpha consistent while the team built it

I designed the dashboards, feed cards, analysis modules and proposal view within a small component system for dense data. It covered spacing, typography, elevation, contrast, card variants and analysis states in light and dark modes.

Guiding the team through implementation

I scoped the work with engineering and wrote separate guides for the data and front-end teams. The annotations connected each part of the interface to its data definitions, design tokens and layout rules, while the tickets made requirements and acceptance criteria explicit.

When delivery became difficult, I organised front-end work into dedicated page tickets and separated the UI build from API integration. This gave the team clearer tasks to work through alongside implementation reviews.

I combined the design work with roadmap and milestone planning, working with product and engineering to keep research, data requirements and interface delivery connected. Within our six-week cycles, I ran Scrum ceremonies including sprint planning, stand-ups and retrospectives, as well as stakeholder reviews and weekly design and implementation discussions. I used these rituals to review progress against the next milestone, resolve open questions and keep the team aligned as deadlines approached.

I managed two engineers during implementation phases and stayed involved in their day-to-day delivery questions. The page-level tickets gave us concrete work to plan and review, while separating UI implementation from API integration made the dependencies easier to discuss. I worked through design and implementation quality with the engineers as the alpha developed.

The taxonomy gave product, data science and engineering one structure for proposals and news, while the component and page system gave us a consistent way to extend the alpha. Over four months, internal front-end delivery speed increased threefold, with higher UI consistency observed in usability tests.