# how to improve cartography *Article written by Marketa Beitlova and Stanislav Popelka, coordinated by the DIG-IT team* With the framework of DIG-IT project, we had the opportunity to get a very precise analysis from Stanislav Popelka and Marketa Beitlova, who are both cartographers at Czech universities. They led eye-tracking testings and made observational analysis, identified weaknesses and proposed easy tips to solve them, for more user-friendly maps. ## Map load Map load refers to the overall quantity of content elements shown on a map – including symbols, lines, areas, labels, and text. It indirectly reflects how detailed and how legible the map is. If the map load exceeds a certain threshold, the map becomes difficult to read, and its usability decreases, because users must work harder to separate important information from visual noise. Map load is strongly influenced by: * the number of symbols in the legend * the number of labels * the typographic choices (font size, type, and style) It is also helpful to distinguish between graphic content (visual elements such as lines, areas, icons) and informative content (text, labels, descriptions), as both together determine how demanding the map is for the reader. ### Quick tips: How to balance map load * **Use colour wisely**: choose calmer, lighter backgrounds in dense areas to avoid visual overload. * **Simplify where you can**: reduce textures, avoid unnecessary detail, and limit the number of labels. * **Choose symbols that don’t shout**: use simple, balanced icon styles rather than highly decorative ones. * **Accept what you can’t change**: a dense medieval street network will always look busy—focus on the elements you can adjust. * **Test the map early and quickly**: show a prototype to a few people for immediate impressions. * **Validate with tools**: use the map-load tool and short user tests to check that the map feels readable, not crowded. * **Aim for clarity, not emptiness**: The goal is a map that feels organised and pleasant, not stripped of useful information.
## Legend The legend of a map indicates the meaning of the symbols it contains. It should follow a few principles: * **Clarity**: the legend should be immediately understandable for any reader, even someone who is not used to reading maps. Each symbol and label must clearly communicate what it represents, without requiring the user to guess or repeatedly go back and forth between the map and the legend. * **Simplicity**: Descriptions in the legend should be as brief and concise as possible. Use short names instead of long phrases, avoid redundant wording, and don’t introduce more categories than necessary; every extra line in the legend adds to the cognitive load. * **Independence**: The composition of symbols and the overall structure of the legend should be logically independent and non-overlapping. Categories must be clearly distinguished; for example, you should not have both “Restaurant” and “Vegan restaurant” as separate main categories if the map already treats them as one type of place to eat. In that case, use a single general class (e.g., “Food & drink”) and express details in the label or description, not by multiplying symbols. * **Orderliness**: The legend should be logically organised into clear groups (e.g., Food & drink, Culture & sights, Nightlife, Practical info, Transport). Within each group, arrange symbols in a consistent order (for example, from most important to least, or from general to specific), so that users can quickly scan and find what they need. * **Completeness**: Everything that appears on the map must also appear in the legend, and nothing should be in the legend that is not used on the map. Missing symbols force users to guess; unused symbols create confusion and raise questions about what they might represent. * **Consistency**: Symbols in the legend and on the map must be identical in shape, size, colour, and style. Even small differences (slightly different shades, changed line thickness, or altered icon size) weaken recognition and slow down reading. Once a visual solution is chosen for a category, it should be applied consistently across the entire map.
### Quick tips: How to build a legend that helps * **Make symbols intuitive**, not mysterious: Use shapes people already associate with a place, like cups for cafés, trees for parks, beds for accommodation. Avoid abstract icons that force users to guess. * **Keep similar things looking similar**: use one basic icon family and small variations for subtypes. Do not colour two unrelated categories almost the same. * **Stick to one clear visual language**: same symbol = same shape, colour, and size everywhere. No exceptions. * **Show only what you actually use**: everything on the map must be in the legend, and nothing should appear in the legend without appearing on the map. * **Place the legend where people can find it**: a good legend is useless if users struggle to locate it. * **Use compressed symbols only when they truly help**: a well-designed composite symbol can save space and communicate more at once—but too much detail creates clutter.
## Labels ### Quick tips: How to make labels easy to read * **Stick to one main font**: use a single clear typeface (plus maybe one variant for emphasis) so the map doesn’t look chaotic. * **Reserve italics for water**: label rivers, streams and lakes in italics so people instantly recognise hydrological features. * **Set a minimum text size**: decide on the smallest point size that is still readable on paper and screen, and never go below it. * **Follow the line, not the reader’s neck**: place labels along roads, rivers or tram lines so they read left-to-right and are never upside down or heavily tilted. * **Keep labels off important geometry**: do not let text sit on top of borders, junctions, tram tracks or other key details; shift or curve the label so the map content stays visible. ## Colour Colour use is one of the most distinctive features of USE-IT maps — but also a frequent source of confusion. ### Quick tips: How to select proper colors * **Use colour as style, not as noise**: decide what kind of “feel” the map should have (vintage, pop-art, seasonal, nature-based, mood-based) and build a limited palette around that. Avoid adding new colours ad-hoc for every idea. * **Prefer qualitative colours over quantitative scales**: USE-IT maps are not thematic or statistical maps, they are categorical, focusing on types of places (food, nightlife, culture, parks, transport). * **Limit the number of strong colours**: too many saturated colours overwhelm users. Keep 2–3 main accent colours for categories and use softer, lighter tones for backgrounds and dense city centres. * **Always protect contrast and legibility**: Make sure streets, labels and icons clearly stand out from the background. If users can’t distinguish streets from other elements, the contrast is too low → lighten the base map, darken the lines, or desaturate the background. * **Use colour consistently for categories**: assign each main category (food, nightlife, culture, practical, parks, etc.) a stable colour and repeat it in symbols, legend, and text markers. Don’t reuse the same colour for unrelated things. * **Avoid over-segmentation by colour**: too many tiny coloured segments or micro-categories confuse people. Group similar things under one colour (e.g. all food under one hue family) and differentiate details with icons or labels, not with yet another colour. * **Test the palette with real users**: do a quick check: print or export the map and ask a few people, “Is anything hard to see or too loud?” If they mention specific colours or zones, adjust saturation/contrast accordingly. If you want to know more on who to improve your cartography, we recommend you to read this super detailed manual written within the framework of DIG-IT project: {% hint style="success" %} *READ MORE*\ → [How to improve your cartography](https://drive.google.com/file/d/1LZ2AKwlzBpYgVBUoEJ3NPuLVfr2sW9Jm/view?usp=sharing), a manual by DIG-IT team {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://use-it.gitbook.io/use-it-wiki/map-design/cartography/how-to-improve-cartography.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.