Senior product designer and design quality analyst in New York. Dashboards, design systems, and AI features that people will use even when they do not know how the model works.
4 projects
Merchandisers plan and manage shelves at scale. They had hundreds of reports available and no idea which ones existed or which applied to their job. Nothing was tagged, nothing was curated, and the search barely worked.
Interviews showed where the time actually went. Not into reading reports, but into finding them and then doubting they had the right one.
Finding the right report was the whole problem. Everything else followed from that.
The home page carried a widget that flagged unusual numbers from a merchandiser's own reports. The users were older, worked to a process, knew Excel well, and did not trust software that made recommendations. Try both versions.
Anomaly detected in SKU cluster 4471B
Confidence 0.87. Deviation of 2.4 sigma from the trailing 12 week baseline. Review recommended.
Why this fails. It is correct and nobody can use it. It asks a merchandiser to translate the model's vocabulary, gives them no way to check it, and sounds like an alarm during the busiest weeks of their year.
Sales on your top endcap fell for the third week running
Worth a look before Monday planning. Three stores account for most of the fall.
From: Weekly Endcap Performance
Three rules I designed to. Say it in plain words and say what to do. Name the report it came from, so people can check it rather than take it on faith. Ask for attention without sounding an alarm, because this kind of feature turns into a warning system very easily.
A replacement tool already existed. Nobody used it and nobody could say why. I proposed a six week pilot. One department, the new tool only, nothing to fall back on, and me supporting them the whole way. The old tool had been in use for over twenty years.
Every user moved across. They were never resisting the product. They just did not know it yet, and teaching them was enough.
A working rebuild of the shipped homepage: search, filter by business task, save a report, or select a few and combine them into one view.
8 reports ·
Select a report to preview it here.
Tax software is built for the person filing. Digilence is built for the accountant, whose work takes far too long with tools that were never shaped for it. In tax season that work becomes 80 hour weeks.
Six kinds of user touch this product and they have almost nothing in common. Designing the inbox for the tax admin and the dashboard for the CEO are opposite problems.
Discovery ends with questions rather than answers. These shaped the information architecture. Tap one.
The one that mattered most. Get it wrong and the inbox and the advisor end up competing for the same place in someone's head.
How the alerts work decides whether the inbox is a relief or just more noise for someone already at 80 hours.
Six kinds of user with opposite needs cannot share one set of onboarding screens or one empty state.
This decides whether the product stays inside the firm or goes out to clients, which changes almost everything after it.
A working rebuild of the two features I owned: the inbox, and a Digital Advisor that shows something different depending on who is looking at it.
6 items need attention
Inbox clear. Nice work.
PBC checklist — Acme Corporation
0 of 4 documents received
Team performance
Firm metrics & system controls
Also on the admin roadmap
No clients found matching your search.
Client creation is view-only in this rebuild.
A founder needed everything from one contractor. I treated it as a test of one question: how much of a real product can a single designer ship if AI does the production work? The answer came down to how much each prompt pinned down. Compare the two.
What comes back. Rounded cards, a sage green palette and a soft sans serif. Competent, ordinary, and impossible to keep consistent across twenty screens because there is nothing specific to hold on to.
What comes back. A direction specific enough to survive twenty screens without drifting, and specific enough that I can tell at a glance when something is wrong. You cannot review a result unless you set the terms first.
AI produces layouts faster than anyone can draw them. It still cannot tell the difference between a layout that is correct and one that feels right. That judgement stayed with me, and it is most of the job.
The same is true of the code. I did not write the animation logic by hand, but checking it meant knowing the React Native Animated API well enough to spot when it was wrong. That is an easier thing than writing it from scratch. It is not nothing.
The old page was a brochure. Sections in blocks of colour, serif body copy, screenshots that did nothing, no route to signing up. The new one leads with a search bar, because that is what the research said people expected.
I tested with 12 people from inside the company. That was a mistake. Everyone I tested already knew what the product was, and explaining that is the one job this page has. I would recruit people from outside who had never seen it.
I work as a senior product designer and a design quality analyst. Most of my career has been as the only designer on an analytics or fintech team, which means I do the research, draw the system and defend the decisions. The work I am proudest of is a hub that stopped a merchandising team from hunting through hundreds of reports every week.
Lately I have worked on AI from two directions. Designing features people will act on when they do not know how the model works, and using LLMs to do real production work across design and code. In both cases the job is knowing what a good result looks like and rejecting everything else.