When I signed up for HCDE 519, a qualitative research methods course, I figured I would walk away knowing how to run a decent interview and code a transcript without losing my mind. I did learn that. But the part that stuck with me was the topic my team picked: what happens to product managers when generative AI starts showing up as a coworker.

It is a strange moment to be a PM. Something like 78 percent of tech companies are already poking around with AI internally, and a majority say they plan to bake it into how their people work. PMs sit right in the middle of that shift. Their whole job is to translate between design, engineering, and the customer, and suddenly there is a tool that can draft, summarize, and reformat all of that in seconds. So my group asked a simple sounding question that turned out to be anything but:

How does adopting generative AI in a PM’s day to day actually redefine their role and reshape how they work with their teams?

Here is what we found.

How we did it

We kept the method honest and small. Five product managers, all based in the US, spread across different sectors and different stages of their careers, from early career to senior. We ran semi-structured interviews over Zoom, each one running about 45 to 60 minutes. We started with a pilot interview to shake out the bad questions, then did our main round.

That pilot humbled me more than I expected. I went in with a protocol I was a little proud of, and within ten minutes I watched my carefully worded questions produce pretty uninteresting answers. The ones that actually opened people up were the plain sounding follow ups: “can you walk me through the last time you did that?” I came out of it having rewritten half my questions, and with a new respect for how much of good interviewing is just active listening.

The fun and slightly painful part came after. We coded everything collaboratively using Taguette. To cut down on bias, each of us analyzed a transcript from an interview we did not personally run, so I spent my first real coding pass inside a conversation a teammate had led, which forced me to read closely instead of leaning on what I remembered hearing. Then we sat together, argued politely about what each code meant, and slowly merged our messy individual codebooks into one shared codebook. This part was harder than the interviews. I learned that two people can read the same sentence and tag it completely differently, and that the disagreement is the point, not a problem to rush past. Talking through why we each saw it differently usually produced a sharper code than either of us started with. We sorted everything into five buckets: role, changes, challenges, feelings and opinions, and tool usage. Out of that came the themes I am about to walk through.

The tools our participants reached for most often will not surprise anyone: ChatGPT, Claude, Gemini, Copilot, and a handful of internal company tools.

Finding 1: AI is a first draft machine

The clearest pattern was that PMs use AI to start, not to finish.

Almost everyone we talked to works inside strict document templates. Funding docs, one pagers, product requirement documents, each with its own required format and tone. AI turned out to be great at getting them off a blank page. One participant described uploading a transcript and notes and getting a structured one pager from their template back in about a minute, then editing from there. As they put it, starting from scratch was not their strong suit, and a tool that hands you a solid launch point changes the whole rhythm of the work.

The more sophisticated users were not just typing requests. They were engineering reusable prompts with formatting rules, tone guidance, and personas baked in, so the AI would mimic their company’s house style without being told every single time. One PM built a persona with a standing list of instructions so they did not have to repeat “follow the style guide” on every prompt.

The second half of this finding was about communication, not documents. PMs used AI to tailor a message for a specific audience and to pressure test it before sending. One person described stressing over the wording of an email to a vice president, then asking AI to rewrite it through a persona to make it land better. Another used it almost like a sparring partner, asking what questions a particular type of leader might raise and what resistance to expect.

Finding 2: Faster, yes. Hands off, absolutely not.

Everyone agreed AI sped up the boring parts. The repetitive, low brainpower work of formatting to spec and filling out routine docs got dramatically faster. One PM said it well: same responsibilities, same tasks, just done more quickly, which freed them up to focus on the actual substance of what they were trying to communicate.

But speed came with a tax, and the tax was judgment.

Generative AI does not know the context that lives in a PM’s head. It does not know the hallway conversation from last week or the decision the team already made and moved past. So our participants spent real time correcting tone, clarifying context, and reining the model back in when it started optimizing for the wrong thing. One person described how a single unclear detail in a prompt could send the whole output sideways, with the AI trying to solve problems that were already solved or were never in scope.

And then there is the trust problem. A few participants brought up hallucination directly. The fear was not that the AI is wrong, it is that it is confidently wrong. As one PM put it, the model fills gaps in its knowledge with whatever it thinks is a good answer, and if you are not deeply familiar with the content, it is genuinely hard to catch when it has made something up. That is the part that keeps a human firmly in the loop.

Finding 3: Ownership

PMs are not handing their work over to AI, and they are very deliberate about it. They have landed on a hybrid model: use AI for efficiency, not for automation. The traditional manual process was slow, but it gave them a deep sense of authorship and a real command of the material. They are not willing to trade that away.

One participant gave us the cleanest definition of ownership I have heard. For them, owning a piece of work meant being able to answer roughly 90 percent of any question someone might ask about it. That is the bar. And they noticed something: the more you lean on AI to create something, the less ownership you tend to feel over it. So they stay on top of that tension on purpose instead of pretending it is not there.

PMs see their value in knowing their work well enough to stand behind every decision in it, and they are protecting that on purpose.

Finding 4: The role is getting bigger

The last theme was about how the job description is shifting.

