ISYS3438 Chap.3 Design Thinking for Visualisation
Design Thinking for Visualisation
Design thinking places the stakeholder problem before the chart menu. This chapter moves from audience and decision through data and task abstraction, alternative sketches, prototypes and testing. It explains why field names must be translated into analytical roles and why preparation decisions such as grain, missing values and type conversion determine later validity.
The worked case shows how a vague request for a delay dashboard becomes a small set of testable views with distinct decision roles.
What this chapter covers
- 01
stakeholder decision
- 02
five design sheet
- 03
data abstraction
- 04
task abstraction
- 05
record grain
- 06
prototype testing
Worked example · free
Turn a delay request into testable views
- +1Rewrite the request as a decision about where and when delay exceeds a useful threshold.
- +1Classify branch and service as categories, dates as time and wait minutes as quantitative.
- +1Confirm one appointment per record and repair invalid waits.
- +1Compare a trend, branch-service heatmap and distribution against user tasks.
Key terms
- Design thinking
- Design thinking is an iterative process that begins with user needs and tests alternative solutions.
- Record grain
- Record grain is the real-world unit represented by one row of data.
- Prototype
- A prototype is a low-cost version used to test whether a design supports its intended task.
- Reverse engineering
- Reverse engineering infers data and task requirements from an existing visual result.
Design Thinking for Visualisation FAQ
Why sketch more than one visualisation?
Alternative sketches reveal assumptions cheaply and make justification comparative. The first chart may be familiar rather than suitable. Testing several routes shows why the selected view supports the stakeholder task better.
What is the difference between data and task abstraction?
Data abstraction classifies fields and structures, while task abstraction names the analytical action. A quantitative field can support ranking, distribution, change or relationship tasks, each of which may require another design.
When is data preparation part of design?
Always. Missing values, duplicates, types and record grain determine what a mark represents. A polished view built on the wrong grain or an identifier treated as a measure is a design failure.
Assessment move
Keep a design sheet for one recurring business problem. Add the audience, decision, attribute types, record grain, three candidate views and a test question for each. Update the sheet after user feedback rather than polishing the first sketch. Preserve rejected options because they become evidence for your final justification. Begin each study cycle with a decision interview.
Ask who will use the result, what action is available, what would count as a meaningful difference and what constraints govern timing, privacy or software. Convert broad requests such as “show performance” into verbs such as compare, rank, locate, explain or monitor. Add the entity, measure, period and benchmark. A precise task abstraction prevents the software interface from deciding the analytical question for you.
Map the data before sketching. Record one-row grain, attribute types, identifiers, missing-value codes and relationships between tables. Distinguish a business label from its analytical role: a postcode may contain digits but function as a category; a date can support ordered time rather than a nominal label. Note every transformation and aggregation that the task will require.
If the available fields cannot support the decision, surface that limitation before producing a persuasive mock-up. Use the five-design-sheet logic as a divergence and selection routine. Generate several genuinely different arrangements, not cosmetic colour variants. One sketch might privilege ranking, another distribution and a third temporal change. Annotate the perceptual task, interaction and evidence boundary on each.
Compare them against the stakeholder decision and data structure, then develop the strongest option. Preserve rejected alternatives because the contrast becomes evidence for the final design justification. Prototype with realistic exceptions, missing values and unequal groups. Give a representative user a concrete task without revealing the intended path, then observe attention, interpretation and filter use.
Classify problems as data, encoding, interaction or explanation failures before revising. Repeat the same task after a meaningful change and compare whether the user finds the right evidence and understands the state. Finish the design log with the chosen route, rejected route, test observation and resulting revision so the final report demonstrates reasoning rather than taste.
Before finalising the prototype, run a constraint review. Confirm the available screen or page size, update frequency, audience access needs, permitted interaction and confidentiality level. Revisit the selected sketch if it depends on hover in a recording, fine colour distinctions on a projector or data that cannot be refreshed reliably. Create a minimum viable view that still supports the decision when those features fail.
Then document the feature that may be added later and the evidence needed to justify it. This exercise keeps feasibility inside the design process. It also provides a defensible explanation when the final submission is simpler than an early concept: the reduction follows from task, user and environment rather than lack of ambition.
Summarise the project in a one-page design rationale containing user, decision, data grain, alternatives, test observation and final revision. Ask whether another designer could understand why the chosen view exists without seeing the polished interface. Any missing link becomes the next research, data or prototype task rather than a sentence of unsupported confidence.