From 141c6db3984cff495ce10e07cf239f6aaee6a9af Mon Sep 17 00:00:00 2001 From: varshav282801 Date: Sun, 26 Apr 2026 21:28:15 +0800 Subject: [PATCH 1/7] Create CNAME --- CNAME | 1 + 1 file changed, 1 insertion(+) create mode 100644 CNAME diff --git a/CNAME b/CNAME new file mode 100644 index 0000000..501c561 --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +info-design-lab.test \ No newline at end of file From 863ba4004a05bb4b4c9172c9ebce78223c783069 Mon Sep 17 00:00:00 2001 From: varshav282801 Date: Sun, 26 Apr 2026 21:29:57 +0800 Subject: [PATCH 2/7] Delete CNAME --- CNAME | 1 - 1 file changed, 1 deletion(-) delete mode 100644 CNAME diff --git a/CNAME b/CNAME deleted file mode 100644 index 501c561..0000000 --- a/CNAME +++ /dev/null @@ -1 +0,0 @@ -info-design-lab.test \ No newline at end of file From 2033e3c1d0cd9b123cefe0184b023e3fededdb9e Mon Sep 17 00:00:00 2001 From: varshav282801 Date: Sun, 26 Apr 2026 21:32:46 +0800 Subject: [PATCH 3/7] Add GitHub Actions workflow for v2 preview deployment --- .github/workflows/deploy-v2-preview.yml | 54 +++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 .github/workflows/deploy-v2-preview.yml diff --git a/.github/workflows/deploy-v2-preview.yml b/.github/workflows/deploy-v2-preview.yml new file mode 100644 index 0000000..616f75e --- /dev/null +++ b/.github/workflows/deploy-v2-preview.yml @@ -0,0 +1,54 @@ +name: Deploy v2 preview + +on: + push: + branches: ["v2-preview"] + workflow_dispatch: + +permissions: + contents: read + pages: write + id-token: write + +concurrency: + group: pages + cancel-in-progress: true + +jobs: + build: + runs-on: ubuntu-latest + + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Setup Pages + id: pages + uses: actions/configure-pages@v5 + + - name: Setup Hugo + uses: peaceiris/actions-hugo@v3 + with: + hugo-version: latest + extended: true + + - name: Build site from v2 + working-directory: v2 + run: hugo --minify --baseURL "${{ steps.pages.outputs.base_url }}/" + + - name: Upload Pages artifact + uses: actions/upload-pages-artifact@v3 + with: + path: v2/public + + deploy: + needs: build + runs-on: ubuntu-latest + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + + steps: + - name: Deploy + id: deployment + uses: actions/deploy-pages@v4 From 873e5e1fb6c5eeff405ee29151ba7c57e960f3c9 Mon Sep 17 00:00:00 2001 From: varshav282801 Date: Sun, 26 Apr 2026 21:37:42 +0800 Subject: [PATCH 4/7] Update GitHub Actions workflow for Hugo deployment --- .github/workflows/deploy-v2-preview.yml | 47 +++++++++++++++++-------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/.github/workflows/deploy-v2-preview.yml b/.github/workflows/deploy-v2-preview.yml index 616f75e..da565da 100644 --- a/.github/workflows/deploy-v2-preview.yml +++ b/.github/workflows/deploy-v2-preview.yml @@ -1,8 +1,8 @@ -name: Deploy v2 preview +name: Deploy v2 Hugo site to Pages on: push: - branches: ["v2-preview"] + branches: ["master"] workflow_dispatch: permissions: @@ -12,43 +12,60 @@ permissions: concurrency: group: pages - cancel-in-progress: true + cancel-in-progress: false + +defaults: + run: + shell: bash jobs: build: runs-on: ubuntu-latest - + env: + HUGO_VERSION: 0.156.0 steps: - name: Checkout uses: actions/checkout@v4 + with: + fetch-depth: 0 + submodules: recursive + + - name: Setup Go + uses: actions/setup-go@v5 + with: + go-version: '1.26' - name: Setup Pages id: pages uses: actions/configure-pages@v5 - name: Setup Hugo - uses: peaceiris/actions-hugo@v3 - with: - hugo-version: latest - extended: true + run: | + wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \ + && sudo dpkg -i ${{ runner.temp }}/hugo.deb - - name: Build site from v2 + - name: Build with Hugo working-directory: v2 - run: hugo --minify --baseURL "${{ steps.pages.outputs.base_url }}/" + env: + HUGO_ENVIRONMENT: production + HUGO_ENV: production + run: | + hugo \ + --gc --minify \ + --baseURL "${{ steps.pages.outputs.base_url }}/" - - name: Upload Pages artifact + - name: Upload artifact uses: actions/upload-pages-artifact@v3 with: path: v2/public deploy: - needs: build - runs-on: ubuntu-latest environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} - + runs-on: ubuntu-latest + needs: build steps: - - name: Deploy + - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v4 From ea738dd4a9968ecebb78f993e32ddc495939bcb2 Mon Sep 17 00:00:00 2001 From: varshav282801 Date: Sun, 26 Apr 2026 21:53:37 +0800 Subject: [PATCH 5/7] Change deployment branch from master to v2-preview --- .github/workflows/deploy-v2-preview.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/deploy-v2-preview.yml b/.github/workflows/deploy-v2-preview.yml index da565da..87dca20 100644 --- a/.github/workflows/deploy-v2-preview.yml +++ b/.github/workflows/deploy-v2-preview.yml @@ -2,7 +2,7 @@ name: Deploy v2 Hugo site to Pages on: push: - branches: ["master"] + branches: ["v2-preview"] workflow_dispatch: permissions: From 8ed8cbdd417e0aa6b69a7e0e8ea9dac0641fb449 Mon Sep 17 00:00:00 2001 From: Varsha Venkatesh Date: Tue, 28 Apr 2026 00:45:50 +0800 Subject: [PATCH 6/7] update course page --- content/_index.md | 2 +- content/courses/de705-de303.md | 23 ++++++++++++----------- 2 files changed, 13 insertions(+), 12 deletions(-) diff --git a/content/_index.md b/content/_index.md index 3207769..4ca8d73 100644 --- a/content/_index.md +++ b/content/_index.md @@ -154,7 +154,7 @@ We work in an interdisciplinary, collaborative atmosphere with partners from aca ### Courses -
  • DE705 Interactive Data Visualization & DE303 Information Graphics and Visualization (Autumn 2025)
    • + diff --git a/content/courses/de705-de303.md b/content/courses/de705-de303.md index 7d92c18..d26ba9f 100644 --- a/content/courses/de705-de303.md +++ b/content/courses/de705-de303.md @@ -1,14 +1,15 @@ --- title: "DE705 Interactive Data Visualization & DE303 Information Graphics and Visualization" date: 2026-04-27 -summary: "Autumn 2025 course overview, schedule, assessment, and references for DE705 and DE303." +summary: "Autumn 2026 course overview, schedule, assessment, and references for DE705 and DE303." +url: "/courses/DE705-DE303/" toc: true ---
    -

    Autumn 2025

    +

    Autumn 2026

    Instructor: Prof. Venkatesh Rajamanickam

    -

    8 Sep to 26 Sep 2025

    +

    31 Aug to 18 Sep 2026

    Venue: BDes 3 Classroom & Mini Theatre, RBTIC

    @@ -52,15 +53,15 @@ Recent advances in technology have enabled the creation, recording, and analysis | Session | Topics | Assignment or Activity | Additional Readings and Resources | | --- | --- | --- | --- | -| Day 01 | Lecture 01: Introduction to Data Visualization | Assignment 1: Visualization Critique | A Tour through the Visualization Zoo by Jeffrey Heer, Michael Bostock, and Vadim Ogievetsky. The Value of Information Visualization by Jarke van Wijk. | -| Day 02 | Lecture 02: Visualization Typology; review of Assignment 1 | Assignment 2: Chart Deconstruction and Redesign | Scott Berinato's Visualization Typology. From Viz to Data. A periodic table of visualization methods. | -| Day 03 | Lecture 03: Data; review of Assignment 2 | Assignment 3: Comparative Visualizations | On the Theory of Scales of Measurement by S. S. Stevens. Reflections on how designers design with data by Alex Bigelow, Steven Drucker, Danyel Fisher, and Miriah Meyer. The Eyes Have It taxonomy. | -| Day 04 | Lecture 04: Data Abstraction; Lecture 05: Task Abstraction; review of Assignment 3 | Assignment 4: Visualizing Burtin's Antibiotic Data | Visualization Analysis and Design by Tamara Munzner, with lecture material on data and task abstraction. | -| Day 05 | Lecture 06: Geo Visualization; review of Assignment 4 | Assignment 5: Schematic Hometown Map | How Maps Work by Denis Wood. The Image of the City by Kevin Lynch. Getting There by Nick Paumgarten. Rendering effective route maps by Maneesh Agrawala and Chris Stolte. | -| Day 06 | Lecture 08: Visual Encoding; review of Assignment 5 | Assignment 6 (Group): Exploratory Data Analysis and Visualization | Nature Methods Points of View columns on data visualization. | +| Day 01 | Lecture 01: [Introduction to Data Visualization](https://info-design-lab.github.io/ID413-DataViz/files/ID%20413(2025)/01_Introduction.pdf) | Assignment 1: [Visualization Critique](https://github.com/info-design-lab/DE705-Interactive-Data-Visualization/issues/45) | [A Tour through the Visualization Zoo.](https://queue.acm.org/detail.cfm?id=1805128) Jeffrey Heer, Michael Bostock, Vadim Ogievetsky. Communications of the ACM, 53(6), pp. 59-67, Jun 2010.
    [The Value of Information Visualization.](https://link.springer.com/chapter/10.1007/978-3-540-70956-5_1) Jarke van Wijk. Proceedings of the IEEE Visualization Conference, pp. 79-86, 2005. | +| Day 02 | Lecture 02: [Visualization Typology](https://info-design-lab.github.io/ID413-DataViz/files/ID%20413(2025)/02_Visualization%20Typology.pdf); review of Assignment 1 | Assignment 2: [Chart Deconstruction and Redesign](https://github.com/info-design-lab/DE705-Interactive-Data-Visualization/issues/46) | [Visualization Typology](https://hbr.org/2016/06/visualizations-that-really-work) proposed by Scott Berinato.
    [From Viz to Data.](https://www.data-to-viz.com/)
    [A periodic table of visualization methods.](https://www.visual-literacy.org/periodic_table/periodic_table.html) | +| Day 03 | Lecture 03: [Data](https://info-design-lab.github.io/ID413-DataViz/files/ID%20413(2025)/03_Data.pdf); review of Assignment 2 | Assignment 3: [Comparative Visualizations](https://github.com/info-design-lab/DE705-Interactive-Data-Visualization/issues/47) | [On the Theory of Scales of Measurement.](http://www.jstor.org/stable/1671815) S. S. Stevens. Science New Series, Vol. 103, No. 2684, pp. 677-680. Jun 1946.
    [Reflections on how designers design with data.](http://dl.acm.org/citation.cfm?id=2598175) Alex Bigelow, Steven Drucker, Danyel Fisher, Miriah Meyer. AVI '14 Proceedings of the 2014 International Working Conference on Advanced Visual Interfaces, pp. 17-24.
    [The eyes have it: a task by data type taxonomy for information visualizations.](https://ieeexplore.ieee.org/document/545307) | +| Day 04 | Lecture 04: [Data Abstraction](https://info-design-lab.github.io/ID413-DataViz/files/ID%20413(2025)/04_Data%20Abstraction.pdf); Lecture 05: [Task Abstraction](https://info-design-lab.github.io/ID413-DataViz/files/ID%20413(2025)/05_Task%20Abstraction.pdf); review of Assignment 3 | Assignment 4: [Visualizing Burtin's Antibiotic Data](https://github.com/info-design-lab/DE705-Interactive-Data-Visualization/issues/48) | [Visualization Analysis and Design](https://www.routledge.com/Visualization-Analysis-and-Design/Munzner/p/book/9781466508910) by Tamara Munzner.
    Her lecture video of the [Data Abstraction chapter](https://www.youtube.com/watch?v=tBWMOSrASkE).
    Her lecture video of the [Task Abstraction chapter](https://www.youtube.com/watch?v=pHljd-cgICY). | +| Day 05 | Lecture 06: [Geo Visualization](https://info-design-lab.github.io/ID413-DataViz/files/ID%20413(2025)/06_Geo%20Visualization.pdf); review of Assignment 4 | Assignment 5: [Schematic Hometown Map](https://github.com/info-design-lab/DE705-Interactive-Data-Visualization/issues/49) | [How Maps Work](https://info-design-lab.github.io/ID413-DataViz/files/How%20Maps%20Work.pdf) Denis Wood, Cartographica, Vol 29 Numbers 3 & 4 Autumn/Winter 1992, pp. 66-74.
    [The Image of The City](https://www.miguelangelmartinez.net/IMG/pdf/1960_Kevin_Lynch_The_Image_of_The_City_book.pdf) Kevin Lynch, 1960.
    [Getting There: The science of driving directions](https://www.newyorker.com/magazine/2006/04/24/getting-there-2) Nick Paumgarten, The New Yorker, 24 April 2006.
    [Rendering effective route maps: improving usability through generalization](https://graphics.stanford.edu/papers/routemaps/rtmaps.pdf) Maneesh Agrawala and Chris Stolte, SIGGRAPH '01 Proceedings of the 28th annual conference on Computer graphics and interactive techniques, pp. 241-249. | +| Day 06 | Lecture 08: [Visual Encoding](https://info-design-lab.github.io/ID413-DataViz/files/ID%20413(2025)/08_Visual%20Encoding.pdf); review of Assignment 5 | Assignment 6 (Group): [Exploratory Data Analysis and Visualization](https://github.com/info-design-lab/DE705-Interactive-Data-Visualization/issues/50) | [Nature Methods Points of View columns on Data Visualization](https://communities.springernature.com/posts/data-visualization-a-view-of-every-points-of-view-column) | | Day 07 | Continuation of Lecture 08: Visual Encoding; review of Assignments 5 and 6 | | | -| Day 08 | Lecture 09: Design Heuristics; presentation of Assignment 6 | | | -| Days 09 to 12 | Dataviz tools | Activity: Data Visualization Tools | Curated lists of data visualization tools, applications, libraries, and platforms. | +| Day 08 | Lecture 09: [Design Hueristics](https://info-design-lab.github.io/ID413-DataViz/files/ID%20413(2025)/09_Design%20Hueristics.pdf); presentation of Assignment 6 | | | +| Days 09 to 12 | Dataviz Tools | Activity: [Data Visualization Tools](https://github.com/info-design-lab/DE705-Interactive-Data-Visualization/issues/51) | [This is a collection](https://visualisingdata.com/resources/) of some of the many data visualisation and related tools, applications, toolkits, libraries, platforms, and packages.
    Another well-curated [list of dataviz tools](https://selection.datavisualization.ch/). | ## Assessment From 3107c6a4ff46322619a2a78a0e0908eff180da59 Mon Sep 17 00:00:00 2001 From: Varsha Venkatesh Date: Thu, 11 Jun 2026 15:23:14 +0800 Subject: [PATCH 7/7] update articles --- .../the-brief-always-arrives-wrong.md | 74 +++++++++++++++++++ content/articles/the-web-of-issues.md | 64 ++++++++++++++++ 2 files changed, 138 insertions(+) create mode 100644 content/articles/the-brief-always-arrives-wrong.md create mode 100644 content/articles/the-web-of-issues.md diff --git a/content/articles/the-brief-always-arrives-wrong.md b/content/articles/the-brief-always-arrives-wrong.md new file mode 100644 index 0000000..c242cee --- /dev/null +++ b/content/articles/the-brief-always-arrives-wrong.md @@ -0,0 +1,74 @@ +--- +title: "The Brief Always Arrives Wrong" +date: 2026-06-09 +summary: "On why the profession will not run out of work simply because machines have learned to make things." +linkedin_url: "https://www.linkedin.com/pulse/brief-always-arrives-wrong-venkatesh-rajamanickam-t7wjf/" +author: "Venkatesh Rajamanickam" +source: "LinkedIn" +--- + +{{< article-byline >}} + +

    Read on LinkedIn

    + +There is a demonstration that circulates in studios and lecture theatres, and it tends to land with the force of an argument even though it is only a performance. Someone opens a tool, types a sentence, and within seconds produces logo concepts, UI screens, a brand colour system with rationale attached. The implication settles without being stated: look what the machine can do; look what you are no longer needed to do. The conclusion; that designers face displacement; is treated as too obvious to require defending. + +The demonstration mistakes fluency for understanding, and output for work. It shows that a system trained on the residue of past design decisions can reproduce their surface appearance quickly and cheaply. It does not show that design consists principally of that kind of production, or that the situations which call for design will become less frequent because production has become frictionless. Behind this mistake is a picture of design as a fixed inventory of things to be made, waiting in a queue for a practitioner to clear it. Automate the making, and the queue empties. What remains is a shrinking perimeter, retreating with each model release. + +This picture is wrong. Working out why it fails is not a matter of professional self-reassurance; it matters because those who hold it are making decisions about hiring, education, and practice on a false account of what design actually does. + +## The Brief Is Where the Work Begins; and It Is Always Wrong + +A striking proportion of design effort is expended not on producing artefacts but on establishing what they should be. The brief that arrives on a designer's desk is typically a compressed and partially mistaken account of a situation the commissioning organisation does not fully understand. Designers do not receive problems. They help constitute them. + +A hospital once commissioned a wayfinding system for an outpatient building where patients were routinely getting lost. The brief asked for signage. A designer who investigated; walking the building with first-time visitors, watching where they hesitated, asking staff which questions patients asked most; found that the decisive problem was not the absence of signs but the position of the reception desk, hidden behind a structural column and invisible from the entrance. The most consequential design work on that project produced no designed artefact. It produced a conversation with facilities management and a modest structural change. + +This upstream work has no stable form. It does not produce something that can be evaluated by looking at it. Generative systems have no access to it because it was never documented; it lives in site visits, in conversations, in the moment a researcher watches a user hesitate for three seconds at a choice they should not have to make. That knowledge must be gathered freshly in each situation, because each situation is particular in the ways that matter. + +## Tools Have Always Raised the Stakes + +The assumption that better tools mean less work runs against everything the history of the discipline shows. When digital pre-press arrived in the early 1990s, it made multi-page layouts producible in hours rather than weeks. The expected consequence was smaller workloads. What actually happened was that clients, now aware changes were cheap, began requesting more of them. Revision cycles multiplied. Non-designers became participants in iteration because the cost of their participation had fallen. The total labour per project did not shrink; the nature of the process changed, and the amount of work in it held or grew. + +Interface design followed the same logic. When prototyping tools made clickable mockups producible without code, clients who had accepted static screens began expecting flows. Flows surfaced edge cases. Edge cases required decisions that had not been made. Unmade decisions required research that had not been done. Each increase in what could be easily produced raised the expectation of what should be demonstrated, and raised it faster than the tools advanced. The prototype that was supposed to close a conversation reliably reopened it. + +Generative AI is already exhibiting this at the concept stage. The capacity to produce twenty visual directions in an afternoon does not compress the concept phase; it expands the option space to a point where clients want to explore more of it, where disagreements a narrower set would have suppressed, now become visible and require resolution. The easier the making, the harder the deciding. Deciding is what designers are for. [1] + +The most consequential design decisions often produce no visible artefact. They produce clarity about what not to make, and why the stated problem is not the real one. + +## A Position Requires Someone to Hold It + +Much of what design produces is not objects but positions; stances taken on contested questions about what a product should do, who it is for, and what it should cost in human terms. These positions are arrived at through a process that is irreducibly social: presentations, critiques, negotiations, and the particular kind of argument [2] that happens when someone with expertise in how people experience things sits across a table from someone with authority over what gets built. + +A generative system can produce artefacts that embody a position without being able to hold that position under pressure. It cannot appear in a steering group and explain, when challenged, why a navigation structure was organised as it was, what alternatives were rejected, and what evidence supports the choice. It cannot push back when a marketing director insists on visual decisions that undermine usability, in a way that carries the weight of professional knowledge and personal accountability. It cannot be wrong in public; wrong with consequences, wrong in a way that requires understanding why. + +When a medical device causes harm because its interface was poorly designed, the accountability structures that follow name practitioners and organisations, not tools. That assumption does not dissolve when a generative system is used in the making; it extends to cover the use of the system itself. The expansion of generative tools into design practice creates new questions of professional judgment; when to accept generated outputs, when to question them, how to identify the subtle failures of contextual fit that a system optimised for statistical plausibility reliably produces; that demand more expertise, not less. + +## Most of the World Has Not Yet Been Designed + +The displacement argument assumes that design demand is currently being met; that the world has roughly the right amount of design, and that AI threatens the existing share of it. This premise is wrong by a wide margin. + +Public services in most countries operate on interfaces and communication materials that have not been reconsidered in decades. Medical devices for clinical settings are frequently produced by engineers with no usability training. Assistive devices outside the premium segment, packaging for products used by people with low literacy, agricultural equipment for smallholder contexts, emergency communication in regional languages; in each of these domains the absence of design is not neutral. It is a failure with measurable consequences for the people who live inside it. + +Design has been absent not because there is nothing to do but because the cost of doing it made it economically inaccessible relative to the budgets involved. If generative tools reduce production costs significantly, they do not reduce the need for design skill in these contexts; they potentially remove the barrier that has kept it out. Whether that opening is taken up is a question about the profession's choices and its willingness to orient towards difficult, unglamorous, high-stakes problems; not a question about whether sufficient work exists. + +## Seeing Is an Argument + +The version of displacement focused on visual production; AI can generate images, therefore image-makers are redundant; rests on a category error. It treats visual output as decoration applied to content that exists independently of it. Visual decisions in design are not decorative. They are arguments made in the register of perception. + +The choice of a typeface for a public health leaflet is a claim about the intended reader and how they should be addressed. Using photography rather than illustration in a financial context is a claim about the relationship between institution and recipient; warmth against authority, proximity against distance. The design of a data visualization is an argument about which decisions are primary, what a user under time pressure should notice first, and what can safely recede. + +Generative systems can reproduce the visual conventions associated with these decisions without modelling the argument those decisions make. An image generated for a maternal health application looks like such applications look; optimised for recognisability against a corpus, not for the specific communicative intent of this application with this population. It has no position on whether clinical authority or human warmth should lead, because it has not been told what the application needs to do to the person who opens it, and would not know how to make that intention visible in form even if it had. The judgment that translates intent into visual argument is not an addition to production. It is what makes the difference between a designed artefact and a plausible-looking one; a difference invisible in a demonstration and consequential in use. + +None of this forecloses the real difficulties ahead. Disruption to specific tasks is already happening, and it falls most heavily on those still learning; people who have not yet accumulated the contextual judgment and professional relationships that constitute the less automatable parts of the work. That is a genuine problem, and pretending otherwise helps no one. + +But task disruption is not professional elimination, and the confusion between the two is where the real damage will be done; not by the tools themselves, but by a misreading of what they threaten. A profession that responds by competing on production speed will lose, because it is the wrong competition. One that understands the disruption correctly; as a redistribution of value within practice, not a deletion of it; is in a position to respond with some intelligence: investing in the capacities that have always been hardest to develop and easiest to undervalue, taking seriously the vast territories of unmet need, and insisting on the difference between a machine that makes things and a practitioner who understands what should be made, for whom, and why. + +The brief always arrives wrong. That is not a problem that needs solving. It is a description of where the work begins. + +--- + +## Notes + +[1] The pattern: digitisation of production expanding revision cycles and client involvement rather than reducing overall labour -- has recurred with each subsequent wave of design tooling, from desktop publishing through to parametric CAD and component-based interface design. It has not been the subject of rigorous longitudinal study across the profession, which is itself a symptom of how poorly the economics and sociology of design practice are documented compared to analogous knowledge professions. + +[2] Design rationale is a synonym for argumentation. Rittel (1972) was the first to advocate systematic documentation of design rationale as part of design. He sees design problems as fundamentally open ended and controversial in the sense that there are no objective criteria for closing problem definitions and settling disagreements. Such closing and settling are necessary for design, but, for the designer, the decisions on closing and settling are judgmental and political in nature. The design rationale takes the form of a network of issues (design questions), selected and rejected answers, and arguments for and against these answers. Rittel's framework -- issues, positions, arguments -- needs to be written as an essay on its own terms rather than as a reference. My next essay [The Web of Issues](/articles/the-web-of-issues/) is precisely that. diff --git a/content/articles/the-web-of-issues.md b/content/articles/the-web-of-issues.md new file mode 100644 index 0000000..a68b472 --- /dev/null +++ b/content/articles/the-web-of-issues.md @@ -0,0 +1,64 @@ +--- +title: "The Web of Issues" +date: 2026-06-10 +summary: "On design as argumentation, and why the process is the work." +linkedin_url: "https://www.linkedin.com/pulse/web-issues-venkatesh-rajamanickam-nxo9f/" +author: "Venkatesh Rajamanickam" +source: "LinkedIn" +--- + +{{< article-byline >}} + +

    Read on LinkedIn

    + +Note: This essay began as a footnote to the previous essay [The Brief Always Arrives Wrong](/articles/the-brief-always-arrives-wrong/), and refused to stay one. + +In 1972 Horst Rittel, an architect and design theorist who had left the HfG Ulm to teach at Berkeley, published a paper that gave the profession one of its most useful and least used ideas. The paper argued that design problems are not problems in the technical sense: bounded, solvable, capable of a correct answer that can be verified after the fact. They are, in his phrase, wicked -- open-ended and intrinsically controversial, resistant to closure, reshaped by every attempt to resolve them. But Rittel did not stop at the diagnosis. What interested him was what followed from it: that because design problems cannot be closed by logic or evidence alone, the process of designing is unavoidably an argumentative process. The designer debates with herself, or with others. Issues arise. Competing positions form. Arguments are assembled for and against each position. Eventually a judgment is made; not derivable from the evidence alone, but made despite its incompleteness, under the pressure of time and the weight of the stakes involved. + +Rittel called this structure a web of issues, and he was precise about its components. An issue is a design question that has been opened and not yet closed: not "what colour should the button be"; that is a preference, answerable by convention; but "what should the primary action of this screen be, and for whom?" A position is an answer to an issue, together with the reasoning that supports it. An argument is the case for or against a position, which may raise new issues, loop back into earlier ones, or reveal that something that appeared settled was not. The web is not a diagram of a method. It is a description of what is actually happening when designers work, whether they know it or not. The process, Rittel observed, "appears as one of formation of judgement, alternating with the search for ideas." + +## The Issue That Will Not Stay Closed + +Interaction design is the field in which Rittel's web is most immediately and most relentlessly visible. Every interaction design problem is simultaneously a problem about behaviour -- what will a user do; and a problem about intent, what should we enable them to do, and what should we make difficult? Those two questions are not the same, and they do not converge naturally. The gap between them is where the design work lives. + +Consider the design of a notification system for a mobile application. The stated brief might be a technical task: implement alerts that inform users of relevant events. Open that brief five minutes into a working session and you find it is not a brief at all but a cluster of unresolved issues, each connected to others. How many notifications are too many? That depends on what the application is for and how often a user will reasonably want to be interrupted; which depends on who the user is and in what context they are using the product, which may not be the context the product team imagined. What counts as relevant? That is not a data question; it is a value question, and the product team will have different answers to it than the users will. Should the user be able to configure their own preferences, or does that merely shift the burden of a design decision onto someone who came to use an application, not to administrate one? Should the default be permissive or conservative? Each answer opens others. + +This is not failure. It is the normal condition of an interaction design problem in progress. The issues are not embarrassing gaps to be papered over; they are the actual substance of the work. A designer who moves from brief to wireframe without passing through this territory has not avoided the web; she has left its issues unexamined, where they will reappear later; in user testing, in a product review, in the support queue, in the slow decline of a feature that nobody turns off because nobody turns anything on. + +A designer who moves from brief to wireframe without passing through the web of issues has not avoided the arguments. She has merely deferred them to a point where they are more expensive to resolve. + +## Closing Is a Political Act + +The most challenging aspect of Rittel's account; and the one that sits most awkwardly with professional self-presentation; is his insistence that the closing of issues is neither logical nor neutral. It is political. When a design team decides that the notification system will default to minimal and require users to opt into more, they have not solved a problem; they have made a judgment reflecting values about user autonomy, about the relationship between product and person, about what kind of attention is worth claiming. Someone with different values would close the issue differently. Neither closure is wrong in a technical sense. Both are answerable for their consequences. + +This matters because the closing of issues does not happen in a vacuum. It happens in organisations, between people with different authority, different expertise, and different stakes in the outcome. The interaction designer sits in a room with a product manager accountable for engagement metrics, a brand strategist who wants the application to feel present in users' lives, and an engineer who knows what is and is not feasible in the sprint. All of them have a position. None is derivable from the evidence. What happens in that room; who speaks, who listens, whose framing takes hold; shapes the design. The outcome is not produced by analysis. It is produced by an argument that someone wins, or that ends in a compromise nobody fully endorses. + +Rittel saw this not as a deficiency to be corrected by better methods but as an irreducible feature of the domain. Design problems are about what should be, not merely about what is. Questions about what should be can only be answered by people with values, answerable to each other. No optimisation function can settle them. No model trained on past design decisions can resolve them, because those past decisions were themselves political closures made under particular conditions by particular people, and those conditions have changed. + +## What Gets Lost When the Process Is Skipped + +The prospect of generative AI accelerating interaction design raises a specific and serious question: what happens to the web of issues when the output arrives before the arguments have been made? This is already the mode in which many teams are beginning to use generative tools; not to assist in working through a problem but to bypass it, moving quickly from a brief to a solution that looks finished and therefore creates a psychological pressure to be accepted. [1] + +A generated set of screens for a banking application's onboarding flow will have decided; implicitly, without deliberation; how much information to request at each step, in what order, with what level of explanation offered to the user. These are design decisions. They encode a position on every issue the team has not yet opened. The danger is not that the position will be wrong, although it may be; the danger is that it will be invisible. Because the output looks resolved, the issues it has closed without debate remain closed. The team moves forward carrying the weight of decisions it did not make, toward consequences it has not examined. + +The documentation of design rationale; which Rittel advocated through his Issue-Based Information System, and which the field has approached with instruments from QOC to design history templates [2]; is precisely the record of which issues were opened, what positions were considered, and on what grounds a judgment was made. It is not bureaucratic overhead. It is the only reliable way to know, when a product fails or succeeds, what decisions produced the outcome. Without it, there is no learning; only repetition. + +## The Designer as the One Who Keeps the Issues Open + +The most important thing an interaction designer does is not to solve problems but to keep the right problems open for long enough that they can be solved well. The discipline this requires is the discipline to distinguish the issues that must be closed by argument from those that can be closed by testing, and both of those from the issues that are not yet open because nobody has yet noticed them. + +A senior interaction designer working on a government service; a tax filing interface, or a benefits eligibility assessment; is doing something structurally different from what a generative model does when it produces a UI for the same task. The model has learned from existing interfaces and will produce something that looks like they look: interfaces built by people who faced the same time pressures and political constraints, whose judgments are now embedded in the training data as though they were the natural shape of the solution space. The designer who knows that a benefit claimant arriving at a digital form has recently experienced a significant life disruption, that the form will be read by people whose first language is not English, that the consequence of a misunderstood question is not a failed submission but a months-long gap in income; that designer is not doing what the model does. She is holding open the issues that the model has already, invisibly, closed. + +Rittel's insight was that design problems have no stopping rule. There is no moment at which a design problem is objectively solved; there is only a moment at which the designer; for reasons that are practical, political, financial, or simply human; decides to stop. What makes that stopping defensible is not that all the issues have been closed but that the important ones have been opened, examined, argued over, and closed with full knowledge of what was given up. That is not a process that accelerates with better generation. It requires people who understand what they are doing and why, and who are willing to be accountable for the answer. + +The image of design that the AI displacement argument offers is of a profession organising the production of resolved solutions to understood problems. Rittel's account offers something truer and more demanding: a profession organising the argumentation that makes any resolution possible at all. The designer is not primarily a maker. She is the person who understands which questions must be answered before anything should be made, who can hold those questions open in a room full of people who want to close them prematurely, and who carries the judgment; and the accountability; for when enough arguing has been done. + +Generative systems will produce more and more plausible-looking resolutions. The profession's task is to remain the part of the process that asks whether those resolutions address the right problems, argued for the right reasons, on behalf of the right people. That task does not diminish as the generation becomes more fluent. If anything, it becomes more necessary; because fluency, unaccompanied by argument, is not design. It is the appearance of design, which is a different thing entirely, and a considerably more dangerous one. + +--- + +## Notes + +[1] The observation that AI-generated outputs render prior design decisions invisible; and that this invisibility creates pressure to accept those decisions without examination; is structurally identical to the problem Rittel identified with first-generation design methods: the illusion that a rational process can produce a determinate solution, obscuring the political judgments that shaped it. The difference is one of speed and surface finish. The problem is the same. + +[2] Rittel's Issue-Based Information System (IBIS) was developed together with Werner Kunz and first published in 1970, with the argumentative model of design reasoning elaborated through the 1970s and formalised in "The Reasoning of Designers" (1987, published Stuttgart 1988). The IBIS notation; issues, positions, arguments; was subsequently implemented in digital form as gIBIS (Graphical Issue-Based Information System) in the late 1980s and influenced the design rationale research programme that extended through the 1990s, producing tools including QOC (Questions, Options, Criteria) and a substantial body of work on how design reasoning is documented, or fails to be. The core insight; that the argumentation is the process and the rationale is its record; remains largely unimplemented in mainstream practice, which continues to document outputs rather than deliberations.