On alternating Tuesdays, I get to be a young second-generation immigrant woman named Selene with great phone presence and multilingual skills. Or I could be a beefy mid-30s guy named Silas with a buzz cut and a flair for figures. Or any of a few others, or several of them in succession.

Every second Tuesday is sprint review day in my department. Our agile teams (those like me who create and test the code) gather to show our execs and internal customers what we’ve done since last time–i.e., during the last “sprint.” And I get to indulge in what may be the world’s least intensive acting career.

As a scrum master, I need sprint reviews to reflect progress made in enhancing our product’s functionality, tightening up its reliability, and shoring up its long-term viability. As a usability engineer, I need us above all to focus on the experience of the human user at the end of our efforts. How to do both? That’s where Selene and Silas (not their real names…not that they have real names) come in.

Selene, Silas and the rest make up our team’s pantheon of user personae. They are, in essence, imaginary friends of ours, in whom we amalgamate our understandings of those actual human beings who will create, administer, and consume data via our product. Many software teams use personae to guide their user-centered thinking, but there is a richness available in them that I think may go generally untapped.

When I am designing a control, I think about what Selene would like. When I user-test or field-test a UI in front of real users, I refine my understanding of who Selene is. When I help spec a feature through a “user story,” I phrase the objective in terms of what she wants to do—“As Selene, I want to switch display text language easily so that I can conduct business in different languages.” And when I demo a feature that has been coded, I impersonate her, literally announcing, “I’m Selene, and I’d like to switch the display text language to French so I can conduct business in that language.”

In fact, when I use the word “pantheon” to describe our group of user personae, I actually do so advisedly: Traditionally, pantheons personify an otherworldly realm in order to allow those in this world to relate to that realm, and in a sense, personae do the same thing.

A Roman smith felt his work was given meaning by its parallels to Vulcan’s; Polynesian mothers felt comforted by Haumea when facing childbirth; a Hindu shopkeeper invokes the blessing of Lakshmi on his business. In general, the archetypes in these pantheons essentially humanize the divine realm. Those of us in design and development also spend time thinking about a mysterious world we never truly enter but whose denizens mean everything to our tasks, and that world is the world of users. We make that world more intelligible and navigable by appealing to our personae.

The more we invest in our personae, the more present they become in our work—and the more our “usability culture” begins to resemble an honest-to-goodness culture. Ultimately, I can envision a style of work that bears some resemblance to many traditional societies’ casual relationships with their pantheons, in which our personae influence most of what we do and crop up in our conversations, jokes, and collective memories. What will happen, I wonder, if Silas becomes important enough—perhaps “venerated” enough—that our QA engineers “feel” him with them when testing, like a Spartan felt Ares with him in battle?

I have never yet opened a sprint review with any variant on “O Selene, accept our humble offering,” but the time may yet come. (Though for that, we may have to move our semi-weekly ritual to Mondays.) In the meantime, we will do what we can to propitiate the gods—er, that is, meet our users’ expectations.