Several participants described brand new responsibilities layered on top of their existing workload. The standout example was the “AI ambassador,” a real role one participant held. It was a top down initiative where leadership tapped one ambassador per team to run lunch and learns, share prompts and policies, demo what good usage looks like, and help everyone else get comfortable. New expectations were showing up too, like accounting for accuracy, testing, and baseline metrics, partly to secure funding and partly to measure whether the AI is actually helping.

Underneath the formal stuff was something more grassroots. Without any real training, PMs are learning AI socially. Nobody emailed them a manual. As one participant described it, the message from leadership was basically “we found this thing, go experiment, figure it out, and share what you learn.” So people swap tips in team meetings, in one on ones, in Slack channels, and on LinkedIn. They are writing the best practices together.

So what should AI tools actually do about this?

Because this was a design course at heart, we did not stop at observations. We turned the findings into recommendations for anyone building AI tools for knowledge workers. Four of them stood out.

Offer a “learning mode.” Tools should recognize recurring task patterns and proactively suggest context aware prompts. Think fill in the blank prompt builders that nudge users to include audience, tone, objective, and constraints. This lowers the barrier for less experienced users and makes the output better on the first try.

Show your work. Source transparency and explainability matter a lot when trust is the bottleneck. If a tool can surface its reasoning and where its information came from, PMs can validate accuracy before they stake their name on it.

Protect human ownership. Tools should augment, not replace. A small move like occasionally asking “do you understand why this was suggested?” keeps the person engaged and reinforces their sense of authorship instead of chipping away at it.

Make space for the conversation. Since so much learning happens informally, organizations benefit from a central place for it. A simple internal hub covering why to use AI, the guidelines and data policies around it, and a library of prompts and FAQs can turn scattered experimentation into shared knowledge.

What I would do differently

If I had more time, I would push this further. The obvious next step is longitudinal work, tracking the same PMs over two or three years to see how the role really settles, because right now we are catching a snapshot of a fast moving target. I would also love to shadow people and watch how they actually use AI in the moment, rather than relying only on how they describe it. And I would widen the net to include more industries, more company sizes, and especially veteran PMs with 15 plus years in the role, along with people in slow moving, heavily regulated fields who are probably adapting in completely different ways than the agile tech crowd.

I also want to be honest about what five interviews can and cannot tell you. With a sample this size, what we found are patterns, not proof. The themes showed up consistently enough that I trust them as signals, but I would be careful about turning any of them into a confident claim about all PMs everywhere. The “AI ambassador” role, for example, was real and striking, but it came from one person at one company. I treat it as a thread to pull on, not a trend I have established. Knowing where that line sits, between what the data suggests and what it actually supports, felt like one of the more useful things I took away from the whole project.

The piece I am most curious about, though, is whether my recommendations actually hold up in practice. Right now they are educated guesses built from interviews. I would want to put them in front of the same PMs, have them try out things like a guided prompting mode or a source transparency feature in their real workflows, and then come back and tell me what helped and what got in the way. Testing the ideas with the very people who inspired them would turn this from a set of observations into something I could actually stand behind.

The thing I keep coming back to

The headline fear about AI is replacement. What our small study actually found was something messier. AI is not erasing the product manager. It is taking the tedious parts of the job off their plate and, in the process, putting more weight on the parts only a person can really do: judgment, context, ownership, and the slow work of getting a team to understand each other.

The PMs who seemed happiest were not the ones who automated the most. They were the ones who figured out exactly where to let the tool drive and where to keep their hands firmly on the wheel.

If you are a PM reading this, that is the move I would steal. Let AI own the blank page and the formatting tax, the stuff that drains your time without using your judgment. Then guard the parts that are actually yours: the context, the strategic call, the ability to answer 90 percent of the questions about your own work. Speed is easy to get now. Ownership is the thing worth protecting.

That feels like a pretty good lesson for the rest of us too.

This was a team project for HCDE 519, Qualitative Research Methods. Huge thanks to my groupmates and to the five product managers who gave us their time and their honest opinions.

I came into my graduate program at the University of Washington’s Human Centered Design and Engineering (HCDE) program with about six years of program management experience. I knew how to build roadmaps, align stakeholders, and keep complex projects on track. What I didn’t know was how naturally those skills would translate into product management.

That realization came during a solo class project where I spent 17 weeks developing a product concept from scratch: the JoyBrand Pupuzzle Feeder.

Where the Idea Started

This project started with my dog. She had CCL surgery on her knee, and for six weeks she couldn’t do any physical activity while she recovered. No walks, no fetch, no zoomies around the apartment. During that time, I leaned heavily on puzzle feeders to keep her mentally stimulated when her body couldn’t be.

That experience gave me a firsthand look at both the value of puzzle feeders and their biggest friction point: they require daily setup. You have to fill compartments, hide treats, and reset the whole thing every single day. When you’re already managing a post-surgery recovery routine, that extra effort adds up fast.

When it came time to brainstorm what I wanted to build for this class project, I kept coming back to problems I wanted to solve for my dog. And then, out of nowhere, the idea just appeared. I could see it so clearly: a volcano-shaped feeder, kibble pouring in at the top, tumbling down through a funnel, and scattering into little puzzle compartments for her to solve. It wasn’t something I sketched out or reasoned my way into. It just popped into my head as a fully formed image. That vivid mental picture became the Pupuzzle Feeder.

