Design for the user who's over your crap

It’s happening again as I write this, with at first people were excited about the stripped-down, back-to-basics user experience of a plain UNIX server designed for serving web pages, and the aspect where logged-in users could chat at the command line gave the place the feeling of an actual social network. But now the initial excitement is spinning down and people are updating their pages less often; whether the chat is still hopping, I couldn’t say – I don’t have an account – but I guarantee you it’s changing.

What do we need from the social network that’s next, the one that we actually own? (You could argue as to whether it’s coming, but no need for that right now.) I propose that the moment we get bored is the most important moment for the designer of an app to consider. Right? Because what’ll people do with whatever revolutionary new web thing you put in front of them? If my experience on both sides of the transaction is any guide, they’ll probably get sick of it, and fast.

There are so many kinds of boredom, though. There’s the smug disappointment of paddling your surfboard over to what looks like the next wave, only to find that it “never” crests. A more common pair, though: there’s the comedown – when something was legit exciting but then the magic leaves – and then there’s the letdown, when something seems exciting at first blush but you investigate and find the glamour was only skin deep. Most systems have more to fear from the latter. New systems that are any good, though, don’t often have a plan for the former. Distributed social networking needs one.

What do people need at first, and then what do they need later?

At first:


One’s needs from the first list never go away, exactly. You’ll always want to bring something up to the group now and then (where “the group” is whoever you’re actually personally invested in conversation with), and play and discovery don’t die. But we see so much more design for that first list – probably because a commercial social network needs to privilege user acquisition over user retention… or thinks it does. And as a whole culture we are only now coming around to the importance of designing for defense, despite the evidence having been here for 35 years.

It’s hard to keep coding when the bloom is off the rose of a project. One way to keep yourself motivated, when the work is unpaid, is to take the perspective of that un-jaded, excited new user, discovering and fooling around. This naturally leads to features that appeal to that mindset. A major obstacle we face in developing the decentralized, user-owned permanent social network is making faster progress while maintaining the mindset that will result in a grownup network for grownups.