A new way to user story: the Monkey Method.

Use "Monkey see, monkey do"instead of "as a user I want..." to generate more concise and action-oriented user stories.

For those who might not know, user stories have become something of a rite of passage in software engineering. Imagine: small teams of coders and product managers huddled around whiteboards, crafting narratives about imaginary users navigating complex systems. These “user stories" emerged from the heart of agile methodology, almost like folk wisdom passed down from bootcamps to help teams understand and shape a user’s journey.

But here’s the irony: user stories, designed as roadmaps, often end up more like forgotten road signs. They become a bulleted list of user actions that gathers digital dust in a project management tool, rarely referenced after planning. Why? Because, as they’re traditionally written, user stories often become massive, bloated to-do lists—“word vomit,” if you will. It’s a system that feels thorough, yet few developers will admit to ever consulting them once development kicks in.

So, what is their real purpose? Like many tools, user stories are ultimately about planning. They force teams to sit down and think through what they’re building. But if that’s the case, shouldn’t these stories be as useful in practice as they are in planning?

In my own work, I’ve seen user stories written every which way. Some feel almost sociopathic in their detail—hundreds of lines like, “As a user, I want to register using Google and Apple” or “As a user, I want to reset my password.” These lists are exhaustive to the point of madness, yet somehow feel empty. There must be a better way, right?

Method 1: The Sociopath Method

This is how user stories were taught to us—bulleted lists that detail every micro-step of a user’s journey. Each line starts the same: “As a user, I want to…” It’s supposed to make things clear, but let’s be honest, it makes our eyes glaze over. The repetition itself can become a barrier, like hearing the same joke on repeat until it loses all meaning.

Method 2: The Recovering Sociopath Method

Here, we try something new: stripping away the redundant “As a user, I want to…” from every line. Instead, we let the bullet points do the talking:

• As a user, I want to…
  • register using my email, Google, and Apple.
  • receive an email confirmation after registration.
  • reset my password by clicking a link, opening an email, and being redirected to a reset form.

It’s slightly more palatable—still filled with detail but a bit easier on the eyes. It’s an improvement, but there’s still room to streamline.

Method 3: The Slightly Tolerable Sociopath Method

This approach flips the script on user stories by focusing on components or major sections of the application. Instead of endless bullets, each component outlines the user’s interactions within that section:

• Authentication
  • Register using email, Google, and Apple.
  • Receive an email confirmation.
  • Reset password using a link.
  • Login using email, Google, or Apple.

This helps organize the information into sections, making it easier to reference and reducing the risk of burnout. It’s a perfectly viable option, though my current favorite is the next one.

Method 4: The Monkey Method

The Monkey Method is less about writing stories and more about programming the user’s experience. The format is simple: who, what, when, and where. (What about the why? Simon Sinek would be outraged!) It’s structured like a series of coded steps that represent what the user sees, what they do, and the results of those actions:

See -> Action -> Result…

• Authentication
  • Register
    • Google Button -> click -> Auth consent screen -> login.
    • Apple Button -> click -> Auth consent screen -> login.
    • Email Input -> type email.
    • Full Name Input -> type full name.
    • Legal Checkmark -> agree to terms.
    • Sign Up Button -> confirmation email sent -> redirected to validation page.
    • Sign In Link -> redirects to sign-in page.
  • Login
    • Google Button -> click -> Auth consent screen -> login.
    • Apple Button -> click -> Auth consent screen -> login.
    • Email Input -> type email.
    • Sign In Button -> magic link email sent -> redirect to validation page.
    • Sign Up Link -> redirects to sign-up page.

This approach reads more like code thanks to the arrows showing what users see, the actions they take, and the results. It offers a more structured framework for thinking through the user journey while also creating a backlog of features needed on each page. (Stay tuned for my upcoming article on the Text UI Design method.)

Projects requiring user stories are often complex. A single app page can end up with an entire sheet of user stories. Multiply that by multiple user roles, and the list can triple or quadruple in size. The time spent on user stories should add value during development and be easy to update as requirements change. The Monkey Method helps you accomplish this with greater clarity and efficiency.