The core tension I wanted to address: simplifying the owner’s experience while maximizing the dog’s mental stimulation.

The Concept

The Pupuzzle Feeder is a puzzle-based feeding system built around a volcano-shaped design. At the top sits a funnel where you pour in your dog’s kibble. The food disperses down into multiple interactive puzzle compartments, each with different mechanisms like lifting flaps, sliding plates, and pressing parts. The dog has to push, pull, slide, and lift to access their food.

The key innovation is that the funnel does the distribution work for you. Instead of manually filling each compartment, you pour kibble in once and the feeder handles the rest. Mealtime becomes enrichment time without any extra effort from the owner.

I designed the V1.0 to be made from durable, pet-safe materials and to be dishwasher safe, because early survey research told me that cleanability was a non-negotiable for pet owners.

Thinking in Phases

One of the most valuable parts of this project was developing a three-year strategic product roadmap. Rather than trying to build the perfect product on day one, I planned a phased release strategy where each version had its own distinct business goals.

V1.0: Market Entry. The first version focuses purely on core functionality. A reliable, well-designed puzzle feeder at $79, launched through e-commerce platforms like Etsy and Chewy. The goal here is simple: get into the market, make sales, and start collecting customer feedback. Small-batch production with small-scale suppliers keeps risk low.

V2.0: Enhanced Design. The second version incorporates real customer feedback to refine the product. This means sturdier materials, easier cleaning, adjustable difficulty levels, and new options like different sizes and colors. V2.0 also expands distribution into retail stores like PetSmart. At this stage, the business shifts from market entry to market expansion.

V3.0: Smart Integration. The third generation is where things get interesting. This version introduces a companion app for tracking meal times, engagement, and calorie intake. It adds an automatic feeder component and expands into new product lines like a travel-sized portable version. V3.0 is about competitive differentiation and cementing brand loyalty with customers who are willing to invest in premium features.

What I learned from this exercise is that phased roadmapping isn’t just about features. It’s about business strategy. Every decision I made about V1.0, from material choices to distribution channels, either enabled or constrained what was possible in V2.0 and beyond.

AI as a Solo PM’s Best Friend

One unexpected takeaway from this project was how much AI tools expanded what I could do on my own. I’m not a product designer or illustrator, but I needed to communicate what this feeder would actually look like. Using AI-generated sketches, I was able to create detailed, labeled product visuals that brought the concept to life in a way I never could have done by hand.

This mattered more than I expected. Having a clear visual of the product, with every component labeled and placed, helped me think through the design more carefully. It also made my final presentation significantly stronger. For solo PMs or anyone working without a dedicated design team, AI tools are a genuine force multiplier for product visualization and communication.

The Program Management Connection

Here’s what surprised me most about this project: how familiar it all felt.

Building a phased release strategy, balancing competing priorities, making data-informed decisions, thinking about stakeholder alignment, all of it drew directly on skills I developed during my years in program management. The frameworks were the same. The mindset was the same. The difference was the lens.

In my previous roles, I was optimizing internal processes and managing operational complexity. In product management, I’m applying those same skills to build solutions that directly impact people’s daily lives. It’s the same strategic thinking, but now with a user-centered perspective that makes the work feel more connected to real outcomes.

This project showed me that program management skills translate to product work. Strategic roadmapping, stakeholder research, and balancing priorities form the foundation of strong PM work. Now I’m applying those same skills through a user-centered lens to build solutions that directly impact lives.

What I’d Do Differently

If I were to revisit this project, I’d want to go deeper on user validation. While I conducted survey research that informed key design decisions like material choices and cleanability, I didn’t do formal usability testing with the product concept itself. In a real product development scenario, I’d want to put prototypes in front of dog owners early and often to test whether the funnel distribution mechanism actually works as intended, and whether the puzzle difficulty levels are calibrated correctly for different dog sizes and breeds.

I’d also want to explore the competitive landscape more thoroughly. The pet enrichment market is growing fast, and understanding where existing products fall short would sharpen the value proposition.

The Bigger Picture

This was a class project, and I want to be upfront about that. The Pupuzzle Feeder isn’t launching on Etsy next month. But the exercise of taking a product concept through a full development cycle, from problem identification to roadmapping to go-to-market strategy, was incredibly valuable.

It confirmed something I suspected when I started my HCDE journey: that my background in program management isn’t something I need to leave behind as I move into UX and product work. It’s an asset. The skills transfer. And when you add a human-centered design perspective on top of operational and strategic experience, the combination is powerful.

I’m excited to keep building on that foundation.

Savannah Buchanan is a graduate student at the University of Washington’s Human Centered Design and Engineering program, with a background in program management and psychology. She writes about the intersection of UX, product management, and career transitions.

Context: This is my journey learning R in an introductory programming course (CSSS508 — Introduction to R for Social Scientists). I came in with minimal programming experience and learned through weekly homework assignments, debugging sessions, and lots of trial and error.

When I first opened RStudio for my intro R course, I had no idea what I was getting into. The blinking cursor seemed to mock me as I stared at an empty script file. Fast forward several months, and I’ve gone from struggling to load packages to creating complex visualizations and understanding tidy evaluation.

