The master conceptual tests at Dreamwidth are, I believe, the
Design Personas.
There are a number of other conceptual tests that long-time Dreamwidth (and LiveJournal) code/design/suggestions participants run against proposed features or implementations. I hope to collect some of them here, and maybe start a wiki page at some point, because this is the sort of stuff that's retained in the tribal knowledge pool, and is therefore vulnerable to the problems of human memory and absence.
* Went to Costa Rica with the Peace Corps (prolonged absence, with or without notice).
How does the proposed feature or implementation affect a user who is away from both their account, and any possible notifications, for prolonged times? In particular, any feature that depends on a user responding to a prompt within say a six-month deadline, with irreversible effects that include data loss, is just not on.
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
christine is the old LJ Support test case: she was previously an active volunteer, and planned her long absence beforehand. She periodically returns and updates us all on her life! She's generally away from her journal a year or two at a time, with no means of access in between.
* Deceased (with or without memorial status) user.
How does it affect (the readers/circle of) a user who will never return? The friends/family of a deceased user may or may not choose to ask for memorial status for that account, so assuming that all accounts belonging to deceased users will have been given memorial status is not a safe assumption.
* Dead Manta Problems
How does it interact with deleted-and-purged accounts, particularly ones who have had the old name reactivated by someone having renamed to it? (Named in honor of the once-and-again deadmantalks, whose old name became ex_deadmanta-some-numbers upon reclaiming the name.)
* Unwanted Contact
How could this be used, either by accident or with malice aforethought, to cause communication between parties who should not communicate with each other? Will it need to restrict anonymous or not-logged-in use or respect ban settings?
* Spam
How could this be used by a spammer?
* Scalability
Consider the potential load if the entire population of the site should use it, or if a large number of users were to use the feature at its highest capacity. For example, what if this feature were used by a high-traffic roleplaying game? (This is usually a developer/architect level problem.)
* Paid Features
Is this a feature that requires a lot of expensive operations? Could this be offset by restricting it (or higher levels of it) to paying users? Would extending a higher level of it to paying users be a nice perk for them? (This is ultimately a staff decision.)
* Malice Aforethought
How could this be used to disrupt others' use of the site? Could any of it be avoided by built-in safeguards or rules, rather than moderation after the fact?
* Journal Types
How does this apply to regular users, communities, and identity users? Does it apply to only one journal type, or can it be usefully used by more?
* Settings Overload
More settings are possibly great for power users, but can cause decision fatigue in neophyte to intermediate users who just want things to work. D has a whole essay on this somewhere, I think.
* Opt-In vs. Opt-Out
Opt-out makes features more discoverable (I think D has an essay on this too), which means that the default state of new features should not piss off, injure (migraine or seizure trigger), or endanger (publish or publicize previously private or covert information such as location or wallet name) users who have not yet turned it off.
I'm sure I'm forgetting some stuff, so if there are other things that either are or should be stuff that gets discussed when talking about a new feature, please feel free to add it in the comments, or in the wiki page once someone builds that.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
