Personas.

I first came across this fascinating term when I joined design school back in 2011, after wrapping up about 8 years of work as an engineer. Personas were my introduction to the user-centric philosophy of design, for they helped me to understand the users of our products and enabled me to put myself in their shoes.

As I graduated and started working in the design industry, specifically in travel and e-commerce, personas became a regular part of my design process in the initial years. I regularly turned to the personas framework to define user journeys; the familiar template of certain named individuals, their day-to-day life and expectations, and how our product/service would fit into their routine. I’ll be honest, it was a very normal practice in those early years of my career and went some way in helping us gauge the direction of our products.

However, after shifting to the hyperlocal / food delivery industry in late 2016, it was the beginning of the end of personas in my design process. To be frank, I was now working in a very early stage (food delivery) startup called Swiggy, and speed was of the essence back then. This meant less time spent on creating fictional characters and a snapshot of their lives, and more time devoted to “listening” to the market and customer feedback — creating quick feedback loops to push the next innovation in our product market fit.

Working in such a startup culture has fortunately exposed me to widely diverse areas of problems to solve — from the consumer and restaurant/store ecosystem to the delivery fleet ecosystem. I’ve gathered many eye-opening insights when solving for scope and pain points; none more vital than how to identify and define the end users of products in the respective ecosystems. Post identification and profiling of the target users, I would then apply the appropriate methodology to solve for them and their customer journeys.

As (not just) a designer but also being a designer with a disability, I’ve come to a point (now) of establishing a strong opinion on personas. But it wasn’t always that way. And this post is the result of a very interesting discussion that started in the Stark Slack community when someone asked:

What are your thoughts on personas? When are they justified or not (if ever)?

Several of the community members, some experts and others new to the field, shared their thoughts as we healthily debated. Here are some of my picks for great stances:

“Personas would be put in the same way that the world was designed by a skewed view of the average person. Hell, I'd argue that the world as a whole in itself isn't designed for anyone that isn't a white able-bodied man that is upper-middle class. Especially in the states.”

“For me, I find it important to leverage them as much as they deliver value but do recognize that they are flawed and often do result in exclusive work.”

“I think personas are a stepping stone to a future method for making designers and product owners consider all of their different use cases. However, In the cruise company I work for, they’re far too many (30+ and counting!) and intersectional to ever be handled well by personas.”

“I’m anti-persona! Mostly because our team is always time-crunched and I’ve never had time where it would have been more valuable to have a fleshed-out persona with demographic data.”

As you see, some answers were very concrete in reasoning, while others made clear for them it’s contextual. As I went through the discussions, it made me retrospect my own takes on personas and my personal learnings from my diverse work experience. The rest of the post follows the overarching discussion on personas, accompanied by the most common questions that tend to arise:

“Are personas needed and when is it justified to use them?”

Personas are one of the ways we can determine how our product/service/solutions can be of utility to our target users, but it is imperative to understand they have their own limitations and constraints. Some kinds of projects require personas and sub-personas, while others are way too complex to even use personas.

“Are there ways to define our target users other than personas?”

Oh definitely. I’ve learned about the various other ways by working with product managers and marketing folks, taking some things out of their playbook. It pays to keep your eyes and ears open, and learn from whoever you work with, even those relatively younger and in different roles. I’ve accumulated most of my sound knowledge from my peers in the workplace.

Nothing is ever black and white in design. It’s taken me a sizable number of years of industry exposure and design networking, to distill the way we can define our users with certain approaches and practices. There’s a whole world of defining users out there!

Here are some ideas of identifying target users, that I've taken forward from my own experience with food delivery:

Personas for the restaurant platform

For restaurants, confirming customer orders and marking them ready for pickup by delivery partners on the app is a daily routine usually performed by the same individual. In small restaurants, the owner usually multi-tasks between managing the restaurant and fulfilling online orders—in which case they can be a primary “persona”. However, for big restaurants and food chains like McDonald’s, Burger King etc, the owner usually oversees entire branches, delegating the handling of online orders to a staff member, usually a restaurant manager. In this case, the primary persona is the staff member, with the owner as the secondary persona.

When you add more players like area managers, city level managers, restaurant staff who focus only on fulfilling and packing online orders, etc, then it requires the designer to define multiple personas and sub-personas across the entire restaurant ecosystem. However, since these users perform the same actions day in and day out, personas allow us to document their key pain points through observation and analysis.

Personas are useful for products which are extremely functional and operated in a consistent manner day in and day out. Healthcare industry, factory automation tools, hospitality industry, and many other high-functioning verticals can be improved through identification and understanding of well-defined personas, but only if backed by the right user research methodologies and effective questionnaires.

Situations for the delivery ecosystem

When it comes to our delivery products, here’s where the wind starts blowing in a completely different direction. Unlike the restaurant industry, food delivery is a gig economy. The delivery partners are not employees of the company; instead, any person who opts to deliver for the company has the option of full-time, part-time, or weekend-only deliveries as per their availability and preference.

