Labs / Chapter 9
Chapter 9 argues that prompt cartography does not remove design responsibility. It amplifies it. In this lab, you will expose the defaults an LLM wants to use, then replace them with a deliberate specification for the map elements that guide interpretation.
Chapter 9 treats map elements as design commitments that must be named in language. This lab trains you to catch the silent choices an LLM makes by default and replace them with an explicit map elements specification.
Choose one thematic web map scenario. Use a topic that can support real interpretation but does not require paid tools or specialized software.
Map mission Topic: Place: Audience: Main question the map should answer: Data resolution or likely data resolution: What users should compare: What users should not infer: Tone and level of urgency:
Begin with an intentionally underspecified prompt. This creates a baseline you can critique.
Create an interactive web map concept for this mission. Include the title, legend, controls, layout, and any other map elements you think are appropriate. Map mission: [PASTE]
Then ask the LLM to make its hidden assumptions visible.
Explain every design assumption you made about this map. Use this table: - title and framing - mapped area and default extent - zoom and pan behavior - interface controls - visual hierarchy - layout system - legend purpose - insets or locator maps - any assumptions about audience, data resolution, uncertainty, or interactivity For each row, explain why you made that assumption and what could go wrong if it is inappropriate.
Titles do two jobs in prompt cartography. They orient human readers and they condition the LLM as it builds the map. Write both.
Create five possible human-facing titles and five model-facing framing lines for my map mission. The human-facing titles should be concise and rhetorically clear. The model-facing lines should be more directive and explicit about scope, audience, tone, and the intended comparison. For each pair, explain what interpretation it invites and what interpretation it discourages.
| Human-facing title | Model-facing framing line | Invites | Discourages |
|---|---|---|---|
| Example: Short note | Example: Short note | Example: Short note | Example: Short note |
| Example: Short note | Example: Short note | Example: Short note | Example: Short note |
| Example: Short note | Example: Short note | Example: Short note | Example: Short note |
Starter examples only; expand this in your own notes or submission document.
Now define where the map's meaning holds and where it breaks down. Be especially strict when your data are aggregated to counties, census tracts, neighborhoods, or regions.
Help me write an extent and zoom policy for this map. The policy must explain: 1. the intended mapped area 2. the default opening extent 3. the smallest scale at which comparisons remain meaningful 4. the deepest zoom level users should be allowed to reach 5. whether panning should be constrained and why 6. what false precision or interpretive harm might occur if zoom and pan are unrestricted 7. one sentence that could be shown to users if the extent requires explanation Map mission: [PASTE]
Interface elements are promises. A filter, slider, search box, or layer toggle implies that the data can answer a question. Keep only the controls that earn their place.
| Possible control | User question implied | Can the data answer it? | Risk if included | Verdict |
|---|---|---|---|---|
| Filter | Example: What changed recently? | Example: Mostly | Example: Could overstate certainty | Keep / revise / reject |
| Temporal slider | Example: What changed recently? | Example: Mostly | Example: Could overstate certainty | Keep / revise / reject |
Starter examples only; expand this in your own notes or submission document.
Review these possible interface controls for my map. For each, identify the user question it implies, whether the likely data can answer that question, accessibility considerations, and whether the control should be kept, revised, or rejected. Map mission: [PASTE] Possible controls: [PASTE TABLE OR LIST]
Visual hierarchy is the reading order of the map. Translate that order into language before the model chooses it for you.
Write a visual hierarchy directive for my map. Specify: - what must dominate first - what users should notice second - what should remain available but visually subordinate - how the title, legend, controls, annotations, and supporting text should behave - which elements must never compete with the mapped data - how contrast, size, opacity, and placement should support the reading order Return the directive as a concise reusable paragraph.
Check the directive by asking the LLM to identify what will likely dominate visually if your paragraph is followed.
Decide whether the map should feel fluid and immersive or compartmentalized and analytical. Then specify stable zones and mobile behavior.
Recommend a layout grammar for this map: fluid, compartmentalized, or hybrid. Explain the choice in relation to the audience and task. Then provide a layout specification that includes: - desktop zones - mobile zones - where the legend lives - where controls live - whether panels may cover the map - what remains fixed during interaction - what may collapse or recede - how empty space should be used Map mission and interface verdicts: [PASTE]
Legends and insets should clarify meaning. They should not merely make a map look complete.
Design the legend and inset policy for my map. The legend must be explanatory rather than an inventory list. Specify whether it should explain classification logic, units, uncertainty, high/low meaning, missing data, or limitations. Then decide whether an inset is needed. If yes, state the exact question the inset answers. If no, explain why omitting it improves clarity. Map mission: [PASTE] Extent policy: [PASTE]
| Element | Question it answers | Required content | Prominence | Decision |
|---|---|---|---|---|
| Legend | Example: Short note | Example: Short note | Example: Short note | Example: Use the simpler option |
| Inset | Example: Short note | Example: Short note | Example: Short note | Use / omit |
Starter examples only; expand this in your own notes or submission document.
Combine the previous decisions into a reusable directive that can be pasted into any prompt-built mapping pipeline.
Compile my decisions into a Map Elements Specification. Use these headings: 1. Human-facing title 2. Model-facing framing line 3. Mapped area and extent 4. Zoom and pan policy 5. Interface controls to include 6. Interface controls to exclude 7. Visual hierarchy 8. Layout grammar 9. Explanatory legend 10. Inset policy 11. Accessibility and user guidance 12. Defaults the model must avoid Write this as a professional design specification, not as a chatty explanation.
Run the specification in a new chat by asking for a revised map concept. Then ask for one final critique.
Critique this map concept against the Map Elements Specification. Identify any remaining default-driven choices, missing constraints, or elements that look complete but do not explain enough. Recommend a minimal revision.
Quick human check before this leaves your desk.
Do the tiny-but-mighty judgment check. If these answers are fuzzy, revise the map idea before polishing the prompt.
For use with Prompt Cartography: Interactive Web Map Design with LLMs, CRC Press. www.promptcartography.com
Prompt Cartography