When Your First Visualization Fails: Lessons from Exploring 2,600 Languages

[embed]embedded link to the Story

I started my information visualization project with what seemed like a straightforward question: What are the dominant word order patterns across the world’s languages?

The Problem with Perfect Charts

My initial visualizations were technically perfect. Clean bar charts showing SOV (Subject-Object-Verb) and SVO (Subject-Verb-Object) word orders dominating globally. Neat frequency distributions by language family. Everything properly labeled, color-coded, and easy to read.

They were also completely useless.

The problem wasn’t the execution. It was the question. I was asking “what is most common?” when I should have been asking “what is interesting?” As Munzner describes in Visualization Analysis & Design, choosing the right task abstraction is fundamental. My visualizations were answering the wrong task entirely.

The data was screaming the linguistic equivalent of “water is wet.” Yes, most languages follow SOV or SVO order. This is well-established in linguistics. My beautiful charts were just visualizing what everyone already knew.

Visualization of documented languages and their word orders

Shifting Focus

Staring at my seventh iteration of essentially the same bar chart, I noticed something in my exploratory heatmap: the Papunesia macroarea (covering Papua New Guinea, Indonesia, and the Pacific islands) had an unusually diverse distribution of word orders. Unlike other regions that showed clear dominance patterns, Papunesia had meaningful representation across almost every category.

This was the moment my project actually began.

I shifted my entire analytical frame:

• Old task: “Present known patterns” vs. New task: “Discover anomalies”
• Old scope: Global distributions vs. New scope: Regional deep dive
• Old question: “What’s normal?” vs. New question: “What breaks the rules?”

This pivot required more than just filtering the data differently. It meant rethinking what the visualization was for. I was no longer creating a reference chart. I was building an investigative tool.

Redefining Outliers

Once I committed to focusing on outliers, I hit an immediate technical barrier: how do you define “outlier” in a way that’s both meaningful and implementable?

My first instinct was to flag languages whose word order diverged from their language family’s dominant pattern. This would have been elegant, showing which languages were syntactically unusual relative to their linguistic neighbors.

Tableau said no.

The tool doesn’t support dynamic mode calculations, and implementing this comparison was beyond my technical skill level at the time. This is where tool limitations force creative compromises. I couldn’t compute what I wanted, so I had to reframe the question entirely.

Instead, I defined outliers simply: the rarest word orders in Papunesia. Specifically OSV, OVS, VOS, and “No dominant order.” This was less sophisticated analytically, but it had a crucial advantage: it was visually intuitive. Users didn’t need to understand what “deviation from family mode” meant. They could see immediately that these word orders appeared in only 1–9 languages each, compared to 145+ for the common orders.

Sometimes the best visualization isn’t the most complex analysis. It’s the clearest story.

Walking the user through filtering for least common word order

User Testing

I thought my visualization was pretty clear until I watched two classmates try to use it.

Test Task 1: “Find the language with the least common word order in Papunesia.”

Both participants succeeded. They identified “6 OSV” as the rarest. But the process revealed problems I hadn’t noticed:

• One participant was confused by my numerical labels (“4–7” for word order types). What seemed like clean categorical coding to me looked like arbitrary numbering to them.
• Another jumped straight to the end of my Tableau Story, expecting interactive filtering that didn’t exist.
• The “81A” prefix in my field names (inherited from the WALS dataset) was pure visual clutter to anyone not familiar with linguistic feature coding.

Test Task 2: “Use the map to locate where the rarest word orders appear. What do you notice about their geographic locations?”

This is where things got worse. One user didn’t even see the full instructions because they were hidden below the scroll line in my story panel. The other wanted quantitative feedback. They kept asking “How many is this?” when hovering over map points, wanting to understand just how rare these patterns actually were.

These were simple, fixable problems. But they taught me something crucial: as a designer, you’re the worst person to evaluate your own work. I had spent weeks with this data. The “81A” prefix was invisible to me. The scroll requirement seemed obvious. The rarity of certain categories was internalized knowledge.

My users had none of that context.

Here is where they had the opportunity to filter for themselves if they wanted

Small Changes, Big Impact

The revisions I made in response to user testing were almost embarrassingly simple:

1. Removed “81A” from all field labels (Reduced cognitive clutter)
2. Resized story panels to eliminate scrolling (Made instructions visible)
3. Changed layout from “Fixed” to “Automatic” sizing
4. Added a static text box listing exact word order counts (Gave users a reference for “rare”)
5. Reworded instructions to define rarity as “bottom 3–4 word orders” (Helped users focus on meaningful subsets)

None of these changes altered the underlying analysis. They didn’t make new insights appear. But they transformed the accessibility of those insights. This is the difference between a visualization that works in theory and one that works in practice.

Story vs. Dashboard

One of the most interesting design choices I made was using Tableau’s Story feature instead of creating an interactive dashboard. This decision shaped the entire user experience.

