Some papers are not directly “my work,” but they change how I explain things. They give me a sharper phrase, a better causal story, or a cleaner warning sign. I do not always need to write a full essay about them. Sometimes I just want a small handle I can come back to later.

So this is a running note for technical papers I want to remember.

The format is simple:

• why I’m saving this
• my TL;DR
• what it changes in my thinking
• where it might connect

Locality in Image Diffusion Models Emerges from Data Statistics

Artem Lukoianov, Chenyang Yuan, Justin Solomon, and Vincent Sitzmann. NeurIPS 2025 Spotlight.

Project page: Locality in Image Diffusion Models Emerges from Data Statistics

Why I’m saving this

This paper is a clean reminder that model behavior is not always best explained by architecture alone.

Sometimes the important structure comes from the data.

That sounds obvious at a high level, but the paper makes it very concrete. It looks at locality in image diffusion models: the pattern where an output pixel mostly depends on a limited neighborhood of input pixels. Previous work connected locality to generalization. A tempting explanation is that locality comes from CNN architecture, especially because many diffusion models use U-Nets.

This paper shows a different story. U-Nets, DiTs, and even a simple linear denoiser can show similar locality patterns on the same data. The locality changes when the dataset changes.

The sentence I want to remember is:

The model inherits a neighborhood from the dataset.

My TL;DR

Diffusion models have a closed-form optimal denoiser under the training objective. But when this empirical optimal denoiser is used for sampling, it tends to memorize training data. Trained deep diffusion models generalize and produce novel images.

The paper asks what helps bridge memorization and generalization.

Their answer is locality.

The key result is that locality is not just an architectural bias from CNNs. It emerges from the statistics of the data. On natural images, the learned locality is compact and roughly isotropic. On more specialized datasets, like centered face datasets, the sensitivity fields can become nonlocal and face-like. If the dataset has an artificial correlation pattern, the learned locality can reflect that too.

What it changes in my thinking

I want to be more careful when I explain AI systems.

It is easy to say:

The model does this because the architecture has this property.

Sometimes that is true. But this paper is a good example of why the explanation may live somewhere else: in the data distribution, the objective, the task setup, or the interaction among all of them.

For my own thinking, the useful move is to ask:

Where did this behavior come from?

Not just “what did the model do?” but “what part of the system made that behavior likely?”

That feels useful for reading AI papers, but also for HCI. When a prototype works, the interesting question is often not only whether it works. The interesting question is what explains the behavior we are seeing.

Is it the model? The data? The interface? The task distribution? The evaluation setup? The way users adapt around the tool?

Good research should help reveal that structure.

Where it might connect

This connects lightly to my note on prototyping to understand humans.

In that post, I was asking what makes HCI research valuable when AI makes it easier to build plausible systems. This paper gives me one more way to say it: a good artifact should help us see where behavior comes from.

The locality result itself is about image diffusion models. The broader habit is what I want to keep: when a system looks intelligent, look for the surrounding structure that made the intelligence possible.

That is the first note. I want more of these: small technical reads that give me better language for explaining AI systems.

Don’s post is about why generative AI breaks many of our old categories. One part that stuck with me is his framing of AI as both specialist and generalist. Humans usually have to choose a shape. You can go deep in a narrow area, or you can become broad and shallow across many areas. Most of us are somewhere in between.

AI makes this distinction weird. It can appear broad like a generalist and deep like a specialist, while still being naive, error-prone, and strangely eager to please.

That helped me connect two things I have been thinking about: research taste and distributed cognition.

Maybe the question is not “should I become a specialist or a generalist?” Maybe the better question is:

What kind of cognitive system am I learning to build around myself?

Don’s point, as I understood it

Don’s argument is not just that AI is powerful. It is that AI does not fit cleanly into categories built for humans.

We keep asking questions like: is AI conscious? Is it intelligent? Is it creative? Does it have empathy? Does it have morals?

Those questions are tempting because they are familiar. But Don’s point, as I read it, is that they may be the wrong questions. We barely understand those concepts in humans, so using them as the default yardstick for AI can make us feel philosophical without making us much more precise.

The more useful move, at least for me, is to treat AI as part of a larger cognitive system. Not a mind like ours. Not a tool like a hammer. Something stranger: a node in a network of people, models, writing, institutions, workflows, interfaces, habits, and artifacts.

That framing immediately felt useful.

Specialist vs. generalist is an individualist frame

The specialist/generalist distinction makes sense when the unit is one person’s mind and career.

A PhD makes this tension especially painful. You are supposed to become very good at a small thing, but good research often requires borrowing from many places: design, cognitive science, systems, methods, writing, teaching, and the actual messy world.

Specialists go deep. Generalists connect. Both matter.

But AI changes the cost of moving between domains. I can ask for summaries, examples, counterarguments, code sketches, paper trails, and analogies across fields. That does not make me an expert in those fields. It does not remove the need to read, verify, or develop taste. But it does change the rhythm of thinking.

So maybe the scarce skill is not knowing everything.

Maybe the scarce skill is knowing how to coordinate partial knowledge.

AI makes breadth cheap, but judgment expensive

This connects to something I wrote in prototyping to understand humans. I was trying to understand what makes HCI research valuable when AI makes building plausible systems much easier.

If AI can help us generate prototypes, write code, summarize literature, produce design alternatives, and simulate parts of the research workflow, then “I built a thing” becomes less impressive by itself.

The more important question becomes: what did the artifact help us understand?

AI can increase the surface area of exploration. It can help me move faster across unfamiliar material. It can make more ideas reachable. But it can also make weak connections feel profound and shallow summaries feel like understanding.

That is why judgment becomes more important, not less.

The work is not just asking AI for more ideas. The work is deciding which ideas deserve friction.

Distributed cognition, but also distributed responsibility

I like the distributed cognition framing because it moves the unit of analysis away from the individual mind. That feels right for HCI. People do not think alone. We think with notebooks, diagrams, search engines, software, collaborators, papers, deadlines, institutions, and now models.

It also connects back to an afternoon with don norman, where the most interesting part of his DLab talk, at least for me, was not just “AI in education” in the generic sense. It was the idea that learning should help people connect across problems, disciplines, and forms of support.

But there is a danger here too.

Distributed cognition can become distributed irresponsibility.

If the model suggests, the paper says, the prototype shows, the user study implies, and the team agrees, then who is actually responsible for the claim?

This is the part I want to keep making uncomfortable for myself. AI as distributed cognition is not just a nice metaphor for augmentation. It is also a demand for better accountability. We need to know what to ask, what to trust, what to verify, what to preserve as human difficulty, and what kind of knowledge should survive after the tool changes.