This isn’t a story about becoming an R expert. It’s about the messy middle: the confusion, the small victories, the embarrassing mistakes I made along the way.

The Beginning: “What Even Is a Package?”

My first real obstacle came early. I could install the nycflights13 package in the R console just fine, but when I tried to use it in a Quarto document, everything broke. This seemingly simple issue taught me a fundamental lesson: R has different "environments," and understanding where your code runs matters.

The solution was elegant once I understood it:

#| label: setup
#| include: false

if (!require("nycflights13")) {
  install.packages("nycflights13")
}

library(nycflights13)

This pattern of checking before installing became a cornerstone of my R workflow. But this was just the beginning.

Wrestling with Data Structures

The real learning began when I encountered R’s data structures: vectors, matrices, lists, and data frames. Each homework assignment felt like solving a puzzle where the pieces kept changing shape.

It’s a bit like learning math. You can’t really do arithmetic until you understand what numbers actually are: not just symbols on a page but representations of quantity that follow consistent rules. R is the same way. You can copy code all day long, but until you understand what a vector actually is, why a dataframe is structured the way it is, and how R thinks about types, nothing quite makes sense. You’re just pushing symbols around and hoping for the best.

Vectors and Factors: The Building Blocks

One assignment asked me to create a vector of the first 10 capital letters and a factor variable from the last 10 lowercase letters. Simple, right? Not when you misread “last 10” as “all 26”:

# What I did wrong:
vec_fac <- factor(letters[1:26])

# What I should have done:
vec_fac <- factor(letters[17:26])  # letters q through z

This mistake cascaded through the entire assignment. I kept creating new variables instead of reusing the ones I’d already defined, breaking the continuity the assignment was trying to teach. The feedback stung, but it drove home an important point: in programming, attention to detail isn’t pedantic. It’s essential.

Matrices: When Everything Becomes Character

Matrices taught me about R’s type coercion rules the hard way. I’d create a matrix with numbers, add more numbers, then add letters, and suddenly everything was a character string:

matrix_mixed <- matrix(NA, nrow = 10, ncol = 4)  # Logical (NA)
matrix_mixed[,1] <- 1:10                          # Now numeric
matrix_mixed[,2] <- rnorm(10)                     # Still numeric
matrix_mixed[,3:4] <- cbind(vec_char, vec_fac)   # Everything becomes character!

Why? Because matrices can only hold one data type, and character is the “lowest common denominator.” This forced me to understand R’s type hierarchy: logical, then integer, then numeric, then character. It’s a concept that seemed academic until I saw my carefully calculated numbers turn into strings.

The Tidyverse Revolution

Then came the tidyverse, and R suddenly made sense. Well, eventually.

The Pipe: Making Code Readable

The pipe operator (%>% and later |>) transformed my code from nested function hell to readable steps.

Real example from a restaurant inspection dataset:

# Before pipes - reading inside-out:
filter(mutate(restaurants, 
  inspection_date = mdy(inspection_date)), 
  grade > 2)

# After pipes - reading top-to-bottom:
restaurants |>
  mutate(inspection_date = mdy(inspection_date)) |>
  filter(grade > 2)

One homework assignment asked me to find the Seattle zip code with the worst average restaurant health inspection grades, then show the trend over time. With pipes, the workflow became crystal clear:

# Find worst zip code
worst_zip <- restaurants |>
  mutate(inspection_date = mdy(inspection_date)) |>
  group_by(zip_code) |>
  summarize(mean_grade = mean(grade, na.rm = TRUE)) |>
  arrange(desc(mean_grade)) |>
  slice(1) |>
  pull(zip_code)

# Show trend for that zip
restaurants |>
  filter(zip_code == worst_zip) |>
  mutate(year = year(inspection_date)) |>
  group_by(year) |>
  summarize(mean_grade = mean(grade, na.rm = TRUE))

Reading left-to-right and top-to-bottom instead of inside-out changed everything. I started thinking in workflows rather than functions. Each |> says "and then," making code read almost like English: "Take restaurants, and then convert dates, and then group by zip code, and then calculate means..."

ggplot2: Where Frustration Meets Beauty

Data visualization with ggplot2 was where I experienced the most frustration and the most satisfaction. Creating my first scatterplot function taught me about tidy evaluation:

scatter_plot <- function(dataset, x, y) {
  ggplot(dataset, aes(x = {{x}}, y = {{y}})) +
    geom_point()
}

Those curly braces {{}} seemed like magic. They let me pass column names without quotes, making my function work like the built-in tidyverse functions. This was when R started feeling less like a foreign language and more like a tool I could shape to my needs.

The Mystery of the Missing Function

One particular error message haunted me: “could not find function ‘mutate’.” I’d copy code examples that should work, but they didn’t. The solution? I hadn’t loaded the required packages:

library(tidyverse)  # This loads dplyr, which includes mutate()

This taught me that unlike some languages where standard functions are always available, R requires you to explicitly load packages. It’s modular by design, which means lighter memory footprint but a steeper learning curve for beginners.

Mastering Iteration and Functional Programming

The real turning point came when I started using across() and the purrr package for iteration. Instead of writing the same code over and over with slight variations, I could apply functions across multiple columns at once.

