Crappy Personas vs. Robust Personas

Jared Spool

November 14th, 2007

There’s been a lot of discussion lately on the Interwebs about how personas are a useless tool. 37Signals’ Jason Fried recently wrote:

We don’t use personas. We use ourselves. I believe personas lead to a false sense of understanding at the deepest, most critical levels.

Every product we build is a product we build for ourselves to solve our own problems. We recognize our problems aren’t unique. In fact, our problems are probably a lot like your problems. So we bundle up the solutions to our problems in the form of web-based software and offer them for sale.

We recognize not everyone shares our problems, our point of view, or our opinions, but that verdict’s the same if you use personas. Making decisions based on real opinions trumps making decisions based on imaginary opinions.

I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist.

There was a lot of discussion on Jason’s blog, with many sentiments similar to this one from Mimo:

I never heard of Personas before. Now I read it on wikipedia. The idea sounds interesting. But I think at the end of the day it is crap. The product is always shaped by two things. YOUR experience (your present ego and YOUR idea (your future ego).

So, to add into the fray, here’s my thoughts on using personas:

It takes virtually no skill to build something crappy

No one is going to make you use personas. If you create a design without using personas, I’ll promise you the sun will continue to rise on schedule, without variation. The universe will remain intact.

However, how do you know you’re actually meeting the needs of your users? After all, that is why you were designing in the first place, right?

Some products, like the tools built by 37Signals, don’t need personas. Not because the folks at 37Signals have any special powers, but because they themselves are the personas they want to build for. They build tools they like to use themselves. For them, that will work great.

Not all teams have that luxury. A hospital IT team, building software systems used by critical care nurses in the hospital’s pediatric intensitve care unit, are not building tools they will use themselves. They are building tools used by others whose education, experience, goals, contexts, and tasks are extremely different.

A well-built, robust persona set can help educate the IT design team on what it’s like to be a critical care pediatric ICU nurse and the things they need to deal with. This information will inform their designs. And good personas help inform the design process.

Oh My God! They’re Made of People!

In his post, Jason says:

Personas don’t
Personas don’t talk back. Personas can’t answer questions. Personas don’t have opinions. Personas can’t tell you when something just doesn’t feel right. Personas can’t tell you when a sentence doesn’t make sense. Personas don’t get frustrated. Personas aren’t pressed for time. Personas aren’t moody. Personas can’t click things. Personas can’t make mistakes. Personas can’t make value judgements. Personas don’t use products. Personas aren’t real.

People do
People talk back. People answer questions. People have opinions. People can tell you when something just doesn’t feel right. People can tell you when a sentence doesn’t make sense. People get frustrated. People are pressed for time. People are moody. People click things. People make mistakes. People make value judgements. People use products. People are real.

It’s clear that Jason hasn’t used robust personas, because, when designed well, they do all these things. Jason hasn’t had the Soylent Green moment to realize that well-designed and researched personas are made of real people — real people who you can ask questions of, observe their frustrations, and discover their true goals.

I can see where Jason’s coming from. Recently we conducted a study of several dozen organizations who claimed to use personas. Less than 5% actually conducted field research to inform their personas. The remaining 95% just made up the descriptions from internal guesswork.

If you’re just going to guess on the personas, why bother? Just design for yourself, like the 37Signals team does.

However, when you do the field studies, you create relationships with the people in your research. You can return to those people and ask them questions. You can learn about the things they do.

The persona becomes a package for containing what you’ve learned from your field research. A package that is transportable to everyone on the team, so they can have the same benefits of knowing the users as you have.

Once you have well-designed, robust personas, you can take advantage of the benefits that come from them:

  • Preventing Grounding
  • Using the Oral Tradition
  • Role Playing

In our research, teams that utilize robust personas find they create better designs, especially for things they wouldn’t normally use themselves.

I’m going to talk in great length today about building robust personas in our latest virtual seminar. See the description for more information. (It’s available live today and there’s still plenty of room. There will be a recording available shortly.)

42 Responses to “Crappy Personas vs. Robust Personas”

  1. Hugh G. Says:

    Excellent point, Jared.

    We don’t use personas in my company, but I do make the effort to talk with the users of the application to understand how they use it. Which is always invaluable.

  2. Sam Says:

    Killer article, thanks! It makes the point that is often so lacking in persona development – the user research *needs* to be there. When I worked at Microsoft, we went out of our way to call user descriptions “profiles” and tell people to not call them personas if they were just internal guesswork and not research-based artifacts.

    And ultimately, it’s just a user research tool, like any other user research tool. It might not be best for everyone, but don’t knock it until you’ve tried it the *right* way, I always say.

  3. Brett Says:

    Thanks for the article, Jared.
    I’m in the process now of building Personas for our company’s internal application, used by a “front line” department that is far removed from our development team. Already my qualitative research has squashed two long-standing assumptions about users that have been passed on to project managers and developers. Until now, these assumptions have influenced enhancement designs for the app. Looking forward to your Webinar in a few. It couldn’t have come at a better time for me!

  4. HCNet » Blog Archive » Técnica ‘Persona’ y ‘Scenario’ Says:

    [...] sobre la utilidad y beneficios reales de esta técnica. Jared Spool ha escrito recientemente un interesante post defendiendo esta técnica a raíz de la crítica que previamente hacía Len Dierickx [...]

  5. Andrew Says:

    You know, one thing that persona advocates could do to start convincing people of their value is *publish some good ones.* Cooper, UIE, and other design firms that espouse personas have basically spent the last decade telling us: don’t write crappy personas. But there are almost no solid examples of great personas that actually added value to a real design project. If these things are so great, and really do all that stuff that you say, *show us some.* If Jason Fried has never seen an example of a robust persona, you should assume that there are thousands of working designers out there who also haven’t seen one. And no matter how many times we hear “good personas are great tools,” without examples, we don’t have any idea what that really means.

    No, these examples won’t be generically useful for all companies and all products, but at least there’d be something we could point to and say: “this is an example of what kinds of information in a robust persona led to specific design decisions.”

  6. Michael Hughes Says:

    Your spot-on point is that robust personas cannot be the product of fiction and fantasy. I think part of the bad rap comes from the cutesy, often irrelevant detail, we see in the “imaginative” personas that really doesn’t shed light on the user context.

  7. Andrew Hinton Says:

    I blogged about this a while back, and came to the conclusion that, to a degree, Fried & co are correct — you really can’t design for someone other than yourself. Which is why we need personas — they allow us to play the role of the user we are not, and help keep us honest about those people. (When they’re done correctly.) We can’t design for anyone but ourselves, which is why it’s so essential that we have great skills at pretending to be someone else.

    This is what Alan Cooper did, after all, when he hatched his persona-based approach.

    There’s an article for B&A in the editorial hopper that explains all this better (not published yet) but the very rough blog post I started with is here: http://www.inkblurt.com/archives/484

  8. Christopher Fahey Says:

    The remaining 95% just made up the descriptions from internal guesswork… If you’re just going to guess on the personas, why bother?

    Personas provide a fabulous way for people who understand their audience/users to communicate their understanding to people who do not understand that audience in a rapid and meaningful way. They are also a great way for people who have different understandings of their target audience (users, customers, etc) to reach common ground on who they are designing for, particularly if the objective is to expand into new audiences rather than simply to serve an existing audience. Neither of these uses of personas requires any original actual hard field research to be done. All it takes is a few good conversations and collaborations around a white board, and a little running around to gather existing documentation.

    This isn’t “guesswork”. It’s communication. In my experience (building web sites for smart clients) using personas in this way has been immensely powerful in ensuring that the new members of the team understand who they are designing for. And our work producing the personas themselves helps reassure the client that we, the design team, are on the same page they are with regards to who we are designing for. In my opinion one very common complaint about personas — that they are created and then ignored — ignores the important fact that the creation of the personas in the first place is probably the most important step, at least from the consultant’s point of view, as well as the initial sharing of them with the team. Without this exercise, our understanding of users is often based only on what our clients tell us in the kick off meeting, and maybe on research documentation that only a few members of the design team can ever be expected to fully ingest. A little stack of compelling personas, however, is a great way to get the design leaders in synch on the user strategy, and they will be consumed by the whole team.

    In all of these cases, please note that I am saying that personas are for the consultant’s benefit, not for the client’s benefit. We are not giving personas to the client to reveal information to them that they don’t already know. Rather, we are using personas to help us and the client reach agreement and understanding about knowledge that already exists, to help us move forward in the same direction. Personas, in this model, are the static artifact of a collaborative exercise, not the actionable product of rigorous research.

    I only say this because I fear that the idealized personas you and many others often describe and champion — which can quite frankly cost tens of thousands of dollars to produce — will discourage many designers from using them in other less rigorous but nonetheless powerful ways, especially when such large budgets are not available.

    Spending a single day building a set of ad-hoc personas using no research and without talking to real users or potential users doesn’t make the resulting personas “crappy”, so long as everyone understands the purpose of the exercise.

  9. Christopher Fahey Says:

    Andrew wrote: You know, one thing that persona advocates could do to start convincing people of their value is *publish some good ones.

    Absolutely. It’s all just talk, and highly idealized, too. Advocates of robust personas unfailingly paint dreamy idyllic pictures of wondrous projects where the team has hundreds and hundreds of person-hours budgeted for persona research. But we readers are left having to imagine how great, how non-crappy, their personas are. Show us the goods!

    Honestly I’m skeptical of how many “robust persona” advocates (a) actually make their personas as robust as they say, and (b) use them at all. Jared, I’m not pointing the finger at you necessarily — perhaps you are in the “if you can’t do em right, don’t do em at all” camp. Maybe your clients typically pay top dollar for really robust personas (and I completely agree that robust personas are the best way to go if you can afford it). But it is hard to bear the finger wagging sometimes.

    It’s also important to note that Cooper has published a few of their personas in the past, but I can’t see how they can be seen as anything but quintessential examples of “crappy” personas. A picture and a paragraph. That’s all, folks. The person who invented personas doesn’t even come close to measuring up to the yardsticks being held up today.

  10. Jared Spool Says:

    Personas provide a fabulous way for people who understand their audience/users to communicate their understanding to people who do not understand that audience in a rapid and meaningful way. They are also a great way for people who have different understandings of their target audience (users, customers, etc) to reach common ground on who they are designing for, particularly if the objective is to expand into new audiences rather than simply to serve an existing audience. Neither of these uses of personas requires any original actual hard field research to be done. All it takes is a few good conversations and collaborations around a white board, and a little running around to gather existing documentation.

    Christopher,

    I believe what you describing is not a persona but a user description. If you have a good understanding of who your users are, describing them for others to understand is an excellent tool.

    However, to be a persona, in our definition, it must be based on primary user research. The research could have been done months or years before the persona was created, but it’s still based on primary research. (The older the data, the more likely it becomes distorted, so I think it’s dangerous to wait too long.)

    User descriptions may or may not be accurate. Often, they are based on common myths about users (“all of our users are above average”) and miss a lot of the richness you get when you spend time actually watching and talking to users in their own environments.

    Well-crafted personas are more likely to capture that richness and reflect what’s really happening with users. For many teams, this is critical to build a common understanding and vision for the design.

    In all of these cases, please note that I am saying that personas are for the consultant’s benefit, not for the client’s benefit. We are not giving personas to the client to reveal information to them that they don’t already know.

    In almost all cases where we recommend personas, it’s when the client team has little or no actual knowledge about who their users are and what they really do with the design. In many cases, it’s when the team has focused all their previous efforts just trying to get the functionality to work and implementing features offered by competitors. These teams are finally ready to think about designing experiences, having the sudden realization they know very little about the experiences users are currently having. That’s where personas have the most value.

    I only say this because I fear that the idealized personas you and many others often describe and champion — which can quite frankly cost tens of thousands of dollars to produce — will discourage many designers from using them in other less rigorous but nonetheless powerful ways, especially when such large budgets are not available.

    Good design isn’t cheap. The clients we work with typically have annual revenues in six to eight figures, so spending $10,000-$20,000 on really getting to know their users isn’t a hard pitch.

    That said, it doesn’t have to be expensive. If you can free up 2 to 4 people’s time for 25 hours a week for four-and-a-half weeks, you can build very robust personas with little additional expense. Again, when it’s important, teams seem to find a way to make this happen.

    Spending a single day building a set of ad-hoc personas using no research and without talking to real users or potential users doesn’t make the resulting personas “crappy”, so long as everyone understands the purpose of the exercise.

    I’ll agree that spending a day documenting what the team thinks they know about their users is an excellent exercise. However, these aren’t personas (and if you insist on calling them personas, we’ll consider them crappy).

  11. Jared Spool Says:

    Andrew wrote:

    You know, one thing that persona advocates could do to start convincing people of their value is *publish some good ones.* Cooper, UIE, and other design firms that espouse personas have basically spent the last decade telling us: don’t write crappy personas. But there are almost no solid examples of great personas that actually added value to a real design project. If these things are so great, and really do all that stuff that you say, *show us some.*

    The quality of persona shows in how it manifests itself in the way it influences the design team to make smart decisions.

    Unfortunately, the paper document describing the persona doesn’t represent that at all. Showing personas is like showing design specs — you can’t really tell the good ones from the bad ones by reading other people’s documents.

    Instead, you need to look beyond the document in how it was created. What makes a good persona is how the research and analysis that went into was done. I can walk you through the process (and just did in today’s virtual seminar), but the end deliverable will look the same to an outsider as a crappy persona deliverable.

    That’s why you never see them.

  12. Jay Zipursky Says:

    I’ve always maintained that the persona “destination” is not as important as the “journey”. As Jared says, personas without research are more than a waste of time.

    However, I’m more skeptical whether a persona can stand on its own without the people who either did the research or those that analyzed the research. In other words, is even a well-researched persona description useful to a designer who’s never met a real-life user? I suspect writing a persona that is that useful is a challenge.

  13. Jay Zipursky Says:

    I see Jared addressed my comment before I even wrote it! (Serves me right for not refreshing first.)

  14. Daniel Szuc Says:

    Speaking with users to create Personas helps.

    It shows a project team new to the technique that:-

    a) Its important to speak to your users i.e. using user interviews and

    b) That the feedback to help create the Personas can reduce internal argument or speculation about a feature.

    We recently used this approach to show that users did not like the amount of copy being displayed on a Home Page (that we were tasked with redesigning).

    Now we could have said this based on best practice or expert review, but to have this come from the voice of our users and then demonstrate this in our Personas really helped our cause.

  15. Mimo Says:

    ok. now i know more about personas.
    or let’s say: you are using another kind of personas then wikipedia is describing them.
    building a relationship to the users who will use the product you design is the best thing to do.
    even if you are already the guys who will use the product yourselves.

  16. pauric Says:

    Jason: “They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist.”

    When a persona skeptic sees Robert DiNiro in The Godfather, do they think..
    a) Mr DiNiro is really a mobster
    b) Mr DiNiro is acting out the role of fictitious person after having spent time researching the character

    In lieu of getting a real mobster for the role, someone can method act a convincing substitute to help flesh out the story. While clearly different, I see a lot of similarities with Personas.

    pauric

  17. Personas vs. User Descriptions; Apples vs. Tomatoes » UIE Brain Sparks Says:

    [...] always intriguing Christopher Fahey commented on yesterday’s post about Crappy Personas vs. Robust Personas: Personas provide a fabulous [...]

  18. Christopher Fahey Says:

    What makes a good persona is how the research and analysis that went into was done.

    It seems to me, then, that the best kind of persona would consist of:
    # A cover sheet which resembles the canonical persona — name, photo, age, goals, etc.
    # A couple of pages of stats and research excerpts to back up the first page, and to enrich the persona.

    … 2 to 4 people’s time for 25 hours a week for four-and-a-half weeks, you can build very robust personas with little additional expense.

    Heh, sounds like you’re in the $50-100k range already, at least by New York standards! :-) That said, I agree that for an organization with little knowledge of their users this is very much money well spent. But it’s important for people to understand that any essay like this one that says that personas must be robust should also say that they must cost tens of thousands of dollars and must take a month or more to produce, just so people can put their own organizations, clients, projects, and assignments in the proper perspective. The vast majority of practicioners don’t have this option, so perhaps it’s more important to target this essay at the decision makers rather than the practicioners. That is, it should be “Managers! Pay more money for user research!” rather than “Designers! Stop being lazy!”.

    In almost all cases where we recommend personas, it’s when the client team has little or no actual knowledge about who their users are and what they really do with the design.

    Your point is well taken that lots of organizations don’t know their audience/users at all. And some products have very specialized users whose needs are hard to discern except through direct observations and analysis. In those cases, it’s foolish to just generate personas from essentially thin air.

    But many other businesses and organizations actually know their audience extremely well, especially in publishing, marketing, and retail where research is conducted, evaluated, and tweaked constantly. Such businesses live and die based on their understanding of their users. We can walk into such a client’s office on day 1 and have access to years worth of server logs, focus group data, marketing plans, polls and surveys, sales reports, market analyses, etc. And we can talk to the people who make and analyze that research face to face. In those industries, the kind of personas I was describing can be created using existing research, and this can be done very quickly — in a matter of days, or even hours. So in this case the personas are highly research-based, even if the research wasn’t done for the explicit purpose of creating design personas.

  19. adrian chan Says:

    I was surprised at how lively the discussion about personas became there! I dont quite understand how expanding the user from one (myself) to some greater number of archteyped or stereotype, even if fictitious, personas can hurt. At a minimum to increase our ability to reflect on user needs in a variety of use cases…

    Interestingly tho, I think in social media/social web they may be pretty unnecessary. Here I think it’s more important that designers join the system in question (preferably a number of them), and use them, and then observe other users. There’s little need for personas in social media design because users exist, and they’re real.

    cheers,
    adrian

  20. Jared Spool Says:

    Adrian Chan wrote:

    Interestingly tho, I think in social media/social web they may be pretty unnecessary. Here I think it’s more important that designers join the system in question (preferably a number of them), and use them, and then observe other users. There’s little need for personas in social media design because users exist, and they’re real.

    Sermo is a social network for doctors and other medical professionals. Non-doctors can’t join.

    I’m sure the developers, while having participated in other social networks, could benefit from a well-crafted set of personas and scenarios, since this social network isn’t your father’s MySpace.

    So, I’d argue that not all social networks are immune from needing a well-crafted set of personas and scenarios.

  21. Personas: Gode råd & meninger » More discussions on personas have been published recently Says:

    [...] Crappy Personas vs. Robust Personas Jared Spool 14-11-2007 [...]

  22. Ukas lenker 16.11.2007 hos IAllenkelhet - Fagblogg om brukervennlighet skrevet av NetLife Research Says:

    [...] slår tilbake mot kritikken av [...]

  23. Len Dierickx Says:

    Great article, but I understand Jasons’ point of view and it probably comes down to what the the 95% of the organizations have when trying to design : no resources.

    I still believe that it is better to design for a persona that has been build with whatever you have (analytics data, sales department stories about clients, marketing reports but no real people) then nothing at all.
    Especially when you as a designer are not the visitor of your website or user of the tool you are building.

    A tool in the right hands can be very useful, even if that tools isn’t as powerful as it should be (no real people or marketingresearch).
    Tools (=personas) are rarely the problem, the problem starts when the people using the tool overestimate the value of the tool.

  24. Lite om personas « Begrepp Information Arkitektur Modell Metod Process Says:

    [...] Crappy Personas vs. Robust Personas (Av Jared Spool) [...]

  25. Max Design - standards based web design, development and training » Some links for light reading (21/11/07) Says:

    [...] Crappy Personas vs. Robust Personas [...]

  26. Bryan Says:

    Up until recently we had never used personas as a method of designing and assessing websites web built. A review of our organisations sites by an external contractor introduced us to their use, and I’ve got to say it made a lot of sense. There were a number of varied personas attempting to represent our varied client base, which were then used with ‘actual’ people carrying out scenarios to determine where things might be falling over. What an eye opener it was, I saw many areas that needed an overhaul, and equally some areas which they found worked quite well (thankfully one was my own!).

    Our challenge now is to construct additional personas for staff and visitors, who differ from the usual client base, so that their sections of the site can equally be moved forward.

  27. Personas Suck - Vlakonline Says:

    [...] In fact, the best personas are created out of exactly this type of research. As Jared Spool rightly points out, you shouldn’t mistake crappy personas for personas being [...]

  28. What I love online today | Lisa McMillan dot com Says:

    [...] Crappy Personas vs. Robust Personas » UIE Brain Sparks [...]

  29.   Creating robust personas by Communications from DMN Says:

    [...] They can be useful, but they have their limits. User interface expert Jared Spool recently weighed in on this subject, and came out in favour of [...]

  30. Weekly Link Roundup: Orange Juice Edition » resist - cleveland design Says:

    [...] Crappy Personas vs. Robust Personas Wufoo’s form templates and gallery. [...]

  31. twoday.tuwien.ac.at/uidesignweblog Says:

    Is using “Personas” a good way for design ……

    For the second blogtivity, we had to find a post on another weblog, writing a comment to it. When dealing with the problem, I found the following post on UIE Brain Sparks

    Crappy Personas vs. Robust Personas
    There’s been a lot of discussion lat…

  32. Personas and the Advantage of Designing for Yourself - Bokardo Says:

    [...] Fahey, picking up on a comment to Jared Spool’s reaction to Fried’s piece, proposes a novel solution that would help [...]

  33. Personas Suck | Editweapon Says:

    [...] – You know the thing about Personas? They suck when you build them sans field research. Why? Because you’re not supposed: …Recently we conducted a study of several dozen [...]

  34. Personas and Google Analytics | Own Page One: Search Engine Visibility Blog - Online Marketing Strategy and Tips Says:

    [...] provide, I found the article (and extensive related discussion, including on Jared Spool’s User Interface Engineering blog) to be enlightening regarding the value and methodology behind [...]

  35. Elizabeth Bacon Says:

    Shameless plug follows…

    Folks interested in this topic might like to check out a presentation I co-authored with Steve Calde called “Death to Personas! Long Live Personas!” from a couple months ago. It tackles some common criticisms of personas and reiterates Jared’s point that proper personas are based on real research. It’s available on Slideshare at http://www.slideshare.net/ebacon/death-to-personas-long-live-personas-presentation/.

    Best,
    Liz

  36. Nelson Vilhena Says:

    “We don’t use personas. We use ourselves. I believe personas lead to a false sense of understanding at the deepest, most critical levels.” Jason Fried

    “Some products, like the tools built by 37Signals, don’t need personas. Not because the folks at 37Signals have any special powers, but because they themselves are the personas they want to build for. They build tools they like to use themselves. For them, that will work great.” Jared Spool

    Designing for yourself is cool. It will work for you. The users (you) will have a broad understanding of the problem and of the solution you’ve just created. They (you) will need no training, no manuals, no support or things alike. Plus they (you) will love the user interface and if something is missing or not working properly they (you) will have a direct line to the people who built it (you).
    This is a fine solution for this type of users (you).

    But what if you have to design for somebody else? What if your knowledge about the problems you’re trying to solve is scarce, or worst, if your limited knowledge leads you false problems leading you to half-solutions?

    Let me tell you one thing: It will not work.
    It might seem to work for a period of time but the end result will be nothing but a “designers playing designers stuff”

    I know this because i’ve been there.
    A few years ago we started a project in healthcare that was quite apart from everything else. Touchscreen interfaces, a beautiful user interface, different “profiles” to meet the needs of physicians, nurses, etc.
    Complexity was low at that time. Expectations for the product were low as well.
    This was designed just as WE were the ones to use it. But we were not. My CEO was the physician (one that never practiced after school), i had no experience as a interaction designer (i was a graphic designer) and we went along with this story.

    The product had a lot of success and the first years sales supported a massive growth of the company. I should say that the sales boost was due to very particular funding context for our clients and to the extreme selling ability of the above mentioned CEO. This means that the product was sold to managers. Not to the people who actually would use it. Also the user interface design work was pretty sexy. Plus the product feature list was loaded and with plenty innovations. Therefore we lived in a ethereal dream of success, thinking that we were doing it right.

    We we’re doing it completely wrong. It was – it is – nothing but a bag of features. It drives people crazy.

    The source of clinical knowledge was that one physician (the CEO) for a long time. But he had no practical knowledge, or even worse, his knowledge was no longer updated. I knew nothing about interaction design and i was designing for hundreds of physicians and thousands of nurses. We were designing for ourselves.

    Let me say at this point that the company is pretty successful at this point in time (2009). It employs more than 800 people. It is a multimillion dollar company.

    But it is a company that will, for sure, disappear with a bang in shortcoming. There’s no future to it.

    The thing is as soon as we started to get feedback from real users we started to embed more and more features into the product. Still the source of knowledge was the same or little improvements were made as to get feedback from users or even to “consider them” into the development cycle. Users were down the line. Inconvenient people that, unfortunately, we had to deal with. We we’re the ones that knew better.

    What a bunch of assholes. Pretty soon we were facing hundreds, thousands of requests, complaints, and as our CEO could no longer pass his “knowledge” to us we started to use consultants here and then for “more difficult issues”. These guys had minimal commitment to the company, to the product and to the problem to address even though they were earning good money for it. Most of their input was considered just as “advices” anyway. So complexity was growing exponentially, knowledge was scarce, design methodology was very fragile, Board directives (e.g. from our CEO, our first and most important, self-refered, egocentric client) was to keep focused in maintaining mental models from the early days which could not / should not apply to the new problems….a typical hell. New features design started with discussions (“i think, you think” type of discussions) and right after a user interface proposal would show up to address it. Graphic User interface designers – by this time already more than a dozen – ruled…They were the enlightened ones and engineers were the most despicable breed on earth. Users were just some strange beings that we’ve heard that might exist… but we were not sure because we never saw them. If there’s a place on earth which could be the Alan Cooper’s asylum, this was it.

    This is what happens when you design for yourself and give it to others to use it (ok, ok, I agree, this was a pretty unusual and extreme mentally deranged company). Or at least it is one possible scenario if you get together a bunch of ignorant imbeciles and loose track of TO WHOM are you designing for.

    I would say the use of personas can help you a lot. Even if they are crappy, lousy personas. They will help reminding you that you are designing for OTHERS. That you are just a designer, trying to make life a little bit easier to OTHERS. That you opinions, judgements, the features you like, they all might not be exactly what OTHERS care about. That you are not designing for YOU.

    “However, how do you know you’re actually meeting the needs of your users? After all, that is why you were designing in the first place, right?” Jared Spool

    Indeed, that is why you are designing in first place, right?
    Nelson V.

  37. Personas « CleaveFast Says:

    [...] Crappy Personas vs Robust Personas by Jared Spool [...]

  38. 周二茶闻:…人物设计 | UXstudy--好的产品是吸引人的,而不是简单的。 Says:

    [...] Crappy Personas Vs. Roburst Personas Persona在以用户为中心的设计中的作用经常受到大家的质疑, 那什么样的Persona才是有用的呢? [...]

  39. Catch Media » Blog Archive » Making personas more useful with profile charts Says:

    [...] When I talk about personas, I mean the archetypal constructs of characteristics, drivers, behaviours and goals that are designed to represent the main audiences at which a digital product is aimed. Personas were made popular byAlan Cooper, and given gravitas and discipline by industry minds such as Andrew Hinton and Jared Spool. [...]

  40. on personas :: ProductMarketing.com Says:

    [...] Read a great post Building a Data-Backed Persona at Boxes and Arrows and Crappy Personas vs. Robust Personas at User Interface [...]

  41. UIE - Thought Leaders on the Persona - Persona Template Says:

    [...] last on my list is this great piece, Crappy Personas vs. Robust Personas by the wise Mr. Spool, which, although a bit snarky, digs down to uncover the underlying sentiment [...]

  42. Using Personas to Create Inclusive Digital Exhibit Interactives | archaeoINaction Says:

    […] “Crappy Personas vs Robust Personas” […]

Add a Comment