IS6335 Chap.2 The What Why How Design Analysis Framework
The What Why How Design Analysis Framework
Three questions, three abstractions
Week two supplies the instrument week one asked for. Any visualization decision splits into three questions. What is shown, whose answer is a data abstraction. Why the user is looking at it, whose answer is a task abstraction. And how it is shown, whose answer is the idiom, covering both visual encoding and interaction.
The lecture describes the framework as a scaffold for thinking systematically about the design space, and warns in the same sentence that the translation process is iterative and tricky.
Both halves of that warning are load-bearing. It is a scaffold because the design space is too large to search by taste.
It is iterative because the first task abstraction is usually wrong: you write down that the reader wants to compare, discover half way through that they actually want to find an outlier, and the idiom that follows changes with it.
Why the vocabulary is deliberately abstract
The lecture makes a point that is easy to skim. Abstract vocabulary avoids domain-specific terms.
Saying that you hold a table of items with quantitative attributes, and that the reader needs to compare values across a categorical attribute, is a description a logistics analyst and a biologist would both recognise. Saying that you have shipment data and need to see which depot is slow is a description only one of them can use.
The abstraction is what makes a solution transferable, and it is what lets you notice that a problem you have already solved has come back wearing different words.
An idiom, in this vocabulary, is one distinct way of building a visual representation and of letting a reader act on it, with a bar graph, a pie chart and a network offered as examples.
The phrase about manipulating is not decoration: an idiom includes what the reader can do to the view, so a static bar chart and one carrying a filter are two idioms serving two tasks.
Analysing an existing design before building a new one
The lecture argues that analysing existing work is a stepping stone to designing new work, and demonstrates it on a nineteenth century flow map of a military campaign.
The decomposition runs in two passes and the order is the transferable part. The first pass reads each axis in isolation: the horizontal axis carries longitude, and the lower panel reads its vertical axis as temperature over time, so taken alone that panel is a temperature record over space and time.
Nothing about the army has been decoded yet, and the restraint is the point, because an axis is a channel and a channel carries one attribute.
The second pass reads the mark rather than the frame. Longitude and latitude place the band on the map and the width of the band carries army size, which the lecture states as an equation of encodings.
Only after both passes does it ask the question on the slide: the design depicts longitude, latitude, army size and temperature, so are there any other features. That closing question is the habit worth copying, because the attributes a design leaves unencoded are invisible until somebody asks for them by name.
The layers, read as a dependency
The framework is laid out as a stack.
Data sits at the top, described by physical type, conceptual type, metadata and semantics. Task sits beneath it as questions, goals and assumptions. Idiom sits beneath that with its own conventions.
Underneath all three, mapping produces the visual encoding, processing supplies the algorithms, and the image is what the reader finally sees as visual channels and graphical marks.
Reading that arrangement as a dependency tells you what breaks when something changes.
Revise the data abstraction, because a column you treated as quantitative turns out to be an identifier, and the task and the idiom both have to be revisited. Change only the task and the data description survives while the idiom is rebuilt.
This is why the course insists the three answers be written separately: one sentence that mixes them cannot tell you which part has been invalidated, and the most common misuse of the framework is to answer all three at once in the language of the chart you had already decided to build.
What this chapter covers
- 01
What is shown, why the user is looking and how it is shown
- 02
Data abstraction, task abstraction and idiom as three separate answers
- 03
Why abstract vocabulary makes a solution transferable
- 04
Two pass decomposition: read the axes, then read the mark
- 05
Asking what the design leaves unencoded
- 06
The layer stack read as a dependency between decisions
Run the framework over a design you have been handed
- 2Write the data abstraction using the type vocabulary.
- 2Write the task abstraction as an action and a target.
- 2List the idiom and every channel assignment.
- 2Give a verdict tied to the task, not to taste.
Key terms
- Data abstraction
- The answer to the what question: the dataset type you hold and the type of every attribute in it, written without domain words.
- Task abstraction
- The answer to the why question, expressed as an action taken on a target. It is what makes effectiveness measurable, because a design can only be effective for a stated task.
- Idiom
- One distinct way of building a visual representation and of letting a reader act on it. Interaction counts as part of it, so adding a filter produces a different idiom.
- Visual encoding
- The mapping from attributes to the graphical marks and visual channels that carry them. It sits below the three framework answers and is a consequence of them.
- Single axis decomposition
- Reading each axis of an existing design in isolation before reading what the mark itself encodes. It keeps one channel tied to one attribute during analysis.
The What Why How Design Analysis Framework FAQ
Do I have to answer the three questions in order?
You have to write them separately, and the order what, why, how is the order the lecture uses, but the process is explicitly described as iterative and tricky rather than as a single pass. In practice the task abstraction is the one that moves: a first attempt says the reader wants to compare, and working through the idiom reveals that the real target was an outlier.
What matters is that the three answers stay distinct on the page, because the stack is a dependency. If the data abstraction changes, the other two have to be revisited; if only the task changes, the data description survives.
Why decompose an old design instead of just designing a new one?
Because analysing existing work is described as a stepping stone to designing new work, and because decomposition teaches the discipline of one channel to one attribute. Reading the axes of an existing chart in isolation, then reading what its mark encodes, then listing every attribute you found, forces you to notice the encodings you would otherwise take for granted.
The final move is the valuable one: asking what the design leaves unencoded. Attributes that were never given a channel are invisible in the picture and stay invisible in your own designs until you make a habit of asking for them by name.
Assessment move
Practise on charts you did not make. Take one a week, write the three answers on paper before reading any caption, then check your task abstraction against how the chart is actually being used in the article or report around it. The gap between the two is usually the interesting part, and it is the same gap that separates a project figure that answers a question from one that merely presents data.
Working through The What Why How Design Analysis Framework in IS6335? Sia is AskSia’s AI Information Technology tutor — ask any IS6335 The What Why How Design Analysis Framework question and get a clear, step-by-step explanation grounded in how IS6335 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