One homework assignment asked me to compute the number of unique values in each column of the Palmer Penguins dataset. My first instinct was to do this:

# The tedious way (don't do this!)
n_distinct(penguins$species)
n_distinct(penguins$island)
n_distinct(penguins$bill_length_mm)
# ... and so on for 8 columns

But with across(), it became much cleaner:

# The elegant way
penguins |> 
  summarise(across(everything(), ~ n_distinct(.x, na.rm = TRUE)))

# Output:
# species: 3, island: 3, bill_length_mm: 164, bill_depth_mm: 80,
# flipper_length_mm: 55, body_mass_g: 94, sex: 2, year: 3

This single line counted unique values across all columns and handled missing data automatically. This was my introduction to functional programming: treating functions as things you can pass around and compose together.

The diamonds dataset taught me how to combine grouping with iteration:

# Group by multiple variables and calculate means
diamonds |> 
  summarise(
    n = n(),
    across(where(is.numeric), mean),
    .by = c(cut, clarity, color)
  )

This groups diamonds by three categorical variables (cut, clarity, color), counts observations in each group, and calculates the mean of every numeric column. The where(is.numeric) part is particularly clever. It automatically picks only numeric columns, so you don't have to list them explicitly. If you add a new numeric column to your dataset later, this code still works without modification.

Understanding the Pipeline

One assignment asked me to explain this code:

diamonds |> 
  split(diamonds$cut) |>
  map(\(df) lm(price ~ carat, data = df)) |> 
  map(summary) |> 
  map_dbl("r.squared")

# Output:
#      Fair      Good Very Good   Premium     Ideal 
# 0.7383940 0.8509539 0.8581622 0.8556336 0.8670887

At first, this looked like gibberish. But breaking it down step by step actually helped me understand how data flows through transformations:

First, split(diamonds$cut) divides the diamonds dataset into 5 separate dataframes, one for each cut quality (Fair, Good, Very Good, Premium, Ideal). Then map(\(df) lm(price ~ carat, data = df)) fits a linear regression model for each cut quality, creating a line that predicts diamond price from carat weight. The next map(summary) extracts detailed statistics from each regression model. Finally, map_dbl("r.squared") pulls out just the R² value, which measures how well carat predicts price (ranging from 0 to 1).

The output tells us that for Ideal cut diamonds, carat weight explains 87% of price variation. Even for Fair cut diamonds, it explains 74%.

When I asked what a regression line actually was, the answer finally made sense: it’s just the straight line that best fits through a cloud of data points, showing the relationship between two variables. In this case, as diamonds get bigger (more carats), they get more expensive, and we can quantify exactly how strong that relationship is. This split-analyze-extract pattern became something I could apply to lots of different problems.

The Visualization Challenge: Making It Personal

Creating meaningful visualizations was perhaps the most rewarding part of learning R. The assignment that made everything click was when I got to explore the popularity of my own name, Savannah, over time using the babynames dataset.

I wanted to see how the name’s popularity changed from 1880 to 2017, separated by gender, with a marker for the year I was born (1988) and highlights for the peak popularity years. Here’s the code that brought it all together:

library(babynames)
library(ggplot2)
library(ggthemes)

# Define custom colors
colors <- c("#1f77b4", "#ff7f0e", "#2ca02c", "#d62728", 
            "#9467bd", "#8c564b", "#e377c2", "#7f7f7f", 
            "#bcbd22", "#17becf")

Savannah_plot <- babynames |> 
  filter(name == "Savannah") |> 
  mutate(sex2 = if_else(sex == "F", "Female", "Male")) |>
  ggplot(aes(x = year, y = prop, group = name, fill = name)) +
  geom_density(stat = "identity", alpha = 0.25, color = colors[1]) + 
  # Mark my birth year
  geom_vline(xintercept = 1988, color = colors[2], linetype = 2) +
  # Mark peak popularity years
  geom_vline(data = babynames |>
                filter(name == "Savannah") |>
                mutate(sex2 = if_else(sex == "F", "Female", "Male")) |>
                slice_max(prop, by = sex2),
             aes(xintercept = year), color = colors[3]) +
  facet_grid(sex2 ~ ., scales = "free_y") +
  scale_fill_manual(values = colors[1]) +
  labs(title = 'Popularity of the name "Savannah"',
       subtitle = "1880-2017, by binary sex category",
       y = "Proportion of babies with this name",
       x = "Year") +
  theme_tufte(base_size = 16) + 
  theme(legend.position = "none", 
        strip.background = element_rect(color = "black",
                                      fill = alpha(colors[10], 0.5),
                                      linetype = 0))

The name “Savannah” was virtually non-existent before the 1970s, then exploded in popularity through the 1980s and 90s. The peak for females came around the early 2000s, meaning I was born right as the name was gaining momentum. The dashed orange line at 1988 shows my birth year, nestled in that upward trend.

The funny thing is, I initially couldn’t get the plot to render at all. I kept getting the error “could not find function ‘mutate’.” After some frustrating debugging, I realized I hadn’t loaded the tidyverse package. Once I added library(tidyverse) at the top, everything worked.

