4 ms·

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

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.

toss1 9y ago
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.
- juliushuijnk 9y ago
  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.
  - toss1 9y ago
    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 ;-)
    - juliushuijnk 9y ago
      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 :)
      - toss1 9y ago
        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...

toss1 9y ago

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.

juliushuijnk 9y ago
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.
- toss1 9y ago
  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 ;-)
  - juliushuijnk 9y ago
    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 :)
    - toss1 9y ago
      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...