Umair Yahya
All work

I wrote my design method down precisely enough for software to run it.

Direkta, 2026. An AI Head of Design that works inside a team’s own Figma file. It plans, audits, fixes causes in the design system, prototypes, prepares the handoff and keeps a decision log. This study is about the method, not the product.

DirektaFieldnote file

    What the audit found

    952
    checks run on the nine screens of the demonstration file
    11
    problems found, three ranked fix first
    10 of 11
    fixed, including all three fix-first; the one still open is a consistency problem
    214 of 214
    accessibility checks passing after the fix, from 181 of 188

    Internal test, on Fieldnote, a made-up app with generated photographs. The totals moved because the fixes added and removed elements.

    Run the audit, open a note, fix it at the cause, and re-check the file. The output is Direkta’s real output on the demonstration file.

    Role
    Co-founder and design lead, from September 2026. The method, the checks, the note formats and the decision rules are mine.
    I owned
    The method itself: what to check, how to rank, where to fix, what to ask before acting, what to log, and what to admit a design file cannot show.
    Worked with
    An engineering partner who built and runs the connector, a brand partner who set the visual bar, and early testers on real files.
    Live
    At direktadesign.com. Verified.

    Small teams ship without anyone who owns the standard.

    The screens go out, the drop-off shows up in analytics, and nobody can say which problem to fix first, because nobody decided what a screen must pass before it ships.

    I had spent fourteen years being that person in the room: the one who writes down what a component must do, which states it must carry, and what a design cannot promise. The method lived in my head and in documents that rarely outlived a project. Direkta writes it down as rules software can follow, inside the team’s own Figma file, with the team’s own components and tokens.

    It does six jobs a Head of Design does, each as a command: plan, design, audit, fix, prototype and hand off. Each rule had to pass one test: would a senior designer say this, in this order, with this number attached? If not, it did not go in.

    The method, as artifacts a team can read.

    If a method cannot be written down, it is only a reputation. Every job produces the same artifacts in the same place, so a reviewer always knows where to look.

    A note beside every screen

    Four fields, always in this order. For: who the screen is for and its one job. Watch out: the thing most likely to go wrong. Needs your OK: anything about money, rules or what the product does. For developers: the exact component, size and token.

    The note under the quote screen. The refund wording is flagged as sample copy that needs the owner’s OK.

    An audit note that ends in a number

    Each problem gets what is wrong, the one thing to do, and the values a developer needs: the check it failed, the criterion and the measured value.

    One audit note, complete: current and suggested side by side, a Do this line, and the developer line.

    A decision log, not a changelog

    Every decision records what was chosen, what was rejected, who owns it and what would reopen it. On Fieldnote, the main measure was set as quotes paid within 48 hours, with a target of 60%, marked as needing the owner’s OK and due to be reopened after the first 10 real quotes.

    Five decisions that make it a method, not a feature.

    Each names the alternative I turned down and who weighed in. The piece beside each one runs the rule.

    Fix at the root, on copies, then re-check everything

    Chose
    Find the shared cause, change it once in the design system, rebuild the affected screens on copies beside the originals, run every check again and show the before and after. On Fieldnote, two of the three worst problems shared one cause, a border color.
    Instead of
    Patching each screen where a check failed, or editing screens in place. Patching leaves the cause in the system; editing in place is the quickest way to lose a file.
    Decided with
    The engineering partner, who built the rebuild-on-copies behavior so the originals are never touched.

    A model of the principle, with the real Fieldnote values: 1.46:1 before, 4.76:1 after, minimum 3:1.

    Every fix gets a before and after, and a developer line recording what changed.

    Rank by what stops people, not by count

    Chose
    A short list to fix first, ranked by where money or completion is blocked. On the pay screen, card fields nobody could see outranked a portfolio you could only swipe through.
    Instead of
    A flat list of findings sorted by severity labels. It looks thorough and tells a team nothing about where to start.
    Decided with
    The brand partner and early testers, on real files, where the ranked page was the part people acted on.

    Five of the 11 notes from the Fieldnote audit.

    The first note of the audit. Money changes hands on this screen, so it ranked first.

    Say what cannot be checked

    Chose
    Every audit ends with what a design file cannot show and who should check it. The accessibility tile reports failed, passed and could-not-check as separate numbers.
    Instead of
    Reporting only what passed. A score that hides what it could not measure teaches a team to distrust it.
    Decided with
    Nobody; it did not need arguing. It is the rule I apply to my own case studies, including this one.

    The same audit, reported two ways. The numbers are Fieldnote’s, after the fix.

    The real tile from the Fieldnote audit.

    Ask before guessing, and report the small calls

    Chose
    Anything about money, rules or what the product does stops and asks. A reversible call, such as a button label, is made and reported in the note. A change to product behavior is never made without asking.
    Instead of
    A fully autonomous agent that decides everything, or a fully manual one that asks about everything. The first is dangerous and the second is useless.
    Decided with
    The tests themselves: in early runs the agent changed product behavior without asking, and that became a rule it cannot override, even in testing mode.

    Four changes from the Fieldnote run, and what the method lets the agent do with each.

    Measured checks run as fixed scripts, not as model judgment

    Chose
    After two models scored the same file’s accessibility 11 points apart, every check with a number moved to fixed scripts: contrast, target size, spacing and radius. Judgment stays with the model where judgment is the job: hierarchy, copy, the laws of UX.
    Instead of
    Letting the model measure contrast, sizes and spacing along with everything else it judges.
    Decided with
    The engineering partner. The benchmark was mine.

    The gap is the real benchmark result. The bars show the difference, not the actual scores.

    One full audit, on a demonstration app.

    Fieldnote is a made-up app for freelance photographers: send a quote, take a deposit, deliver the pictures. Its screens and photographs were generated for the demonstration; the audit, the notes and the numbers are Direkta’s real output. Direkta audited the nine screens in one Figma file, then fixed them.

    The worst one was on the pay screen. Before anyone typed, the Expiry and Security code boxes nearly vanished into the page, on the step where money changes hands. The boxes measured 1.46:1 against the page; the suggested border measured 4.76:1. Two of the three fix-first problems shared that one cause, which is the whole argument for fixing at the root.

    Two kinds of check. Measured checks have a number and a threshold, and run as fixed scripts. Judged checks need a designer’s eye, run through the model, and are why the notes read like a person wrote them. Focus states, screen reader order and real wait times are handed to a named person, not scored.

    Before the audit, three directions.

    Direkta planned and designed Fieldnote from a one-line idea and offered three looks with a recommendation. The decision log records the choice and the two it rejected.

    Studio journal: editorial serif, cream sheet. Rejected.
    Darkroom: warm black, photographs first, one orange for what to tap. Chosen and logged as settled.
    Keepsake: tilted prints, a date card. Rejected.

    The unhappy paths were designed with the screens, not after them: a declined card keeps what was typed and says nothing was charged; going offline keeps the details with one button to try again; pictures that are not ready yet come with a date and a way to be told.

    Declined.
    Offline.
    Not ready yet.

    After the fix, it added a second theme, tablet and desktop sizes, a prototype and the handoff: seven playable flows with 205 links and no dead ends, and 353 tokens in CSS and JSON, with 322 of their values compared against Figma and 0 mismatches.

    Ready for developers, checked against the file.

    What this is evidence of, and what it is not.

    • VerifiedDirekta is live at direktadesign.com, and the audit on this page is one any team can run on a flow in its own file.
    • Internal testThe Fieldnote audit, counted the same way before and after the fix, including the 5 items a design file cannot check, down from 21, each assigned to a person.
    • Internal testThe handoff checks: tokens compared against Figma, and every prototype flow walked for dead ends.
    • Internal testTwo models scored accessibility 11 points apart on the same file. That gap is why measured checks run as fixed scripts.
    • ReportedOne early tester told me they designed a complete mobile app with it in about an hour; I did not time it.

    What I can claim

    The method: the rules are mine, the output is real, and the numbers were counted the same way before and after. Fieldnote is a demonstration on a made-up product, so no customer outcome, revenue or retention figure is claimed. Direkta runs on a third-party AI model and a Figma connector; neither maker endorses it.

    What I would do differently

    Set the bar before the first test. An early run on a childcare app missed my standard, and the fix was to collect 10 to 15 example interfaces that define good before the agent designs anything. I would also move the measured checks into scripts before benchmarking the models, not after.

    What it taught me

    Writing the method down was the work; the software was the proof it was written down well enough. Fixing the cause once is the only fix that scales. And the honest audit is the one that lists what it could not see.

    Verified on the record: a live product, a public page or a project document. Internal test measured by me or the team, outside production. Reported someone told me; I have not seen the data.

    Building something harder than it looks?

    Open to Principal and Lead Product Design roles, in Dubai or remote.

    umairyahya48@gmail.com

    LinkedInResume