This visualization made data feel personal. It wasn’t just about learning syntax. It was about seeing my own story reflected in 140 years of naming data. That’s when I understood why people get excited about data visualization. It’s not about making pretty charts; it’s about making abstract information concrete and meaningful.

Common Pitfalls and Hard-Won Lessons

Looking back at my homework assignments, I can see patterns in the mistakes I made. Here are the ones that cost me the most points and the most time.

1. Reading the Instructions Carefully

My biggest mistakes came from not reading assignment instructions carefully. Creating new variables when I should have reused existing ones, using 26 letters when only 10 were requested. Those errors taught me that in programming, assumptions are dangerous.

Example mistake:

# Assignment said: "Use vec_fac from Question 1"
# What I did: Created a brand new vec_fac
vec_fac <- factor(c("low", "medium", "high"))  # Wrong!

# What I should have done: Used the existing one
# (the factor I created earlier with letters q-z)

2. Understanding Data Types

R’s automatic type coercion can be helpful or harmful. Learning when R converts types and how to check types (typeof(), class()) saved me countless hours of debugging.

The hierarchy to remember: logical, then integer, then numeric, then character

R always coerces “up” this hierarchy. Mix numbers and text in a matrix? Everything becomes text.

3. Package Loading

Always load your packages at the start of your script. This seems obvious now, but early on I’d scatter library() calls throughout my code, leading to confusion about what was loaded when.

Best practice:

# At the very top of your script:
library(tidyverse)
library(lubridate)
library(palmerpenguins)

# Now all your code below has access to these functions

4. The echo: true Saga

In Quarto documents, chunk options matter. Learning to use message: false and warning: false to suppress package loading messages made my rendered documents much cleaner:

---
title: "My Analysis"
execute:
  echo: true       # Show the code
  message: false   # Hide package loading messages
  warning: false   # Hide warnings
---

5. Handling Missing Data

The na.rm = TRUE parameter became my best friend. R's handling of missing values is strict. One NA can ruin an entire calculation. Being explicit about handling missing data makes code more robust.

mean(c(1, 2, 3, NA))              # Returns NA
mean(c(1, 2, 3, NA), na.rm = TRUE) # Returns 2

Tools and Resources That Helped

Essential Packages

• tidyverse: The meta-package that includes dplyr, ggplot2, tidyr, and more
• lubridate: For working with dates (because date formats are a nightmare)
• palmerpenguins: A fantastic practice dataset (better than iris!)

Key Learning Resources

• R for Data Science: The bible of modern R programming (free online!)
• RStudio Cheatsheets: Visual guides for dplyr, ggplot2, and more
• Stack Overflow: Where I found answers to 90% of my errors
• R-bloggers: Daily articles about R from the community
• Tidy Tuesday: Weekly data visualization challenges

Key Concepts to Master

1. The pipe operator (|> or %>%): Makes code readable
2. Tidy evaluation: Understanding {{}} for writing functions
3. across(): For applying functions to multiple columns
4. map() functions: For iteration in functional style
5. ggplot2 layering: Building plots piece by piece

What I Wish I’d Known Earlier

R is a language, not just a tool. It has grammar, idioms, and multiple ways to say the same thing. Once I learned the tidyverse dialect, everything made more sense. Base R and tidyverse R can look like completely different languages sometimes.

Errors are genuinely useful. Every “could not find function” or “object not found” error taught me something about how R’s environment and scoping rules work. I stopped seeing them as failures and started seeing them as feedback.

The REPL (the R console) is your best friend for learning. Running code line-by-line before putting it in a script saves so much time and helps you understand what each piece actually does.

The documentation is better than I initially thought. The ?function_name help system and package vignettes are actually helpful once you learn how to read them. They're dense, but they're accurate.

Community matters more than I expected. Stack Overflow, R-bloggers, and course forums were lifesavers. I learned as much from reading other people’s questions as I did from the course materials.

The Breakthrough Moment

There wasn’t one single moment when R “clicked.” Instead, it was gradual, and honestly frustrating because I kept waiting for that lightbulb moment that never came.

In the first couple weeks, I was completely lost. I’d stare at error messages and have no idea where to even start troubleshooting. By week three or four, I at least understood what vectors and matrices were, even if I couldn’t use them correctly. Around week seven, something shifted. I started recognizing patterns in the code. The pipe operator started to make sense. I could read a ggplot call and mentally picture what the output would look like.

By the end of the course, I was writing custom functions and didn’t need to constantly reference the documentation. More importantly, when something broke, I had strategies for fixing it rather than just panicking.

The real breakthrough was when I stopped seeing R as a series of commands to memorize and started seeing it as a way of thinking about data:

• Data flows through transformations (that’s what the pipe is for)
• Variables have types and structures (and R is strict about them)
• Functions are composable (you can chain them together)
• Visualization tells stories (numbers alone rarely convince anyone)

These principles, once internalized, made everything else fall into place. When I successfully created the Savannah name popularity visualization, which combined data wrangling, date manipulation, grouping, and layered plotting. I knew I’d crossed a threshold. I wasn’t just following tutorials anymore; I was solving real problems.

Looking Forward

I’m not an R expert by any stretch. But I can now load and clean datasets without constantly googling syntax, create visualizations that look professional enough to share, write custom functions using tidy evaluation, use iteration to avoid repetitive code, and debug errors systematically instead of randomly changing things until something works.