That last part feels especially important for HCI research in the age of AI. If we are studying human-AI systems, then “the system” is not only the interface. It is also the researcher, the model, the prompts, the documentation, the study protocol, the evaluation frame, the institution, and the incentives around the claim. Research taste is partly the ability to notice where responsibility is hiding.

A reading note I want to keep

Why I’m saving this: Don gave me a cleaner frame for something I have been circling around. Maybe “specialist vs. generalist” is not the right unit anymore. Maybe the more interesting unit is the cognitive system: person plus model plus tools plus representations plus collaborators plus institutions.

My TL;DR: Don argues that generative AI breaks the old distinction between specialists and generalists. It is not very useful to judge AI only with categories built for biological humans, like consciousness, morality, or empathy. A better frame is to treat AI as one node in a distributed cognition system.

What it changes in my thinking: I have been wondering whether a researcher should become more specialist, more generalist, or some strange hybrid. Don’s framing makes me think the answer may not be an individual identity at all. The more important question is what kind of thinking system I am learning to assemble around myself.

What I am still unsure about: Distributed cognition is powerful, but it can also blur responsibility. If cognition is distributed across people, models, tools, and institutions, then accountability has to be designed too. Otherwise everyone can point somewhere else when the system produces bad knowledge, bad design, or bad decisions.

Go read the original: Don says this better than my tiny summary, and I really do think the original is worth reading: Beyond Human Categories.

Related notes

This connects back to my older note, an afternoon with don norman, where I wrote about Don’s DLab talk and his thoughts on education in the age of AI.

It also extends my note on prototyping to understand humans. There I was asking what makes HCI research worth doing when building tools becomes easier. This post is one possible answer: maybe good research is not just about making artifacts, but about learning how to arrange cognition so that better questions, claims, and responsibilities become possible.

Fast tools make it easy to produce more interface. They do not automatically make the interface clearer. So the real loop was not “ask the agent to make it cooler.” It was:

1. Say what a rushed visitor should understand.
2. Ask Codex for a plan before implementation.
3. Implement one pass.
4. Look at desktop, tablet, and mobile screenshots.
5. Remove the parts where the ink did not earn its place.
6. Write the lesson back into a heuristics file.

That last step matters. I wanted this to become a teaching artifact for COGS 125, Advanced Interaction Design, where I am a TA in Winter 2026. A lot of students are just starting to use AI to build portfolio websites for course projects. “Make it clearer” or “use better hierarchy” can stay abstract; a living markdown file gives the critique something to hold onto.

The file itself grew gradually through screenshot critique, interface revisions, and distilled design iterations, so it records the process instead of pretending the rules arrived fully formed.

Download the heuristics MD Open the case study

Loading heuristics...

The site before the loop

The older site was useful, but it was mostly a container for information. The new version tries to make the story visible sooner: I am a UC San Diego HCI PhD student studying how interfaces can sharpen design judgment, especially in an age where AI can generate many plausible directions quickly.

What the agent was good for

I used Codex with high-reasoning, plan-first implementation loops. The useful thing was not outsourcing taste. The useful thing was making iteration cheaper: more variants, faster screenshots, more chances to notice what felt wrong.

Donald Schon writes about the reflective practitioner as someone who thinks through action. That framing fits this kind of work surprisingly well. You make a move, the material talks back, and then you reframe the next move. In this case, the material was the website: awkward line breaks, a bubble covering my face, a motion section becoming too dominant, a blog page that felt narrower than its purpose.

What changed

The biggest design rule became: every ounce of ink should matter. Color should mean action, state, or grouping. Motion should explain what changed. Whitespace should manage cognitive load, not create mystery.

Follow-up: play with receipts

After the first redesign, I kept pushing on the pages that still felt too quiet. The projects page got an IKEA-inspired card opening pattern: one project expands in place, the grid stays visible, and the visitor can inspect an artifact without feeling thrown into a separate product page too early.

The publications page got the weirder experiment: a Wall of Rejection. It is rejection-only: short Steam-ish badges, click-to-open receipts, and a nerdy Spooder-Man XP joke from my post-UIST 2026 rejection mood. It is not a review-activity dashboard. It is a tiny celebration of failure as part of research life.

This is also where GenAI felt creatively useful. I could hand the agent a messy vibe, then use the design heuristics to pull it back toward the site: restrained motion, clear evidence, theme-aware color, and playfulness that does not drown out the bibliography.

Note to future me: not sure if this is taste, but I had great fun.

Credit where credit is due

I was also borrowing from people and artifacts I admire. The AI in Design 2026 report helped frame the moment: infinite output makes taste and craft more important. Katie Dill says, “AI is sparking a creative renaissance in design.” Stripe’s site was useful as a pattern reference for calm motion, crisp hierarchy, and compact controls.

The point is not to copy them. The point is to notice the underlying practice: make the claim legible, put proof near the claim, and let details increase trust.

The lesson for students

If you give an AI agent vague taste, you usually get vague interface. If you give it constraints, screenshots, critique roles, and a living heuristics file, you get a much better collaborator.

So my recommendation is simple: do not just prompt for prettier. Build a small design memory. Use it to critique. Then keep revising until the page is clearer, not merely louder.

Sources and inspirations: AI in Design 2026, the Craft chapter, Stripe, Katie Dill at Stripe Sessions, IKEA PS 2026, the local Wall of Rejection mockup, the Spooder-Man trailer reference, Donald Schon’s The Reflective Practitioner, and this Wayback snapshot of the old site.

I have been thinking more about science communication.

Not just “how do I give a better talk?” or “how do I write a clearer blog post?” Those are important, but they feel like symptoms of a deeper question:

What does it mean to explain science in a way that actually respects the person listening?

I used to think of communication as something that happens after the real work. You do the research, write the paper, make the slides, and then package the knowledge for other people.

I do not think that anymore.

Communication is part of research culture. It shapes who can enter a field, who trusts a field, who benefits from a field, and who gets left outside of it. It is also part of public responsibility. Science is not produced in a vacuum. People fund it, live with its consequences, vote around it, misunderstand it, argue about it, and sometimes need it.

If we want people to care about science, we probably have to care about them first.

The audience is not generic

One lesson I learned from my undergraduate advisor, Judith E. Fan, is that a talk is not just a container for what the speaker knows.

A talk is an encounter between a speaker, an audience, and an idea.

That sounds obvious, but it changes everything. If I am talking to cognitive scientists, I can assume one kind of background. If I am talking to designers, engineers, high school students, or family members, I need a different path into the same idea. The point is not to make the science less rigorous. The point is to build the bridge from where people actually are.

Judy is very good at this. In her MIT talk, “Cognitive Tools for Making the Invisible Visible”, the ideas are subtle, but the talk still feels generous. There is a clear sense that the audience is being guided, not tested. The figures, examples, and structure are not decoration. They are part of the thinking.

That is the first thing I want to remember:

