Why build a restaurant when a recipe card will do?
How to give a method away without building a product around it.
I wrote about a survey method that gives you a headline number and the specific insight to act on. Enough of you replied asking “OK, but how do I actually run one?” that I built the tool. Here’s what I made, and why I very deliberately didn’t turn it into a product.
After the article went out, a message came in that I could see coming: “OK, but how do I actually run one?”
A few weeks earlier I’d written about Actionable Experience Surveys (AESurveys) – the method I use to replace flat “lovely!” satisfaction scores with something that actually tells you what to do next. Regarding tooling I mentioned explicitly that “the design is the asset, not the software.” Indeed, any survey platform can create AESurveys – Qualtrics, Typeform, Google Forms, a well-built Storyline slide … a form on a napkin.
I stand by the fact that this is a mental model and therefore tooling agnostic – but also, I can appreciate that if you’ve never done it before, it’s not the shallowest of learning curves. Someone wishing to switch to AESurveys has the mental load of designing the survey in addition to deploying the thing, wrangling the responses back out again, and working out how to display the information in a way that serves the unique insights AESurveys are designed to elicit. The method doesn’t stop being the method when the tools get in the way; it just … well, puts an effort barrier there.
So Andy, build a product! Give it a catchy name, set up a business, charge a subscription, market it! Hang on, the whole point of AESurvey design is that it’s portable. AESurveys are a design process that belongs to whoever reads about it, not to me and not to one platform or product. But I do want people to be able to get started easily, so I’ve built the smallest and simplest tool I could get away with – and it’s here for anyone to use, for free, right now.
Making a recipe card, not a restaurant
AESurveys are a method, like a recipe. If a product gets associated to that recipe suddenly I’ve made a restaurant. It’s the difference between a hamburger and a Big Mac.
That was the framing that decided the development. If the goal is a recipe card, then:
· No backend. No account, no login, no database. Every kitchen has an oven; just as every laptop has a browser. That’s enough.
· No data on my hardware. If I hold nobody’s responses, I can’t lose them, leak them, or misuse them. GDPR becomes a paragraph in a README rather than a lifetime of compliance. I’ll stay completely out of any data generated.
· No moat, no vendor lock-in, no pricing page. MIT licence, source on GitHub, fork away – it’s genuinely free.
· Small enough to hold in your head. The whole thing is a handful of self-contained HTML files. You can read it in an afternoon. Anyone who can write a form can extend it however they desire.
What’s in the recipe?
Three pieces, each of which works on its own and hands off cleanly to the next.
A survey builder. It’s a form in the browser. Type your prompts, drop in four (or more) statements per question, pick a band for each – Alarming, Concerning, Acceptable, Superior – and tick whether you want a comment box. When you’re done with your survey design, hit Copy shareable link. The link contains your whole survey, encoded into the URL. No upload, no save-to-cloud, no “here are the terms of service and here is our privacy policy.” Just a URL.
A participant page. Your respondents click the link. They see the survey as any respondent would, pick their statements, and – if they want – leave a comment. At the end they can save the whole thing as a PDF, email it back to you, or copy a response link they can paste to you separately. The link opens the analyser with their single response already loaded, so a busy person can send you a link and be done in ten seconds.
A report analyser. Drop in the response files, paste the response links, or open one directly. You get full visualisations including Below/Above the Bar per question, hover-tooltips showing the statement each band represents, and every free-text comment grouped by band and paired to the exact statement the respondent picked. Print it out and you’ve got a PDF-ready report.
There’s a fourth mode for anyone who wants to run this through their Learning Management System (LMS): the survey design can be uploaded via SCORM zip export to Totara, Moodle, SCORM Cloud, whatever LMS you’re running. It records the response category, the exact statement chosen, and any comment as SCORM interactions, so you can export the standard “Track details” CSV and drop it into the report analyser above.
Nothing here is clever, technically. The whole tool is a handful of HTML files a browser understands. But the constraints – no backend, no data on my hardware, no vendor lock-in – are quietly doing a lot of work. By taking those choices seriously, the design of the tool almost wrote itself.
Try it (with a worked example)
Open the builder at andyrogers.design/tools, build from scratch or click Load demo to populate a four-question AESurvey about a feedback workshop, wired up and ready. Edit to your heart’s desire. Ten minutes and you’ve got a survey.
Now click Copy shareable link. That URL – nothing else needed – goes to your colleagues. Two days later, you have your replies in your inbox. You open the analyser, paste their response links into the panel, and there it is: the Below/Above the Bar picture, the split per question, and the comments grouped so you can see which frustrated respondents said what.
Total infrastructure involved: none. Total accounts anyone had to create: none. Total data sitting on my servers: none (there are no servers).
What I very deliberately left out
· No account system. Because there’s no data to protect, there’s nothing to authenticate against.
· No aggregation on a shared server. For small cohorts (a team, a class, a research pilot), an inbox is a fine aggregation layer. For hundreds or thousands of respondents, you probably want something with a real backend – and that “something” isn’t this tool (unless you integrate your LMS and have AESurveys in SCORM). Otherwise, reach for a proper survey platform, run the AESurvey method inside it, then come back to the analyser to view the export.
· No public URL directory of surveys. No listing, no discovery, no “trending”. A shareable link is enough.
· No branding options. The look is fixed. I’d rather you spend the ten minutes you’d waste on colour pickers to write better questions.
Feature choices should say something. These say: the recipe is the thing. Anything the tool adds beyond carrying the recipe is a distraction from it.
Where else this pattern applies
The shape of what I built here – a small, portable, no-backend enabler around a method rather than a product – isn’t specific to surveys. It’s a pattern worth stealing wherever you’ve got a design you want to give away.
Wherever a method depends on a specific piece of infrastructure – a login, a subscription, a shared database – reach is quietly gated. Wherever a method fits in a self-contained tool that runs in a browser, or a spreadsheet you can email around, or a printable one-pager, reach is quiet, wide, and permanent. You’d be surprised what fits:
· Design frameworks. A prompt library, a critique checklist, a card-sort exercise. Web page, no login.
· Facilitation aids. A retrospective template, a decision-log form, a role-clarifier. Static HTML.
· Research protocols. Consent forms, interview guides, coding schemas. Version-controlled Markdown someone else can fork.
Each of these is a “recipe” – an idea with a shape – that someone else could use if it were sitting on a card. It doesn’t need a product around it. It just needs the card.
The takeaway
If you’ve designed something useful and you want it to spread, the temptation is to wrap infrastructure around it – apps, subscriptions, dashboards, growth loops. That machinery does spread things; it also gets between the reader and the idea, and it makes the idea contingent on your company staying alive.
There’s another route. Make the idea portable enough that it doesn’t need you. Give it away in a form small enough to travel, cheap enough that no one has to justify the spend, and open enough that anyone can pick it up.
In the end the design is the asset. The tool is the recipe card. Sometimes a recipe is enough.
Try it yourself
· Build your own in the browser and copy a shareable link.
· Explore the report with sample data – twelve respondents, four questions, comments grouped by band.
· Source on GitHub – MIT-licensed.
The method it enables – Actionable Experience Surveys – is written up here: A call for the resignation of the customer satisfaction survey.