In a previous post we explored the importance of User Stories for projects whose websites and applications had their end-users in mind. These projects have fairly linear deliverables and would fall into the B2C business approach, meaning we should be designing from the consumer’s perspective. Now we will consider another dimension that, if the project allows, should also have a seat at the discovery table. These are called Admin User Stories, which focus on how the ship should be run (B2B).

What is an Admin User Story?

For all intents and purposes, it’s exactly like any other User Story. However, the first blank is already filled in:

As an Admin, I want to ________ so that ________.

In other words, it’s the story of how the business owner, our client, wants to use whatever we’re making for them. This part of the process is about discovering the client's driving purpose, unpacking their business approach, and making it simpler for them to provide for their customers (aka the End User).

When Are Admin User Stories Necessary?

Some projects are straightforward enough that an Admin User Story seems redundant, whereas others may truly benefit from a phase of self-reflection. Then there are also projects that cannot even begin without a thorough assessment of how the client expects to be using the software at hand.

For example, while a simple splash page would benefit from End-User Stories, there wouldn’t be much need for Admin User Stories (although who knows, it might help). This would especially be the case for projects using an out of the box Wordpress CMS with no customizations. Checkout our work on tailtown.ca as an example of a splash page.

However, if we’re considering a multi-page enterprise website, perhaps with ecommerce (with or without a custom CMS), End-User Stories would be strongly advised and Admin User Stories would be advised. These days a website has such potential benefits for the company’s internal efficiency; it’s only by gathering administrative qualms (through stories) can we brainstorm solutions. See our Railtown Catering Case Study. Here’is what one of their Admin User Stories looked like:

As an Admin of Railtown Catering, I want to receive receipts from ecommerce orders automatically into Quickbooks so that I don’t have to manually process them.

Lastly, if we were to design/build an application used by a team, with potentially multitiered admins, both End-User and Admin User Stories should be required. For these types of projects, the Admin User (or Super Admin) is likely the biggest stakeholder user (aka the client). These types of projects often involve multi-tiered User Authentication flows, admin dashboard views, user profile pages, email template design for multi-marketing campaigns and likely a public-facing page to get the word out there. In these contexts, Super Admins want to control every layer of the application’s Role Based Access Control System (RBAC). Our MLngn Case Study breaks this down in detail. Here’s one of their Super Admin User Stories with regards to onboarding clients to the platform:

As the Super Admin of MLngn, I want to a) invite brokerages, b) invite agents, c) do both individually or as a bulk file upload so that a) brokerages can onboard their own agents, b) I can invite non-represented agents, c) I can respond to the growth of the application.

Admin User Stories are the stories of the people using the nuts and bolts of the software. The stories of how the software should merge seamlessly with and ameliorate a business model. The stories of maintenance, once the product is built. They are the stories of the Beginning-User, not the End-User. And like any story, there should be a beginning, middle and end.