Good science communication begins by asking who the audience is, what they already know, and what would help them care.

Public communication is not extra credit

This year I also took COGS 260 with Bradley Voytek, a course on communicating science. The Winter 2026 syllabus and readings made the point from many angles: communication is not a side quest for people who happen to like writing or performing. It is a skill scientists should take seriously.

Brad is a great example of this because he is clearly not embarrassed by meeting people where they are. His zombie-brain work, including the TED-Ed videos on diagnosing a zombie’s brain and body (part one, part two), is funny, but it is not only funny. It uses a playful frame to smuggle in real neuroscience.

That feels important. Science communication does not have to mean sanding away the weirdness of science. Sometimes the weirdness is the door.

Brad’s outreach page also makes this broader point nicely: outreach can happen online, in classrooms, in museums, in public talks, and in strange cultural spaces where people are already curious. The scientist does not always need to drag people into the seminar room. Sometimes the better move is to go where attention already lives and bring the science there.

Why bother?

The obvious answer is that people deserve to understand science that affects their lives.

That is especially true when scientific ideas shape health, education, technology, climate, public policy, and everyday decisions. If researchers only talk to each other, then the public conversation gets filled by whoever is most confident, most entertaining, or most willing to oversimplify.

But there is also a selfish reason to communicate well: explaining an idea to real people reveals what I do and do not understand.

Writing for a broader audience is a stress test. If I cannot explain the core idea without hiding behind jargon, maybe I do not understand the core idea yet. If the story only works when I omit every caveat, maybe the story is too weak. If people consistently misunderstand the point, maybe the problem is not only with them.

Communication can be a public service and an idea engine at the same time.

This is one reason I liked Jamil Zaki’s essay “So you want to write about science…”, published on May 19, 2026. Zaki argues, among other things, that outreach can serve civic life and also sharpen the scientist’s own thinking. He also frames communication as a kind of service: the communicator is not the main character; the goal is to create an encounter between readers and ideas.

I like that framing a lot.

How to do it better

I am still learning, but a few principles feel useful.

First, know the audience. Not in a shallow demographic way, but in a practical empathy way. What do they care about? What are they afraid of? What words will open the door, and what words will quietly close it?

Second, center people. Science writing often becomes abstract because abstraction feels safer. But most readers understand people before they understand constructs. Instead of beginning with a technical phrase, begin with a situation someone can recognize. Then introduce the concept when it becomes useful.

Third, tell science as a process, not a monument. Science is not a pile of finished facts guarded by experts. It is a way of becoming less wrong. That means uncertainty is not the enemy of communication. It can be part of the story. The interesting thing is often how a question changed, how a result surprised someone, or how a field learned that an older explanation was not enough.

Fourth, be gentle with the reader’s attention. A sentence can be accurate and still be unkind. If it makes the reader carry too many terms, clauses, and assumptions at once, it might be technically correct but communicatively careless.

This does not mean talking down to people. It means taking responsibility for the path.

The goal

Good science communication is not about sounding impressive.

It is not about proving that I know a lot, or making every caveat visible at once, or compressing a whole literature into one heroic paragraph.

The goal is simpler and harder:

Help someone hold an idea they could not hold before.

That might mean giving them a metaphor. It might mean removing a piece of jargon. It might mean telling a story. It might mean admitting uncertainty. It might mean changing the talk because the audience in front of me is not the audience I imagined while making the slides.

That is why I keep coming back to kindness.

Science communication is kindness when it treats attention as precious, meets people where they are, and gives them a real path into the idea.

And if we are lucky, it makes the science better too.

I have been thinking about what counts as good HCI research, especially now that AI makes system-building much easier.

This is not a theory of all research. It is a working note for myself. I am writing it because I have been confused about the difference between a useful product idea, a publishable HCI artifact, and a research contribution that still matters after the prototype is gone.

The confusion

A lot of HCI artifact and system work can look like this:

1. Find a real user need.
2. Build a tool.
3. Compare it against a baseline.
4. Show that users do better or like it more.
5. Claim a contribution.

This can be valuable. But it can also feel unsatisfying.

If the main claim is only “we built a better tool,” then a startup or big company might be able to do something similar faster. Product teams can identify user needs, prototype features, run beta tests, dogfood internally, A/B test, and iterate with many more users than most academic projects can.

So the question that bothers me is:

If industry can also follow a research-like workflow, what makes academic HCI research worth doing?

I do not think the answer is “companies only use knowledge and researchers produce knowledge.” Companies can produce knowledge too. Some product teams run careful experiments. Some industry researchers do excellent public research.

But I do think the default incentives are different.

A company often wants knowledge as an input:

Should we ship this? Does this improve our metric? Does this help our product?

Research, at least at its best, tries to produce knowledge as an output:

What can other people reuse, question, test, adapt, or build on?

That distinction is not absolute. It is more like a useful starting lens.

What the contribution is

One paper that helped me here is Jacob O. Wobbrock and Julie A. Kientz’s Research Contributions in Human-Computer Interaction.

The paper helped because it makes a simple but important point: HCI research produces different kinds of knowledge. Not every paper should be judged as if it were the same kind of paper.

Wobbrock and Kientz describe several contribution types in HCI, including empirical, artifact/system, methodological, theoretical, dataset, survey, and opinion or argument contributions. This is useful because a system paper is not automatically weak because it is not a polished product, and an artifact paper does not always need the same kind of user study as an empirical paper.

But the reverse is also true: a prototype is not automatically research just because it exists.

The question I want to keep asking is:

What kind of knowledge does this work produce?

Product knowledge can be local:

Version B works better for this product, this user base, this metric, and this moment.

Research knowledge should be more portable:

This kind of interaction mechanism helps this kind of human activity under these conditions, while creating these trade-offs.

For HCI, “portable” does not have to mean universal. It might mean a reusable interaction pattern, a clearer account of a human process, a new way to evaluate a class of systems, a boundary condition, a design trade-off, a conceptual vocabulary, or an artifact that opens a new design space.

A good HCI contribution is not “only HCI” in a narrow sense. It is a contribution about interaction: how people understand, use, coordinate around, resist, appropriate, trust, misuse, or reshape technology.

AI makes this sharper

This feels especially important now because AI makes it easier to build plausible demos.

In the past, building a system could itself be strong evidence of technical imagination. Now, many prototypes can be assembled quickly with LLM APIs, prompt chains, generated UI code, and existing infrastructure.

That does not make artifact or system research obsolete. But it does raise the bar for what the artifact needs to show.

“AI applied to X” is usually not enough.

A weak artifact claim might be:

We built a GenAI tool for designers, and users liked it better than the baseline.

A stronger artifact claim might be:

We built an artifact that externalizes AI-generated alternatives into editable design dimensions, making trade-offs visible and negotiable for teams.

