Your final project simulates a client relationship: you develop a requirements document, interact with a stakeholder who wants this visualization, and turn in a final project. This mirrors the situation you’ll actually be in after graduation. A client usually knows their domain and doesn’t know visualization design. What they ask for is not always what they need, and the criteria they judge you on are not always the criteria they stated up front. An LLM can produce a competent chart from a vague prompt in minutes; it cannot decide whether that chart answers the client’s real question or mixed signals, and it cannot push back when the client is wrong about what they want. That judgment — specifying a requirement precisely, reconciling what a simulated client told you with what a real client thinks, and deciding when to push back on either one — is what this project grades.

Project Team Assignment

You will work in a 2 person project team (3 person teams allowed but discouraged). You can form your own team and use the class Slack to find teammates; if you can’t find a team we will assign you to one. The real world requires collaboration, but if your schedule genuinely requires working alone, ask us for permission.

Announce your team by the date on the schedule — we need every team locked in before Phase 4, when we assign each team a peer client to review for.

Project Phases

The project runs in five phases. Each phase produces a written artifact that is committed to your team’s GitHub repository, timestamped by the commit itself.

For due dates, see the schedule. No extensions will be given on these dates for any reason.

1. Requirements Documentation

Choose a topic and dataset for your project, then develop your requirements document by interviewing an LLM through at least three distinct stakeholder personas grounded in your topic — for example, an executive sponsor, an end user, and a domain expert. Ground each persona in a real question and a real stake in the answer, not a generic “make a dashboard” request, and interview each one separately, the way you’d interview different stakeholders at an actual client organization: ask what they’re trying to learn, who else will look at this, what would make the visualization useless to them. Push back on vague answers; a persona who says “just make it look professional” hasn’t told you anything, and you should keep asking until they have.

Your personas will not agree with each other. Commit all of the interview transcripts to your repository, then write the requirements document as a single, coherent synthesis of what you heard — not a transcript dump, and not just the easiest persona to satisfy. The document should include:

  • The real need. Not “a dashboard of X” but the question your stakeholders are actually trying to answer and why it matters to them. If any persona can’t articulate the underlying need, keep interviewing.
  • Audience. Who this is for — your personas and anyone else who’ll see it — and what each already knows.
  • Data. The dataset you’re using, with provenance (source, collection method, known gaps or biases). If you’re sourcing your own data, document how.
  • Where personas conflicted. Where two personas wanted different or incompatible things, say so explicitly: what each wanted, and how you decided what the design should actually prioritize. This is the most important part of the document — it’s the reconciliation work a real requirements process requires, and it’s what a designer who only interviewed one stakeholder wouldn’t have had to do.
  • Must-have vs. nice-to-have. What makes the design a failure if it’s missing, versus what’s welcome but not critical, after that reconciliation.
  • Acceptance criteria. The specific, checkable criteria this document’s client would use to judge the final design. Write these from the interviews, before you’ve designed anything — they are what you will be held to in Phase 4, when a real client reads this same document.

A TA will review requirements documents. A requirements doc that just says, e.g., “make it look good” will be sent back, whether that phrase came from you or from an LLM persona you interviewed.

Deliverables: requirements document, LLM client interview transcripts (one per persona).

2. Design & AI Critique

Build your first-round design against the requirements document from Phase 1. You should be building at least 3 variants of the design (one per team member, plus one as a team). You may use an agent for ideation, data wrangling, and implementation — this is expected, not a shortcut you need to hide.

Once you have a working first drafts, subject them to a structured critique from an agent: give it your requirements document and your design, and ask it to assess the design against each stated criterion. Agents are unreliable critics — sometimes precise, sometimes confidently wrong. Commit the full critique transcript, then write a reconciliation: for each point the agent raised, state whether you agree, and if you disagree, say why. Your grade here is on the quality of that reasoning, not on how much of the agent’s feedback you accepted.

This reconciliation is what you’ll use to synthesize your first full design in Phase 3.

Deliverables: initial designs, AI critique transcript, reconciliation.md.

3. Redesign from AI Review

