Before you start
This course is the sequel to graphical perception. That one was about whether a mark can be read. This one is about whether it should have been drawn at all — and it starts one level upstream, where somebody decides what the user is actually trying to do.
What you will be able to do
Take a real record of somebody's analysis work — an interview transcript, a feature request, a support thread, a meeting note — and produce a task abstraction memo:
- a chained sequence of tasks, each stated as a why, a how, and an input/output;
- the design implications that follow from that chain;
- and an explicit list of what the abstraction is still guessing at.
That memo is the artifact. You will produce a crude one in week one — not at the end — and then rebuild it three times as the vocabulary sharpens. Every week declares what evidence it wants from you before it gives you any content.
Who this assumes you are
Written for a specific entering state. If this doesn't match yours, the pitch will be wrong in a predictable direction, so adjust: comfortable with visual encoding — marks, channels, effectiveness rankings, the Cleveland & McGill line of work. Has run user interviews and written product requirements. Has seen dashboards get built and get ignored. Has not read Munzner's nested model or any formal task taxonomy, and has no working vocabulary for the layer between "what the user said" and "what we built."
What this deliberately is not
- Not a course on visual encoding. Encoding is one level downstream of everything here and is assumed as prior work.
- Not a survey. Brehmer & Munzner compare their typology to more than two dozen prior classification systems Sourced S1. You will meet four of them. The rest are named in the sources list and left there.
- Not data abstraction. Choosing between a table, a network, and a field is a real and separate problem. It shows up here only as the what of a task.
- Not design study methodology. The nine-stage process for running a real design study is adjacent and out of scope.
- Not a claim that the typology works. Its authors validated its descriptive power and explicitly left its generative and evaluative power as future work Sourced S1. Week four is spent on what happened when people tried to use it.
Time
Roughly 14 to 16 hours across four weeks. Every block below carries its own estimate, and those estimates are the honest ones: they already have the standard 2.5× correction applied, because self-paced learners consistently take about that much longer than the plan says. If a block takes you the stated time, the estimate was right, not generous.
The blocks are sized to be opened and closed in one sitting. None is longer than about two hours, most are under an hour, and your place is saved as you go.
How claims are marked
Every load-bearing claim carries a chip saying where it came from. Numbered chips link to the sources list, which also says — per source — whether it was read in full or verified some other way. A field that teaches you to demand provenance from designers should show its own.
- Sourced S1 Traceable to a numbered source that says this.
- Inference My reasoning or application. In no source. Argue with it.
- Contested The field genuinely disagrees.
- Single study Real, but one study, unreplicated.
- Vendor framing True, but authored by a party with a product in the fight.
One honest warning about the evidence here
This is not an empirical field in the way graphical perception is. There are no effect sizes to replicate. The primary sources are proposed vocabularies, argued for by their authors and adopted because practitioners found them useful. The best evidence about whether the central framework actually works in practice is negative and comes from one of its own authors Sourced S3. You will read it in week four. Treat everything here as a well-made tool with a documented failure mode, not as a finding.
Week one
Abstract one real thing, badly
Feeds whyhowwhat · about 3 hours
Evidence this week wants from you
A one-page memo describing a real piece of somebody's work as at least two chained tasks, where each task has a why, a how, and a stated input and output. It will be wrong. That is the point: you cannot fix an abstraction you have not written down.
The word "task" is doing four jobs at once
Munzner lists the levels the word gets used at, all in the same literature, often in the same paragraph Sourced S2:
- High-level domain — cure disease; make web search feel good.
- Lower-level domain — investigate microarray data showing gene expression levels and the network of gene interactions.
- High-level abstract — expose uncertainty; confirm hypotheses.
- Low-level abstract — compare; sort; find anomalies; correlate.
Those are four different kinds of statement, and mixing them is not sloppiness you can write around. It is what makes requirements arguments unresolvable. Two people can agree the user's "task" is X and be describing objects at different levels of the design.
The two literatures that don't meet
By 2013 there were two well-populated bodies of work and a hole between them Sourced S1.
Low-level classifications enumerate what people do. The most-cited is Amar, Eagan & Stasko's ten: retrieve value, filter, compute derived value, find extremum, sort, determine range, characterize distribution, find anomalies, cluster, correlate Sourced S5. Precise, checkable, and mute on motive. Applied to a reader comparing two states on an election map, this yields a series of value retrievals — which is true and tells you nothing about why they were looking, what they already knew, or whether the map worked.
High-level models — sensemaking, information foraging, the exploratory/confirmatory split — describe motive. They cannot reach down to the interface. Told that a user is "making sense," you cannot decide whether to add brushing.
Brehmer & Munzner's claim is that this gap has a specific consequence: without something spanning it, you cannot distinguish the ends of a task from the means, and that failure limits how rigorously anything can be analysed Sourced S1. Their typology exists to close it.
Three questions
A complete task description answers all three, and it is not complete until it does Sourced S1:
Two details that are easy to skim past and shouldn't be.
It is a typology, not a taxonomy. The authors are precise about this: a taxonomy classifies things you can observe happening; a typology classifies abstract concepts Sourced S1. Nobody discovered these categories in the wild. They were constructed to be useful. Week four is about what follows from that.
The notation is deliberately informal. They chose a loose visual notation over a formal grammar so that descriptions could be made and revised in ordinary design sessions — coloured sticky notes on a whiteboard Sourced S1. If you find yourself wanting a schema, you have misread the intent.
Two worked examples, both from the paper. Read them slowly; you are about to imitate them.
One: a stranger reads an election map
Someone reading a blog post after a US presidential election meets a static choropleth map encoding two attributes per state — the winning candidate and the margin. They compare Texas to California. Not to test a hypothesis. Not to present anything. Because they are idly interested in politics Sourced S1.
out: a comparison
Watch what each slot is doing.
- enjoy is a first-class intent, not a failure to have a real one. Casual encounters with visualization were largely absent from prior classification systems, and Brehmer & Munzner put them in on purpose Sourced S1.
- lookup rather than locate, because this reader knows American geography. Change that one fact about the person and the same physical act becomes a different task: an unfamiliar reader must locate the two states first Sourced S1. Nothing on the screen changed.
- encode is the entire how, because the map is static. There is nothing to manipulate.
The move to notice
The task classification depends on what the user already knew. That is not a quirk of this example — it is the organising principle of the search level, and it is the single most-mimicked and least-understood part of the typology. Week three is spent on it.
Two: the same task, two tools
A user of a tree visualization cares about two nodes in a large tree and wants to show her colleagues the path between them. SpaceTree and TreeJuxtaposer both support this, with different focus-plus-context strategies: TreeJuxtaposer lets her rearrange regions of the tree to keep areas of interest visible, while SpaceTree ties selection to aggregating and filtering what wasn't selected Sourced S1.
+ arrange
+ filter + aggregate
Same why. Same what. Different how — and the difference is now sitting in a specific slot where you can argue about it. That is the whole return on the machinery: the comparison between two tools becomes a sentence rather than a vibe Sourced S1.
What the alternatives produced for the same case
Brehmer & Munzner run the same example through two respected taxonomies Sourced S1.
Heer & Shneiderman's taxonomy of interactive dynamics gives data and view specification plus view manipulation — a clean account of how, silent on why.
Lee et al.'s graph-visualization taxonomy gives a topology task, finding a shortest path — a clean account of what, with only a fragment of why.
Neither connects the user's actions to her actual goal of showing something to colleagues. More damningly, neither description distinguishes SpaceTree from TreeJuxtaposer at all. Two tools, one description. If your vocabulary cannot tell two designs apart, it cannot be used to choose between them.
Now produce version zero of your memo. Complete, crude, and about something real.
Pick a source
- Preferred: your own material. A discovery interview transcript, a feature request with a rationale attached, a support thread where someone describes what they were trying to find out. It needs to contain a person doing something with information, described in their own words.
- Fallback: an analyst investigating an abnormal spike in failed airline transactions. She looks at distributions across attributes — airline, flight time, travel agent — and eventually pins one travel agent as the likely culprit Sourced S3. Short, real, and it chains naturally.
Write it in this shape
Two tasks minimum. If you only find one, you have described a step, not a piece of work.
Expect this to feel bad
Most people stall here, and stall in the same place: the why slot fills up with interface language. You will write something like "filter to the failing airline" and only later notice that filtering is a thing she did, not a thing she wanted. Leave it in. That specific error is the material for week three, and it is much easier to see in your own handwriting than in a worked example.
Self-explanation, in the workspace below. Most people are shallow self-explainers unless asked directly, so this is the asking.
- Which slot was hardest to fill, and what made it hard?
- Where did you write down something the source never actually said? Name it.
- If a designer built exactly what your memo describes, what would they get wrong?
A request arrives, verbatim: "The principals need a heatmap of attendance by grade so they can spot problem grades."
Sort that sentence into why, how, and what. Then say which of the three is weakest as written, and what you would have to ask to fix it.
how: "a heatmap." what: attendance by grade — the input. why: "spot problem grades," which is the only part gesturing at intent.
The why is the weakest, and it is weak in a way that is easy to miss because it looks like a purpose. "Spot problem grades" does not say whether the principal already knows which grades are trouble. If she does, this is lookup and the heatmap is doing almost no work — a sorted list would serve. If she does not, it is explore, and the whole design question changes.
The question to ask is not "what do you want to see." It is "when you find a problem grade, what have you already suspected?" — because the answer decides the search type, and the search type constrains the encoding Inference built on the search structure in Sourced S1.
Note the shape of the request: it arrived as a how with a why bolted on. That is the normal shape of feature requests, and learning to see it is most of the practical value of this course.
In the tree-tool example, a low-level interaction taxonomy produced the same description for SpaceTree and TreeJuxtaposer. Which slot of the typology separates them, and why can't a why-only account do the job either?
How separates them: arrange versus filter-plus-aggregate. But a how-only account is exactly what the low-level taxonomies already gave, and it failed — because without the why, you cannot say whether the difference matters. Two tools differing in how are only meaningfully different relative to a shared why and a shared what. That is the argument for holding all three at once Sourced S1.
The general form: how tells you what is different; why tells you whether the difference is a problem. Inference
Week two
The level you are solving on
Feeds why · about 3 hours 25 min
Evidence this week wants from you
Your memo's problem statement, rewritten at the right level of the nested model — plus an explicit list of the assumptions you are making at levels above the one you are working on. If you cannot write that list, you are making the assumptions anyway.
Four levels, nested
Four years before the typology, Munzner published a model that splits visualization design into four levels, each with its own threats and its own valid ways of checking Sourced S2:
| Level | The design problem | The threat, plainly |
|---|---|---|
| 1 · Domain | Characterise the problems and data in the target domain's own vocabulary | Wrong problem — they don't do that |
| 2 · Abstraction | Map those into generic operations and data types | Wrong abstraction — you're showing them the wrong thing |
| 3 · Encoding & interaction | Design how it looks and how it responds | Wrong encoding — the way you show it doesn't work |
| 4 · Algorithm | Compute it automatically and fast enough | Wrong algorithm — your code is too slow |
The four threat statements are Munzner's own phrasing, borrowed from software engineering and deliberately blunt Sourced S2. They are worth memorising in that form, because in a real meeting they are usable and "abstraction validity" is not.
The nesting is the whole idea
Output from each level is input to the one inside it. So an error upstream cascades to everything downstream, and — this is the part that stings — flawless work at the lower levels cannot rescue it. A bad abstraction, perfectly encoded and perfectly optimised, still fails to solve the problem it was aimed at Sourced S2.
The case that makes this concrete: lost in hyperspace
Early web visualization work took the problem of users getting lost on the web and abstracted it, mostly without saying so, into: show the searcher the topological structure of the hyperlink graph Sourced S2.
People do not need an internal representation of that structure to find a page. So the abstraction was wrong at level two. The consequence was not that these systems were mediocre. It was that no encoding could have saved them — each one added cognitive load rather than reducing it, which is the exact opposite of the job. Years of level-three and level-four craft, spent downstream of a level-two mistake Sourced S2.
Munzner's own diagnosis of why this keeps happening: designers skip the domain level, accept the first abstraction that occurs to them, and jump to encoding because encoding looks like the only interesting design problem Sourced S2. If you have ever watched a team open Figma before they could state the user's question, you have seen it.
Two words worth fixing
Munzner reserves problem for a task described in the domain's own terms and operation for the abstract version, using "task" only when talking across the levels Sourced S2. Adopting this costs nothing and makes level confusion audible: if someone says "the task is a heatmap," you can hear immediately that no word in that sentence is at the right level.
Validation has to match the level
Each threat admits different evidence, and pairing them wrongly is the most common defect in weak work Sourced S2.
- Domain threat → observe and interview target users; downstream, watch adoption. Adoption is a weak signal with plenty of false negatives — well-designed tools fail all the time — but it has the virtue of recording what users do unprompted.
- Abstraction threat → target users doing their own work with the deployed system. Not tasks the designers specified. A lab study with dictated tasks cannot test this threat, because dictating the task assumes away the thing in question.
- Encoding threat → justify against perceptual principles; downstream, controlled lab studies of time and error.
- Algorithm threat → complexity analysis; benchmark timings.
The confound that makes this hard
Most validation for outer levels is downstream: it needs the inner levels built first. So a disappointing result at an outer level may actually be caused by a poor choice at an inner one — a clumsy encoding casting doubt on a perfectly good abstraction Sourced S2. This is why "we shipped it and usage was low" is a nearly uninterpretable signal on its own, and why the discipline of naming which level you are claiming is worth the trouble.
Where the typology sits
Level two of this model is precisely where the why/what/how typology lives. Brehmer & Munzner build it as the missing vocabulary for the abstraction level, and the ordering — why first, then how — is chosen to mirror the level-two-then-level-three direction of the nested model Sourced S1. Week one gave you the instrument; this week tells you which bolt it fits.
Completion problems. The first is worked; the rest are yours.
Worked
"Teachers say they waste the first ten minutes of every intervention meeting arguing about which students are actually behind."
Level 1, domain. It is in their vocabulary, about their workflow, and it names an observed cost. It is also — importantly — not yet detailed enough to be input to level two. "Which students are behind" needs unpacking into operations and data types before anyone can design anything. Munzner makes exactly this point: a domain statement has to be detailed enough to feed the abstraction, and high-level goals like "cure disease" are not Sourced S2.
Now assign a level to each of these, and — this is the part that does the work — say what the immediate validation for it would be.
Compare after you have written all five
a — level 3, encoding and interaction. Immediate validation: justify the choices against known perceptual and cognitive principles. Downstream: a lab study of time and error.
b — level 1, domain. In their words, about their workflow. Immediate validation: observe and interview counsellors. Note that it is almost a level-two statement — "compare two cohorts" is nearly an operation — which is exactly why levels one and two blur in practice. Munzner raises this herself as an open question about whether the two should be separate levels at all Sourced S2.
c — level 4, algorithm. Immediate validation: complexity analysis. Downstream: benchmark timings.
d — level 2, abstraction. Domain-free, stated as operation plus data type. There is no immediate validation for the abstraction threat — that is the uncomfortable finding. It has to be tested downstream, by target users doing their own work with a built system Sourced S2.
e — a trap. "A single screen they can open in the morning" is a solution wearing domain clothing. It is a level-3 answer stated as if it were a level-1 observation, which is why it feels so agreeable and yields so little. The level-1 version is whatever they are doing at 7:40 a.m. that this would replace — and nobody has asked Inference.
If you got (e) as "domain," that is the expected miss and worth sitting with. It is the same error as the heatmap request in week one, in a costume that fits better.
Return to your memo. Two operations on it.
- Separate levels one and two. Write the domain problem in the source person's own vocabulary — their words, their workflow, their cost. Then write the abstract operations underneath it. Keep both. The gap between them is where you will find your invented assumptions.
- State your upstream assumptions. Everything you are taking on faith at levels above where you are working. Munzner's second recommendation to authors is exactly this, and it applies harder to product work than to papers, because product work rarely has reviewers Sourced S2.
These reach back to week one on purpose. A check sitting under the section that taught it measures reading, not retention.
Name the three questions a complete task description must answer. Then say which one low-level classifications typically omit, which one high-level models typically omit, and what the consequence of the omission is.
Why, how, what. Low-level classifications give how and drop why; high-level models give why and cannot reach how Sourced S1.
The consequence is the point: with the gap unbridged you cannot distinguish the ends of a task from its means, and without that distinction you cannot compare two designs, cannot tell a requirement from an implementation, and cannot say which level a failure occurred at Sourced S1.
A team ships a dashboard. Six months later, almost nobody opens it. Which single piece of evidence would tell you the most about where the failure occurred?
(c). Low adoption is the downstream signal for a domain-level or abstraction-level threat, and both of those are validated by observing target users doing their own work — not work you assigned Sourced S2.
(a) is a level-3 method: a dictated task cannot test whether you characterised the problem or abstracted it correctly, because the dictation assumes both. (b) answers a level-4 question nobody asked. (d) gathers preference, which is not validation at any level.
The general form worth keeping: match the evidence to the level of the claim, and be suspicious when a downstream measurement is offered as a verdict on an upstream choice Sourced S2.
One paragraph, in the workspace. Written to a colleague, not to yourself.
Pick a real project you have worked on that underdelivered. Name the level the failure was probably at, name the evidence you would have needed to catch it at that level, and say honestly whether that evidence was available at the time. The last part is what stops this being a blame exercise.
Week three
Ends and means
Feeds how · about 3 hours 40 min
Evidence this week wants from you
Your memo with every how evicted from every why slot — and for each search in it, the specific fact about the user's prior knowledge that decides which of the four search types it is. If you cannot name that fact, you have guessed, and the memo should say so.
The same word, on both sides
Here is the observation the whole typology is built to handle. The word derive appears in at least six prior classification systems. Is it a task, or the means by which some other task gets done? Sourced S1
Both, depending on the sentence. A user may derive data as an end in itself — reducing the dimensionality of a dataset because that is the job. Or as a means toward something else — deriving a low-dimensional space in order to check whether clusters exist in it Sourced S1.
And it is not just derive. The same ambiguity sits on filter, navigate, record, and sort Sourced S1. These are the most common words in the requirements you write. Every one of them can be an end or a means, and the sentence almost never says which.
Why this is the crossing
Splitting why from how does not resolve it by itself. Take sort: it has an input and an output, and what gets sorted might be data items inside one view, or the views themselves — and either way the sorted result can feed the next task Sourced S1. So the second move, after separating ends from means, is to say what a task consumes and produces. That is why the third question exists, and it is what week four is about.
Why, in full
Three levels of specificity, narrowing Sourced S1.
Top: consume or produce
- Consume splits into present (communicating, storytelling, guiding an audience — in planning, forecasting, teaching, decision-making), discover (generating or verifying hypotheses, whether theory-driven or prompted by something unexpected), and enjoy (casual encounters, curiosity without a stake — from a map glanced at in a blog post to an hour in a museum).
- Produce is for making new artifacts: derived or transformed data, annotations, recorded interactions, screenshots. Crucially, what gets produced may be consumed by some later task that has nothing to do with visualization — new categorical attributes tagged onto clusters and then fed to a predictive model Sourced S1.
Middle: search, keyed on what the user already knows
Whatever the intent, the user has to find the thing. The four types are distinguished not by what the user does but by two facts about what they knew before they started Sourced S1.
| Target known | Target unknown | |
|---|---|---|
| Location known | Lookup California on a map, by someone who knows US geography | Browse within this subtree, leaf nodes with few siblings |
| Location unknown | Locate California, by someone who doesn't | Explore anywhere in this scatterplot, outliers — usually starting from an overview |
Two things follow that are worth slowing down for.
You cannot classify a search by watching it. Two users performing identical clicks are performing different tasks if one knew where to look. The distinguishing fact lives in the person, not the interaction log Sourced S1. This makes the search level genuinely hard to code from telemetry, and easy to fake by guessing.
Search and explore are not synonyms. The terms get conflated constantly in practice; the typology deliberately refuses the conflation Sourced S1. "Exploratory" as a product word usually means "we didn't ask."
Bottom: query, by how many targets are in play
Identify one, compare several, summarize the whole set — an increase in how much of the data is under consideration, with summarize often tied to overviews Sourced S1.
The subtle bit about identify, which almost everyone misses
Identify returns different kinds of thing depending on which search preceded it Sourced S1.
If the search returned a known target — lookup or locate — then identify returns its characteristics. You knew you wanted California; identify tells you the winner and the margin.
If the search returned targets matching characteristics — browse or explore — then identify returns the reference. You wanted the largest margin; identify tells you it was California.
The arrow reverses. Same word, opposite direction of information flow, decided entirely by the search that came before it. This is the clearest evidence in the whole framework that these levels are coupled and that you cannot code one without the others.
How, in full — as published in 2013
Three classes of method, meaning families of related encoding and interaction techniques Sourced S1. Encoding and interaction are treated together, not separately, because many methods are both at once — focus-plus-context being the obvious case.
| Class | Methods | What it does |
|---|---|---|
| Encode | — | How the data becomes a representation in the first place. Most tasks rest on it. |
| Manipulate | select · navigate · arrange · change · filter · aggregate | Alters elements that are already there. |
| Introduce | annotate · import · derive · record | Adds elements that weren't. |
- Select — marking some elements off from the rest, from a click to brushing across linked views.
- Navigate — anything altering viewpoint: zoom, pan, rotate. Details-on-demand is navigate combined with select.
- Arrange — spatial organisation, of data (reordering parallel-coordinate axes, rows and columns of a matrix) or of views themselves.
- Change — alterations to the encoding: colour scale, point size, axis scale, or wholesale chart-type changes, which is where animated transitions earn their keep.
- Filter — adjusting inclusion criteria. Sometimes reversible hiding, sometimes outright deletion.
- Aggregate — changing granularity, and its converse, segregating. Monthly to daily; a clique to a glyph and back.
- Annotate · import · derive · record — adding notes or labels; bringing in new elements; computing new data from existing data; capturing state as a persistent artifact. Note the boundary Brehmer & Munzner draw between derive and aggregate: derived data must persist; aggregated data need not Sourced S1.
Where the why/how split comes from
Distributed cognition distinguishes pragmatic actions — consciously goal-directed — from epistemic actions, which coordinate your internal model with the external representation. The typology maps why onto pragmatic and how onto epistemic, and the manipulate methods in particular are where epistemic action lives Sourced S1. It is a real theoretical grounding rather than a tidy diagram, and it is why the split is not arbitrary.
For each ambiguous verb, write one sentence where it is an end and one where it is a means. Same verb, both times. The first is done.
Worked · derive
As an end: she needs a per-school chronic-absence rate, because that number goes in the state report. Producing it is the work.
As a means: she computes the same rate so she can see whether schools with high mobility also have high absence. The rate is scaffolding; the end is discover → explore → compare.
One reading of the hard case
Navigate is usually the hardest to write as an end, and that is informative: zooming is almost always epistemic — you do it to see, not because seeing the zoomed view is the goal Inference.
Record is the opposite and often the easiest, because recording is frequently the entire point: assembling a graphical history is a produce task whose output is the artifact Sourced S1.
The practical use: verbs that resist being written as ends are ones you should be suspicious of when you find them in a why slot. If a requirement's stated purpose is "navigate the hierarchy," a purpose has gone missing Inference.
You claimed, on the basis of interviews, that counsellors spend meeting time arguing about which students are behind. A colleague runs a lab study where participants complete assigned tasks with your tool, and they are slower than with the spreadsheet. He says this refutes your claim. Why is he wrong — and what would the study legitimately refute?
He has matched a level-3 method to a level-1 claim. A lab study with tasks specified by the study designers cannot test whether the problem was mischaracterised, because specifying the task presupposes the characterisation Sourced S2.
What the study legitimately bears on is the encoding and interaction level: measured time and error for a given operation is exactly the downstream validation for that threat Sourced S2. So the result is real information — about a different level than the one he named.
The remaining trap runs the other way: a poor encoding can make a good abstraction look bad, because outer-level validation is confounded by inner-level choices Sourced S2. So neither of you can conclude much until the encoding is defensible on its own terms.
A district data lead opens the enrolment dashboard every Monday. She has learned over two years that Riverton Elementary is where enrolment surprises show up first, so she goes straight to it, and reads off whatever this week's number is.
Which search type — and name the specific fact that decided it. Then say what would have to change about her, not the tool, to make it a different type.
Lookup. She knows the target (Riverton) and she knows where it sits in the display. Both known Sourced S1.
The deciding fact is two years of experience — not anything in the interface. A new hire performing identical clicks is doing locate: same target, unknown position. And a lead who does not know which school will surprise her, scanning the whole district for anything odd, is doing explore: neither target nor location known.
The design consequence is concrete. If most of your users are doing lookup, effort spent on overview-first layouts is misplaced; if they are exploring, a layout optimised for going straight to a known school actively hides the thing they need Inference. Same data, same screen, opposite verdicts — decided by a fact you can only get by asking.
Here is a task description written by someone who has read the paper once. Three things are wrong with it. Find as many as you can.
- Why and how are swapped. Discover is a why — a top-level intent. Filter is a how — a manipulate method Sourced S1. Written this way, the description says the purpose of the work is to filter, which is the exact ends-means confusion the typology was built to prevent.
- "Drill down" is not a query. The query level takes identify, compare, or summarize, and it answers how many targets are in play Sourced S1. "Drill down" is interface vocabulary — closer to navigate, on the how side.
- The what is a tool, not a task input. "The attendance dashboard" is where the work happens, not what the task consumes and produces. The requirement is to state input and output — here, something like in: attendance rates for all schools; out: the schools with anomalous rates Sourced S1.
A fourth, if you want it: nothing in this description could be used to compare two tools, which is the test of whether an abstraction is doing any work Inference.
Third pass on the memo. Less scaffolding this time — you get the constraints, not a form.
- Every why slot reads: one of consume/produce, then a search type, then a query. No interface verbs anywhere in it.
- For each search, the deciding fact about the user's prior knowledge is written down — or explicitly marked as a guess you have not verified.
- Every how slot names methods, not features. "Brushing between the two panels" becomes select; "the year dropdown" becomes filter.
- Anything that turns out to be produce rather than consume gets its own task. Producing a derived attribute is a task, not a footnote.
This is the week people quit
The stuck feeling here is not a sign the material is badly explained. It is the crossing itself. You are being asked to stop using a set of words the way you have used them for years, and the discomfort is that your existing sentences keep coming out wrong. That resolves — but only by writing enough wrong ones to hear the difference. If you are irritated with the vocabulary right now, you are exactly where the design expects you to be.
Without looking back: a colleague says "our users' task is exploratory analysis." Write the three follow-up questions that would turn that into something a designer could build against — and say which level of the nested model each answer belongs to.
- "What do they already know before they start looking?" — decides between the four search types, which is a level-2 abstraction question Sourced S1.
- "When they find something, is it one thing, a few, or a picture of the whole?" — the query level: identify, compare, summarize Sourced S1. Still level 2.
- "What do they do with the answer afterwards?" — surfaces whether there is a produce task hiding downstream, and often reveals that the real domain problem is one step later than the one you were handed. Level 1 Sourced S2.
What none of these ask about is charts. That is the tell that they are the right questions Inference.
Week four
Chains, and the limits of the thing you just learned
Feeds what · about 4 hours
Evidence this week wants from you
A complete task abstraction memo on a source you have not touched before, written without a template — plus a paragraph naming where this framework failed you and what you reached for instead. The second half is not a formality. A practitioner who cannot say where their tool breaks is using it on faith.
What: bring your own
The third question is the least prescriptive part of the typology, on purpose. Prior work has never agreed on what a visualization is made of — values and attributes, nodes and links, temporal intervals and spans, pixels and structures — so Brehmer & Munzner decline to pick Sourced S1. Bring whatever vocabulary your data has.
There is exactly one hard requirement: when you describe a sequence of interdependent tasks, you must explicitly distinguish each task's input from its output Sourced S1. That constraint is what makes chaining possible, and chaining is what makes the typology able to describe real work rather than isolated moments.
The case study, as a chain
Overview is a tool for exploring large document collections. A user wants to tag semantically related documents with a new categorical attribute, using clusters as scaffolding. Here is what that actually is Sourced S1.
out: low-dimensional data
out: cluster hierarchy
outputs feed
out: clusters of interest
output feeds
out: tags for those clusters
Three structural facts about that diagram, each of which took the field a while to arrive at Sourced S1:
- 1a and 1b can happen in either order. Task 2 depends on both. It is a dependency graph, not a pipeline.
- The user's actual goal is last. Everything before it is scaffolding. A description that started at task 2 — the interesting-looking one, with the linked views — would have missed both the derivation it rests on and the point of the whole exercise.
- Two of the four tasks are produce, not consume. Most task vocabularies have no room for these at all. Descriptions built from other classification systems could not express the annotation step Sourced S1.
Constraints, not sequences
Stage- and cycle-based models of analysis impose a global ordering, and empirical observation of real visualization use has found actual behaviour doesn't match those orderings Sourced S1. The typology deliberately imposes no global sequence: it expresses local dependencies through constraints on input and output Sourced S1. If you have ever drawn a user journey as a straight line and watched real users refuse to walk it, this is the formal version of that complaint.
In the Overview chain, suppose the clustering (task 1b) is wrong — the hierarchy groups documents that have nothing to do with each other. Trace what happens downstream, task by task, and say which level of the nested model the failure is at.
Then: what would a user of the finished tool most likely conclude about why it wasn't working?
Task 2 takes the hierarchy as input, so exploring it identifies "clusters of interest" that are not coherent. Task 3 then annotates those incoherent clusters with tags. The output artifact — a tagged corpus — is corrupted, and the corruption is invisible in the interface, because every step after 1b executed correctly on bad input.
The failure is at level 2, abstraction: deriving a cluster hierarchy was chosen as the scaffolding for the discovery process, and if that derivation doesn't reflect anything real, no encoding of it helps Sourced S2. Note that this is the same structure as the lost-in-hyperspace case: a plausible derived structure, presented beautifully, that the user did not need.
The user would almost certainly blame the scatterplot — the thing they can see. Level-2 failures are routinely reported as level-3 complaints, which is precisely why the nested model insists you name the level before you accept the diagnosis Inference.
Independent. No template, no worked example, no form to fill in. A source you have not used in this course, and a memo somebody else could act on.
If you have your own material, use it. If not: find a recorded analysis session, a bug report where a user explains what they were trying to establish, or a written account of somebody investigating something in your own organisation.
What has to be true of the finished memo
- The domain problem is stated in the source person's vocabulary, separately from the abstraction.
- At least three tasks, with at least one dependency where one task's output is another's input — and if two tasks are order-independent, that is said.
- At least one produce task. If your source genuinely has none, say so and say how you know.
- Every search type has its deciding fact recorded, marked known or assumed.
- A design implications section where each implication points at a specific slot in a specific task.
- An open questions section: what you would need to observe to replace each assumption.
What happened when people tried to use it
Four years after the typology, Munzner co-authored a paper whose premise is that abstracting real analysis with existing task classifications — including her own — is slow, laborious, and hard Sourced S3. The diagnosis is precise, and it is structural rather than cosmetic:
Working bottom-up forces you to abstract each low-level step without the context of what the analysis was for. In theory you should be able to code the steps and group them into goals. In practice, the coder is stranded Sourced S3.
The two admissions worth reading twice
The authors tried coding an interview transcript line by line using the typology and one other framework. They floundered, lost the thread in long discussions, and abandoned the attempt. It only worked once they had identified the higher-level analysis goals first Sourced S3.
And a former student, trying to improve a dashboard for HIV researchers, attempted to abstract the domain tasks with Brehmer & Munzner's typology and did not succeed — reporting that he found the terminology confusing, specifically search versus query, and did not understand the structure Sourced S3. If week three felt hard, you are in documented company.
Their fix is not to discard the typology but to put something above it: nine analysis goals on two axes — specificity (explore → describe → explain → confirm) and number of populations (single or multiple), each goal scoped by an input and an output Sourced S3. You chunk the stream into units with goals first, then code the steps inside each unit using a task classification. Top-down, then bottom-up.
| Explore | Describe | Explain | Confirm | |
|---|---|---|---|---|
| Single population | Discover Observation | Describe Observation (item / aggregate) | Identify Main Cause (item / aggregate) | Collect Evidence |
| Multiple populations | — | Compare Entities | Explain Differences | Evaluate Hypothesis |
Derived by open-coding 20 design study papers from IEEE InfoVis 2009–2015 Sourced S3. The authors are candid about the limits: design study papers are curated write-ups, not faithful records, so floundering and failure are almost entirely absent from the source material, and the framework is explicitly described as incomplete Sourced S3.
The categories moved
In the 2013 paper, annotate, record, and derive sit under how, in the class called introduce Sourced S1. In Munzner's 2014 book, the same three sit under why, as the content of produce; how is restructured entirely into encode / manipulate / facet / reduce; and what stops meaning task input-output and starts meaning the data abstraction, with a separate list of targets Sourced S4.
What to make of that
One year, same author, and three concepts crossed from the means side to the ends side. That is not a correction of an error. It is evidence about the status of the categories: they are conventions chosen to be useful, exactly as the word "typology" promised in week one Sourced S1. The permanent contribution is the discipline of asking all three questions and keeping ends separate from means. The specific box a word lives in is negotiable, and treating it as fixed is the mimicry failure this whole framework exists to prevent Inference.
Two more things the field says, briefly
There are rival carvings. Schulz et al. published a competing design space in the same year and the same venue, with five dimensions — goal, means, characteristics, target, cardinality — composed as tuples Sourced S6. It overlaps the typology substantially and divides the space differently. Neither has displaced the other, which is itself informative Contested.
Nobody has established that it is reliable. The 2013 paper validates only descriptive power, by demonstration; generative and evaluative power are named as future work Sourced S1. There is a published treatment of the threats to validity that arise at each stage of constructing a task classification and how to mitigate them Sourced S9 — which tells you the field knows this is an open question. If you and a colleague independently abstract the same transcript and disagree, no published agreement rate exists for you to compare against Inference.
And one about the illustrations. Several of the canonical produce examples — graphical histories, provenance trails — come from tools built by the companies whose researchers co-authored the surrounding literature Vendor framing. The work is peer-reviewed and the examples are apt. But the reason those features are the textbook cases of produce is partly that they existed and were well documented, which shapes which parts of the design space look well-populated Inference.
You have a one-hour recorded session of an analyst working, thinking aloud, with no stated goal. You want a description you can design against. Which do you reach for first, and why?
(c), and this is exactly the case the Lam et al. paper was written about. Interview and think-aloud data is noisy, participants follow a stream of consciousness rather than announcing goals, and coding line by line with a task classification pulls you down to the level of transcript actions — which the authors found unworkable until they chunked by goal first Sourced S3.
(b) is the trap, and choosing it is not a wasted answer — it is the move a careful reader of weeks one to three would make. (a) is worse for the same reason, one level further down. (d) is a category error: the nested model describes levels of design decisions, not utterances, and it has no coding scheme Inference.
What survives from weeks one to three is that once you have chunked by goal, the typology is what you use inside the chunk. The frameworks stack; they do not compete Sourced S3.
A colleague who has not read any of this asks why you keep making the team rewrite requirements. Answer in five sentences or fewer, without using the words typology, abstraction, or taxonomy.
Most requests arrive as a solution with a purpose bolted on, and the purpose is usually too vague to build against. If we can say what the person is trying to find out, what they already know before they start looking, and what they do with the answer, then two designs can be compared on something other than taste. If we can't, we're arguing about charts. And the expensive mistakes aren't in the charts — they're in having correctly built a thing nobody needed.
Score yourself on whether you needed the jargon. If your own answer only works with the vocabulary in it, the vocabulary is carrying the belief rather than the understanding — which is the specific failure mode of half-crossing a threshold like this one.
Your calibration
Every probe asked you to predict confidence before revealing. Here is what that predicted, against what happened. Solo study has almost no feedback loops; this is the cheapest one available, and the gap is more informative than the score.
Nothing recorded yet.
What you should be able to do now
- Hear a feature request and say, out loud, which part of it is a how wearing a why's clothes.
- Ask the one question — what did they already know? — that decides the search type, and know why the answer changes the design.
- Name which of four levels a proposed piece of evidence can and cannot speak to.
- Write a chain rather than a task, and notice when the goal is the last link rather than the first.
- Say where this framework stops working, and reach for the goal-first alternative when the material is noisy.
The honest limit: none of this tells you what to draw. It tells you what you are drawing for, which is upstream of every encoding decision you already knew how to make — and, on the evidence of the lost-in-hyperspace case, is where the expensive errors actually live.
Apparatus
Sources
Numbered to match the chips in the text. Each entry says how it was actually verified, because "there is a citation" and "somebody opened the citation" are different claims, and only one of them is checkable.
- S1 Brehmer, M. & Munzner, T. (2013). A Multi-Level Typology of Abstract Visualization Tasks. IEEE TVCG 19(12): 2376–2385 (Proc. InfoVis 2013). Tier 1 · primary source, read in full from the authors' manuscript. Every S1 claim in this course was checked against the text rather than against a summary of it.
- S2 Munzner, T. (2009). A Nested Model for Visualization Design and Validation. IEEE TVCG 15(6): 921–928. Tier 1 · primary source, read in full. The four levels, the four threat statements, the lost-in-hyperspace case, and the validation-matching argument all come directly from it.
- S3 Lam, H., Tory, M. & Munzner, T. (2018). Bridging From Goals to Tasks with Design Study Analysis Reports. IEEE TVCG 24(1): 435–445. Tier 1 · primary source, read in full. The account of abandoning line-by-line coding, the student's difficulty with the terminology, the nine analysis goals, and the authors' own statement of the framework's incompleteness are all from the paper itself.
- S4 Munzner, T. (2014). Visualization Analysis and Design, ch. 3, "Why: Task Abstraction." CRC Press. Tier 2 · verified indirectly. The chapter's structure — produce containing annotate, record, derive; how restructured into encode / manipulate / facet / reduce; targets added alongside actions — was confirmed from the publisher's chapter contents and from Munzner's own lecture slide decks. The chapter text was not read in full for this course. Treat the claim about what moved between 2013 and 2014 as verified in outline, not in argument.
- S5 Amar, R., Eagan, J. & Stasko, J. (2005). Low-Level Components of Analytic Activity in Information Visualization. Proc. IEEE InfoVis: 111–117. Tier 1 paper, verified indirectly. Abstract read; the ten-task list confirmed independently in two places, including Munzner's own enumeration of it in S2. Not read in full. Used here only for the list and for the fact that it is the canonical low-level taxonomy.
- S6 Schulz, H.-J., Nocke, T., Heitzler, M. & Schumann, H. (2013). A Design Space of Visualization Tasks. IEEE TVCG 19(12): 2366–2375. Tier 1 paper, verified indirectly. Abstract read; the five dimensions — goal, means, characteristics, target, cardinality — confirmed from two independent secondary descriptions. Not read in full. Cited only to establish that a rival carving exists, published in the same issue as S1.
- S9 Kerracher, N. & Kennedy, J. (2017). Constructing and Evaluating Visualisation Task Classifications: Process and Considerations. Computer Graphics Forum 36(3): 47–59. Tier 3 as used here · reached through S3 and a published abstract. Not read. Supports one claim only: that the field has explicitly examined the threats to validity in building task classifications. Do not lean on it further without opening it.
Also named in passing and deliberately not load-bearing: Shneiderman's task-by-data-type taxonomy (1996); Heer & Shneiderman's interactive dynamics (2012); Lee et al.'s graph task taxonomy (2006); Rind et al.'s task cube (2015); Vicente on constraint-based versus sequence-based task analysis. Each is discussed inside S1 or S3, and this course reports what those papers say about them rather than what they say about themselves. If any becomes important to your work, open it directly — that one step is the highest-value move available when you are working from someone else's summary.