How A Children's Book Can Improve Design
Recently, I’ve discovered a new phrase I’ve been saying more while planning and designing projects and discussing how features will work.
“If you give a mouse a cookie…”
Used as a prompt to make sure all options have been considered, it’s the title of a book from my childhood, If You Give a Mouse a Cookie, written by Laura Joffe Numeroff.
Others may be familiar with a few of its sequels, If You Give a Moose a Muffin, If You Give a Pig a Pancake, and If You Give a Dog a Donut – plus many (many) more.
Sadly, it seems even children’s books aren’t immune to the Hollywood model of never-ending spinoffs.
In the original story, a boy meets a mouse, who asks for a cookie. With the cookie, the mouse asks for a glass of milk, then a straw to drink the milk, and then a napkin to clean its face.
This pattern continues, but ultimately comes full circle when the mouse later asks for another glass of milk and a cookie to go with it.
As silly as the story may be, how often has this happened to you? You’ve delivered a tool or product someone has specifically asked for, but then they ask for something a little extra.
You might have been frustrated by the request at the time, wondering why they weren’t simply thrilled with what you brought them. Or maybe you happily obliged and realized you should have seen it coming.
In either instance, the art of anticipation is key. I’ve found “if you give a mouse a cookie…” works extremely well for this.
Sure, people could get by with that simple, bare-bones tool you’ve built. But what might be some other small tasks they’d want to do, or what additional info would help them complete the task quicker?
Going back to our story, ask yourself (or your team):
"If I give a mouse (my client or their users) a cookie (this feature/ability/content), what else will they want? Can I provide it to them? Do we have the resources to do more? Are there questions I need answered first? Will it be helpful?"
There are a lot of paths you can go down, but hopefully your limitations will be obvious and guide you in the vetting process.
For context, consider this example:
We recently completed a new site for a great, longtime client of ours, Leaning Tower of Pizza, an Ankeny-based pizzeria.
A clear feature any restaurant website needs is a food menu. The trouble is, menus can change frequently – prices, dishes, ingredients.
Before building a tool to manage the menu, we thought of the many variables that would change and what the outcomes might be.
If you give a mouse a cookie…
As a result, we created a tool that let Leaning Tower of Pizza create as many menu items as they wanted, assign those items to a group, such as appetizers or entrées, and even dictate whether a dish came in various sizes.
There were other micro features as well, but as you can see, the tool was built to be flexible.
The difference between ideation and scope creep
One quick note: The method above should not to be confused with facilitating scope creep.
Scope creep is a term used to describe when clients or team members ask for (or perhaps demand) extra features on top of the project requirements that were previously agreed upon.
Sometimes these features are asked to be included within the original timeline or budget.
That is not what we are talking about here.
What I’m encouraging you to do is ask more questions in order to anticipate user or client needs in the early planning and concept stages. Then, talk about these ideas. Analyze them. Reject them. Explore them.
Good ideas have the best intentions, but time and budget tend to be fixed resources. By using this prompt, you can have a collaborative discussion to figure out what the starting point of a feature or project must be and what future enhancements will make it even better.