The difference is that the second version names a reusable interaction idea. The system is not just a product. It is a research object.

An HCI artifact contribution is not a worse product. It is a different kind of object. A product asks whether something is useful, reliable, scalable, desirable, and worth shipping. A research artifact asks what new interaction possibility, representation, workflow, architecture, or design trade-off this prototype makes visible.

A prototype can be rough and still be valuable if it makes an idea inspectable. But a rough prototype with a vague claim is just a rough prototype.

The prototype should train the researcher too

Minas Karamanis’s essay The machines are fine. I’m worried about us. gave me another way to think about this.

The question is not simply whether AI should or should not be used in research. The harder question is what kinds of work we are allowing AI to replace, and what kinds of human capacities we are still trying to develop.

Karamanis makes this vivid through the contrast between Alice and Bob. From the outside, both can produce something that looks like successful research. But only one may have gone through the slow process of reading carefully, getting confused, debugging, checking assumptions, and learning what a good or bad result feels like. The visible output can be similar while the internal development is completely different.

That distinction matters for HCI prototyping too. Two researchers can end up with similar demos, but only one may have built the judgment needed to explain, critique, debug, and defend the artifact. If AI helps with syntax, prose, interface polish, or generating alternatives after I already understand the problem, that seems useful. I am still responsible for the intellectual work.

Where I become uncomfortable is when AI chooses the method, interprets the data, writes the claim, or smooths away the struggle before I have understood what the struggle is teaching me. Karamanis’s phrase that “the failures are the curriculum” feels right here. Some friction is waste, but some friction is how taste develops: the confusing paper, the broken prototype, the weird user behavior, the bug that reveals a missing model of interaction.

This connects to something my undergraduate advisor Judy once told me: in a very high-dimensional design space, one goal of research is to become a more efficient navigator. AI can help with that. It can eliminate bad options, surface alternatives, speed up implementation, and give me more things to compare. But the researcher still has to learn where to point the tool, what to trust, what to reject, and what is worth understanding more deeply.

Prototype as probe

The most useful shift for me is this:

Do not prototype only to make a better tool. Prototype to better understand people, and to train my own ability to notice what matters about them.

Instead of starting with:

What tool can I build?

I want to start with:

What human process am I trying to understand or change?

That process might be comparing alternatives, forming shared understanding, negotiating trade-offs, critiquing ideas, converging on decisions, preserving agency, calibrating trust, or maintaining ownership.

Then I can ask:

What interaction mechanism might change that process?

The mechanism might be externalized design dimensions, contrastive examples, editable rationales, structured critique, shared design-space maps, provenance traces, role-based prompting, progressive disclosure, or representations that preserve useful ambiguity.

The artifact becomes valuable when it makes the mechanism concrete enough to inspect, use, and evaluate.

This is also how I read Karla Felix Navarro, Eugene Syriani, and Ian Arawjo’s guidelines for reporting LLM-integrated systems in HCI. Their practical advice is not just “document every prompt.” It is to help reviewers understand what the LLM is doing, why it belongs in the system, and how much the claim depends on it. That feels like the reporting version of prototype-as-probe: frame the work around the human process or interaction idea, not around “an LLM solved X.” If the LLM is central, then the paper owes readers enough detail about prompts, configuration, engineering process, robustness, and failure modes to judge the claim. If the LLM is only an implementation detail, then maybe the more durable contribution is the user understanding, design principle, or interaction pattern that will still matter when the model changes.

This also changes how I think about studies. The study is not only product validation. It is a way to stress-test a claim about human activity. A prototype can help reveal what users notice, what they ignore, how they make decisions, where they lose agency, what trade-offs they care about, and what breakdowns happen in practice.

The prototype is not the endpoint. It is a probe.

What survives after the prototype dies?

The test I want to use is:

If the prototype dies, what knowledge remains?

A weak answer is:

Users preferred our system.

A better answer is:

Externalizing design dimensions helped teams move from output-level preference talk to attribute-level trade-off reasoning.

An even better answer includes a boundary or trade-off:

Externalizing design dimensions helped teams compare and converge, but sometimes narrowed exploration by imposing criteria too early.

This kind of claim feels more durable. Other people can reuse it, test it, disagree with it, or build better systems from it.

It also helps me avoid confusing product improvement with research contribution. If the only thing that survives is “our tool was better,” I may have built something useful, but I have not yet made clear what the research community can learn from it.

Evidence should match the claim

Another lesson from Wobbrock and Kientz’s paper is that contribution types should be judged differently.

If the contribution is empirical, the evidence needs to support the finding. If the contribution is an artifact, the paper needs to show what the artifact makes possible and why the design is insightful. If the contribution is methodological, the method needs to be useful, reproducible, reliable, and valid. If the contribution is theoretical, it needs to explain or organize something in a way that has power beyond a single example. If the contribution is an argument, it needs to be fair, persuasive, and grounded.

Sutton and Staw’s What Theory Is Not sharpens this point. References, data, lists of variables, diagrams, and hypotheses can all support theory, but none of them are theory by themselves. The theoretical work is the explanation: why the relationship should hold, what mechanism connects the pieces, and where the claim should break.

For HCI artifact work, this is a useful guardrail. A prototype is not theory. A positive study result is not theory. A clean system diagram is not theory. The theory is the account of why this interaction mechanism changes this human activity under these conditions.

This connects to Dan R. Olsen Jr.’s Evaluating User Interface Systems Research and Saul Greenberg and Bill Buxton’s Usability Evaluation Considered Harmful (Some of the Time). A user study is not automatically the right validation for every system contribution. Sometimes a premature or poorly matched evaluation can obscure what is actually interesting about a system.

The point is not “avoid evaluation.” The point is:

Evaluate the claim, not just the interface.

A formula I want to use

When planning a project, I want to fill in this sentence:

This project contributes a [type of contribution] by showing [knowledge claim] through [artifact/study/method], and it should be evaluated by [appropriate standard].

For an artifact or system contribution:

This project contributes an artifact that demonstrates [new interaction possibility] by implementing [specific mechanism] for [human activity/context]. The artifact shows that [previously hard thing] can become [possible/easier/inspectable/contestable/collaborative], while exposing the trade-off between [A] and [B].

For example:

This project contributes an artifact that demonstrates design-space-based interaction with generative AI. By implementing editable dimensions, alternative clustering, and rationale-linked comparison, the system makes AI-generated design options inspectable and negotiable by teams. The artifact exposes a trade-off between structuring exploration and preserving open-ended creativity.

I should be careful with projects whose main claim is:

We built a better AI tool and users performed better.

That can be useful, but it risks becoming lower-efficiency product engineering.

I should also be careful with:

We borrowed a trick from another literature and put it into an HCI system.

