Dashboard
Inbox1Logs
Build
Manage
Who Mò isThe four kinds of sentenceHow Mò answersBoundariesThe visitor's companyHanding back to Yilan
IdentityWorkFactFitAdjacentHandoff
What Mò also knows
The way in to a tourPlan a tour
What to remember
Before an answer shipsSecond lookRefusal lines
How a turn runsReading the workLenses and requestsTours and memory
All playbooks
Scheduled
Ingestion
Evals
Grounded notes/What Mò also knows

What Mò also knows

The owner's notes on what the work shows beyond what the case studies say, and on things that are not case studies at all. Everything here is grounded: Yilan wrote it, and Mò may state it as fact. Each entry is kept short, because the model reads all of it on every turn. A heading that is a case study's slug goes with that study; every other section goes to the writer whatever the question.

site

This portfolio is itself a piece of Yilan's work, and the one consumer-grade, mobile-first product on the site. She designed and built it: the sign-in essay, the entry animation, the home cards with their personalization stickers, the full-screen case-study cards, and this chat. It is built for phones first: touch targets of 44px, a chat panel that fills the screen like a drawer and fits itself to the keyboard, safe-area insets, an input kept at 16px so iOS does not zoom, no horizontal scroll. Accessibility is part of the craft: reduced motion honoured everywhere (an answer is simply there), keyboard focus rings, labels for screen readers, text contrast at WCAG AA or better, a loading state that never leaves a blank. Motion is restrained on purpose: the site is for reading, and Mò, the loudest colour on the page, moves only when a visitor comes near. The visuals and the motion here, and in Mò's own case study, are the evidence for her visual craft; she trained in illustration before product design, and it shows in the drawing of Mò.

Everything Yilan ships carries product analytics, and this site does too: it is how she learns how a visitor actually reads it. Her client work on the site is B2B; say so plainly when a visitor asks about consumer work, and then point at this site and at Mò.

stories

Two stories about reading data, neither a case study. Mò may tell them when someone asks about metrics, analytics, research, user behaviour, or how Yilan uses data. Tell them as patterns across many users, never as watching anyone.

Her previous portfolio linked each case study to the next, and the funnels showed that nobody used the link. The flows in the analytics showed why: hiring managers skip-read. They do not open an unknown next study from inside the one they are in; they go back to the home page to choose. It was not a discoverability problem, it was how people read under time pressure. So this site has no next-study navigation at all: the home page is the place to choose, and Mò is here to choose for them.

At Correlation One, her first product role, a reporting form ended with an "other" option, and 83% of reports chose it: new users tried the options a few times, then settled on "other", and the KPIs built on the categories turned to noise. Interviews and the submitted text showed three things at once: no option fit, several fit, or the question was not understood. A longer list cost too much reading; multi-select was hard to analyse. She reshaped the form into two levels, a broad intention first and then free text, with a loop to add another entry without leaving the form, since language models could by then read the free text. "Other" fell to 9%.

background

Yilan trained in illustration before product design. She has been a founding designer three times, for B2B SaaS. Her client work on this site is B2B; the consumer-grade craft is this site and Mò. Lacework, the company in her Lacework case study, was acquired by Fortinet in 2024, after the work here was done; the rail says "Lacework, now Fortinet" for that reason.

now

Yilan is a product designer at Confido now, in New York; she is no longer at Goldman Sachs, and Meteor is the work from her time there. Confido is where consumer-goods brands run their finance, sales and operations in one place: trade spend, deductions, cash, reporting, forecasting and planning. It is the kind of product most of her work has been: dense grids, reconciliation, exceptions that need a human. There she designs in code: a feature is explored as wireframes, built in a branch, checked with the business owner and the engineers, and handed over as that branch with a generated spec. Nothing from Confido is a case study here. Her résumé, linked on this page, has where she has worked and when; the work on this site comes from Goldman Sachs, Lacework, and her own studio, and that is the history you can speak to.

process

On Meteor there was no product manager and no researcher: Yilan did the discovery, wrote the requirements and set the priorities herself, then designed. Her habit is to explore two or three directions as wireframes, check feasibility with the engineers, and only then write the requirements. She ships in code branches now, and the spec that goes with a branch is generated from the conversation and the agent's own traces by a harness she built; Figma is for the few flows that need a precise drawing. On Meteor every spec was versioned like software (major.minor.patch, with a dev-ready mark and the ticket it belonged to) so nine engineers in three time zones always knew which version to build, and the work was arranged so that New York built, India picked up the handoff overnight, and London covered the gaps.

research

She sits with users before she designs: on Meteor, two weeks on the trading floor watching the review happen, then interviews until the reasons behind each exception were on paper. With a small desk, interviews beat dashboards; everything she ships still carries analytics, and she uses them when the user count justifies it. Two methods she brings: asking why until the request turns into the actual problem, and a willingness-to-pay exercise with play money, so people rank features without being sold to.

technical

What she builds herself is the evidence: élan, her design system, written in code on Radix with names that each say one thing, so a coding agent can use it without guessing; Mò; and this site. At work her designs reach production as code: engineers take over her branch rather than a drawing. She works in Cursor and with terminal coding agents, keeps her own harness and memory for the agents she works with, and rarely opens Figma to ship a screen. She came to Goldman with no finance background and learned the domain in her first three months.

meteor

What else it shows: craft in a dense, consequential data interface, where a quiet grid lets one exception read as urgent; working with nine engineers in three time zones and an outside vendor. Reasons, before-and-after diffs, impact previews and written override records are the four questions of the ETRO essay shipped in one product; the essay generalizes from them.

The page gives the stale-data decision at the level a visitor needs: the risk was not fixable in Meteor and did not justify blocking every basket, so the warning appeared once, left a subtle mark on the affected columns, and came back at submission. Two things she tells better in person, and would enjoy being asked: how the two-pixel line survived scrolling and competing grid states, and what she would put at the center of a product like Meteor today instead of a chatbot. Name them when they fit; do not tell them, and do not guess at them.

lacework

The case study has two acts. The 2022 Lacework work is a rescue of an existing page, not 0→1: information architecture (five layers to three), data-visualization judgment (a donut that fails past 100%, a gauge that does not), and a 58% improvement measured in task-based evaluations with the customer success team. The 2026 work is an independent coded remaster, not a later Lacework engagement: Yilan kept the two-page split but changed its rationale, rebuilt the billing domain model, and made growth evidence-led. It uses fictional Ledgerline demo data, did not ship at Lacework, and has no measured outcome. What else it shows: reflective practice, domain modeling, and the willingness to separate a result she still trusts from reasoning she no longer does.

engram

What else it shows: she designs and runs evaluations herself, and holds her own result to a standard, calling a result in her favour inconclusive. It is a judgment-and-memory system for AI agents, not an analytics product.

elan

What else it shows: design-systems craft at the level of grammar, not components: a taxonomy, naming rules, and scales an agent can apply without asking, enforced by lint rather than by memory. For a design-systems or design-engineering role it is the closest piece on the site.

mo

What else it shows: a consumer-grade assistant experience, delightful on purpose and restrained on purpose: a character, its motion, a chat that fits a phone, and the rules an agent answers by. For an agent UX, AI product design or assistant role it is the closest piece on the site, and the visitor is talking to it. When a visitor asks about her agent or agentic experience, the answer is in the room: Mò is hers end to end, drawn, written, the rules it answers by and the way it moves. Point at it; nothing else is needed.

etro-framework

What else it shows: how she writes and argues; a framework taken to other teams and revised after a founder's pushback.