A dashboard says: “Here’s the data. Explore it yourself.”

A story says: “Let me show you what I found.”

For this project, I needed the latter. I wanted to walk users through my own process of discovery:

1. Overview: Global distribution of word orders (establishing baseline)
2. Zoom: Heatmap showing Papunesia’s unusual diversity
3. Filter: Table of word order frequencies in Papunesia
4. Focus: Unfiltered map of the region (setting up the reveal)
5. Insight: Filtered map showing only rare word orders clustered in isolated coastal/island areas

This sequence follows Shneiderman’s mantra of “overview first, zoom and filter, then details on demand,” but with a deliberate narrative progression. Each view built on the previous one, gradually narrowing focus until the pattern became visible.

The tradeoff? Less interactivity. Users couldn’t freely explore or test their own hypotheses. But they got something arguably more valuable: a guided tour that made the central insight almost impossible to miss.

What I Learned

This project forced me to confront several fundamental principles from Munzner’s framework:

1. Idiom Must Match Task

My early bar charts were perfectly encoded (position on a common scale, clear categorical grouping). But they were solving a “lookup” task when I needed a “discover anomalies” task. The idiom was technically correct but conceptually wrong.

2. Expressiveness Isn’t Everything

The matrix heatmap showing word orders across macroareas used color hue and presence/absence rather than precise quantitative encoding. It was less “expressive” in the formal sense (you couldn’t read exact values). But it made the pattern (Papunesia’s diversity) immediately visible. Sometimes approximate visibility beats precise invisibility.

3. Tool Constraints Shape Design

I had to work around Tableau’s inability to do dynamic frequency filtering. This forced me to use static text annotations and simplified definitions of rarity. These weren’t my first choices, but they led to a clearer narrative. Constraints can be creative catalysts.

4. Consumption vs. Presentation Matters

I wasn’t building an exploratory tool for linguists to use in their research. I was presenting a specific finding to a general audience. That fundamentally changed how I structured the information, how much control I gave users, and how much scaffolding I provided.

The Finding

Here’s what’s funny: I spent most of this article talking about visualization design, and barely mentioned the actual finding.

The final visualization revealed that rare syntactic structures in Papunesia (OSV, OVS, VOS word orders) appear disproportionately in geographically peripheral areas: remote coastlines, isolated islands, and archipelagos. The hypothesis this suggests is that geographic isolation may contribute to syntactic divergence.

It’s a tentative finding that would need much more rigorous testing. You’d want to control for population density, language contact patterns, colonization history, and topography. You’d want to test if the pattern holds in other macroareas. You’d want actual statistical validation.

But here’s the thing: I would never have seen this pattern without the visualization.

Looking at the raw data table, or even at summary statistics, this geographic clustering isn’t obvious. It emerged through the process of visual encoding, specifically through the spatial position of points on a map, filtered by a categorical attribute.

This is what visualization does. It makes patterns visible that would otherwise remain hidden in the data.

Looking Back

If I were starting this project over, knowing what I know now:

I’d fail faster. I spent too long polishing my initial global visualizations before admitting they weren’t working. The sooner you can recognize that a visualization isn’t serving its purpose, the sooner you can pivot.

I’d test earlier. User testing revealed fixable problems that I could have caught weeks earlier. Even informal “can you tell me what you see here?” sessions with classmates would have helped.

I’d embrace tool limitations sooner. I wasted time fighting Tableau’s constraints instead of working with them. The workarounds I eventually found (static text boxes, simplified rarity definitions) weren’t ideal, but they worked. Sometimes good enough is actually good enough.

I’d think about the story arc from the beginning. I created individual visualizations first and assembled them into a narrative later. Starting with “what’s the story I want to tell?” would have given me better direction for which views to create.

Final Thoughts

Information visualization courses often focus on technical skills: which chart type to use, how to encode data, when to use color. These are important. But the deeper lesson (the one that only emerges from doing an actual project) is about design thinking.

You have to be willing to throw away work that isn’t serving its purpose, even if it’s technically correct. You have to watch real users struggle with your design and resist the urge to defend it. You have to work within tool constraints creatively rather than fighting them stubbornly. And you have to remember that the goal isn’t to make a beautiful chart. It’s to make insight visible.

My project started with a simple question about word order patterns. It ended with a tentative hypothesis about geographic isolation and linguistic diversity. But what I actually learned was how to think like a visualization designer.

Final page of my Tableau Story showing the least common word orders in this Macroarea

The full interactive visualization is available on Tableau Public.

The dataset used is from the World Atlas of Language Structures (WALS).

References:

• Munzner, T. (2014). Visualization Analysis & Design. CRC Press.
• Heer, J., Bostock, M., & Ogievetsky, V. (2010). A tour through the visualization zoo. ACM Queue, 8(5), 20–30.