Design Engineering with Maggie Appleton

Maggie Appleton describes a route into technology through cultural anthropology, early HTML and CSS, illustration and developer education. Illustrating programming concepts at Egghead required understanding the React and JavaScript material she was explaining.

At Elicit, she then worked through a broader product cycle: understanding scientific literature-review work, designing an experience, implementing frontend pieces, shipping and measuring. The small team and repeated releases gave her practice connecting the user's domain to the system that served it.

That history explains the perspective she brings to this interview. Design is not only the final visual treatment. It includes how a problem is framed, what the software lets people manipulate and whether those choices make sense in use.

Appleton compares design with engineering problem-solving using different materials. Visual materials include space, size, color, prominence, motion and words. Product design also has to decide the nouns and verbs of the system.

A shop has familiar objects such as a product and a cart. Developer tools can involve abstract data containers and transformations. Agent tools introduce sessions, plans, skills and connections whose boundaries are still being invented. What is a thing the user can point to, and what can they do to it?

Forking a session, for example, raises questions about what is copied and what remains connected. A coherent model lets people predict the result of an action. Reducing a flexible technical system to a small understandable set of concepts is difficult work, even when the interface looks simple afterward.

Appleton defines her own role around close engagement with the technical shape of a product. Backend data, APIs and model capabilities constrain what can be represented in an interface and what users can reasonably expect.

She does not insist every designer must work in the same way. Some domains benefit more from a designer concentrating on research, user advocacy or a familiar flow, without deep involvement in the database. Visual and motion specialists also occupy valid positions.

Her version of design engineering crosses the boundary: working with engineers, often implementing frontend work herself and understanding enough architecture to reason about the experience. It is broader than producing an attractive hover animation, although that detail can still matter.

Appleton's current planning experiments begin with frustration at long agent interviews. Repeated multiple-choice questions can exhaust a person before the decisions are finished. A recommended option can become something accepted automatically rather than understood.

Different questions need different evidence. A choice about border contrast needs a visual comparison. An architecture decision may need a data-flow diagram or state machine. She is exploring decision cards or small documents that give each issue enough space, rather than representing every choice as another short chat turn.

She also wants an owner and a record of the information available when the decision was made. That is useful for reconstructing why a team chose an approach later. These are prototype ideas, not a claim that a finished collaborative planning product already solves the problem.

Appleton still sketches because a loose arrangement of boxes or a possible composition can be faster to draw than to explain to an agent. The page externalizes something that is not yet a precise verbal specification.

It also remains physically available. A notebook on the desk can remind her the next day what shape she was investigating. Her illustration background trained her to use drawing as problem-solving, not merely as a polished output.

She finds current agents inconsistent at spatial and visual work, so she often works out the shape before delegating implementation. Those observations do not mean models literally have no image input. The practical issue is whether they understand and preserve the relationships the design needs.

The familiar tension between a perfect mockup and a difficult implementation is partly a tool problem in Appleton's account. Static design tools can hide performance, loading, rendering and state constraints that become unavoidable in a working application.

She compares this with understanding wood when making furniture. A web designer needs some awareness of data fetching, slow states and possible races, just as a physical designer needs to know how a material behaves. Agents can help explain an unfamiliar technical constraint and let a designer explore it.

Her workflow uses sketches and sometimes medium-fidelity Figma work, then moves into a browser early. Font rendering, breakpoints and scrolling can change how a composition feels. A prototype exposes those interactions more directly than another static screen.

Appleton borrows the term jig from woodworking for a small set of controls built for the task at hand. Ask the agent to attach sliders, color pickers or other controls to the variables that remain uncertain, then adjust them while looking at the live result.

Her constellation-page experiment makes this concrete. Animation speed, star variation, sizing, scroll behavior and glass effects become parameters she can manipulate directly. Changing the glass treatment reveals a real readability trade-off: too bright or too faint produces different problems.

57:20View full image

This does not mean the agent independently produced design to her standards. She describes substantial direction and iteration. It also matters that GitHub Next is a research and prototyping team: the quality constraints of an exploratory artifact differ from those of a change shipped to GitHub's established users.