That can be good research, but only if the project tests something non-obvious about how that mechanism behaves in a new context. The stronger version is:

This known mechanism should behave differently in this human-AI setting because the task, agency structure, uncertainty, or collaboration pattern is different.

Then the contribution is not just the borrowed trick. The contribution is the translation, boundary condition, and explanation.

One theory-specific check I want to keep near the formula:

Am I explaining the mechanism, or only listing references, variables, diagrams, results, or hypotheses?

Two extra checks I want to add, especially when AI is involved:

What difficulty am I intentionally preserving because it helps me build judgment?

Could I still explain, evaluate, and defend this result if the AI assistance disappeared?

That is the distinction I want to keep in view: not whether a prototype is impressive by itself, but whether it helps articulate a piece of interaction knowledge that can outlive the prototype.

Related notes

Don Norman’s Beyond Human Categories helped me think about this from another angle: maybe the important question is not whether AI is specialist or generalist, but what kind of distributed cognitive system we are building around it. I wrote a short follow-up here: specialists, generalists, and AI as distributed cognition.

I started a small collection of technical papers i want to remember. The first note is on Locality in Image Diffusion Models Emerges from Data Statistics, which gave me a sharper way to ask where an AI system’s behavior comes from: the model, the data, the interface, the task, the evaluation setup, or the larger arrangement around it.

Credits and references

This note came out of conversations with mentors and labmates.

Dev pointed me to Wobbrock and Kientz’s paper.

Zhiqing gave me a helpful framing about companies often using knowledge as input, while research should output knowledge that others can reuse.

Philip Guo recommended Karamanis’s essay in his graduate seminar, which helped me connect AI use with researcher judgment and training.

Main references:

• Jacob O. Wobbrock and Julie A. Kientz. Research Contributions in Human-Computer Interaction. interactions, 2016.
• Robert I. Sutton and Barry M. Staw. What Theory Is Not. Administrative Science Quarterly, 40(3), 371-384, 1995. MIT-hosted PDF.
• Dan R. Olsen Jr. Evaluating User Interface Systems Research. UIST 2007.
• Saul Greenberg and Bill Buxton. Usability Evaluation Considered Harmful (Some of the Time). CHI 2008.
• Karla Felix Navarro, Eugene Syriani, and Ian Arawjo. Reporting and Reviewing LLM-Integrated Systems in HCI: Challenges and Considerations. arXiv preprint, 2026. Companion guidelines.
• Minas Karamanis. The machines are fine. I’m worried about us.. March 30, 2026.

Last updated: June 28, 2026.

It is also about slowly building the invisible skills that make research work feel less mysterious: how to read, how to scope a project, how to write, how to run a study, how to interpret evidence, and how to stay alive through long, uncertain projects.

This is a small starter pack I point students to when they ask, “What should I learn on my own before, during, or after joining a research project?”

It is not a complete syllabus. It is a map.

It is also an ongoing thing. I will keep updating this post when I run into more resources that feel genuinely helpful.

Related note: I also wrote a more reflective piece on what counts as good HCI research now that AI makes prototyping easier: prototyping to understand humans.

1. Learn to read research papers

Reading papers is its own skill. You are not supposed to understand every paper perfectly on the first pass, and you are not supposed to read every paper with the same level of attention.

Prof. Philip Guo recommended Srinivasan Keshav’s How to Read a Paper. Keshav describes a three-pass method: first get the shape of the paper, then understand the content, then go deep enough to reconstruct and critique it. This is useful because it gives you permission to read strategically instead of getting stuck on page one.

Philip also recommended Jacob O. Wobbrock’s Catchy Titles Are Good: But Avoid Being Cute, which is primarily an HCI writing guide. Its section map also doubles as a useful reading check: what job is each part of this paper trying to do? I reach for it most while drafting HCI papers, so I unpack that map in section 3.

When you read a paper, try to answer:

• What kind of paper is this?
• What problem or opportunity motivates it?
• What is the main contribution?
• What evidence supports the contribution?
• What assumptions does the paper make?
• What would I need to believe for this paper to be convincing?
• What would I do differently if I were designing the study or system?

Reading well is not passive. You are reconstructing the research.

2. Learn to define and refine a research direction

A topic, a technology, or a proposed system is not yet a research problem. If I say, “use technique X to do Y,” I have mostly described a solution shape. A problem-shaped version sounds more like: “people currently cannot do Y reliably under these conditions.” Those are different decisions. Choosing a direction is about deciding what gap, confusion, or possibility is worth understanding. Implementing a solution is only one way to test whether that direction is real.

Marco Tulio Ribeiro’s essay on coming up with research ideas helped me put language around this. One way to find directions is to expand the “adjacent possible”: build broad awareness of nearby areas, while going deep enough in your own area that you can notice non-obvious connections. I also like the practice of keeping a list of important problems or questions that keep pulling my attention back. That list changes what I notice when I read, watch talks, or debug prototypes.

Failures are especially useful here. When something breaks, behaves strangely, or keeps annoying me, the easy move is to find a workaround and forget it. A better research habit is to write it down before it normalizes. Confusing observations often point to a missing concept, weak assumption, or hidden workflow that other people may also be struggling with. Analogies can help too, but not as “apply technique X to domain Y.” The useful work is asking where the analogy holds, where it breaks, and what the break teaches. Similarly, challenging a status quo is only interesting after I understand why it became the status quo in the first place.

Ribeiro gives a nice example from the path to LIME. During a Google internship, he had a model with strong cross-validation accuracy that behaved badly “in the wild,” and the frustrating part was how much effort it took to understand what the model was doing. That annoyance became a productive interpretability problem: how might people understand and evaluate the behavior of models they otherwise experience as black boxes?

Once I have a possible direction, I want to define it before choosing an implementation. Ribeiro’s organizing and evaluating research ideas framework can be compressed into a checklist:

• What is the problem?
• Why is it important?
• What existing approaches could address it, and why are they insufficient for this problem?
• If a useful solution existed, what would it make possible? Describe the needed capability before prematurely choosing an implementation.
• How would we know that the problem had been meaningfully addressed?

I would add two follow-on checks:

• What assumptions or uncertainties could invalidate the project?
• What is the cheapest first probe that could reduce the most consequential uncertainty?

That probe does not have to be a full system or study. It might be a targeted literature review, skeptical feedback from collaborators, manually simulating part of a workflow, testing a crude lower bound, or doing a focused hacking session. Skeptical feedback is information, not an automatic verdict. If someone says the idea is flawed, I should ask what would have to be true for that criticism to be fatal. This also helps with sunk-cost risk: while I am still reducing uncertainty, I should keep calling the direction a possibility, not “the project,” until there is enough evidence to commit.

A four-sentence compression test