As a team, select one of your Phase 2 design variants to move forward with — or combine elements of several — based on your reconciliation with the AI critique, not on the raw agent output. This is redesign round one, driven by the AI review, not by a human. Commit the result as v1.

Alongside v1, write a redesign rationale: for each point in your Phase 2 reconciliation, say what you changed in response (or why you didn’t), and separately, note any other changes you made that weren’t prompted by the AI critique at all — a rethought encoding, a scrapped idea, a decision one of your interview personas would have wanted — and why you made them. This is where “we used an agent” stops being a sufficient answer to “why does v1 look like this.”

Deliverables: v1 (synthesized design), redesign_rationale.md.

4. Peer Critique

Your assigned peer client team reads your Phase 1 requirements document and your v1 design, and reviews the design against the acceptance criteria in that document — standing in for the client you interviewed, but now with independent human judgment. They may notice that the LLM’s stated criteria don’t actually add up to a coherent need, or that a “must-have” doesn’t serve the goal it was attached to. They commit a structured critique addressed to you.

Deliverables: peer client’s critique.

5. Final Submission

Respond in writing to each point in your peer client’s critique — implement the change, propose an alternative, or push back with a reasoned justification for why you’re not making the change. Pushing back is not a way to avoid work — it is a deliverable in its own right. If your peer client’s request doesn’t actually serve the need documented in Phase 1, say so and explain why, in writing, before you decide whether to comply. If your peer client thinks the Phase 1 document itself got the need wrong, that’s worth writing about too. Your peer client can accept or contest each response in a short reply.

Revise your design based on this exchange. This revision is redesign round two, driven by human feedback, and produces your final design (v2).

Then deliver the finished visualization and submit your project. Store the following in your team’s GitHub repository:

  • Code — all site files and libraries, unless too large to include.
  • Data — the dataset(s) used, or a link to where they’re stored if too large for the repository.
  • Design history — v1 and v2 (or code of each), with the reconciliation, redesign_rationale.md, and critique documents from Phases 2 through 4, plus your written response to the peer critique and the reasoning behind this final revision. This is your record of how the design changed and why — it is graded as heavily as the final design itself.
  • AI use disclosure — a short statement of what an agent produced at each phase, and what you changed and why.
  • Screencast — a two-minute narrated screencast demoing your final visualization: what it shows, how to use it, and the single most important thing you’d want an audience to take away. Upload it to YouTube, Vimeo, or a similar platform and link it from your README. We will strictly enforce the two-minute limit, so lead with your strongest point rather than building up to it.
  • README — an overview of what’s included, which parts are your code versus libraries, a link to your hosted site, a link to your screencast, and an explanation of any non-obvious interface features.

Host your visualization on GitHub Pages and link it from your README. If you can’t publish your work (e.g. due to confidential data), say so in your Phase 1 requirements document.

Grading

The majority of your grade is on the reasoning and revision that produced your final design, not on the final design in isolation.

  • Requirements documentation — 10%. Is the need concrete, the acceptance criteria checkable, the data provenance stated? Do the interviews show you pushing each persona past vague answers, and does the document reconcile conflicts between personas rather than ignoring them?
  • Initial design & justification — 20%. Does the v1 design address the stated requirements, with visual encoding choices justified by the design and perceptual principles from this course?
  • AI critique reconciliation — 15%. Quality of reasoning about each point of AI feedback, not agreement with it.
  • Peer critique response — 15%. Quality of the designer’s response to the peer client’s critique, including the reasoning behind any pushback.
  • Design improvement across rounds — 30%. Comparing v1 to v2 against the Phase 1 acceptance criteria: did the design actually get better at answering the documented need?
  • Implementation quality — 10%. Is the code reasonably robust and readable? This is a minority of the grade — a well-reasoned design in a rough implementation is worth more here than a polished implementation of a poorly-reasoned design.

AI Use

Agents are allowed and expected throughout this project — to interview as your client in Phase 1, for ideation, data wrangling, and implementation, and for the structured AI critique in Phase 2. What is graded is not whether you used an agent but what you did with its output: whether you can tell when it’s right, when it’s confidently wrong, and what you changed and why. Each phase’s deliverables should include a brief, honest note on what an agent produced and what you did with it.