This seems extremely tricky to implement at the design level (granted, my background is not really in design at a scale where “personas” become feasible).
A lot of the emphasis today in “forward-thinking” design seems to be accessibility, open ess, one-design-for-all - that sort of thing.
Attempting to reign in requirements at the design level with “anti-“personas seems like opening yourself up to the gigantic world of what pop- design seems to view as (at the very least) majorly uncool.
In my world, figuring out what a thing will and will not do gets sorted out by folks that aren’t afraid of the word requirements - very early on - and again, in my little world, if designers (I assume UI, or “front-end”) are having these discussions at the persona stage, then we’ve gone done messed up somewhere.
I believe the personas in the article are at a different level than what you talk about. The personas I’m familiar with encapsulate user stories of how a product will be used, not the UI design: Mark wants to enter transactions at the Point Of Sale Terminal, John wants to enter inventory counts as fast as possible, Jim wants to run reports, and so on.
However, I’m very interested in an expansion of this article that provides examples.
Maybe something like: Mark at the POS terminal is under pressure to scan items (customers are queuing!) and does not have the time to hunt for the right button or undo mistakes; buttons must be big, accessible and not error prone. Therefore, adding more features to the screen(s) he uses is counterproductive for him.
This rises almost to the level of a persona. Mark is our POS terminal’s intended end-user, and the decision to minimize the number of new features is tailored toward making his experience as an end-user better. I think they’re talking something a bit more like “Mark wants to watch Netflix on the POS terminal.”
I think it pops up quite a bit in terms of taming complexity.
Tons of UIs have user configurable filters. If the filter is a single dropdown, it’s super easy to use but not very powerful. If you have a full condition builder with nestable conditions then it’s infinitely configurable. But you have to decide: do you expect your user to understand boolean logic?
Saying that you don’t expect an email marketer to understand boolean logic over event driven state machines defines a good Anti-Persona. You explicitly don’t go out of your way to empower those users because it hinders the actual Persona you’re targeting. Plenty of platforms already exist that can take on that customer you’re explicitly saying you aren’t prioritizing.
This advice would be much stronger with an example
There’s a general lack of information in this article, but you can buy their book!
–> spam
This reminds me of this similar advice from Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20070321-00/?p=27543
This seems extremely tricky to implement at the design level (granted, my background is not really in design at a scale where “personas” become feasible).
A lot of the emphasis today in “forward-thinking” design seems to be accessibility, open ess, one-design-for-all - that sort of thing.
Attempting to reign in requirements at the design level with “anti-“personas seems like opening yourself up to the gigantic world of what pop- design seems to view as (at the very least) majorly uncool.
In my world, figuring out what a thing will and will not do gets sorted out by folks that aren’t afraid of the word requirements - very early on - and again, in my little world, if designers (I assume UI, or “front-end”) are having these discussions at the persona stage, then we’ve gone done messed up somewhere.
I believe the personas in the article are at a different level than what you talk about. The personas I’m familiar with encapsulate user stories of how a product will be used, not the UI design: Mark wants to enter transactions at the Point Of Sale Terminal, John wants to enter inventory counts as fast as possible, Jim wants to run reports, and so on.
However, I’m very interested in an expansion of this article that provides examples.
Maybe something like: Mark at the POS terminal is under pressure to scan items (customers are queuing!) and does not have the time to hunt for the right button or undo mistakes; buttons must be big, accessible and not error prone. Therefore, adding more features to the screen(s) he uses is counterproductive for him.
This rises almost to the level of a persona. Mark is our POS terminal’s intended end-user, and the decision to minimize the number of new features is tailored toward making his experience as an end-user better. I think they’re talking something a bit more like “Mark wants to watch Netflix on the POS terminal.”
I think it pops up quite a bit in terms of taming complexity.
Tons of UIs have user configurable filters. If the filter is a single dropdown, it’s super easy to use but not very powerful. If you have a full condition builder with nestable conditions then it’s infinitely configurable. But you have to decide: do you expect your user to understand boolean logic?
Saying that you don’t expect an email marketer to understand boolean logic over event driven state machines defines a good Anti-Persona. You explicitly don’t go out of your way to empower those users because it hinders the actual Persona you’re targeting. Plenty of platforms already exist that can take on that customer you’re explicitly saying you aren’t prioritizing.