Kent Beck’s OOPSLA advice offers a useful clarity test for a research direction: state the problem, explain why it matters, state what the work achieves or changes, and state the implication of that achievement. I like this because it makes vagueness hard to hide. But it is not a rigid gate. Ribeiro notes that early project formulations usually change, and his template is more naturally problem-oriented than exploratory. For exploratory or descriptive work, I would treat the four sentences as a provisional hypothesis that should evolve as the research teaches me what the real problem is.

Project selection also has to fit the researcher. A good project for a summer intern may not be the same as a good project for a Ph.D. student building a thesis direction. I would look at my goals, available time, skills, collaborators, data, and institutional resources. For an internship, I value high upside, fast learning, early tests of fatal assumptions, and credible partial-success paths. I would not reduce the decision to simple publication maximization. A safer project is not automatically better, and a high-upside project is not automatically feasible.

This connects to my companion note on prototyping to understand humans. After I define the problem, the next question is what reusable knowledge the artifact, study, or method will produce, and what evidence should support that claim. The project direction tells me what I am trying to learn before the prototype makes the answer look obvious.

3. Learn to write research clearly

Research writing is not decoration after the “real work” is done. Writing is where you discover what your contribution actually is, what evidence you still need, and what your reader is likely to misunderstand.

Keep Wobbrock’s paper map beside you

The writing resource I reopen most often while outlining an HCI paper is Jacob O. Wobbrock’s Catchy Titles Are Good: But Avoid Being Cute. The title advice is memorable, but the guide is really about the promises each part of a paper makes to its reader. My shorthand version is:

• Abstract: Tell me what you did and what you found.
• Introduction: Move from the state of the world and the “big but” to what you did, what you found, and what you contributed. Wobbrock credits this five-part pattern as building on advice from Scott E. Hudson.
• Related work: Teach me the landscape and differentiate the work fairly.
• System or artifact: Explain the goals, rationale, operation, tradeoffs, and limits that matter to the research claim.
• Method: Give an expert enough detail to understand or repeat the work.
• Results: Report what happened in a sequence the reader can follow.
• Discussion: Explain why the findings matter, including implications, surprises, and limits.
• Conclusion: Show that the paper delivered on the promises it opened with.

I keep this guide nearby while outlining because it helps me see whether the argument is carrying its weight from one section to the next. I use it as a diagnostic map, not a rigid template: different kinds of HCI papers need different structures, but every section should still have a clear job.

Shape the argument for a tired reader

Wobbrock gives me the paper-level map. For the writing decisions inside that map, I start with Tzu-Mao Li’s writing tips. I like this page because it is short, direct, and very practical. A few lessons I especially want students to absorb:

• Know who you are writing for.
• Start early, ideally when the research idea is still forming.
• Explain the “why” before the “what” and “how.”
• Put the important points before the implementation details.
• Make figures early and use them to shape the story.
• Treat collaborators’ confusion as useful evidence about where readers will also get confused.
• Be generous and careful when writing about prior work.

Tzu-Mao Li also recommended two writing resources that I would read after his page. The first is Fredo Durand’s Notes on writing. Durand emphasizes something that sounds obvious but is surprisingly easy to forget: your contribution only matters if people can understand it. His notes are especially useful for learning how to build a paper around a clear story, hierarchy of ideas, motivation, overview, figures, and results that support your claims.

Then read Bill Freeman’s How to write a good CVPR submission. Even if you do not work in computer vision, it is useful because it explains the reviewer’s situation very honestly. Reviewers are busy. Area chairs are often looking for reasons to reject borderline papers. Your job is not to hope they figure out your point. Your job is to make the problem, contribution, evidence, limitations, and relationship to prior work easy to see.

Use the draft to discover missing research

I would also read Marco Tulio Ribeiro’s Writing, part 1 — the process. It is useful because it treats writing as a process for discovering and organizing thought, not as a final cleanup pass. His loop is deliberately concrete: dump raw material, outline both top down and bottom up, write an imperfect draft from that outline, reverse-outline what you actually wrote, rewrite at multiple levels, and ask for feedback. I like this because it makes confusion less shameful. If a paragraph collapses when I outline it backward, that is not a sign that writing failed. That is the writing doing its job.

My repeatable writing loop

My practical takeaway from Tzu-Mao Li’s advice, the Durand/Freeman resources he recommended, Ribeiro’s process essay, Wobbrock’s paper map, and my own writing habits:

• Draft the outline before drafting polished paragraphs.
• Make the central figure earlier than feels comfortable.
• Write the first paragraph as if a tired reviewer will only give you 30 seconds.
• For every section, ask: what does the reader need to believe by the end of this?
• For every claim, ask: what evidence makes this believable?
• For every related-work paragraph, ask: am I being accurate, fair, and useful?
• Rewrite more than you think you need to.

Good writing is not about sounding fancy. It is about making the reader’s job easier.

4. Learn to review papers generously

Reviewing is another way to learn research taste. A good review does not just find flaws. It identifies what is valuable, what is missing, what is overstated, and what would help the work become stronger.

Ken Hinckley recommended his own essay, So You’re a Program Committee Member Now: On Excellence in Reviews and Meta-Reviews and Championing Submitted Work That Has Merit. It was written for MobileHCI 2015 program committee members, but it is useful well before you are actually on a program committee.

The big lesson I take from it is that reviewing is a responsibility to the field, not just an exercise in criticism. Look for the strongest version of a paper’s contribution. Be fair about weaknesses. Separate correctable presentation problems from deeper research problems. Write in a way that helps authors improve, especially when you recommend rejection.

When practicing reviews, ask:

• What is the paper trying to contribute?
• What is genuinely valuable here?
• What evidence is strong?
• What evidence is weak or missing?
• What claims are too broad for the evidence?
• What are the most important changes the authors could make?
• Am I being fair to work that is outside my exact taste or method comfort zone?

Writing reviews is also a sneaky way to become a better author. You start to feel what makes a paper easy or hard to evaluate.

5. Learn what Ph.D. life can feel like

If you are considering a Ph.D., you should read about the lived experience, not just the application process or the highlight reel.

Philip Guo’s The Ph.D. Grind is valuable because it gives a concrete, personal account of a computer science Ph.D. journey: uncertainty, advisor fit, failed directions, rebuilding momentum, publishing, graduating, and making sense of the whole experience afterward.

Do not read it as universal truth. Every department, advisor, funding structure, research area, and person is different. Read it as one detailed case study of how research can feel from the inside.

The main reason I recommend it is that it makes the hidden parts visible. Research often looks clean after it is published. During the process, it can feel like false starts, ambiguous feedback, lonely debugging, changing goals, and small wins that only make sense months later. Knowing that ahead of time can help you avoid over-interpreting normal struggle as personal failure.

Useful questions to ask while reading:

