The criticism that opened my eyes to the issues with Personas was this example from Alan Klement:
> Why did Alan buy the Snickers candy bar?
A. Alan is a thirty-five year old; has a degree in marketing; likes peanuts, chocolate, nougat, and caramel; loves Snickers, eats one every day; has an active lifestyle; drives a Honda; aims to retire from age 55
B. Satisfy his hunger
---
My other insight was that many UX firms treat artifacts like Personas as the deliverable. It is something concrete to show the value of the time and money spent doing research. But it is a deliverable that has almost no value to improving the product. The point of doing user research is to improve the product, not to produce a beautiful 20 page "research document". But translating user research from interview into fully-realized and delivered features is hard, and emailing a PDF of personas is comparably much easier.
The other problem with Personas being the deliverable is often they're a form of making the marketing person's personal preferences look like user research. So instead of testing what thirtysomething professional males actually respond to, the campaign gets designed around imaginary Alan's enthusiasm for active lifestyles.
(In an extreme example of this, "Stefan" who was conceived by an internal marketing team to illustrate how a certain niche used a certain industry website ended up as an actual marionette with social media profiles with 2000 followers, blog articles about his holidays and photos taken with some very bemused industry executives who were also encouraged to download Foursquare so they could check in with him at tradeshows. An awful lot of paying customers' actual needs got ignored at the same time as the marketing team were having fun turning a persona they'd conceived into a mascot though)
I find this comment really funny because "satisfy your hunger" is the primary marketing message that Mars pushes for Snickers.
So in the course of questioning the value of a marketing concept (personae), Alan is inadvertently demonstrating that he has fully internalized the Snickers marketing.
Maybe this was intentional? If you have a link for greater context, I'd be interested to see it.
Do you buy a Snickers bar from a place that only sells Snickers bars?
If not, then the question of why you chose Snickers to satisfy your hunger--as opposed to all the other options available for about the same price--is of deep interest to just about any snack company.
I'm amazed that anyone would choose Snickers if they were hungry. It's just sugar -- eat a snickers bar and you'll be hungry again in 20 minutes. Is this not common knowledge?
I myself would only buy a Snickers if I was having a stressful day and needed something to make myself feel better.
Except when it's cold. One the early selling points for Clif Bars was that they would still be edible after a couple of hours snowshoeing. I'm not sure if that's still true for their current products.
I prefer frozen snickers to room temperature. I think a lot of overweight people share this preference because it helps us slow down and enjoy the dessert over a longer period.
if one were to read the motivating factors behind personas as described in “the inmates are running the asylum”, one would never come up with A. If one were to follow agile in principle (do; evaluate; improve what hurts; repeat), one would not end up with capital-A Agile Industry prescribing process by the book.
This sounds like the same reason people avoided C++: after seeing lots of unnecessary complex C++ just for the sake of being “object-oriented” but entirely missing the point, who’d think it’s possible to write clearer code in C++?
Yeah. I think one of the deep problems is that people don't know why they're doing something (or refuse to admit it to themselves).
A lot of the very early Agile adopters were there because they sincerely wanted to make better software. They were willing to be bold and do a lot of hard work. But after them came all the people who thought the wanted to make better software. The ones who wanted to feel bold and have the appearance of change without doing much work.
Those people were ripe for the sorts of consultants and books and certifications that promised the moon while letting them slap Agile decals on the dumb stuff they were already doing. And what they were already doing was a lot of top-down nonsense that helped powerful people feel powerful. "Yes, Mr. Executive! This will deliver the exact thing you wanted! And it will be precisely on time, for whatever you mean by 'on time'! And have no defects!"
It was nonsense, of course. But it let people pretend to be doing what they wanted to think of themselves doing, while also letting them actually do what they really wanted to do.
Maybe it's because people aren't being introduced to personas in the proper context, with examples of proper usage? Personally, I've seen the concept in some software books and articles, but didn't really make use of it because my impression was that they want you to produce answers like the example A here, and then to magically divine some insights out of them.
> My other insight was that many UX firms treat artifacts like Personas as the deliverable.
This matches my (limited, anecdotal) experience. They can be used to demonstrate that a set of UX choices will result in a set of results, but don't by themselves say if those results are better than alternatives unless the alternatives are also run through the same test. Essentially they act as benchmarks. Benchmarks are not a good deliverable and have little value if you benchmark only a single option.
In my former life as a consultant I came to very much dislike personas as implemented by ux designers.
Personas are a magnet for prejudice: they are based on the idea that clusters of people all behave the same (old people, young people, professionals, stay-at-home mothers, what have you).
This very idea is, I think, flawed. If we really need to sort people into groups, then we should use criteria based on what people are trying to achieve right now, not inherent characteristics that are supposed to influence/define their behavior all of the time.
Therefore it would make more sense to have just one typical user, with different attitudes based on her -changing- goals.
I’ll throw out another (admittedly anecdotal) issue - cost and effort to develop something that - in my experience - isn’t all that valuable in the end. In my life as a consultant I’ve watched a team of UX ‘experts’ churn for 2 weeks over a set of 5 personas. Jaw dropped every time we would check in - this is what you spent the last 3 days on? Even more stunning was the client’s reaction to the 3rd review of those personas. It was the same 1hr convo as the previous 2 reviews, and no one seemed to think this wasn’t a massive waste of time and their money. After the personas were done, no one ever referred back to them for the remainder of the project. It was one of the greatest ‘value minimization’ excersises I’ve seen in my career.
RACI can at least be useful for defining who should be in what meetings early on, how communications should go out, and even CYA later on in the project. It can be good to have investment levels explicitly defined.
There are probably plenty of places it's useful that I've just never been exposed to, but I bet for every one of those, there's two or more others using it who don't need it, but only because they were sold it by management consultants at a lean management training course or something like that.
Yes, the very idea that customers can be bucketed is flawed. We are all unique people.
But we do not categorize our customers into buckets because we are denying their individuality. We do it because we lack the cognitive firepower to address several thousand people individually, by multiple orders of magnitude. Categorization isn't a denial of their humanity, it's an acknowledgement of our humanity, as opposed to being some sort of post-Singularity AI or Deity that is capable of individually addressing people. We have no options to address this flaw.
Pretending that we've just got one user who wants to routinely buy Depends, yet at others for no apparent reason, is intensely into punk rock, and on another day forgets how to speak English and is only going to interact with your site in Tagalog, is just going to distort your UI in other ways. I don't think acknowledging people's individuality is accomplished by only acknowledging one individual, with that individual constructed in such a way that this one individual is representative of nobody.
I think GP is fine with bucketing, but they're saying that f(age, gender, interests, ...) is not a good hashing function.
I haven't seen studies on the topic, but on the surface of it, I'm inclined to agree - it doesn't seem to be a good bucketing strategy, and unless we're talking about cold-calling/edge of the funnel, and painting in very broad strokes, it misses the most important factor uniting them all - they're on your site, so they must want something. Hence, "we should use criteria based on what people are trying to achieve right now".
it would make more sense to have
just one typical user,
Some products have users with distinct - almost contradictory - requirements.
For example, some spreadsheet users want simple graphs with big numbers that will look good in presentations, and a simple UI they can use on their phone. Other spreadsheet users want to make complex graphs with labelled arrows, thousands of points, multiple different graphs with aligned axes, and things like that.
Multiple personas can be useful for expressing that fact - otherwise you're stuck saying the just-one-user wants things to be simple and complicated at the same time.
OK but this is a 30 minute exercise: whom are we building this for?
I've seen talk about building personas where you try to specify all kinds of ancillary data about the personas: where they live, how many kids, etc.
I would love to hear about a time where the persona development led to a new insight because it's a persona. Like: this person's a parent-> probably attends parent-teacher groups-> voila! needs XXXX
When it's just abstract information, especially information that has no basis in user research, it is worthless.
But I'll give an example of where I've seen this be useful.
> Bob is a marketing guy. He mostly uses his mobile for calls, but doesn't have a headset. As a result, he can't type quickly while on the phone, so any UI he needs to use while on the phone should be optimised for mouse clicks or single keypresses.
This came out of some actual user research and was the justification for spending time on a 'point and click' friendly UI.
I know it’s just an example, but does one need Bob to come to that realization? If you say you’re building for mobile, you look at the strengths and weaknesses of input on mobile devices.
The biggest strength is precise finger movement. The biggest weakness is lack of tactile feedback.
That leads to the same conclusion without extraneous data.
I feel like personas are a way to force people to think critically about the end product. That’s not a bad thing, but just deciding to critically consider what your goal is before building something already goes a long way.
I think "does one need Bob" is the wrong way to look at it.
Humans are narrative animals. Storytelling is a human universal. Done right, personas are a way we can engage our narrative capacity to help us in thinking through the complexities of a domain. (Done wrong, they let our preconceptions and prejudices erase the complexity of our domain.)
I'm not personally a huge fan of personas. Instead, I'm big on primary user research, where we spend a lot of time studying actual people, their lives, and how our products fit into them. But if the group of makers is large enough, you need some way to organize the insights from that into something convenient for discussion.
At my last startup we were working on something related to purchasing decisions. For us, the satisficer vs optimizer distinction was key. We did dozens of user interviews, and user testing each week.
We ended up with two main personas, one for the satisficer and one for the optimizer. It was handy to be able to talk about Bob vs Cate in terms of how each would react to a given design choice. By having specific imaginary people made it easier for us to put ourselves in their shoes, to talk about how the product fit into their lives.
We would also talk about specific real people (e.g., user test subjects, actual users) and about theoretical constructs. But having fictional archetypes was useful to us in thinking empathetically without getting bogged down in a specific person's details.
If you tell the programmers that people need to be able to use a desktop web app with one hand, they're going to want to know why. Are there really that many one-handed users out there? Sounds like a corner case.
Personas are useful if they're backed by user research. That's how you know that yes, there really are a lot of "one-handed" users among your actual customers, and here's why.
It seems like one pitfall with personas might be giving them to developers without including any of the supporting research that makes them a valuable summary.
>If you tell the programmers that people need to be able to use a desktop web app with one hand, they're going to want to know why. Are there really that many one-handed users out there? Sounds like a corner case.
If your programmers are tightly integrated with product development, they should have access to the insight that makes it a priority in the first place.
If your programmers are removed from it, then they probably won’t care/ask.
I think you kind of hint at that in your last paragraph in mentioning sharing the supporting research.
Like I said, personas aren’t a bad thing, but things like user research are just good ideas anyways. Having user research lets you come to similar conclusions without a persona. If personas are what it takes to convince people to do things like crticically think and do user research about products before building I’m fine with it, but those are things you really should be doing regardless
I think of Bob as a team communication tool. Hopefully, most people on the team are familiar with Bob. When I'm working with someone else on that critical thinking thing about the end product, I can ask "What about Bob?" and teammates know what I'm talking about. Bob is a mobile user might not be complex enough to warrant a persona. I think personas are more likely to be a useful tool as the number of user types/goals increases.
Personas can also be a kind of checklist as a change is made, ensuring that the change makes sense (and doesn't break) in the most common product scenarios.
It's about trying to be empathetic about the end user. Yes, you get to the same result, but personas are mostly useful when it's very hard for the team developing a product to eat their own dogfood. It's a tool that could bring you closer to how the end user feels/could interact with the product.
The idea is supposedly to "get inside the heads" of the target user. This will lead presumably lead to some sort of intuition about what their needs are and how to market to them.
TFA sheds no light on the unique advantages offered by detailed personas.
The idea is to get the user in your head as a real human being not as an abstract category.
If you design for "User who needs product X" then you come up with different design than if you think about "Jim wants to buy a gift for his nephew's birthday, he is late, the birthday is tomorrow." You can better come up with ways to support Jim. You feel the importance of a speedy delivery.
You can also think about new features like asking this user if he wants a suggestion mail sent to him for next year (minus two weeks), that has present suggestions for kids that are 1 year older.
Now I just made that up, and it might be a terrible idea, but the point is, that you could never come up with something like that without a persona.
Hmmm. My product has "this cluster of users" vs "that cluster of users". But we really don't attempt to imagine their home-life. Or race or sex or orientation. Just what they are into feature-set wise.
EDIT: I think we call them "User-Type-A" and "User-Type-B". That doesn't sound very sexy - but it helps us prioritize feature development (esp. since "User-Type-B" never pays for anything - those features come last. But the non-paying user type is the most winge-ey - I've never figured out how that could be - but they are)
That's not contradictory. People need different things out of their tools at different times. People are not monotone. And understanding that one person can have N need is different than understanding that N people have individual needs.
Exactly. How does knowing that someone's favorite color is purple add to that? I can certainly see trying to understand these peoples' lives and what their needs are, but not having a team spend two weeks in Imaginationland to come up with it.
I disagree. Where website have a variety of different potential types of user, it can be useful to explicitly describe those different types of users, their needs and goals. Calling them Bob or Mary, can just be useful shorthand and avoid segments getting forgotten about.
In speccing and QA, I've always included a section on 'Works for Mary? Works for Bob?' etc. It's not rocket science and shouldn't be stupidly glossy in my opinion. But initial agreement can really help functional design.
I think the two are fairly closely linked. In my mind, each persona is essentially a group of user roles collected together and given a explanatory biography and a fake moustache
I disagree. The concept of personas is useful for abstracting the user's previous experiences and habits formed, not their current goals.
It's a useful abstraction that should be considered an abstraction and not a concrete example. When discussing 'stay at home moms', we're encapsulating the past experiences of such personas.
I think therein lies the real reason why personas (often) fail - no one establishes the connection from the personas to the types of user / customer segments companies will have already established, from analysing their sales data and usage analytics.
By contrast to something like A/B testing, which can produce actionable results, in my experience personas frequently end up as nothing more than MeetingWare, so that everyone attending "can be on the same page"
I think for some products this would actually be useful. Some products are inherently not exactly goal-oriented - Point A to Point B.
Take Facebook for example. It's not about achieving the objective of putting photos online, it's about the mystery of being invited to a website to share who you are with your friends and learning how you can interact through this new medium. It really mattered that Facebook targeted a specific demographic. If they didn't target that demographic exclusively, they wouldn't have succeeded, because college student's mom's would have been on there and they would have felt vulnerable, and found somewhere else to share.
Persona as a "mascot" for a scenario has been helpful for me. It helps to think through the idea from the user's point of view, not how the software wants to be written, so to speak. Having two personas for a scenario also helps to delineate a spectrum (i.e. a casual and pro user) when you're going to have users with different requirements going through the life cycle of your product.
Similarly, I hate it when vendors organize their site according to what they expect their customer's line of business to be, rather than the features that actually distinguish their own product or service lines. For example, AppliedMicro divides its products page into "data center", "carrier", and "embedded". So instead of browsing (or - dare I dream? - parametrically filtering) the product lines to find something with the features I need, I have to decide which hat I'm supposed to be wearing to be sold the right thing.
Yes. I particularly hate when I am in none of the categories yet want the product or service. Makes me feel like they have no interest in selling to me right off the bat.
I experienced this just yesterday, I'm pretty sure it was exacerbated by a website bug, but selecting "All Laptops" took me to just Home laptops, where the XPS line couldn't be found at all.
I ended up forgoing trying to compare all their lines and just selected the XPS section directly.
Did I want the "Datacentre" or the "Agile Datacentre"? Fucked if I know, all I know is that my servers aren't responding and your phone tree is fucking confusing.
I think there is a disconnect between what people think personae are for (improving usability for everybody) vs. what they are actually for (focusing resources on the few most important market segments). Focusing means that usability may actually go down for people who don't fit into those segments.
And of course like anything else, even if personae are conceptually sound, a company can still screw up in the execution.
I've done a few sessions using personas and can see little benifit to justify the time expended upon them. If generated out of thin air rather than from actual users it's just an exercise in exploring the teams predudices rather than any external market needs.
>In order for stakeholders to use personas, they have to believe in them, feel invested, and have ownership over them. The most successful personas are created with involvement from their end users. Otherwise, people will have no understanding of the data behind them and the rigor that went into creating them. Coworkers may think that the UX team just went away and played story time for a few weeks, emerging with these fake people and asking everybody to play along. That is NOT the attitude we want to foster.
>To avoid this pitfall, you must include the persona end users in the process of creating personas. Invite stakeholders to sit in on a research session. Send out a daily recap of the activities undertaken to create the personas. Help people see how your research uncovers the customer segments early on, so that when you roll out the personas there is built-in investment in their validity and value.
Important to differentiate between personas as archetypes and those based on stereotypes. The difference? Solid, hard-yards user research that comes from a large enough sample set.
That's my understanding too. The useful way to do a persona is:
1. Find a (real!) user of your product, that you believe to be more-or-less an "archetype" of a class of similar users
2. Start writing down his(her) workflows/ how (s)he uses your app/what (s)he's trying to achieve, etc.
AFAIK my company is even preserving the real first name of the "persona". If we're talking about real people, then it makes sense to use their behaviors/needs to guide the design of the product. If we're talking about imaginary people... well, you're just optimizing your product for some imaginary user :)
"Solid, hard-yards user research that comes from a large enough sample set"
Unfortunately, not so simple in my experience. That's a lot of time and money many companies can't or will not fork over. So, shortcuts and approximations are used as an alternative.
Agree, unfortunately that is the tricky aspect:
evaluating the cost/benefit of undertaking user research (with personas as one aspect, along with diary studies, interviews, observational studies et al - depending upon the nature of the tasks/problem to solve.
What definitely costs companies a huge amount of time and money is launching new products or concepts into markets - especially without some form of pre-qualification i.e. is there a need? does this solve a problem? will customers actually pay for this service? etc.
As the old user experience adage goes: "spend $1 on usability and save $100* down-the-track".
This seems like the right answer- I wish it was higher in the thread. Do you have a reliable reference? As I said in another thread I'd really like to see examples of insights that were arrived at due to the use of personas- at least where personas made getting that insight more efficient.
One of my favorite examples of where personas really helped was driving both strategy and design for a wholesaler.
Through research, one of the personas that fell out was "man with a van", that is a sole proprietor who did most of their work out of their van. Two key insights were:
1) The median age was higher, being in the 50s they were starting to thinking about the retirement and handing over the business. Even if they had little interest in engaging with digital, their protégé would, and ignoring digital would mean losing market share in the future.
2) They were on the road a lot, and mobile-based experiences would be helpful over having to call/fax orders, bills, etc. However research showed that their biggest complaint was the small size of UI elements for both reading, and more importantly clicking on (lots of complaints about how hard mobile website were to use with fat fingers).
I hope this was useful; I find well developed personas useful to keep in mind the disparate users of a system, what they are trying to achieve, and how. There was a comment about validating personas as part of user stories, which I'd recommend.
That is a useful anecdote- thank you. Just to be sure I unerstand: You had an intended customer base who used a mobile office of sorts, and by exploring the persona you could drill down and discover certain usability issues as well as a future to bear in mind. The persona exercise helped make this clear.
Something like this, fleshed out with more detail, would have been great to include in the original article. It shows how personas can be a useful framework for exploring potential markets (or niches, maybe).
Just to clarify, the intended customer base was made up of various types of customers over different axes: big companies, small business, people that work in purchasing, people that recommend products, and so on.
It's useful, to me at least, to come up with personas that are based on clusters of customers (based on research) so that every design choice can be validated against the impact to them. Each persona may have a different goal or priority.
The other use is when thinking of scenarios for personalization, what data can be used to segment customers?
It might be useful to have a dashboard on the homepage showing the status of POs and bills for somebody in purchasing vs. showing previous items ordered to facilitate reordering for somebody else.
Interesting how hardly any of this page is specific to "personas". Anything created without a clear intent to use it, or created in a silo and then imposed on the rest of the organisation, is likely to fail.
It’s more fun to play what-if with your fellow devs. We like to blame everyone else for feature creep but we add plenty of our own too.
That’s a big part of what personas are for. To get out of analysis paralysis, and stop adding features that add combinatirally to the complexity of the app.
It still makes sense to remind, that UX processes are not exception here. Failures of classical software engineering may feel distant and even not applicable to an agile team focused on UX, so some good explanations on why this also happens in the UX domain, and maybe even as a part of their process, are helpful.
It also depends where you use these. While personas are often low value in product design and UX (where JTBD can shine), in marketing and sales personas can be a big help (although even there, JTBD has strong role).
A lot of straw manning in this thread. Personas can be a very useful way to characterize your product's users. There are other ways as well. Each have their pros and cons. Personas are great for deriving a small covering set of concrete user types that can be used to guide and sanity check your design choices. It allows you to gather a bunch of user requirement info once and package it in a reusable way such that you don't have to do new research for every new design choice that pops up.
Have a new new design question about user needs or motivations? Consult your personas.
If the personas don't answer the question? Do some additional research and expand your personas.
Personas not the right fit for the question? No problem, use another tool like classic functional user requirements for this question.
Personas for food ordering apps demonstrate the usefulness nicely. You want to know the preferences that segment your users like restaurant quality, cost, and healthy options as well as demographics like age and income. From this you can derive a few clusters, and ultimately personas. Useful ones like "Jeff, the young workaholic that needs dinner brought to the office each night" or "Tom and Sarah, parents trying to find decently healthy takeout options for their kids". Now you can ask questions like, "do we have enough healthy options that Tom and Sarah's kids will like?" and "do we have an easy way for Jeff to reorder weeknight meals? Do we need a subscription plan?" You can do similar things with other user research tools but personas are very natural and intuitive for many scenarios.
Although this article talks about them from the perspective of UX, personae are fundamentally a marketing concept. They are simply a handy abstraction to help non-experts reason consistently about market segments.
This is like using the idea of "selfish genes" to help people reason consistently about natural selection. We don't think that genes are actually selfish, any more than we think that all customers fit into a few neat buckets. It just tricks the mind into adopting a different perspective.
It matters for product UX because your product will only serve the people who experience it, and people will only experience your product if you market it to them. (This is often where developers, who tend to look down on marketing and PR, fall off this wagon. But it is largely true.)
If you want a basic concrete example of the value of personae, then compare the bathrooms at an elementary school vs a bar. You're not going to position the fixtures the same way in both. But in order to reason about that, you need to first know who is coming into the respective establishments, and why.
As a marketing person, I can confirm that they can often be a useful abstraction, particularly when collaborating with people who need to get the general direction of an audience, but aren't necessarily data nerds who need to be intimately familiar with the detailed demographics, psychographics, technographics, behavioral data, etc.
They absolutely have limitations and can overly simplify things to a fault sometimes, but as long as everyone gets that it is a representation and not the absolute, they can help streamline things.
A golden quote by the author, from the comments section:
> In the end, there is only one user story: "As a human being, I wish to breathe, drink, eat, procreate and accomplish other, more abstract tasks of my own choosing."
Personas are always just a projection of bias whether from the UX team or from stakeholders. They are absolutely a useful tool, but often abused.
Too often I saw tickets written by product owners with stories like "As user type X I want to be able to do Y when I'm in this situation" where there was no empathy in correlating the actual functionality with anything to do with the persona and they literally just wanted that functionality in the system. Which is fine, but at that point admit your persona system is bullshit and you're just doing opinion lead development.
While Personas may plausibly work as an aide for marketing program development (a convenient way to abstract audience preferences), it is fundamentally doomed as a useful UX design concept.
Any product or software is a TOOL to get things done. The UI is the exposed interface to allow that work to be done, whether it is the deign of the handle on a hammer, or the menu/button/etc. structure. The good UI makes it obvious and easy to perform the actual task or tasks for which the tool is intended.
A "Persona" is simply too vague a spec to provide guidance on how to design a more usable tool. What is needed is a clear concept of the tasks to be done, not some abstract set of demographic characteristics, motivations and attitudes.
UI design is not the same as UX design, important difference and potentially a source of misunderstanding. If you are at the point that you know that a page with a certain purpose needs to be made, then the UI is often not that hard to design and you can make use of best practices, a/b testing, etc.
But for UX design, you also need to figure out the "clear concept of the tasks to be done". Taking the perspective of the persona helps you define the list of tasks to be done. If a hammer is needed, a screwdriver or a phone (to call someone who can build things).
All people in the creation process have an idea about who that user is and what their needs are, by making it explicit you make sure you are all on the same page building the same thing.
To add a metaphor; when you design a class, you could say 'all i need is to know the purpose of the class, the API is enough'. But how would you define the API if you don't have a deep understanding of what the higher level purpose is of the class? The architecture used, related classes, etc.
Perhaps the class you want to work doesn't actually needs to be built at all because it will be never called!
Same goes with UX, it's first about the knowing the purpose of the program, architecture, the content, how it's related, etc, then you try to define the classes ('pages') and their API's ('what needs to be done on the page'). Once you know that, often the class ('the UI') is probably easy to build. But you'll probably make a better class if you understand why it exists in the first place.
Agree that this is a higher level of design abstraction.
Yet, I still do not think that it is a high enough level of abstraction for a Persona to be useful (you need to get out to marketing, if they're ever useful).
Even at the 'What classes/pages/workflows do I need' stage, what you really need is living users who are domain experts who will actually use the tool to identify both the tasks and the ways they might best be accomplished.
There's a reason that many of the best products are designed by someone who was building them for themselves as Customer#1 -- they internally knew what was needed.
To extend the metaphor a bit - you're trying to design an improved hammer, but how helpful would it be to consider the "Joe Carpenter" Persona and what he'd want, vs talking to a bunch of live carpenters and finding that they really have good hammers, but actually need better nail-pullers? The persona will get you nowhere, but the actual carpenters will get you a new market and product that sells.
The best persona's are based on interviewing real people, and I totally agree that you need to keep doing those interviews to validate your design and when the site/app/whatever is live.
it's not always possible to be your own target audience, for instance every time you design something for someone who doesn't care about how technology works :).
To add/stretch the metaphor; I get why (big investments in) personas can feel like a waste of time, in the same way that you can waste a lot of time on software architecture. It only makes sense if the team is going to use it. And even then for simple projects it may be fair to say that common sense is good enough. Still it can't hurt to invest 20 minutes in talking about the architecture/personas just to be sure we're all somewhat on the same page.
Of course it's not possible to always be your own target audience, just an ideal example. Yet your counterexample is also interesting. I'd say that you need the best domain expert to design something for someone who doesn't care how tech works. Obviously, this expert canNOT be one of those myopic tech-centered geeks, but the essence of designing for non-tech users is to understand the tasks & goals at a very deep level so that you can effectively simplify the UI & process.
I'm all over architecture, as that can really simplify the dev, maint, upgrade, sysadmin, & running processes.
But it'll take a lot more than these examples to convince me that personas are useful for development.
I could be convinced that Personas are useful for marketing, but that's because I don't know that much about marketing ;-)
So you get that best domain expert in the room with (part) of the team and then the team needs to document the knowledge it has learned, to make it easy to reason and discuss design choices for when the domain expert is not around..
"I could be convinced that Personas are useful for marketing, but that's because I don't know that much about marketing ;-)"
I guess the marketing people are right then. Everything is marketing :)
They should be documenting the actual micro-detail of the tasks themselves, what are the essential inputs & components of the tasks as well as the signs/outputs/feedback that helps the user do it correctly and efficiently.
Zero of this detail has any significant or useful relationship with broad characteristics of some abstract set of demographic characteristics, motivations and attitudes.
The team should NOT be attempting to abstract the domain expert's knowledge into some silly Persona, which will lose all of the micro-detail about how the person would actually perform the task. It'd be like trying to build a car and talking about the paint color after you just interviewed the suspension expert that told you about the key factors to the performance being how you keep the tire in contact with the road at the proper angles and pressures.
If you are designing a hammer, it doesn't matter if the user is a small high-school girl or an ex-Marine weighlifter, the characteristics you care about are hand size and grip strength, and the range of sizes and types of nails being driven. (The actual roles might be a small guy on the Asperger's spectrum and a Woodsman competing woman -- the persona is irrelevant)
If your app is balancing a checkbook, it doesn't matter if it is a high-school kid with their first account or a middle-aged worker -- the relevant data is the key numbers on the screen, and the degree of background knowledge they have which might influence what relevant data they want to see (e.g., novice vs expert mode). The persona tells you zero about the skill set or assumptions -- you need to know the detailed skill set.
Their age/sex/race/preferred clothing/music/etc. is utterly irrelevant.
I sincerely hope that you are not attempting to build tools of any sort, because with the kind of garbage you promote as input, for the output, I don't expect much...
"the characteristics you care about are hand size and grip strength"
"the degree of background knowledge they have which might influence what relevant data they want to see (e.g., novice vs expert mode)"
If your research shows you that those are the relevant perspectives to take, then you will base your personas on these main skill sets.
"Their age/sex/race/preferred clothing/music/etc. is utterly irrelevant."
You only include the qualities that make it a human being, so you can think of this person as a human. So yes you need gender, age, race. If they are not relevant to the task at hand, you can just take the average of your (expected) user base, so no need to spend much time on that.
As for micro-details, you like to have a perfect list of all essential. In the beginning of the process this is often not known. It's the job of the UX designer to figure out what is essential. Sometimes it's obvious, sometimes it's not.
"I sincerely hope that you are not attempting to build tools of any sort, because with the kind of garbage you promote as input, for the output, I don't expect much..."
How sincere.
My goal is not to promote my skills, but to explain how personas are used in the UX process in practice to those who are curious about it. Let's say Jim, 31 year old back-end developer in Boston who want to move into front-end development and is curious about how UI and UX comes about in practice.
Secondary personas is me. I'd like to learn what the thinking is behind the negativity you see in some of these comments towards personas.
My current understanding that the negativity is based on a misunderstanding of what UX design is (it's more than usability and UI design), and bad experiences with personas in the past what wasted a lot of resources on 'irrelevant micro details'.
You seem quite passionate about providing a good user experience. Everybody has the right to be grumpy every once in a while, so I sincerely hope you have a nice day!
OK, here's the thinking behind the negativity towards personas:
it is an unnecessary abstraction that makes you think it's helping you, but actually impairs your ability to deliver good tools.
To really deliver good tools, you need to get as close as possible to the actual user, ideally becoming one. I found that having a manager in the user company "gather user requirements" and deliver them to us in meetings (sometimes requested by clients thinking it would reduce costs) dramatically degraded what we could deliver and increased schedules and costs, compared to having the devs talking with and sitting next to the users for even an hour. (and yes, we did talk to the mgrs as users for their specific needs too)
Personas are an even worse level of abstraction than talking only to the managers.
You must focus on the very details of the interface where the rubber meets the road, not on some 3rd- or 4th-level abstraction.
Even in you get all the micro-details and include then in your "Jane Persona" abstraction, it won't help you interpolate the data sets from Task A and Task C to figure out how to implement Task B any better than looking directly at your two data sets. And, talking to actual user "Jane Real Person" will beat both of those options, because you'll probably learn something new.
Always go as close as you can to the source. Abstraction is often just a good way to fool yourself.
Can't reply to your comment, so I'll just say over here, thanks for clearing that up.
"I sincerely hope that you are not attempting to build tools of any sort.."
First, don't insult people like that, it makes you look small minded. Secondly; I'm working on a text command based ux tool :), you might just be my target audience.
Fair enuf, mostly referring to the handicap you'd be working under w/those abstractions. (should have written "not developing tools under that handicap..." or similar)
The article mostly suggests that personas are just done wrong, and that's why they fail. Has this method ever actually been proven to increase success? In my experience, they always end up being hideous stereotypes that nobody takes seriously(for good reason).
Personas are primarily a mapping tool for providing the team with a library of potential users, their background and needs with relation to your product and to which the team can design up against. They fail (at being useful) because they often have very little to do with the actual user's situations.
A better way IMO is to use customer support to figure out who your users actually are or go and speak with your users and learn what they actually want.
We never recommend doing them unless a project needs a lot of documentation for a lot of switching hands and you are worried that some of the insights might be lost on new team members.
As a design tool they aren't really that helpful for anything.
Funny title that everyone reads and goes on with their comments. The article was saying Personas in their current form fail. Mainly, because the companies that design professionals use them for are not being utilized together with the clients involvement. They aren't being translate throughout the entire design process, they are for understanding design reasoning, instead of always bringing up random things a customer may need, they are compacted into easy to id personas, and that is what they are for. Simple recall, for clients and designers to have a common vocabulary to talk about who we are solving problems for.
I feel like I need to point out that in my experience demographic personas like this aren't used by product designers. I've seen marketing use them. Not designers.
Designers often get associated with fluffy exercises so I want to kill that stereotype. I don't think I've ever worked on a product team that used demographic personas like these.
That would require real effort instead of storytelling during work hours.
Whoch is harsh, but that’s the point. You are going to get far more insight from real customers than you are from one relatively homogenous sub-department’s imaginary beliefs about who your customers might be.
IMO the latter is pretty much the definition of one of David Graeber’s bullshit jobs.
There's nothing more valuable than watching customers actually use a product. Almost never will they do it the way you expect, and absolutely never will they want to do it the way that the designer intended. Nothing points out a painful, complicated, broken, confusing UI as quickly.
It may make sense, when you have 10 users, but then you can just skip profiling (and, by the way, profiling real users, at least in EU, is strictly limited from legal perspective - it just doesn't worth it). When there are thousands of users, real customer contacts may create unnecessary bias. There's no "average" real person, which means that serving the needs of one real person, you may hurt others too much. Personas are synthetic profiles for a reason: they cover the whole audience of the project or feature.
> Why did Alan buy the Snickers candy bar?
A. Alan is a thirty-five year old; has a degree in marketing; likes peanuts, chocolate, nougat, and caramel; loves Snickers, eats one every day; has an active lifestyle; drives a Honda; aims to retire from age 55
B. Satisfy his hunger
---
My other insight was that many UX firms treat artifacts like Personas as the deliverable. It is something concrete to show the value of the time and money spent doing research. But it is a deliverable that has almost no value to improving the product. The point of doing user research is to improve the product, not to produce a beautiful 20 page "research document". But translating user research from interview into fully-realized and delivered features is hard, and emailing a PDF of personas is comparably much easier.