3 ms·
> Seems like a recipe for having your software slowly evolved into a giant heap of dark patterns. Just don't test for dark patterns?
by activiation 3y ago
> Seems like a recipe for having your software slowly evolved into a giant heap of dark patterns.
Just don't test for dark patterns?
- mtlmtlmtlmtl 3y agoWell, how does one "just not do" that though, specifically?
- activiation 3y agoFirst determine if what you want to test for is a dark pattern?
- mtlmtlmtlmtl 3y agoAnd how do you determine that? I'm not trying to be coy here, I genuinely don't understand. Because you're not testing for patterns, what you test is some measurable metric(s) you want to maximise(or minimise), right? So how can you determine which metrics lead to dark patterns, without just using them and seeing if dark pattern emerge? And how do you spot these dark patterns if by their very nature they're undetectable by the metrics you chose to test first?
- activiation 3y ago[flagged]
- mtlmtlmtlmtl 3y agoWell this discussion isn't helpful at all. Why reply at all if you're just gonna waste my time?
- activiation 3y ago[flagged]
- iudqnolq 3y agoThe "patterns" in dark patterns doesn't mean they're an emergent property of the system. You test whether a change improves a metric in A/B tests. You avoid accidental dark patterns in the change like you avoid bugs that cause accidental data loss in the change: you think carefully about what you're doing, maybe a reviewer looks it over, and so on. This isn't perfect, but nothing is.