• What kinds of uncertainty does this person have to tolerate?
• What changes when a project starts to become their own?
• How do mentors, collaborators, and institutions shape the experience?
• What parts of this life sound energizing to me?
• What parts sound costly, and am I honest about that cost?

A Ph.D. can be meaningful and joyful. It can also be hard in ways that are not obvious from the outside. Both can be true.

6. Learn empirical methods, qualitative research, and statistics

For HCI, design, psychology, education, and human-centered AI, methods matter a lot. If you want to study people, you need to learn how evidence gets made.

This is where statistics is not just a class requirement. It is part of your research taste. It helps you notice weak comparisons, confounds, underpowered claims, measurement problems, and conclusions that are stronger than the study can support.

Prof. Scott Klemmer has recommended reading David W. Martin’s Doing Psychology Experiments for learning experimental thinking.

I would use this book to learn the mindset, not only the formulas:

• What is the actual research question?
• What is being manipulated?
• What is being measured?
• What are the dependent and independent variables?
• What are the threats to validity?
• What would a better control condition look like?
• What can this study conclude, and what can it not conclude?

Scott also recommended two qualitative papers as examples of how to turn close observation into a strong research contribution.

Janet Vertesi’s “Seeing like a rover”: Embodied experience on the Mars Exploration Rover mission is useful for HCI students because it shows how qualitative work can make a technical practice socially and bodily legible. The paper is based on two years of ethnographic fieldwork with the Mars Rover mission, and the lesson for me is that good qualitative research does not only report what people said. It reveals the situated practices, metaphors, gestures, tools, and team arrangements that make a form of work possible.

Robert I. Sutton and Andrew Hargadon’s Brainstorming Groups in Context: Effectiveness in a Product Design Firm is useful for design research because it asks what effectiveness means inside a real organization. Instead of treating idea count as the only outcome, the paper studies brainstorming in context and shows that the practice can support other organizational functions. The takeaway is a good qualitative habit: before deciding whether something “works,” ask what work it is doing, for whom, and in what setting.

For quantitative modeling, I would next read Seth Roberts and Harold Pashler’s How persuasive is a good fit? A comment on theory testing. The title gives away the lesson: a model fitting the observed data is not, by itself, strong evidence that the model is right. You also need to ask how flexible the model is, what outcomes it could not have fit, how noisy the data are, and whether plausible alternative results would have actually challenged the theory. This is a good guardrail against being dazzled by a clean curve or a high $R^2$.

Then read Tamar R. Makin and Jean-Jacques Orban de Xivry’s Ten common statistical mistakes to watch out for when writing or reviewing a manuscript. This is the piece I would use when a paper’s claims feel like they might be outrunning the design or analysis. It covers recurring problems like inadequate controls, comparing two effects without directly comparing them, inflated units of analysis, spurious correlations, small samples, circular analysis, and overstated null results. The larger habit is simple but hard: make the strength of the claim match the strength and kind of evidence.

For students entering HCI or human-centered AI, I would pair methods reading with practice. Take a paper you like and reverse-engineer the study:

• Write the research question in one sentence.
• Identify the claim the study is trying to support.
• Sketch the study design.
• List the variables and measures.
• If the paper is qualitative, identify the field setting, the interpretive claim, and the observations that make that claim believable.
• Write down possible confounds.
• Ask what result would have changed your mind.
• Check whether the paper’s conclusion matches the evidence.

This exercise is slow at first, but it builds the kind of judgment that makes you a much stronger collaborator.

7. A note on credit

This list credits both the people who recommended resources to me and the people who wrote those resources:

• Philip Guo for recommending Srinivasan Keshav’s How to Read a Paper and Jacob O. Wobbrock’s Catchy Titles Are Good: But Avoid Being Cute, and for writing The Ph.D. Grind.
• Jacob O. Wobbrock for writing the HCI paper guide I keep beside my drafts, and Scott E. Hudson for the introduction structure Wobbrock credits and extends.
• Tzu-Mao Li for his writing tips and the writing resources he recommended there: Fredo Durand’s Notes on writing and Bill Freeman’s How to write a good CVPR submission.
• Marco Tulio Ribeiro for writing Writing, part 1 — the process.
• Jo Vermeulen for sharing Marco Tulio Ribeiro’s Coming up with research ideas and Organizing and evaluating research ideas with our Autodesk summer intern group, and for connecting Ribeiro’s questions to Kent Beck’s How to Get a Paper Accepted at OOPSLA. Thanks, Jo, as always, for another thoughtful pointer.
• Ken Hinckley for recommending and writing So You’re a Program Committee Member Now.
• Scott Klemmer for the recommendation to read David W. Martin’s Doing Psychology Experiments, and David W. Martin for writing it. Scott also recommended two qualitative exemplars: Janet Vertesi’s “Seeing like a rover” and Robert I. Sutton and Andrew Hargadon’s Brainstorming Groups in Context.
• Seth Roberts and Harold Pashler for How persuasive is a good fit? A comment on theory testing.
• Tamar R. Makin and Jean-Jacques Orban de Xivry for Ten common statistical mistakes to watch out for when writing or reviewing a manuscript.

Research is a craft. The nice thing about craft is that you can practice it before anyone gives you permission.

Last updated: July 18, 2026.

This is mostly for students interested in HCI, design, human-centered AI, and adjacent work, but a lot of it generalizes.

The short version

You do not need to be perfect on day one.

You do need curiosity, initiative, follow-through, and genuine respect for other people’s time.

The more you can self-learn before joining a lab, the better your odds usually are. Classes, lab meetings, and project meetings can teach you a lot, but labs also tend to notice the students who are already trying to build their taste, skills, and judgment on their own.

Skills that help a lot

Some mix of the following is very useful:

• Design and prototyping. Figma, wireframing, storyboarding, and the ability to communicate ideas visually.
• Taste and judgment. Being able to notice when something feels generic, confusing, weak, or unconvincing, and having some instinct for how to improve it.
• Builder fluency. Some solid development understanding so you can prototype, debug, and collaborate with technical teammates.
• Rapid prototyping. Yes, being able to vibe-code can help. But only if you can evaluate what the model gives you rather than blindly accept it.
• Research skill. Reading papers, tracing related work, doing literature reviews, and figuring out what is still missing.
• Methods. Statistics classes and research methodology classes matter more than many students think.
• Communication. Writing clearly, making slides and figures, asking sharp questions, and giving useful updates.

You do not need all of these before you start. But if you can honestly show progress on several of them, that helps a lot.

Resources worth checking

Deadlines and eligibility change all the time, so always check the official pages. A few good starting points:

