Signal
The context
I joined UT Labs, an internal startup team, to design and build Signal: an agentic research platform with no existing product, team convention, or design pattern to extend. It was a 0-1 problem in the fullest sense: the interaction model, the information architecture, and the underlying automation all needed to be defined at once.
Signal aggregates research feedback and continuously monitors it for trends, sentiment shifts, and emerging feature signals. When it surfaces something worth acting on, it can trigger an automated workflow for a product manager, rather than waiting for someone to notice the signal manually.
With one designer per squad, there was no separation between deciding the interaction model and shipping it. I owned this end-to-end: research, interaction design, product copy, and the front-end implementation.
Design engineering in practice
From Paper design to shipped code
I switched to Paper design to work directly against the constraints of the real codebase and shipped the resulting UI myself, rather than handing a static file to engineering. Design decisions and implementation happened in the same loop, so tradeoffs got caught before they became rework.
The trigger flow, recreated
The interactive demo below recreates the core trigger interaction from the product shown above: an always-on agent surfaces a signal and hands a product manager a ready-to-run workflow. It's genericized (not the real product's screens or data), built to demonstrate the pattern hands-on.
Feed
Agent
Users re-submit payment after a silent delay
Several sessions show a pause with no loading state right after "Pay," then a retry that double-charges.
Draft a fix ticket
- Summarize the 6 sessions where this occurred
- Attach the clearest recording as evidence
- Open a ticket assigned to Checkout squad
An AI-native workflow
Building Signal meant using the same category of tool I was designing: AI ran through research, prototyping, and iteration, not just the final product.
I used AI tools to synthesize research signal faster, to prototype interaction ideas as working code instead of static comps, and to move from an idea to something clickable or shippable in the same day. That loop was also what made design engineering practical here: an idea could go from a rough hypothesis to a real PR without waiting on a separate build step.
Key learnings
Ambiguity is the job, not an obstacle to it: There was no existing pattern to default to, which meant every interaction decision needed a rationale I could defend, not just a convention I could copy.
Design engineering compounds: Owning implementation didn't slow design down. It removed the translation loss between what I intended and what shipped, and let me iterate on real interaction feel instead of a static approximation of it.
AI changes the shape of iteration, not just the speed: Using AI throughout research and prototyping means I can test more of my own assumptions before bringing something to the team, so the artifacts I do bring are further along.