ISC StormCast for Wednesday, May 27th 2015 http://isc.sans.edu/podcastdetail.html?id=4501
Here's a cool post that demonstrates the differences between interpreters, compilers, and just-in-time compilers. My first exposure to this was the dynamic recompilation that some Nintendo emulators would do for speed. At the time I didn’t realize that it’s pretty much the same thing as JITing.
Thanks to one of our readers, for sending us this snipped of PHP he found on a Wordpress server ( ...(more)...
A few years ago, I started getting into video games like Katamari, Animal Crossing, and Borderlands 2. Their designs are astounding; each feels like I’m having a natural conversation with the game, and each introduces content in the moment I needed it. As a result, the game experience feels so dang smart, and I feel like a hero whenever I play.
Here’s an example from the very first minute of Animal Crossing. All you’ve done is started a new game.
If you watch it, you’ll see the game designers make assumptions about you so they can collect innocuous personal information in a conversational way. When their assumptions are wrong, they respond in a humorous way. No harm, no foul. Yes, yes, yes.
So I started wondering how the video game industry has mastered this art of interactive storytelling so brilliantly. Who are the people on their teams? What are they called? How do they work?
I started reading up on the history of particular games in development, which kinds of themes show up in forum discussions, and checked out job descriptions that Nintendo, Bethesda Games, and Gearbox Software used.
I learned a few interesting things
Game designers start with the story. What they add to the experience complements and builds on the core story; it doesn’t distract from the priority of “accomplish goal,” even when that takes a year longer than expected, as was the case with Journey, Sony’s award-winning game from thatgamecompany. (Journey doesn’t even have a single word as part of the main game story line. Unreal.)
They design for discovery—learning in the moment not only increases retention and engagement, but it’s delightful and emotionally empowering.
I also learned of a unique role that’s part of their design process; it isn’t “copywriter.” It’s called narrative writer, game writer, or story designer.
These are content strategists, and they’re responsible for designing the conversation between player and game.
Content as the product experience is par for the course in the video game industry. And since 60 percent of people (average age 30) play video games—and it’s an $82 billion industry that just keeps expanding into every interface imaginable—it’s to be expected that our web and mobile experiences should feel more like conversations.
So I started practicing what the video game industry preached (and what the advertising industry leaders like George Lois preached before them): start with the word.
I immediately changed my process. I started writing content on day one of projects I was involved with. Those included a mobile utility, magazine, and personal projects. They also included the Annie E. Casey Foundation (AECF) and Ben & Jerry’s site redesigns with Happy Cog, and User Interface Engineering’s conference and webinar content.
AECF, for example, was redesigning its website, which included an enormous amount of content. More than 20 stakeholders from various internal teams had their own set of requirements and goals for the new website. So at the kickoff meeting, we facilitated discussions around how well the content seemed to be meeting audience expectations by asking those stakeholders, “What are the top questions your audiences ask? What are their top complaints?”
That focused early discussions on the communication gaps we could solve with content. We then looked at “top content” and “time on site” data to qualify which pages in the existing experience were drawing the most eyeballs and interest.
What we found was AECF’s research reports were highly sought-after, but the content in those reports wasn’t surfaced in a way audiences could easily find or understand. So we started there in week one of the project, rewriting the research report page using real content from them. After we did one, we asked, “How would someone get here?” and “Where would someone go next?” as a means of determining which content to write next. Doing this enough times, over and over, meant a natural structure (IA) emerged.
This shift of working content first (conversation design) instead of structure first (system design) is how we worked for several weeks, all in a Google Doc, before we ever moved to layout and design. This approach also ended up reverse-engineering the conversation of the website—from most-sought-after content up and out—until we got to the homepage. By then, we’d already written all the content for other pages, so designing the homepage was loads easier.
The artifact we continually used through this process is called a content workbook, and AECF so kindly lets me share it in its naked state.
Working in this content-first way made for the most joyful and collaborative design projects I’d been involved in since starting my web career 12 years ago. They were iterative earlier on, focused on getting real content before trying to structure it (because designing for real content is real), and ended up leading me to join Capital One.
I never dreamed practicing content-first design and talking about it at a couple conferences would lead me to work for a bank. Especially one I knew nothing about. But the idea of creating jobs for people who get that content is product design, well that was too dang good to pass up. So now we’re growing a niche team of UX content strategists, sort of like our equivalent of the video game industry’s story designer.
Part of our process is working directly with designers and product managers to design conversations in plain text. We call them content prototypes, and they take many forms depending on the team and project.
A content prototype is a Word document, text file, or Google Doc full of words that we can test with real customers to see if we’re speaking their language.
Designers and product managers can make them just as a content strategist or copywriter could. The goal of the prototype is to write the conversation we want to have with someone, then design an experience that best brings that conversation to life, no matter the technology. How to start:
- Start writing what kind of conversation you’d have in real life if you didn’t have an interface yet.
- Start writing.
- And don’t edit. (That’s the hardest part.)
- Keep writing. How the conversation should go will become clearer the more you write. (And the more you test with other people.)
For example, if we’re designing interactive experiences, we might create content prototypes using loads of if-then statements. (It’s like a Choose Your Own Adventure book: read some stuff, make a choice, see the corresponding story. Rinse and repeat.)
For example, this is a content prototype the product and design team created for Ideas, which suggests things to do, see, or buy based on your purchasing history.
Before launching the pilot in a few cities, the team wanted to A/B test some language for “Mary,” the persona they were designing for. But they already had an app designed and in regular usability testing. So they actually extracted the content from the design and put it in this Word document to isolate the conversation, then created a B version of that conversation. A few days later, they ran the test with real people. Here’s what Cary Feuer—a product manager on Ideas—said about it:
“Content prototyping FTW” seems like a pretty good tagline, eh?
More to come
We’ve got content prototypes for different kinds of projects at different stages of development, from scripts we can test on the street or in user labs, to content experiments we can deliver through email or SMS, or prototypes that capture the full (real) content across time and channels.
A lot of the content prototypes we’re creating at Capital One are for experiences that aren’t publicly available yet, but I’ll share them as I can in future posts. And hopefully you can get content at the table where you are. Content prototyping changes the way we work. It’s not a piece of real estate on a page. It’s not an asset. It’s experience design, after all.
There is more information available as to what Big Data really mean. In the type of business that ...(more)...
In her beautiful, award-nominated “A Talk About Nothing” at the 2015 .concat() web development conference, Lena Reinhard delivers a luminous exposition of how tech’s version of meritocracy is a brilliant system—for the people who get to define what merit is. When we overlook entire groups of people who could be making fantastic contributions to our future, we all end up with less. Don’t miss this talk. It’s full of stars. —Rose Weisburd, columns editor
Your weekend reading
- “Hold on a second. I’m like a two-out-of-ten on this. How strongly do you feel?” In The Sliding Scale of Giving a Fuck, Cap Watkins shares a useful framework for communicating how strongly you feel about a topic you’re debating with colleagues. I appreciate that it’s intuitive enough to use without explanation, and provides a way to engage on opposite sides of a subject without needless drama. —Aaron Parkening, project manager
- You may be intimately familiar with a typeface like VAG Rounded from (until recently) Apple keyboards. Or perhaps you’ve chosen a rounded sans like Process Type’s Bryant for a project. But how well do you know the history of these letterforms? FontShop’s Ferdinand Ulrich recently published the second part of his comprehensive survey of rounded type. (Part 1 appeared in March, and Part 3 is on the way.) —Caren Litherland, editor
- I’ve been doing some research into virtual reality (VR) and, although this is a few months old, I’ve just stumbled across it and wanted to share it. Mozilla has a team working on virtual reality and the open web. Their video presentation, Virtual Reality & The Web: Next Steps, is a fascinating introduction to how VR works, with demonstrations on how to build experiences for it using HTML and CSS. —Anna Debenham, technical editor
- “Progressive enhancement just works.” Aaron Gustafson compares two real case studies—one built to progressively enhance and another built to degrade gracefully—to show how progressive enhancement from the ground up can save considerable amounts of time and money for a project in the long run. —Michelle Kondou, developer
- I can’t say that I’m 100 percent sold on my own lifelong vegetarianism, but I like to think that it lends me a small amount of objectivity in hamburger-related matters. As such, I’m on the same side as the BBC when it comes to hamburger menus and their inscrutability for the average user: just because we designers and developers have a taste for them doesn’t mean they should always be on the menu. —Mat Marquis, technical editor
Overheard in ALA Slack
Your Friday Vine
Current status: Reading "The Unreasonable Effectiveness of Recurrent Neural Networks".
Typically we try to device attackers into different groups, all t ...(more)...
Another cool find: "Probabilistic Programming & Bayesian Methods for Hackers"
This is really useful! "Top 10 data mining algorithms in plain English"
Instant Articles are here, and the announcement is all about speed. From a user perspective, I think that Instant Articles are a good thing. But I bristle at the implications for the open web. Implicit in the sales pitch (and explicit in much of the commentary that followed) is the familiar criticism that the traditional HTML/CSS/JS web stack is too slow to deliver a first-class experience. Facebook may have been throwing shade, but others were more overt in their criticism.
John Gruber put it in stark terms:
I don’t believe that the web is inherently slow, although I do acknowledge that over-produced web design could give rise to that assertion. But that’s a fine distinction, because in practice it might as well be true—as Scott Jehl says so very succinctly:
That the performance of bloated websites is the norm is profoundly disappointing, all the more so because we’re the ones who made it that way. Users of all kinds need the open web, because it serves everyone—including people without a Facebook account and people without access to the latest mobile devices. But even without the Instant Articles bar to measure against, we’ve been shipping slow sites and thus failing those very users. Tim Kadlec gets to the heart of the matter in his post “Choosing Performance,” and it’s simultaneously simple and complex:
I think Tim’s point is dead on. Later in the piece he points out how culture change usually moves more slowly than technical solutions, and that’s specifically true for the folks building the web.
My family and I are big fans of cooking-competition shows. I love how the judges save their harshest criticism for chefs who let their dishes leave the kitchen without tasting them. “Did you taste this dish before it went out?” they ask, and the chef can do nothing other than hang their head in shame and reply, “No chef, I did not.”
That’s my biggest takeaway from Instant Articles: we (designers and our clients) have to start tasting our work. Not just in our proverbial kitchen, but where our users actually eat the stuff. How do we do this? Some of it is tactical. Dan Mall has a great primer on setting up a performance budget. Scott Jehl’s Responsible Responsive Design has a lot of good, practical advice on tooling and testing to make things fast, in both absolute and perceived respects.
But again: we can’t just engineer our way to a faster web, because for every bit of extra speed we wring out, we’ll find a way to fill the gap with even more over-produced design. M.G. Siegler’s analysis of Instant Articles comes to this conclusion:
I don’t want this to be tantrum trigger, where we throw up our collective hands and yell, “We can’t do anything cool on the web! Fine! Just make it all text! ARE YOU HAPPY NOW?” I think we do have to be better at weighing the cost of what we design, and be honest with ourselves, our clients, and our users about what’s driving those decisions. This might be the toughest part to figure out, because it requires us to question our design decisions at every point. Is this something our users will actually appreciate? Is it appropriate? Or is it there to wow someone (ourselves, our client, our peers, awards juries) and show them how talented and brilliant we are?
Lara Hogan’s Designing for Performance might be the most useful resource in this regard, because it talks about how to educate and incentivize our teams toward a performance-focused culture. If you, your team, and your client build that culture with your user in mind, then the sites you build can be beautiful and immersive without negating the accessibility and reach that makes the open web so vital.
What’s exciting about this user- and performance-focused mindset is that it will still be valid and useful even if we see some much-needed advances in browser-based capabilities. I hold out hope that components like HTTP/2 and service workers will allow us to build smarter, more performant sites. But we have the means to build sites faster right this minute. If nothing else, Facebook just turned that into a higher priority for the entire web community. And that’s a good thing.
15 years ago this month, a plucky ALA staffer wrote “Much Ado About 5K,” an article on a contest created by Stewart Butterfield that challenged web designers and developers to build a complete website using less than five kilobytes of images and code. Hundreds did, and their work far exceeded what any web professional could have reasonably expected:
Having learned once again the importance of constraint and the empowering creative influence it can have on design, our community high-fived itself…and promptly forgot everything it had learned as we started building heavier and heavier sites.
And still the little article memorializing the little 5K contest sat online, its lessons forgotten in an arms race wherein the average home page now weighs over 2MB. Put that in your Edge network and smoke it.
Ah, but what goes around (performance) comes around (performance). Beginning in 2013, conversations about responsive web design “shifted from issues of layout to performance” as leading web designers and data sifters came to realize that, even on speed and bandwidth-limited networks, users expected sites to render as fast on phones as they do on the desktop—if not faster. That if your site didn’t render as quickly as users expect, they would abandon it, perhaps forever. That a traditional, desktop-first approach to responsive web design guaranteed user disappointment and site abandonment; that, performance-and-bandwidth-wise, at least, a “mobile first” approach made far more sense—and not just for mobile users. That you could no longer give high design marks to a site (however innovative, however visually arresting) if it took forever to load over constrained mobile networks. Because performance was part of design, and always had been.
As one group of web makers embraces performance budgets and the eternal principles of progressive enhancement, while another (the majority) worships at the altar of bigger, fatter, slower, the 5K contest reminds us that a byte saved is a follower earned.
For more on performance:
- Designing for Performance: Can We Have It All? A List Apart: On Air video archive
- “More Weight Doesn’t Mean More Wait,” by Filament Group
- “How to Make a Performance Budget,” by Daniel Mall
- “Performance Budget Metrics,” by Tim Kadlec
- Designing For Performance: Weighing Aesthetics and Speed, by Lara Hogan
- “Planning for Performance,” an excerpt from Scott Jehl’s Responsible Responsive Design
- “Rules for Mobile Performance Optimization,” an overview of techniques to speed page loading by Tammy Everts
- “Performance Matters,” by the W3C Web Performance Group
- And, for your pleasure, Stewart’s original 5K contest ℅ the Wayback Machine
FIFTEEN years ago this month, a plucky ALA staffer wrote “Much Ado About 5K,” an article on a contest created by Stewart Butterfield that challenged web designers and developers to build a complete website using less than five kilobytes of images and code.
As one group of modern web makers embraces mobile-first design and performance budgets, while another (the majority) worships at the altar of bigger, fatter, and slower, the 5K contest reminds us that a byte saved is a follower earned.
More in 15 Years Ago in ALA: Much Ado About 5K.
In the past few days, weve seenNuclear and Angle ...(more)...
Ever had a moment on the internet when you’ve been forced to stop and think about what you’re doing? Maybe you’ve been surprised. Maybe you’ve stumbled across something new. Maybe you’ve come to see things in a different light. I call such experiences meta-moments: tiny moments of reflection that prompt us to think consciously about what we’re experiencing.
Take Google. In the early days, its clean white page helped distinguish it from the pack. While its competitors tripped all over themselves telling you how great they were and how much they had to offer, Google’s quieter strategy seemed bold and distinctive. “Our search experience speaks for itself,” it suggested. No need for spin or a hard sell. Over the years, as Google has continued to develop its search technologies, it has managed to retain that deceptive surface simplicity. I love that its minimal homepage has stayed intact (in spite of incessant doodling). Encouraging a thoughtful moment remains central to Google’s design.
Yet the prevailing wisdom within user experience design (UXD) seems to focus on removing the need for thought. We are so eager for our users to succeed that we try to make everything slick and seamless—to remove even a hint of the possibility of failure. Every new service learns about our movements in order to anticipate our next move. Each new product exists in an ecosystem of services so that even significant actions, such as making a purchase, are made to seem frictionless. The aim is not only to save us time and effort, but to save us from thinking, too.
Steve Krug’s seminal book Don’t Make Me Think! may have helped to shape this approach. This bible of usability is an undisputed cornerstone of UXD. But it can be taken too far. In fact, Krug himself has unofficially rechristened the book Don’t Make Me Think Needlessly! In doing so, he acknowledges that there are times when thoughtful interactions online are worth encouraging. While we shouldn’t need to think about where to find the search tool on a site (top right, please!), we should, of course, be encouraged to think before we purchase something—or, for that matter, before we make any significant commitment.
It’s a question of courtesy, too. When asking for deeper attention, we should feel confident that we’re not wasting people’s time. What we offer should more than repay them for their efforts—though there aren’t many moments when we can guarantee this.
I’m currently working on a project—an online version of a medical self-screening form—that has a valid reason for making users think. Success will involve making sure that users really understand the meaning of each question, and that they take the form seriously—that they take the time to answer honestly and accurately. My teammates and I find ourselves designing a slow experience rather than a fast one.
But what slows people down and makes them more thoughtful? And what is it about a particular design that makes people really invest their attention?
Laying the groundwork for thoughtfulness
In my experience, there seem to be three main strategies for encouraging meta-moments.
Inbox by Gmail makes you think by confronting you with a barrier. You can’t just try the service. You have to be invited. You can request an invitation (by following the instructions on their site), or a friend can invite you—but you can’t get started right away. Anticipation and excitement about the service has space to gather and develop. And it does. In its first few weeks, invites were going on eBay for $200.
This strategy certainly worked on me. Within moments of landing on the page, I went from being slightly intrigued to a state of I-must-have-it. Following the instructions, I found myself composing an email to firstname.lastname@example.org requesting an invitation. “Please invite me. Many thanks, Andrew,” I wrote, knowing full well that no one but me was ever going to read those words. Why hadn’t they simply let me submit my email address somewhere? Why were they deliberately making things hard for me?
Something clever is going on here. Adding a barrier forces us to engage in a deeper, more attentive way: we are encouraged to think. Granted, not everyone will want or need this encouragement, but if a barrier can create a digital experience that is noticed and remembered, then it’s worth talking about.
Putting up a “roadblock,” though, seems like a risky way to encourage a meta-moment. Stopping people in their tracks may make them simply turn around or try another road. For the roadblock to be effective (and not just annoying), there has to be enough interest to want to continue in spite of the obstacle. When I encounter a paywall, for example, I need to be clear on the benefits of parting with my money—and the decision to pay or subscribe shouldn’t be a no-brainer, especially if you’re hoping for my long-term commitment. iTunes’s micropayments, Amazon’s “Buy now with 1-Click,” and eBay’s impulse bidding all represent a trend toward disengaging with our purchases. And in my own purchasing patterns, things bought this way tend not to mean as much.
Smartphone apps have a similar impact on me. Most of the time, it seems that their only aim is to provide me with enough fleeting interest to make me part with a tiny upfront cost. As a result, I tend to download apps and throw them away soon afterward. Is it wrong to hope for a less disposable experience?
In-app purchases employ a kind of roadblock strategy. You’re usually allowed to explore the app for free within certain limitations. Your interest grows, or it doesn’t. You decide to pay, or you don’t. The point is that space is provided for you to really consider the value of paying. So you give it some proper thought, and the app has to do far more to demonstrate that it deserves your money. FiftyThree’s Paper, my favorite iPad app, lets you have a blast for free and includes some lovely in-app promotional videos to show you exactly why you should pay.
Roadblocks come in many shapes and sizes, but they always enforce a conscious consideration of how best to proceed. Navigating around them gives us something to accomplish, and a story to tell. This is great for longer-term engagement—and it’s why digital craftspeople need to shift their thinking away from removing barriers and instead toward designing them.
Speed bumps are less dramatic than roadblocks, but they still encourage thought. They aim to slow you down just enough so that you can pay attention to the bits you need to pay attention to. Let’s say you’re about to make an important decision—maybe of a legal, medical, financial, or personal nature. You shouldn’t proceed too quickly and risk misunderstanding what you’re getting yourself into.
A change in layout, content, or style is often all that is required to make users slow down. You can’t be too subtle about this, though. People have grown used to filtering out huge amounts of noise on the internet; they can become blind to anything they view as a possible distraction.
Online, speed bumps can help prepare us mentally before we start something. You might be about to renew your vehicle tax, for instance, and you see a message that says: “Hold up! Make sure you have your 16-digit reference number…” You know that this is useful information, that it’ll save you time to prepare properly, but you might find yourself getting a little frustrated by the need to slow down.
Although most of us find speed bumps irritating, we grudgingly accept that they are there to help us avoid the possibility of more painful consequences. For example, when you fire up an application for the first time, you may see some onboarding tooltips flash up. Part of you hates this—you just want to get going, to play—and yet the product seems to choose this moment to have a little conversation with you so that it can point out one or two essentials. It feels a little unnatural, like your flow has been broken. You’ve been given a meta-moment before being let loose.
Of course, onboarding experiences can be designed in delightful ways that minimize the annoyance of the interruption of our desired flow. Ultimately, if they save us time in the long run, they prove their worth. We are grateful, as long as we don’t feel nagged.
In spite of the importance of speed bumps online, we tend not to come across them very often. We are urged to carry on at speed, even when we should be paying attention. When we’re presented with Terms and Conditions to agree to, we almost never get a speed bump. It’d be wonderful to have an opportunity to digest a clear and simple summary of what we’re signing up for. Instead, we’re faced with reams of legalese, set in unreadable type. Our reaction, understandably, is to close our eyes and accelerate.
Online diversions deliberately move us away from conventional paths. Like speed bumps, they make us slow down and take notice. We drive more thoughtfully on unfamiliar roads; sometimes we even welcome the opportunity to understand the space between A and B in a new way. This time, we are quietly prodded into a meta-moment by being shown a new way forward.
A diversion doesn’t have to be pronounced to make you think. The hugely successful UK drinks company Innocent uses microcopy to make an impact. You find yourself reading every single bit of their packaging because there are jokes hidden everywhere. You usually expect ingredients or serving instructions to be boring and functional. But Innocent uses these little spaces as a stage for quirky, silly fun. You end up considering the team behind the product, as well as the product itself, in a new light.
Companies like Apple aim for more than a temporary diversion. They create entirely new experience motorways. With Apple Watch, we’re seeing the introduction of a whole new lexicon. New concepts such as “Digital Touch,” “Heartbeat,” “Sketch,” “Digital Crown,” “Force Touch,” “Short Look,” and “Glances” are deployed to shape our understanding of exactly what this new thing will do. Over the course of the next few years, you can expect at least some of these terms to pass into everyday language. By that time, they will no longer feel like diversions. For now, though, such words have the power to make us pause, anticipate, and imagine what life will be like with these new powers.
The magic of meta-moments
Meta-moments can provide us with space to interpret, understand, and add meaning to our experiences. A little friction in our flow is all we need. A roadblock must be overcome. A speed bump must be negotiated. A diversion must be navigated. Each of these cases involves our attention in a thoughtful way. Our level of engagement deepens. We have an experience we can remember.
A user journey without friction is a bit like a story without intrigue—boring! In fact, a recent study into the first hour of computer game experiences concludes that intrigue might be more important than enjoyment for fostering engagement. We need something a little challenging or complex; we need to be the one who gains mastery and control. We want to triumph in the end.
Our design practices don’t encourage this, though. We distract our users more than we intrigue them. We provide the constant possibility of better options elsewhere, so that users never have to think: “Okay, what next?” Our attention is always directed outward, not inward. And it—not the technology itself, but how we design our interactions with it—makes us dumb.
UXD strives toward frictionless flow: removing impediments to immediate action and looking to increase conversions at all costs. This approach delivers some great results, but it doesn’t always consider the wider story of how we can design and build things that sustain a lasting relationship. With all the focus on usability and conversions, we can forget to ask ourselves whether our online experiences are also enriching and fulfilling.
Designing just one or two meta-moments in our digital experiences could help fix this. Each would be a little place for our users to stop or slow down, giving them space to think for themselves. There’s no point pretending that this will be easy. After many years dedicated to encouraging flow, it will feel strange to set out to disrupt users. We’d be playing with user expectations instead of aiming to meet and exceed them. We’d be finding little ways to surprise people, rather than trying to make them feel at ease at all times. We might tell them they need to come back later, rather than bend over backwards to satisfy them right away. We might delegate more responsibility to them rather than try to do everything for them. We might deliberately design failures rather than seek to eradicate them.
How will we test that we’ve achieved the desired effect and not just exasperated our users? Usability testing probably won’t cut it, because it’ll be tricky to get beyond the immediate responses to each set task. We might need longer-term methods, like diary studies, in order to capture how our meta-moments are working. Our UXD methods may need to shift: from looking at atoms of experience (pages, interactions, or tasks), to looking at systems of experience (learning, becoming, or adopting).
It will be a challenge to get people behind the idea of adding meta-moments, and a challenge to test them. The next time we create a design solution, let’s add just one small barrier, bump, or quirk. Let’s consider that the best approach may be a slow one. And let’s remember that removing needless thought should never end up removing all need for thought. Putting thought into things is only part of a designer’s responsibility; we also have to create space for users to put their own thought in. Their personalities and imaginations need that space to live and breathe. We need to encourage meta-moments carefully and then defend them. Because they are where magic happens.
There’s a curious concept in astrophysics known as the Drake Equation. Developed to quantify the potential for intelligent life in our galaxy, it raises a number of odd questions, among them: does having intelligence, in the long run, actually benefit or harm a species? In other words, will amoebas ultimately outlive humans in the face of eternity?
If you’re like me, these are the types of things you think about while listening to hold music before conference calls. But as a content strategist, I can’t help but ask the same question about something my clients suddenly seem to be clamoring for: personalized user content.
It sounds great in theory: content that is more targeted to the user can provide a richer, more precise experience. But there is also a dark side: used improperly, targeting risks invading privacy and eroding trust. As Drake supposes, true intelligent life is rare, in part because it has the potential to destroy itself.
So how might you dip into this intelligence without wrecking your content in the process? How can we approach personalized content in a way that is sustainable and respectful, not self-destructive?
For good or for evil
At a basic level, personalization (aka targeting) means serving unique content to a user based on something we know about him or her—from geographic location to specific browsing history. And as you’ve likely observed, the value of personalization is largely in how you wield it. It’s helpful to us when Amazon makes recommendations based on our past viewing history. Conversely, we’ve all been bothered at some point by a creepy targeted ad—the one that either somehow knows too much about you, or is trying to sell something you don’t want.
Historically, the average UX person hasn’t played much of a role in either of these scenarios, the latter being controlled by online marketers, the former monopolized by the Amazons of the world. But the recent advent of so-called “experience management systems”—like Adobe Experience Manager, Sitecore Experience Platform, and Episerver Personalization Manager—has (somewhat precipitously) made the ability to personalize content more accessible to clients. You don’t have to look much further than the goodie bag from the last conference you attended to see that all of the big name CMSes are now aggressively marketing their own flavor of personalization software.
Do you even need it?
So what do you do when your client says they want to personalize content? The good news is that the foundation of personalized content strategy is the same set of tools you know and love: a core strategy statement, a set of guiding principles, and a basic content model. You now must consider how (or if) targeting can advance these directives. For example:
Good reasons to target site content:
- Your audience can be segmented in ways that are meaningful.
- Narrowing your message provides incremental value to your users.
- Personalized content is tied to specific KPIs or business objectives.
Bad reasons to target site content:
- Because we can.
- Some variation of #1.
You may face some strong headwinds if your client just bought a shiny new EMS and can’t wait to start solving world hunger. Again, as is always the case with the technology du jour, the product demos for these things are very seductive and typically involve light shows and kittens and free ecstasy. You may have to be the voice of reason. But that’s why you went to content strategy school, right?
Partial steam ahead!
Next, consider your targeting technology. As a general rule, the systems that support targeted content will be one of two things:
- Rules-based: The more manual approach, this involves setting up discrete audience segments in the system and writing rules for when and how to show them content. Example: It looks like Colin’s IP address is from Washington, DC, so let’s show him what we show everyone in that location.
- Algorithm-based: The “secret sauce” approach, this focuses less on the overall segment and more on a specific user’s behavior. Example: Colin clicks on 3.65 articles/day about soup, so let’s show him a campaign for soup.
For our purposes, we’ll take a closer look at a rules-based model, since this is more likely what you’ll be running into if your client is just starting out with personalization. You’ll first need to determine your “segments.” Similar to UX personas, segments are groups of users with some distinguishing set of traits like age, interest, or location. The difference here is that a targeted segment will be determined by real-time data, either internal or external to your site. Typically this data will be fed through some type of centralized rules engine accessed by your CMS.
Applying a personalized content framework
This is all getting a bit abstract, so let’s imagine for a moment that we’re creating a new site for An Airline Apart (obviously the next logical brand extension). We want to target busy creative professionals who travel regularly for work. What online content should we create to give us an edge with this audience?
Our first bright idea is to start a content campaign that takes the stress out of business travel. Easy enough, right? But that actually makes a lot of assumptions—what does “stressful” even mean? Can we break it down by audience?
A recent study from Carlson Wagonlit Travel asked 7,400 global business people who travel regularly for work to rank how stressful business travel is to them at each stage of their trip. Here’s what they found, sorted by gender:
There are clear differences: women tend to find the pre-trip phase the most stressful, while for men this is the least stressful phase. And for some reason, at the post-trip phase, it’s the complete opposite.
It gets even more interesting. Here’s what happened when they sorted the data by role:
According to this, business travel stress changes wildly depending on company role. For example, high-level employees are least stressed before the trip, and more stressed after; for support staff, it’s the total opposite.
Now, if we were doing this properly, we would absolutely want to drive into the “why” behind this. But for the sake of our sample exercise, we have more than enough justification to pursue a segmented content approach to our campaign. We could potentially set up 12 segments across gender and role in our system; here, though, let’s limit our focus to senior execs, male and female.
Mapping segments to content
From a technical point of view, personalizing content comes down to running targeted rules on individual components on a page. So let’s say we have our An Airline Apart homepage with typical content zones. If we didn’t know who you were, we would show our usual default content:
Now in theory, we could write rules to target content for all of these blocks for our users. But how do we know where to begin? This is the “substance” question in content strategy, and where we need to consider very specifically what value we are adding.
To help us think through this, our team at ICF Interactive developed a framework for the four core types of personalized content. The first two have to do with the “task at hand,” or what the user came to your site to do today. The second two have to do with the “big picture,” or what you’re trying to get people to see and feel as part of your larger brand experience. Here’s how it breaks down:
- Content that alerts. This type of targeting improves the customer experience by displaying relevant, time-sensitive information, such as a weather delay, service disruption, or other real-time issue.
- Content that makes tasks easier. The second “task at hand” category, this type makes users’ lives easier by helping them do what they came here to do—e.g., “smart” navigation, deep links to useful tools, or automatically deprioritizing unrelated content.
- Content that cross-sells. This type may make your inner designer squirm, but it will realistically be one of your most important use-cases (and likely the one most directly tied to project ROI). Whether you’re a global oil conglomerate or a non-profit that provides hugs to reindeer, this is your place to market whatever it is you need to market. Again, the trick here is to show users something relevant, not just what you want them to see. Examples: ad for a new product, announcement for your upcoming conference, call to join or donate, etc.
- Content that enriches. A close cousin to the cross-sell, content that enriches a user’s experience is supplemental to their overall brand perception. This might include blogs, articles, community features, social networks, or third-party content. Think of this as the “soft sell” versus the “hard sell.” On a standard task-oriented page, this content will typically occupy the least critical zone.
Going back to our example, here’s how we could apply this approach to the personalized content we want to show on the An Airline Apart homepage:
|Type of personalized content||What to show senior execs|
|Alert||A list of flight cancellations impacting this user in real time|
|Make easier||Some shortcuts to content for our Priority Flyers service|
|Cross-sell||An ad for our new business class upgrade|
|Enrich||Tips on pre-trip (female segment)
Tips on post-trip (male segment)
Remember our bland default page? With our rules up and running, a senior exec will instead see this (color-coded by type):
Notice we’re now showing content specific to our executives, with the added nuance that the bottom right zone (“enrich content”) differs for our female versus male audience, based on that research nugget around stressful travel.
Bear in mind that these two are looking at the same site at the same time from two different locations—the CMS is targeting the content based on what we know about them, so they effectively get a different experience (and if everything is set up correctly, a better one).
Content on crack
You’re starting to see the implications, right? If we were to follow this through, instead of writing one content strategy, we now effectively need to write 12—one for each audience segment we had identified. As a content strategist, you’ve probably swallowed your content gum. The technology is there to help you accelerate that process to some extent, but this is precisely why taking a disciplined approach to personalized content is critical. Otherwise, you will be quickly overwhelmed, not only in terms of creation and execution, but also maintenance and support.
Taking the first step
What’s that you say? You’re not intimidated? Great! Just a few things to keep in mind.
Have the right resources
Remember that putting personalized content in the field requires not only a sound strategy, but also the resources to support it. You may still need some work if:
- You don’t have enough content to make targeting useful
- You don’t have enough staff to maintain targeted content
- Your content is not semantically rich—you need a taxonomy, metadata, etc.
- You don’t have a CMS that supports it
- You don’t have analytics and tracking in place to gain insights and adjust
There’s a whole other conversation to be had around the ethics of targeting, but suffice it to say there is a line between providing helpful personalization and invading privacy. If you find yourself trying to force content on people with your newfound power, stop. Think of Ida Aalen’s core model. Is your content truly at the intersection of user and business goals, or just business goals? Approaching targeted content strategy with respect for your users will ensure that your site lands on the right side of web personalization history.
Sound like a lot? Consider that it doesn’t have to be that complex. In fact, can you guess the number one method of personalized content in use today? That’s right, email. So chances are you’re probably already doing targeting on some level, and have an organizational starting point from which to build. With the right strategy and technology, you’re really only limited by your imagination, and your ability to adapt to mistakes along the way.
And who knows? You may discover that the web can, in fact, support intelligent life.
IN ISSUE № 420 of A List Apart:
Meta-Moments: Thoughtfulness by Design
by ANDREW GRIMES
Does the internet ever stop you in your tracks? Does it sometimes make you pause and think about what you’re doing? Andrew Grimes calls such moments meta-moments. He walks us through why meta-moments are occasionally necessary and how we might build them into the experiences we design. ⇛
Approaching Content Strategy for Personalized Websites
by COLIN EAGAN
Experience management systems are making it easier than ever to customize content for your visitors—but are you using your newfound personalizing powers for good (or for creepy)? Colin Eagan shows that personalization can be done, thoughtfully, using the same tools you would apply to any content strategy conundrum: by asking why, being deliberate, and putting users first. ⇛
Theres a new vulnerability in town. ...(more)...
Yesterday on 2015-05-19, I attended a meeting fr ...(more)...
Thanks to Xavier for bringing this to our attention. It looks a couple of days ago, a legitimate ...(more)...
Yes, there is a security patch for the Apple Watch now. It fixes 13 different vulnerabilities ...(more)...
Conversions@Google published a complete video recording of my two and a half hour seminar last month (April 2015 in Dublin) on designing for mobile and across devices.
In part one I walk through the growth of connected screens and how to design software that works well across a wide variety of devices from mobile to TVs and beyond. In particular I focus on output (what can show up on a screen), input (what people can put into our screens), and posture (how people interact with the output and input of a screen).
In part two I answer audience questions and cover screen-less devices, responsive web designs vs. native applications, form conversions, touch gestures, navigation, cross-platform consistency and more.
Thanks to the Conversions@Google team for making these sessions available to all.
On PCs (or smartphones, or TVs) computer operating systems have a lot of user interface elements and conventions in common. So it's really the differences in each OS that define their unique personalities. Wearables are no different as my recent companions between Android Wear and Apple Watch help illustrate.
Both operating systems contain an extensive but "hidden" interface layer. That is, there's lots of controls and features available but they require knowledge of touch gestures, audio commands, or hardware to operate. In practice I've personally found it hard to keep all these invisible interface commands memorized (especially across devices).
When starting from a watch face with touch, Android Wear mostly maintains a continuous vertical scroll path. Apple Watch's scroll flow, on the other hand, varies between vertical and horizontal swipe interactions.
When I first began designing touch interfaces, I'd make UIs that required people to switch between vertical and horizontal scrolling often —sometimes even in the same task. Over the years I've come to appreciate the importance of scroll flow: a singular, simple gesture that makes an app's core value easily accessible. Which may be why it took me a while to get used to Apple's multi-directional model.
Another key difference between Apple Watch and Android Wear is how useful information is organized. Apple allows you to set a specific order for these "glances". Once set, that order stays consistent whenever you access them. Android Wear, instead, displays these "cards" based on which are most relevant at any given time or place. Clearly both approaches (consistency and context) have benefits and both seem to reflect the strengths of each of the companies behind their OS.
Android Wear's focus on context is also reflected in the display of information on the watch face. Rather than showing when a meeting on your calendar will begin, Wear displays the time left until the meeting starts. A small but useful difference in making "timely, glance-able information" work.
Both operating systems offer multiple ways to access apps and information including touch gestures, voice commands, and hardware controls. In practice, however, I find myself relying on heads-up glance-able information frequently and voice or touch activated actions much more rarely.
On the wrist, awareness (glance-able, contextually relevant updates/info) and triage (lightweight actions in response) work well. Initiating tasks happens a lot less often and usually requires more time focusing on the watch than necessary.
In other words, actions, not apps seem to make for better wrist-based experiences. At least for now...
A new vulnerability arised in Safari Web Browser that can lead to an ...(more)...