They go on to show how this can be alleviated (for example, by showing people who polluted a lot a sad face and those who polluted a little a happy face), but this is an interesting rule of thumb. People will more likely regress towards the mean once they know what the mean is.
As much as we complain about other people, there is nothing worse for mental health than a social desert. The more connected we are to family and community, the less likely we are to experience heart attacks, strokes, cancer and depression. Connected people sleep better at night. They live longer. They consistently report being happier.
The Infinite Jukebox is so up my alley it’s … uncomfortable. It analyzes any song you want and then plays it back, moving between similar-sounding parts to make a seamless remix that keeps changing and never ends.
Or! It’s not seamless at all and makes all sorts of screwy decisions! Or! It gets stuck in a little four-second loop forever! I find the weird mess-ups even more endearing than when it all works perfectly. Poor li’l robot. It tries its best.
BTW, if you absolutely hate yourself you should totally check this out. Nice knowing you!
Resist the urge to regress when a solution has problems. The only way out is through, with more knowledge. We all have a moral obligation to our descendants to be a force for the growth of knowledge, so that they may live like kings compared to us.
— Today’s email from The Listserve. They’re often good, but today’s was great.
Towards the end of a recent project at work, I came up with a technique to help us do more user-focused QA work, which was unambitiously titled the Scenario Card Game.
How does it work?
You write down the main tasks that someone will do in your application, and print them off on something playing card(ish) size.
Write down all the little nuance details that might make those tasks happen differently, and again print those off on something playing card sized. The best things to use here are things that a user might need, or unique facts about them that would change the task.
Pick a task card, and few nuance cards (we used three). You now have a specific scenario to use when walking through your application. Check that everything makes sense together, if anything conflicts just put some cards back and draw new ones.
At this point, you should actually use that scenario to walk through your app, and record the results. Were there bugs? Was it hard to figure out what to do because of the nuances?
Make the app better. Repeat.
In our project, there was a lot of functionality, but people were having a hard time seeing how everything fit together. So we created some scenarios that outlined specific flows a user might go through, and developers/QA would walk through these to make sure everything was working. It was a pretty good system, but the scenarios were very perscriptive, which meant that after you had done the scenario once, people started seeing them as a bit of a chore, and it didn’t invite the level of creative exploration that we were hoping for.
So this game was an attempt to capture the big picture things that people would need to do, provide some constraints, but still leave lots of room for people to make their own decisions when testing them.
I like it because it combines testing the technical issues with the app (“there’s a bug on the account screen”), and usability/design issues (“how do I select a Spanish consent form?”). And it provides some more direction than “take a look at the app and see if anything is busted”.
Try it out, I’d love to hear if it helps you out on a project.
We originally tried this with a third card type: for personas. This was great because it humanized each of the scenarios, but the cards didn’t really change the scenarios in any way, so I think you could get by without them. If you already have personas created for your project, add them as a third card type. But if you don’t (we can argue about whether you need personas at a later date), I don’t think that should stop anyone from trying this out.