More importantly, I’ve learned how to learn. When I run into a new R challenge, I know where to look, what to search for, and how to break down problems into pieces I can actually solve.

Advice for Future R Learners

Start small. Don’t try to learn everything at once. Get comfortable with vectors before worrying about matrices. Master single operations before trying to chain them together with pipes. Learn basic ggplot before attempting complex visualizations with multiple layers.

Embrace the errors. Every error message is teaching you something about how R works. Read them carefully, Google them, try to understand what actually went wrong rather than just finding a quick fix.

Type the code yourself instead of copy-pasting examples. It feels slower, but typing forces you to notice details and builds muscle memory. Plus, you’ll catch typos before running the code.

Work with data you actually care about. Using datasets that interest you (like my name popularity data) makes learning feel less like homework and more like exploration.

Ask for help when you’re stuck. The R community is surprisingly welcoming. Don’t waste hours struggling alone when someone else has likely solved your exact problem and posted about it.

Be patient with yourself. Learning R is genuinely hard. It requires understanding statistics, programming, and data manipulation all at once. Give yourself some grace when things don’t click immediately. They didn’t for me either.

Conclusion

Learning R changed how I think about data. It’s not just about running analyses. It’s about understanding how data is structured, building workflows that other people can follow, and turning numbers into visuals that actually communicate something.

The journey from “how do I install a package?” to creating complex data pipelines wasn’t linear. There were plenty of frustrations, late nights debugging, and moments where I questioned whether I’d ever understand this language. But each small victory made it worthwhile.

After one course, I completed 9 homework assignments (with varying degrees of success), debugged countless errors, and created dozens of visualizations. More importantly, I had a shift in mindset from thinking of code as instructions to thinking of it as a way to communicate with data.

R isn’t easy, but it’s worth it. If someone who struggled with basic package installation can eventually write custom functions and wrangle complex datasets, you can too.

Ready to Start Your R Journey?

If you’re thinking about learning R, here’s what I’d recommend for your first week:

1. Install R and RStudio
2. Work through Chapter 1 of R for Data Science
3. Load your first dataset with data(mtcars) and run summary(mtcars)
4. Join the RStudio Community forum for when you get stuck

Tags: #RStats #DataScience #LearningToCode #DataVisualization #Statistics #RStudio #Tidyverse

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.

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.

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.

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.

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.

When Your First Visualization Fails: Lessons from Exploring 2,600 Languages was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Photo credit: Gail Wong, Urban Sketches Seattle

Introduction

Coined by sociologist Ray Oldenburg in 1991, the term third place refers to an informal public gathering space outside of home and work that fosters belonging and community connection¹. There has been a recent decline in third places due to “economic, social, behavioral, technological, and policy changes”, negatively impacting mental health, community belonging, and social equity²𝄒³.

Throughout this 9-week course project, we explored revitalizing third places in different communities. We found that Seattle’s rapid urban development, particularly around its growing light rail system, offered a unique opportunity to integrate new third places near transit hubs. Moving forward, we focused our project around the question: How can we improve third places around Link light rail stations in Seattle?

Our Process

In our project, we used a design-thinking methodology. Roughly, the process we followed was Empathize → Define → Ideate → Prototype → Test. Implementing this was a non-linear and iterative process, where several stages were repeated.

A visual representation of our design process

Research

Through our research, we wanted to understand individual motivations behind Link light rail usage and attitudes towards existing nearby third places in the Greater Seattle area. We conducted secondary research, rapid ethnographies, and a web-based survey. The questions we explored were:

1. What types of spaces do Link riders visit when traveling via the light rail?
2. What kinds of spaces do Link riders want near light rail stations?
3. What improvements could make spaces near light rail stations more inclusive for all Link riders?

Secondary Research

We reviewed over 15 sources of existing literature and research surrounding third places and adjacent topics such as community psychology, urban planning, global perspectives, inclusivity, and anti-racism.

Map of different topics reviewed and their interconnectedness

Rapid Ethnography

We conducted rapid ethnographies at several Link Light Rail stations, including Columbia City Station and U District Station. By immersing ourselves in the environment, we could better observe rider behaviors, available amenities, and station accessibility.

Left: Columbia City Station, Right: U District Station

Survey

We recruited survey respondents by putting up fliers near several Link light rail stations in the Greater Seattle Area. The survey was also shared online on various social media platforms and through student networks.

Left: Survey fliers put up near link light rail stations, Right: Web-based survey outline

Research Insights:

According to our secondary research, third places:

• Foster social interaction, community belonging, quality of life, inclusivity, and overall well-being
• Are critical to public health, providing environments that enhance resilience against stress and loneliness⁴

Through our rapid ethnography, we discovered that stations lacked:

• Amenities (restrooms, trash cans, Wi-Fi)
• Seating, adequate shelter from the elements

Our survey insights were:

• 50% of survey respondents were from Columbia City Station
• 84% reported wanting more community spaces near light rail stations (parks, playgrounds, community centers, and co-working spaces)
• Respondents disliked the lack of seating, bathrooms, and available community spaces

Our research insights by category