The host asks about engineers generating many high-fidelity options instead of working with a designer. Appleton sees value when no designer is available and a simple interface is needed to test a hypothesis.

A new product primitive presents a harder question. Someone must examine what users understand, test alternatives and determine whether the system is coherent. Many polished options can repeat the same unexamined assumption.

She also criticizes context-insensitive application of design rules, such as explanatory labels everywhere. That is an argument about matching information to the user and situation, not a general instruction to remove accessible names or necessary guidance. Visual polish and usable behavior still need to be examined separately.

At Elicit, the team explored canvases, cards and composable documents for extracting data from scientific papers. In interviews, users repeatedly asked for the table format they already used in spreadsheets.

Appleton's lesson is specific to that task: familiarity reduced cognitive load. New model capability did not require an entirely unfamiliar interface. The table could become more capable through features within and around it.

She expects familiar documents, sidebars, cards and tables to remain useful. The claim is not that chat is always wrong or every AI product should be a spreadsheet. Start with the work people are doing and test whether a new interaction improves it.

Appleton calls the uneven experience of model ability “capability gaslighting.” A model can impress on one task, leading a person to trust it on another where it fails, sometimes without the failure being noticed immediately.

A changed prompt, different context or a new version can also change results. The metaphor describes a user's mistaken expectation of consistent expertise, not an assertion that a model intentionally manipulates someone.

The consequence for design is to verify the task at hand. A beautiful prototype or a successful earlier session should not make a team overlook a failed interaction, incorrect state or a result that merely looks plausible.

Appleton argues that software remains team work even when each person can implement much faster with an agent. Before an issue is ready for implementation, colleagues still need agreement about the feature, architecture and experience.

She describes experiments with shared compute and a chat-like workspace, including the ACE prototype. It proved ambitious for a small team; the conversation does not present it as a completed general solution. Shared access is only a starting point if the team still lacks a way to make and record decisions.

Her next questions concern proactive agents and shared documents: how can useful background work arrive without overwhelming or interrupting people? The imagined hundred cheap agents are a design thought experiment. The scarce resource in that scenario is human attention, not just model capacity.

Appleton still intervenes in transitions, spacing and other details because agents do not consistently meet her standards. She wonders how she would feel if a perfect interface appeared without her participation; the interview leaves that question unresolved.

She also distinguishes basic readability from aesthetic fashion. A style that currently signals care can become generic when it is repeated everywhere. The meaning of a visual language depends on a changing cultural context.

The host questions whether specialists recognize generated text or design more readily than everyone else. The discussion does not establish a reliable detector of AI authorship. What matters is the experience and meaning people take from the artifact, rather than an unsupported claim that appearance proves its origin.

Away from product interfaces, Appleton describes publishing writing at different stages: seedling, budding and evergreen. A piece can be incomplete if the reader can see that status and the work can be updated over time.

Clear labels let rough notes coexist with polished essays without pretending both are finished. That helps her work publicly despite perfectionist tendencies.

The principle is a contract with the audience. Showing work in progress is different from presenting unfinished material as the best completed work. The distinction depends on accurate communication, not merely a gardening metaphor.

Appleton discusses Robin Sloan's home-cooked software idea: applications made for oneself and one's family, rather than necessarily for sale at scale. She extends it toward a community power user who can build a small useful tool for a local group.

Lower construction cost does not remove engineering risks. She explicitly worries about security, data handling and persistence when people build without understanding the code. Her preferred local-first foundations are a proposal for stronger ownership and reliability, not proof that any locally stored application automatically has those properties.

The opportunity is therefore partly in frameworks and support. A tool that appears to work today still needs to preserve the community's information and remain manageable when something goes wrong.

Appleton encourages designers to learn the technical shape of their product and engineers to study typography, usability and alternative representations. An agent can be a patient tutor or brainstorming partner, while its suggested interface still needs judgment.

Her anthropology background adds another question: what unspoken assumptions shape how this audience interprets the system? People use products in physical and cultural contexts, with different habits and expectations. Going closer to the customer's work can reveal when and why the product is chosen.

The interview ends with attention to the consequences of design, including a book about gambling-machine environments. That closes the loop with her definition of the job: understand the people, understand the material, make the model coherent and test what the experience actually does.