Constraints Are the Clearest Brief You'll Get
Regulatory requirements and hardware limitations are not obstacles to work around. Read them correctly and they tell you exactly what the product has to do.
Tagged
Product Design
Product design from research through shipped code. Case studies covering mobile apps, web platforms, desktop tools, and design systems.
18 results
8 Min Read
Adda: Your AI Workspace
Designed a desktop AI agent workspace where teams of AI agents collaborate on projects, with structured context management, sandbox security, and an evidence-backed learning pipeline.
5 Min Read
Revenue Cycle Management. Redesigned.
Redesigned a healthcare clinic's revenue cycle management from patient intake to payment collection. Solo UX design, 6-week sprint, shipped to production.
8 Min Read
Three Crises, One Design System
Built a Figma design system at seed stage, then rebuilt it twice for a rebrand and clinical regulation. Token architecture absorbed ~40 features and two team transitions with zero sprint delays.
8 Min Read
Inclusive Healthcare by Design
How we designed an inclusive sexual health platform for the LGBTQ+ community where regulatory compliance and user dignity were the same problem. 6 certifications, mobile and web.
8 Min Read
Building an App for a Screenless Device
Designed and shipped a cross-platform Flutter companion app for a screenless NFC medical device, from discovery workshop through App Store and Google Play launch.
8 Min Read
Living Light: An Interface in Sync With the Sun
Designed and built a cross-platform Flutter companion app for a premium IoT sunlight machine, from workshop through BLE integration to App Store and Google Play launch.
Blog Posts
When You Can't Make It Faster, Make the Waiting Intentional
Hardware latency you can't remove is still a design material. The craft move is converting a wait into something that reads as feedback.
Hard Shadows Are a Constraint, Not a Style
Ban blur, gradients, and opacity from a design system and something unexpected happens: the decisions get harder, and the results get more honest.
The Same Feature Is Help to One User and Surveillance to Another
When two user groups share one system, a feature does not carry one meaning. Designing for both requires holding two opposed readings of the same screen at once.
Prototype the Argument Instead of Winning It
When a team deadlocks on an interaction model, arguing harder just hardens positions. Build both options and let the evidence end the debate before it becomes a conflict.
Reading the Role Before Writing a Word
A senior product designer role and a design-engineer role may both fit you. They are not the same reader.
I Stopped Building the Design System First
The instinct to lay a solid foundation before drawing a single screen is backwards. Building the system alongside the screens is what makes both finish on time.
Complexity Is a Safety Problem
Feature count debates miss the point. When your users are vulnerable, every added setting is a new failure mode, and cutting scope becomes a form of harm reduction.
Designing for Split Attention: Two Screens, One Story
When your interface lives on two devices, the user can only look at one. Sound, haptics, and invisible latency absorption become your real design tools.
Designing a Learning System Around How My Brain Actually Works
I have ADHD. Most learning tools ignore that. So I built one that doesn't.
Why Node Graphs Fall Apart at 15 Nodes
Node graphs demo beautifully with 5 nodes. At 15 they become unreadable. The problem is topology, not tooling.
Prototyping in the Wrong Tool on Purpose
The right prototyping tool depends on the question you're trying to answer, not the phase you're in. Sometimes paper beats Figma and code beats both.