These insights guided our design requirements and ideation, narrowing our scope to designing a third place for Columbia City Station with an emphasis on community engagement and public amenities.

Ideation

To kick off ideation, we identified the following as out of scope:

• Detailed construction plans and city codes
• City-wide development or large-scale infrastructure changes
• Funding and policy implementation

Phase 1: Generating Ideas

In the first phase of ideation, we brainstormed various concepts and ideas that incorporate the needs of Link riders into a community space. We sketched a wide range of possibilities, prioritizing inclusivity and utility.

Our early sketches (including seating, garden features, art installations, potential parks and cafes, and an app for riders)

Phase 2: Applying Ideas

For the second phase of ideation, we honed in on practical ways of applying our ideas to an empty plot of land adjacent to the Columbia City Station.

Our final sketches focused on two key concepts: a passenger cafe and a community garden, each addressing unique aspects of community engagement and Link rider needs.

Left: Empty plot of land highlighted in pink, Right: Our final sketches selected for prototype development

Through feedback and reflection, we found these concepts to complement each other and combined them into a unified solution for our prototype: the Community Garden Café, designed to provide a welcoming, inclusive space with accessible amenities for both Link riders and the surrounding community.

Design Goals:

Before beginning the prototyping process, we defined our design goals based on insights from our user research and constraints of the physical space.

Our design goals were organized into three main categories:

• Accessibility and Convenience: Entrances, walking paths, and seating areas must be easily accessible and ADA compliant. Design should include flexible seating options, both indoor and outdoor.
• Safety and Comfort: Environment must be clean, well-lit, and actively monitored to ensure safety and willingness to spend time in the area.
• Space Design and Flow: Area must include designated spaces that support Link rider needs, including amenities for eating, drinking, bathrooms, and community activities. Design should optimize flow of people and reduce congestion.

User Flows

We mapped out several user flows to better understand how visitors would interact with the Community Garden Café. Guided by our user research and final sketches, these flows informed decisions about the physical layout and amenities, ensuring design goals were met while minimizing friction points.

User Flow used for our storyboard prototype

Prototype

Due to time constraints and limitations of prototyping for a physical space, our team created an interactive storyboard that would visually represent the interaction and experience of visiting the Community Garden Café.

In addition to the physical space, we expanded our prototype to include screens for an accompanying “Explore My Station” website. This was influenced by our goal of providing users with easily accessible information around station amenities and nearby community spaces.

Medium fidelity prototypes used for usability testing; Left: Website screens, Right: Several of the storyboard screens created

Usability Testing

We conducted usability testing with three Link riders. We sought feedback on the functionality and experience of visiting the Community Garden Café and the navigation of the accompanying website.

During testing, participants navigated the storyboard scenario and made choices based on how they would engage with the physical space in real life. They talked us through their exploration of the website and shared their thought process.

Our main takeaways from usability testing that were incorporated in our final design were:

• Preference for water fountain (to cover nearby road noise), greenery, cleanliness, and covered outdoor seating
• Preference for website over app (due to ease of use) and desire for website to be backed by city or transit authorities for reliability

Final Design: Community Garden Café

Left: Proposed site plan for empty plot of land near Columbia City Station, Right: 3D rendering of proposed site plan

Left: Proposed floor plans for cafe interior (top and bottom level), Right: 3D Rendering of proposed floor plans

3D rendering of proposed cafe design — certain features (railings, automatic doors) were not included due to software limitations

Final Design: Explore Link Light Rail Stations

Proposed design for “Explore Link Light Rail Stations” website backed by Sound Transit

Conclusion

The Community Garden Café represents more than just a physical space — it’s a vision for fostering inclusivity, accessibility, and connection within urban environments.

Our design combines physical and digital approaches to transform Columbia City Station into a thriving community hub where Link riders and local residents can relax, connect, and engage with their surroundings. We hope this solution inspires similar initiatives to create sustainable third places for all.

References

1. Project for Public Spaces. (2008, Dec 31). Ray Oldenburg. Project for Public Spaces. https://www.pps.org/article/roldenburg
2. Steuteville, R. (2024, July 3). Vanishing third places and what can be done. Congress for the New Urbanism. https://www.cnu.org/publicsquare/2024/07/03/vanishing-third-places-and-what-can-be-done
3. Wolfe, C. (2023, June 21). From vacant storefronts to vibrant hubs: Revisiting ‘third places’ for urban resilience. GeekWire. https://www.geekwire.com/2023/from-vacant-storefronts-to-vibrant-hubs-revisiting-third-places-for-urban-resilience/
4. Finlay, J., Esposito, M., Kim, MH., Gomez-Lopez, I., Clarke, P. (2019, Nov). Closure of ‘Third Places’? Exploring Potential Consequences for Collective Health and Wellbeing. National Library of Medicine. https://pmc.ncbi.nlm.nih.gov/articles/PMC6934089/

Thank You!

If you are interested in learning more about our work in Rethinking Third Places around Link Light Rail Stations, please leave us a comment or connect directly through email.

University of Washington Human Centered Design and Engineering
HCDE 518 User Centered Design, Autumn 2024
Team: Haneen El-haj, Shanna King, Savannah Buchanan, Bri Tran