There are clear reasons why personas would not work for us in solving for delivery partners:

• Delivery partners don’t have any commitment to the company and can flit between full time / part time / weekend based on their personal situation.
• The pay and rates are different for all the 500+ cities in India that Swiggy operates in. To account for hundreds of thousands of delivery partners, using a broad persona spectrum of part time/full time/weekends only could help us with the direction of our designs; however, we have seen that a much deeper understanding is required to provide answers to the right questions.
• The delivery job is rather thankless, and delivery partners are at the mercy of the external environment, traffic jams, multiple distractions, and no idea when the next order would come for them. There is no fixed set of behaviours that we can assign to them.

So rather than rely on personas, we focus on designing an optimal product experience which works for anyone who uses the app. We conduct extensive on-field research sessions, and take regular feedback loops from fleet managers, to give us signals on which areas to improve. Our roadmap includes projects that provide noticeable improvements in usability and communication related to orders and payments.

Some good examples of focusing on problem areas instead of personas are:

• Enabling delivery partners to be able to read info on the app in harsh sunlight, overcast conditions, rainy conditions etc (solving for situational disabilities)
• Enabling delivery partners to locate charging points, drinking water provisions, public toilets etc (solving for humanizing shifts)
• Enabling delivery partners to find women-friendly utilities during their shifts
• Making payments information clear and understandable and allowing them to withdraw their earnings at any time (solving for unpredictable needs)

Archetypes instead of personas

Ah shit! Here we are, in the belly of the real beast—the million customers who order from Swiggy every single day. Here, food ordering and delivery is driven by continually evolving needs on a daily basis, and identifying patterns in food delivery is like looking for a needle in a stack of other needles!

In such cases, a persona would completely fail to define the extent to which we are solving for the customer. However, when your food delivery app has 1 million users transacting every day, you need to be able to define user segments to provide a more personalized experience. Therefore, instead of using personas, we focus more on “archetypes”.

Here are some instances where I can exhibit different food ordering behaviours:

• I can plan my meals some days and wing it other days.
• I can have sudden late night cravings and order ice-cream.
• I can fall sick one day and just decide to order instead of cooking.
• I have guests over and decide to order something in bulk.
• I came home later than expected from work and am too tired to cook.

User archetypes are our way of classifying our users based on their spending power, the type of city they live in (tier 1/tier 2/tier 3), the kind of restaurants they prefer to order from, the number of dishes they order each time (are they single or have family?), and so on.

• So while Prazy can change his ordering pattern based on his situation and changing needs, we all know that Prazy will order only from high-value and healthy restaurants and generally order one meal and one dessert/beverage along with it since he is supposedly a bachelor.
• Lucy is a working mother with 2 young kids, and she tends to order fast food on alternate weekends for the entire family from McDonald’s or Burger King, usually with a cart value of \$15-20.

So instead of a persona defining Prazy and Lucy, we use archetypes across our entire target segments and try to find out which archetype these users belong to. Archetypes can be thought of as sub-personas, but with roots in marketing and product research. Archetypes allow our team to be able to correlate ordering behaviours across multiple nuanced segments, allowing us to scope down the design framework to solve for visualizing the customer journey for users in each archetype.

These are just a glimpse of the complex and time-consuming thought processes and practices that revolve around defining the users of your product. Personas are definitely a valuable tactic towards garnering critical information about the users we are designing for, but their effectiveness and utility depends on the daily habits and needs of the target users — if users exhibit variable behavorial patterns with respect to the product usage, it's worth pursuing other ways of solving for them outside of personas.

Regardless of the route we take in identifying our users' patterns, the fundamental fact remains that user testing must be carried out to validate the hypotheses and derivations from our user identification exercises. From my personal experience, field research and contextual interviews have uncovered more in-depth insights and surprising details about the users we design for, as compared to drafting user profiles from the comfort of our desks. I fondly recall the pre-CoVid days where I would travel to different cities with the research team for multiple projects and never fail to be amazed by the new bits of knowledge I glean from all sessions with the research participants.

I hope whatever I’ve surmised in this post adequately answers the question “When is a good time to use personas?”. I would also urge fellow designers to uncover other means of extracting valuable user backgrounds that can enable us to design the right product market fit for our target users, just by talking to product managers, strategy folks and marketing folks.

If Ted Mosby were a product designer instead of a failed architect, then the saying would go:

“And kids… that’s how I feel about personas.”

---

A candid admission footnote: I have sheepishly not even watched How I Met Your Mother, but he did some initial research because he bizarrely believes that Ted Mosby is the ideal persona to answer the question on personas.

---

What is your opinion on personas? Do you use them? Why or why not?

Join the conversation with other designers, developers, and product managers on our Slack community, or chime in on Twitter and Instagram.