--- title: Turning chatter into decisive signal slug: omniscient summary: Founding designer at Omniscient AI. Reframed the problem and designed the signal model behind the platform that replaced Renault's entire monitoring stack in under eight months, retiring €700k a year in spend. url: https://charlieholland.com/#work/omniscient --- # Turning chatter into decisive signal **Company:** Omniscient AI · **Role:** Founding Product Designer (sole designer, working across product strategy, design, and code) · **Year:** 2025 to present · **Stack:** TypeScript, React, Tailwind CSS, Vite. We'd just raised €3.5M, and the pressure was on to ship fast. As the company's fourth employee and only designer, I took Omniscient from a rough prototype to the platform that replaced Renault's entire monitoring stack in under eight months. Headline outcomes: €700k of annual spend retired; three vendors replaced by one platform; signals vetted in under 15 minutes; insights briefed to Renault's board. Design partners: Renault and On are the two paying design partners. BHP is a partner too, but not a paying one. ## Overview Omniscient is a seed-stage signal intelligence platform. It watches 150,000 sources across regulation, reputation, and geopolitics and surfaces the handful a brand genuinely needs to act on. As the founding product designer, I worked across the entire stack, joining with no design function in place and owning the whole arc, from research and product strategy to shipping production code. To me, the part that mattered most was reframing the problem and designing a signal model the whole product could be built upon. This study follows that work to the point a client retired its entire monitoring stack. ## Challenge: three tools deep and still finding out late Comms and risk teams aren't short on monitoring tools. They're drowning in them. Renault ran three monitoring vendors in parallel, spent roughly €40k a month on agency briefings, and still waited up to two days for an in-depth report on a breaking story. By then the story had usually escalated. The deeper problem wasn't a missing feature. The comms and risk teams we spoke to kept describing symptoms, but no one had a proper grasp on the root causes. What we heard in research: "We always find out too late." "One message goes to everyone." "We're always reacting, never ahead." "We're flooded with noise." "Positive stories get lost." "Impact is hard to measure." ## Approach: from symptoms to a system that scales ### Reframe the problem The expectation was to keep shipping. There was already a rudimentary POC, and the pressure was to polish it and push it out. I made the case to get the problem right first. Shipping the POC as it was would only have scaled its untested assumptions, and we needed to understand the problem properly before committing the roadmap to it. So I ran a fast, lightweight discovery loop, enough to find the real problem without slowing the team down: align on the problem, trace symptoms to root causes, challenge each assumption, find the workflow wedge, and test to see what blocked users. The outcome wasn't a deck, it was a direction. The reframe moved Omniscient off "another monitoring tool" and onto getting teams ahead of signals, not reacting to them. Out of it came five missing capabilities, grouped into four moves that became the backbone of our roadmap: Detect (early detection and positive surfacing), Triage (signal vs noise), Prove (impact quantification), and Act (tailored messaging). That gave us one target to build against, and licence to say no to everything else. Looking back, it felt like a defining moment for the team. We'd been the blind men and the elephant. Everyone was holding a different piece, and nobody had a structured way to see the whole. For the first time we were all arguing from the same problem, not our own versions of it. ### Design the signal model That thesis became the product's conceptual model, a single core flow from detection through to action, with the idea that a signal could run through the entire product and serve multiple modules, from reputational risk to geopolitics. A signal is the product's atomic unit, a structured object the pipeline ingests, classifies, and scores. The big challenge I faced was twofold. First, the model had to apply across a variety of use cases and domains, but still be nuanced enough to drive action. And second, there's no neutral data underneath: every signal is AI-made, so trust had to be designed into the model, not treated as an afterthought. The end result was a model that matched the way comms and risk teams actually think in high-risk, critical situations: What's happening? What sources are generating this, and are they reliable? Where is this coming from, and how fast is it moving? Can I really trust this? Each question has a fixed home in the signal card's anatomy. The topline summary answers what is happening, the cited sources answer where it came from and whether they hold up, and the momentum indicator answers how fast it is moving. Trust is the one you cannot answer with a number, so every score drills into the coverage behind it. Reinforcement feedback sits over the top, and telling the model a signal missed trains the next one. Every AI-generated summary cites its sources. Users don't have to take a signal on faith; they can interrogate it. The sharpest evolution of the signal model came from our partnership with Renault. While signals were proving their worth, one observation kept coming up in our in-person sessions. A live event could trigger 80 or more signals at once, more than any team could hold in their head. So I added Topics, an abstraction layer that groups related signals into topics. This was the first true test of the signal model, and it held. Users no longer saw every signal up front; instead they read the roughly 20 topics first to grasp what was happening, then drilled into the signals beneath them only where it mattered. Collapsing 80-plus signals into roughly 20 topics changed how people scanned, but also improved productivity. In the product, triage lives in the Control Tower, the surface built on that same Topics layer. ### How it actually went This was far less linear than it reads. The core flow held, but the surfaces on top were shipped, tested in demos and research, and reworked, often more than once. The signal cards drifted into inconsistency before I pulled them into one design system; I cut more than one feature after research said it wasn't earning its place. Signals and topics ended up as reusable primitives, the same two objects rendered as a card, a canvas node, a brief, a chat reply. A fixed architecture is what let the model harden through all that change instead of fragmenting. ### Built, not just designed Working as a design-engineering hybrid was a massive change in mindset for me, and the wins deserve their own space: - I shaped the rules for how the backend signal pipeline qualifies and ranks raw sources, because signal-vs-noise is won before anything reaches a screen. - I shipped production frontend in React and shadcn/Radix, built to surface a pipeline of 150,000 data sources. - Quality and release were mine too: Playwright and Vitest tests, Storybook coverage, and a release-candidate (RC2) stability push. This is a shift in what one designer can own. A few years ago, ingestion logic, test suites, and release hardening were someone else's layer. I'm a big believer that tools like Claude Code and Cursor changed the trajectory here. I could follow a decision from Figma sketch to the pull request that shipped it. ## Results: one platform, a retired stack, €700k of spend gone Renault and On signed on as Omniscient's two paying design partners. Enterprises don't put reputational risk through a seed-stage tool on a hunch. For Renault, one platform replaced the stack: - €700k a year in retired spend across vendor contracts and agency briefings, excluding risk and cost avoidance. - From three vendors to one platform, overlapping contracts discontinued. - Under 15 minutes to detect, qualify, prioritise, and vet a signal, down from multi-day reports. - Insights now brief up to the board. Omniscient's intelligence reaches Renault's leadership, not just the analyst desk. For the product, the design held up: - The core flow held through every release without a rework, becoming the reference that product, design, and engineering all planned against. - The signal model renders consistently across every surface; the triaging view became the primary pattern for daily review. - Design partners self-serve. They onboard and make decisions without anyone explaining the product. ## What was hard: the cost of speed, and of being the only designer Shipping fast accrued real debt. The honest version of "eight months" is that the product broke in demos and needed someone in the room to explain it. Stability is a feature. I drove an RC2 push that chose hardening over new work, and built the onboarding that let partners self-serve instead of being walked through it. Being the sole designer is a bottleneck, not a flex. Owning strategy, design, and code sounds impressive until you're the constraint on everything. The only way to keep pace was to spend leverage early, on reusable systems and specs engineers could build from without waiting on me. I learned to design the process as deliberately as the product. It's still early. Omniscient is moving from two paying design partners towards general availability, and the test of the system is no longer whether it demos well. It's whether the anatomy, the triage patterns, and the trust affordances hold in the longer term, without me in the room. That was the point of building them as a system.