In design, it's always easer to say "yes" than to say "no." Nobody is hurt by a "yes," so nobody fights against a "yes." That's why applications have a tendency to grow until they become unwieldy and unusable.

Personas are a common tool to make better design decisions, but they're mostly used for feature addition. What do these people need? Who is this feature for?

They're a less powerful tool for feature prevention.

That's why, in addition to a list of Personas, it can also be helpful to have a list of Anti-Personas. The term "Anti-Persona" has a bunch of different meanings, including people you specifically want to prevent or discourage from using your product, but in our case, they are just Personas we aren't targeting. They're a bad fit for our product.

Having these types of Anti-Personas helps delineate the border between features that make sense, and features that are outside of your product's scope.

If you're working with Personas, it may be worthwhile to also define Anti-Personas. Together, the two allow for more intentional design decisions, where saying "no" becomes a choice that is easier to make.

If you require a short url to link to this article, please use

designed for use cover

But wait, there's more!

Want to read more like this? Buy my book's second edition! Designed for Use: Create Usable Interfaces for Applications and the Web is now available DRM-free directly from The Pragmatic Programmers. Or you can get it on Amazon, where it's also available in Chinese and Japanese.