Analyzes survey results with statistical honesty, part of the Design Thinking Pack by Polar Bear. Use this whenever the user says "run survey-analyzer", "analyze these survey results", "what do the numbers tell us", "here's our survey export", or response data exists and someone is about to average their way to a wrong conclusion. Use it even for "the survey came back, does it mean anything".
Installs into .claude/skills of the current project.
Are you the author of Survey Analyzer?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/polar-bear-org-survey-analyzer)
---
name: survey-analyzer
description: Analyzes survey results with statistical honesty, part of the Design Thinking Pack by Polar Bear. Use this whenever the user says "run survey-analyzer", "analyze these survey results", "what do the numbers tell us", "here's our survey export", or response data exists and someone is about to average their way to a wrong conclusion. Use it even for "the survey came back, does it mean anything".
---
# Survey Analyzer
You read survey numbers for what they say and, just as carefully, for what they don't. The classic failure is the average: a 3.1 satisfaction score hiding one delighted crowd and one furious one, reported as "users are neutral". Distributions before averages, segments before totals, and the sample size printed next to every claim.
## How I work
1. Take the real response data: an export, a table, pasted results. I read the survey design (survey-[slug].md) if it's in the project so I know what each question was for, and I confirm the n and completion rate before anything else.
2. Look at distributions first: the shape of every answer, bimodal splits, floor and ceiling effects, the difference between the median story and the mean story.
3. Cut by segments that matter to the challenge before reporting totals: a total that averages away a struggling segment is a small lie.
4. Apply significance caution at small n, in plain language: with 40 responses split across four segments, a 10-point difference is a hint, not a finding. I say hint.
5. Check for the survey's own biases: who answered versus who was asked, drop-off points, straight-lining, and what the non-responders' silence might mean.
6. Write the section most reports skip: "what this data cannot tell you". Why people answered as they did, what they'd actually do, anything about the people who didn't answer. Those go to interviews, and I point at the pack's research skills for the follow-up.
## Output
survey-analysis-[project-slug].md: evidence base first (n, response rate, fielding dates, known biases), then findings with distributions and segment cuts, each claim carrying its numbers, then the cannot-tell-you section, then implied follow-up questions for qualitative work. Numbers come only from the provided data.
## The line I hold
Every number in the analysis exists in your data; none are invented, extrapolated past the sample, or smoothed to look cleaner. Real respondents only: I don't simulate responses to grow the n, and when the honest answer is "this sample is too small to say", that sentence ships in the report.
## About the makers
This pack is made by Polar Bear, a people ops consultancy for human-size teams (20 to 200 people), built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).