• UC San Diego Undergraduate Research Hub: TRELS, the Faculty Mentor Program, and the REAL Portal.
• HDSI pathways: HDSI Lab 3.0 and undergraduate financial opportunities.
• Design-oriented opportunities at UC San Diego: Design Lab internships and the Junior Designers program.
• Department-specific routes: many departments have 99/199 independent study, special topics seminars, faculty-mentored research sequences, or lab-specific application pages.
• External examples worth knowing about: CMU HCII Summer Undergraduate Research Program, CMU CSD Summer Research Internship, Brown UTRA, and KAIST URP.

This is not a complete list. It is just enough to give you a map.

What to actually do

The best outreach is intentional outreach.

• Reach out to professors whose work you are actually interested in.
• Do not spam every professor in your department.
• Go to seminars, talks, and office hours with your TAs or course professors.
• Read the lab website.
• Read at least a couple of papers.
• Try to understand the problems they care about, not just the title of the project.
• When you do reach out, ask informed questions and explain why there is a real fit.

Prof. Philip Guo also reminded me that TA and course professor office hours are one of the lowest-friction ways to start. They are not only for homework questions. You can ask what research looks like in that field, how the TA or professor first got involved, what skills mattered, and what a small next step might be. Those conversations build research self-efficacy: you get a better sense that you can ask real questions, talk with researchers, and decide whether research is something you actually want to try.

The same rule applies when reaching out to graduate students or undergraduate researchers in a lab. Their time is valuable too. Respect people’s time, but do not be afraid to reach out thoughtfully. A lot of people were helped by others earlier in their own journey, and many are happy to pay that forward.

If you are still figuring out what you even care about, that is normal. One of the best ways to discover your actual research interests is to attend talks, read papers, sit in on seminars, and notice which questions keep pulling you back in. If you are exploring HCI and design at UC San Diego, the weekly Wednesday Design Lab research meeting is a great place to hear current work, learn how research conversations sound in practice, and get a better sense of what kinds of questions you are actually interested in.

Once you have done some of that homework, you will usually have much better questions. That is often the right time to go to office hours or ask for a coffee chat.

What I usually look for

I am usually more excited by a student who is clearly curious, prepared, and serious about learning than by someone who is trying to sound impressive.

Strong signals include:

• evidence that you really engaged with a lab’s work before reaching out
• a concrete domain, question, or problem space you genuinely care about
• willingness to read, prototype, iterate, and do unglamorous work well
• ability to learn independently rather than waiting to be told every next step
• good collaboration energy

A note on authorship expectations

This section is adapted from Scott Klemmer’s guidance on working with his group, which I think sets a very healthy bar for undergraduate and master’s researchers.

My rough view is:

• If you do your RA work diligently and reliably, that matters a lot. That work should be credited, belongs on your resume, and absolutely helps with recommendation letters.
• Co-authorship is a higher bar. It usually means you contributed something substantively important to the paper, not just the tasks you were assigned.
• That contribution can be intellectual, technical, methodological, or a major implementation effort, but it should materially shape the project.
• Co-authorship also means staying invested through the tedious parts: iterations, studies, analysis, figure making, writing, revisions, and often review cycles.
• Authorship conversations should happen early, not right before a deadline.

In short: doing assigned work well is valuable and appreciated. Co-authorship usually comes from helping carry the project all the way to a strong finish.

Before you reach out

If you are thinking about emailing me, the best version of that email usually comes after you have done a little homework first.

Read a few things. Go to a talk. Figure out what question or domain you care about. Then send a thoughtful note.

That usually leads to a much better conversation for both of us.

If you want a more concrete self-study list, I also wrote a companion post on research skills to practice before and during research, including writing, Ph.D. life, statistics, and experimental-methods resources.

Last updated: June 1, 2026.

After the talk, I got to chat with him, get the famous Yellow Book (The Design of Everyday Things) signed to Sirui, and somehow even grab a selfie. That honestly made my whole day. Don rarely takes selfies with people, so I was extra happy he said yes 😃 On top of that, he shared really insightful takes on how to better educate the next generation in age of AI and pointed me toward some really exciting research directions! I am genuinely super grateful for that. And yes, this photo is absolutely going into my intro slide the next time I TA CogSci and DSGN courses to impress my students a little, haha 😉

If you are into design, go check out the charity and buy his newer book, Design for a Better World - he told us it is much more correct than The Design of Everyday Things!

Update: I also just read Don’s recent Substack piece, Why I Am Against STEM Education, and it made the education part of his DLab talk click a little more for me. The title is mischievous: he is not against science, technology, engineering, or math as knowledge. He is against education that turns them into isolated specialties, teaches at students instead of helping them learn actively, and treats collaboration as suspicious even though real work is collaborative. I was especially interested in his cautious optimism about AI tutors. I have been wary of that idea, but his framing made me feel more positive about AI as scaffolding: not to make students narrower or more dependent, but to help them connect across areas, debug their thinking, and become a little more generalist. That also connects to project-based classrooms and to Don’s larger point that we should teach problems rather than disconnected disciplines. Don’s original piece says all of this much better than my tiny summary; go read it.

Update 2: Don has another recent Substack piece, Beyond Human Categories, that connected even more directly with what I have been thinking about around specialists, generalists, AI, and distributed cognition. I wrote a separate reading note here: specialists, generalists, and AI as distributed cognition.

Ellen is a member of the San Diego Potters’ Guild and teaches classes there.

How I Discovered Ellen’s Work

Last year at the Craft Center Fair, I saw Ellen’s booth and fell in love with her piglet artwork. I had to buy it! That piece got me excited about pottery, so when I found out she teaches classes, I signed up right away.

If you’re interested in seeing more of Ellen’s beautiful creations, definitely check out her page!

My First Three Commissioned Works (Design Drafts)

I have three pieces commissioned that I’m excited to create. These are my design drafts - the actual pottery pieces will be made during my pottery journey with Ellen Fager:

1. Psyduck Coffee Cup

A fun and quirky coffee cup featuring everyone’s favorite confused Pokémon, Psyduck. This will be a functional piece that brings joy to morning coffee routines. (Design draft - not yet produced)

2. Winnie the Pooh Pot with Lid

A charming honey pot inspired by the beloved bear, complete with a bear-head lid. This piece will be both decorative and functional, perfect for storing honey or other sweet treats. (Design draft - not yet produced)

3. Cat Sculpture Pair

Two small cat sculptures - one dancing with joy and another peacefully sleeping. These will showcase different moods and poses, adding personality to any space. (Design draft - not yet produced)

Stay Tuned

I’ll definitely share updates as I go along and show you the finished pieces when they’re done. Right now these are just my design ideas - the fun part starts when I actually get to work with the clay!

Note: These are design drafts and concepts - the actual pottery pieces will be created during my pottery journey with Ellen Fager. The images shown are design renderings, not finished pottery.

Update (2025/12/15): I got humbled by the lesson. It is fun but hard, haha! I might update this post more later.

MidJourney