Design Engineering with Maggie Appleton

Maggie Appleton discusses design engineering, her prototyping work at GitHub Next, and how coding agents change the work before implementation. Her practical approach combines paper sketches, browser prototypes, and agent-built controls for adjusting a design directly.

Based on the video's English auto-generated captions, not an independent review of the audio or visual demonstrations. Workflow outcomes and model limitations are Appleton's observations; proposed interfaces and predictions are not established findings.

Key points

• Design engineering connects user concepts to technical constraints. Appleton describes product design as choosing understandable “nouns and verbs”: what objects users work with and what actions they can take. For agent tools, deciding whether sessions, plans, or groups of sessions are the main objects changes how users understand the product. She notes that other design roles can legitimately focus more on user research than technical internals. 10:46–17:42(opens in a new tab) Her definition of a design engineer includes understanding how backend data and technical capabilities constrain what the interface can offer, and often implementing it herself—not just designing polished animations. 33:37–35:36(opens in a new tab)

• Sketch before asking an agent to implement. Paper lets her explore the shape of an interface quickly, before she can express it precisely in words. The sketch stays visible and easy to revise. She does send photos to agents, but reports poor spatial and visual results, so she prefers to work out the design first. 25:54–29:02(opens in a new tab) She still uses Figma, but moves into browser prototypes early because font rendering, responsiveness, scrolling, and motion need to be judged in the medium users will experience. 38:43–39:45(opens in a new tab), 57:40–58:28(opens in a new tab)

• Have the agent build controls for the choices you need to make. Her “jig” is a small, task-specific tool: sliders, color pickers, and other controls wired to a live prototype's variables. Instead of repeatedly describing a desired animation speed or contrast in chat, she changes it and sees the effect immediately, then commits the selected values. The interview describes this with a constellation animation. Such controls were possible to build manually before; agents make building a custom set more practical. 39:45–40:44(opens in a new tab), 47:40–50:37(opens in a new tab), 56:41–58:28(opens in a new tab)

• Use a visual feedback loop for prototype implementation. Appleton reports asking an agent to implement a Figma design, use Playwright screenshots, and keep iterating until the result matches. This frees time for more ambitious prototypes, but she still supplies substantial design direction. 45:37–47:40(opens in a new tab) She emphasizes that her research prototypes have a lower quality bar than production GitHub software. 19:26–21:17(opens in a new tab)

• Show the information each decision needs. Appleton argues that long sequences of questions become tiring, especially when users lack the information needed to judge the options and start accepting the recommended answer. Multiple choice may be enough for simple decisions. For harder ones, she is prototyping decision cards with relevant visuals: border previews for appearance choices, or architecture diagrams for structural choices. She proposes retaining who made each decision and what information they saw so teams can later revisit the rationale. These are design explorations, not a finished system. 21:17–24:59(opens in a new tab)

• Faster individual coding does not establish team agreement. Appleton argues that faster implementation leaves less time to resolve disagreements along the way, making agreement on scope, interfaces, and technical changes more important before handing work to an agent. Shared sessions help expose work, but do not themselves settle decisions. 1:00:32–1:03:12(opens in a new tab) GitHub Next's ACE prototype combined a Slack-like workspace with shared sandboxes and review tools; she says turning the whole system into a product proved too ambitious for the small team, so they are exploring smaller pieces and related questions. 1:03:12–1:07:00(opens in a new tab)

• Polished alternatives are not a usability check. Appleton sees generated mockups as useful for simple interfaces or developers without access to a designer. For a new product concept, someone still needs to test what users understand; choosing an attractive variant does not answer that question. 50:37–52:44(opens in a new tab)

• Start with interfaces users already understand. Elicit's users already extracted research-paper data into spreadsheets, with one paper per row and extracted values in cells. The team tried canvases and cards, but users found them confusing and repeatedly asked for a table. Appleton says familiarity reduced the effort of learning the tool. Elicit could then add capabilities within and around that familiar structure rather than replace it. 53:47–56:41(opens in a new tab)

• Do not generalize from one impressive model result. Appleton's phrase “capability gaslighting” describes how an impressive result can make her trust a model enough to underestimate how badly it fails on another task. It is a metaphor for her experience, not evidence of intentional deception or a benchmark finding. 58:28–1:00:32(opens in a new tab)

  In her design work, even skills—written instructions specifying preferences such as padding and borders—do not consistently produce the intended result, so she still adjusts values herself. Those preferences are not universal design rules. 1:08:03–1:09:45(opens in a new tab)

• Small community software needs sound foundations. Appleton extends “home-cooked software”—tools made for yourself and your family—to community needs. Her “barefoot developer” is a technically inclined community member who uses agents to build tools, such as scheduling or inventory software, when a spreadsheet is insufficient. She argues that these builders need frameworks that provide security and reliable data storage rather than leave them to solve unfamiliar engineering problems. She favors local-first foundations: keeping data on users' devices and syncing it between machines rather than requiring a cloud database. This is a proposal for supporting less experienced builders, not an assurance that generated apps are safe. 1:15:43–1:21:47(opens in a new tab)

Full video: https://www.youtube.com/watch?v=KZSzF0KEFRg(opens in a new tab)