Reflection
How to Write an HCI Introduction: A Six-Part Recipe
August 20, 2026
What makes a good introduction?
For me, a good introduction does one thing particularly well: it makes the rest of the paper feel inevitable.
By the time I reach the research questions, I should understand why these are the questions being asked. By the time I reach the contributions, I should understand why those contributions matter. And somewhere along the way, I should have stopped wondering what the paper is actually about.
This sounds obvious. It is surprisingly difficult to do.
I think the introduction is probably the most important section of an HCI paper. When I receive a paper as an Associate Chair (AC), I usually form an opinion about it fairly quickly after reading the introduction. I get a sense of whether the authors understand the problem, whether they have thought carefully about the literature, whether the paper has somewhere interesting to go, and — perhaps most importantly — whether I am in good hands.
A strong introduction creates that feeling of security. The authors know where they are going. I can follow them.
Interestingly, this is also why I think the introduction should be one of the last things you write.
A lot of academic writing happens linearly. Introduction first, then related work, methods, findings, discussion. I rarely work that way. The introduction has to tie the entire paper together, and it is difficult to tie together something that does not yet exist. Your findings might change what you think the paper is about. Your discussion might reveal the contribution more clearly. Sometimes the argument you thought you were making at the beginning simply does not survive the data.
So, in our lab, we generally write the introduction toward the end.
Over time, I have also developed a fairly predictable recipe for writing one. I use some version of it in almost every HCI paper I write, and I ask my students to use it too.
It has six parts:
The Drop → World Building → The Players → Player One → The Deal → The Loot
It is vaguely inspired by the hero’s journey, with some video-game terminology thrown in because apparently that is how my brain works.
Here is what each part does.
Part 1: The Drop — Why does this problem matter?
The first job of an introduction is not to define the problem.
It is to make me care about the problem.
This distinction matters because a lot of introductions begin with conceptual housekeeping:
Conversational agents are systems that allow users to interact with computers using natural language…
Maybe that sentence eventually needs to exist. But I probably do not want it first.
I like to begin by dropping the reader directly into a world where the problem already exists and already hurts.
That might mean starting with a striking statistic. It might mean describing a situation the reader immediately recognizes. Or it might mean telling a short story that makes the stakes obvious before we start explaining terminology.
One of our papers on serious illness conversations begins with a patient with end-stage heart failure arriving in the emergency department in severe respiratory distress. Within minutes, the clinician may need to choose between aggressive intervention that could temporarily stabilize the patient but also initiate a prolonged and invasive course of treatment, or comfort-focused care during what may be the patient’s final hours [2].
Suddenly, the problem is not abstract.
There is a person. There is a decision. There is very little time. And ideally, that decision should reflect what the patient actually wants.
But what happens if nobody knows what the patient wants?
Now I have your attention.
Only after establishing those stakes do we begin explaining serious illness conversations, emergency-department workflows, communication barriers, and everything else the reader needs to understand the research problem.
This is similar to movies that start with “You must be wondering how I got here…” You are watching something unfold before you, not fully understanding how everyone got there. Eventually, the story fills in the missing pieces.
Introductions can do the same thing.
Another approach is to start with a story. In one of our papers on personality in LLM-based conversational agents, we begin in 1966 with ELIZA. ELIZA used fairly simple pattern matching and substitution rules, yet people still responded to it socially. Joseph Weizenbaum famously described his secretary asking to be left alone with the system despite knowing perfectly well how it worked [1].
That gives us a very different kind of drop.
If people perceived personality and social presence in something as simple as ELIZA, what happens when the conversational system is an LLM capable of sustaining remarkably fluent interactions?
The story creates the question for us.
George Carlin used to say that the opening joke of a comedy set should be one of your strongest. I think introductions work similarly.
Your first sentence has a disproportionate amount of work to do.
Do not waste it.
Part 2: World Building — What is the problem, exactly?
Now that I care, you can explain things.
This is world building.
What concepts does the reader need to understand? What causes the problem? Where does it happen? Who is affected? Who are the stakeholders? What assumptions or constraints shape this particular environment?
If I am writing about serious illness conversations, I might now explain what those conversations involve, why they are difficult in emergency departments, and which clinicians, patients, and family members are involved.
If I am writing about LLM personality, I might explain what personality means in conversational systems, how it can be simulated, and why personality might matter differently during a casual conversation than during a goal-oriented task.
This section gives the reader the conceptual scaffolding needed to understand the rest of the paper.
And this is exactly where I think many introductions start too early.
People often begin by defining everything.
I would rather know why I need the definition first.
Once you have shown me that something consequential is happening, I am much more willing to learn the rules of the world.
Think about starting a video game. At first, something gets you interested enough to play. Then the game teaches you what the buttons do, what the rules are, where you are, and what you are trying to accomplish.
That is world building.
The reader should leave this section knowing what world they are in and how it works.
They should not have to guess.
Part 3: The Players — What has been done before?
Now we introduce everyone who got here before us.
The players are the researchers, theories, systems, methods, and studies that already occupy this space.
There is a practical reason to take this section seriously: the people you cite are very likely to be the people reviewing your paper.
HCI is not that big.
Keep that in mind before writing, “Prior work has failed to consider…”
Your job here is not to make previous research look bad so that your paper looks good. I see this surprisingly often, especially when authors are desperate to establish novelty.
I do not think it is necessary.
A paper can be excellent and still leave something unresolved. In fact, most good papers do. One study might establish that something happens without explaining why. Another might work beautifully for one community but tell us very little about another. A system might solve one problem while creating a new set of questions.
That is how research progresses.
So give previous work its flowers.
Explain what those researchers did. Explain what they allowed us to understand. Explain why their contribution mattered.
Then identify the limitation, blind spot, or unanswered question that allows your work to move the conversation forward.
The difference is subtle but important.
You are not saying:
These people did a bad job, and now we are here to fix it.
You are saying:
Because of what these people taught us, we can now ask the next question.
That is usually a much stronger intellectual position anyway.
If your work is interdisciplinary, this section also becomes especially important. You may need to introduce two different groups of players — perhaps one from HCI and another from healthcare, psychology, communication, education, or some other field — and then explain how your paper creates a bridge between them.
By the end of this part, the reader should understand the existing landscape.
And ideally, they should also start noticing an empty space in it.
That empty space is where you enter.
Part 4: Player One — What are you doing differently?
This is the most important transition in the introduction.
Player One is you.
You have established the stakes. You have built the world. You have introduced everyone else who has worked on the problem.
Now stop hiding.
What exactly are you doing?
Be specific about the gap.
Be specific about your approach.
Be specific about what makes your study necessary.
This is not the place to suddenly become shy.
I often see authors spend two pages making a strong argument and then write:
In this paper, we explore…
Sometimes explore is exactly the right word. But often it is just a safer word than the one the authors actually mean.
If you argue something, say you argue it.
If you propose something, say you propose it.
If you introduce a framework, introduce it.
If you demonstrate an effect, say what you demonstrate.
There is a strange tendency in academic writing to become less confident precisely when describing our own contribution.
I think the opposite should happen.
By this point, you have done the work. You have shown why the problem matters and where the gap exists. Now tell me exactly what you are doing about it.
This section should usually answer a few fairly simple questions: What is the specific gap? What approach are you taking? What methods, theories, or conceptual lenses are you using? And why is that approach useful or novel given what came before?
Clarity matters more than elegance here.
You cannot write poetry forever.
At some point, you have to tell me what the paper actually does.
Part 5: The Deal — What are your research questions?
Next comes the deal.
The deal is your research questions.
I generally prefer putting research questions directly in the introduction unless there is a strong reason not to. We have occasionally placed them later, but most of the time I think readers benefit from seeing them early.
Research questions establish a contract with the reviewer.
You are essentially saying:
Here are the questions I promise this paper will answer.
That contract creates useful discipline for the rest of the paper.
If RQ1 asks one thing, I should eventually see a finding that answers RQ1. If RQ2 builds on RQ1, the findings should probably reflect that progression. By the end, I should be able to draw a fairly clean line from the questions you promised to answer to the evidence you provide.
This is also why the order of research questions matters.
RQ1, RQ2, and RQ3 should not feel like three unrelated questions that happened to survive a lab meeting.
They should tell a story.
Perhaps the first establishes a phenomenon. The second explains how or why it happens. The third asks what that means for design.
Whatever the progression is, it should make sense.
More importantly, your research questions should feel inevitable given the introduction that came before them.
If I reach your RQs and think, Wait, why are we asking this?, the problem may not actually be the research question.
You may need to go back and fix your world building or your gap.
A well-constructed introduction creates a kind of intellectual funnel. By the time I reach the research questions, I should almost be able to predict what they are.
That is a good sign.
Part 6: The Loot — What did you find, and what do you contribute?
Finally, we get the loot.
Why should anyone care that you answered these questions?
This is where you briefly tell the reader what you found and, more importantly, what those findings contribute.
I think we are often too vague here.
Phrases like:
This work provides insights into…
or:
Our findings have implications for…
are not inherently bad. But they are incomplete until you tell me what the insight is and who the implication is for.
Be concrete.
Perhaps your paper generates a set of design strategies that practitioners can use.
Perhaps it changes how researchers should conceptualize a phenomenon.
Perhaps it reveals something important about how a particular community experiences a technology.
Perhaps it identifies a tradeoff that designers need to account for.
Different papers generate different kinds of loot.
And different people may value different parts of it.
A designer might care about a set of actionable design implications. A researcher might care about a conceptual framework. A clinician might care about how a system fits into workflow. An end user might benefit because the study reveals something that changes how future systems are built for them.
So say who gets what.
This is particularly important for literature reviews, where the same synthesis can generate very different contributions for researchers, designers, and practitioners.
Do not make the reviewer reverse-engineer your contribution from twenty pages of findings.
Name the insight. Name the audience. Name the implication.
Make the journey feel worth it.
So what does the full introduction look like?
The recipe, then, is fairly simple:
The Drop: Why does this matter? Establish the stakes and hook the reader.
World Building: What exactly is the problem? Define the key concepts, causes, stakeholders, and context.
The Players: What has already been done? Give prior work its flowers, then identify what remains unanswered.
Player One: What are you doing differently? State your gap, approach, and novelty clearly and confidently.
The Deal: What exactly are you promising to answer? State research questions that follow naturally from everything above.
The Loot: What did you find, and what does the field gain from it?
I call this a recipe, but like most structures I use in research, it is really a scaffold.
Not every introduction needs six paragraphs. World building might take two. The players and Player One might be tightly intertwined. Some papers might place the RQs after related work. Different kinds of HCI papers will inevitably bend the structure in different ways.
That is fine.
What matters is the logic underneath it.
A reviewer should finish your introduction understanding why the problem matters, what world they have entered, what we already know, what remains unresolved, what you are doing about it, what you promise to answer, and why the answer is useful.
If you can do all of that, something important happens.
The reviewer stops trying to figure out what your paper is supposed to be.
They can just read it.
And at that point, you are already in a much better position.
(A note about this blog: This post was adapted from a talk I gave at the University of Illinois and Northeastern University. I gave the transcript to ChatGPT and asked it to turn the talk into a blog while preserving my writing style, and then edited the result myself. It was partly an exercise in curiosity: I wanted to see how well ChatGPT could preserve my voice when translating spoken words into writing. I am fairly impressed. It did drop some of the jokes I made, though. Maybe that’s for the best.)
References
[1] Rahman, H., & Desai, S. (2026). Vibe Check: Understanding the Effects of LLM-Based Conversational Agents’ Personality and Alignment on User Perceptions in Goal-Oriented Tasks. Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems, CHI ’26, 1–30. https://doi.org/10.1145/3772318.3790388
[2] Zhao, M., Yong, Z., Guan, R., Chang, K.-W., Haimovich, A., Ouchi, K., Bickmore, T., Zhang, Z., Yao, B., Wang, D., & Desai, S. (2026). Balancing Efficiency and Empathy: Healthcare Providers’ Perspectives on AI-Supported Workflows for Serious Illness Conversations in the Emergency Department. Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems, CHI ’26, 1–19. https://doi.org/10.1145/3772318.3791301
Good ideas start with a conversation.
Interested in collaborating, exchanging ideas, or exploring new research? Let’s connect.
-
Research -
Collaboration -
Mentorship -
Conversation