In my last column, I explained what I see as the advent of the post-connected user. Neither hyper- nor dis-connected, they are looking for a more balanced relationship with the tools they use on the internet. It’s our responsibility as web makers to design services and interactions in response to these aspirations. It’s a big opportunity, too. Part two is therefore dedicated to what you can do—or at least what you can experiment with.
Through the eyes of post-connected users#section1
When I was teaching UX, I found one key design principle influenced my students most: evaluate your design through the eyes of others. The gap between intended and real usage can be striking indeed.
Try getting back to an application after a week or two of inactivity. If you recently returned from vacation, you already know the result: a massive user pain.
I tried it, and it felt like all the applications and websites were yelling at me: You’re late! You’ve missed out on so much! Piles of notifications and unread messages pointed an accusatory finger at me: you shouldn’t have disconnected, you shall now suffer to get caught up.
This is exactly what post-connected users hate. They feel—and rightfully so—that hyper-connection is forced upon them. They’re looking for applications that adapt to their tempo, not the reverse. Personal productivity and well-being books, such as the bestselling 4-Hour Workweek by Tim Ferris, recommend taking deep work periods which, just like deep sleep, are uninterrupted by external stimuli. If you try this healthy work habit, don’t expect much help from your mailer or team communication tool though. They hold to the dogma of synchronicity.
Synchronous vs asynchronous#section2
Is synchronicity always a good thing? Given the huge success of chat applications, be it WhatsApp with friends or Slack at work, it seems the answer is yes. Yet synchronicity can create the online equivalent of walking into a colleague’s office to ask her a quick question. Sure it works—you get an immediate answer—but it has a disastrous side effect: the group’s rhythm becomes the only rhythm. Many individuals feel powerless to prevent interruptions so they need software to help them make work happen at work.
Real-time is a designer’s magic wand. No need to face complex design issues, real-time solves it all, plus—icing on the cake—it sounds like a cool, modern solution. On the other hand, timeliness, as Cheng puts it, is much harder to achieve. Instead of delivering messages as they arrive to all users, each user’s behavior and preferences must be taken into account. For some, Twitter is at its best when it offers a short selection of personally curated tweets through the weekly email digest or the Highlights app.
A great example of timeliness is Watchup’s daily newcast: just pick your preferred time of the day, Watchup composes a fixed-duration video digest and learns from your behavior to fine tune your experience.
To design an asynchronous yet efficient tool like this, machine learning comes as a great aid indeed. I would even say that machine learning is a post-connected user’s best friend. Intelligently automated processes can be left to work in the background, helping post-connected users to fight the glut of information (let’s call it infobesity).
The designer’s dilemma#section3
Have we in the web industry focused too much on how to build? We get excited by new devices, better browsers, or the latest coding technique. We want to try them out, so we prefer to build something new, from scratch.
And so do architects. In my hometown of Lyon, a major urban renewal program is in progress. Search for “Lyon Confluence” in Google Images or Flickr and you’ll see pictures of brand new, futuristic buildings. The program also includes the eco-friendly renovation of early 20th-century blocks of flats, but everybody associates La Confluence with these eye-catching bright orange and green new constructions.
Web designers don’t renovate. We move on to the next new thing. But if we begin to question why we build and who we build for, we’ll realize we’re leaving behind many unsolved user problems and many users who don’t participate in a cycle of continuous adaptation to new tools.
Actually, things are changing. Some start-ups have started to renovate old communications real estate, like email or even SMS. Not because it’s sexy (email isn’t, unless you like HTML 1.0), but because there are so many problems to solve: infobesity, lack of actionability, or poor interactions like `no-reply`.
This is what post-connected users are after: less embellishment, more solutions to existing problems.
Looking forward shouldn’t stop us from looking back. This is a solid UX principle after all: release, evaluate, rework. The industry will continue to invent new ways to make the web, much to our delight, but there will always be work for the web renovators as well. While people may be getting more reluctant to spend time or money on software as such, they are coming to see the value of a less noisy, more balanced working life. A growing public of post-connected users is waiting for you.