James Stout explains how Responsive Design won’t fix your usability issues for you. If your site is bad before the redesign, those problems won’t just magically go away once you’ve gone responsive. It’s a good article, and I especially like this bit:

But in the face of all this great technology, it’s more important than ever to avoid the “features for features’ sake” pitfall. Maintain that ever-present purpose and goal and be deterministic concerning whether these technologies help drive that goal, or whether they’re being included simply because they’re new. Use only those features you need and make them truly spectacular when you do.

The mobile revolution is nothing new, yet the battle to bring it about rages on. Understand that success on the web is not defined by the tools in your arsenal, which any web-MacGyver can use, but by the strategy you employ, including the very manner in which you approach the field.

It reminds me of one of my favorite Product Management quotes, from Barbara Nelson’s Who Needs Product Management?:

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

Des Traynor’s Product Strategy Means Saying No is also a great article on the topic of product focus and market needs:

Identifying and eliminating the bad ideas is the easy bit. Real product decisions aren’t easy. They require you to look at a proposal and say “This is a really great idea, I can see why our customers would like it. Well done. But we’re not going to build it. Instead, here’s what we’re doing.”

And since I haven’t linked to Michael Wolfe’s answer to Why is Dropbox more popular than other programs with similar functionality? yet this year, I might as well do it now and get it over with:

“But,” you may ask, “so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!”

No, shut up. People don’t use that crap. They just want a folder. A folder that syncs.

In The Joy of Unfollowing Maureen O’Connor takes on the idea that it’s possible to “do social networks wrong”. Here’s her take on whether it’s possible to “share too much” on Facebook or Twitter:

No. There is no such thing as TMI on the Internet. We are living in a post-TMI age, and everyone needs to deal with it. Preferably by using the “unfollow” button.

There is such a thing as too much information for you. There is such a thing as information the speaker will later regret. But if an audience is willingly and pleasurably consuming the information, then by definition, that is the right amount of information for them. Assuming the information in question is yours to share — your life, your ideas, your stories, your pictures, your theories about elf genealogy in Lord of the Rings — you cannot share too much of it. There are no captive audiences on the Internet. […]

If you follow someone on Twitter and you find that her tweets are too much for you, then you may unfollow her. If you continually recoil at TMI, it’s because you lack the willpower to stop consuming (or foresight to avoid) the information in question. That’s your fault.

We are responsible for the information we take in. We can’t blame other people for that. The hardest (and most important) thing to do, is to realise that it’s ok to let the vast majority of information pass us by.

(link via The Loop)

I’m excited to be part of Industry Web Conference in April this year, alongside some people I’ve admired for a long time. I’m going to be talking about a thing that’s fallen out of fashion a little bit over the past year or so: Deliverables. Yep — the business we’re supposed to be getting out of. So I’m a bit nervous about the talk, but I hope people will give it a chance.

The talk is called Getting back into the (right) deliverables business, and here’s a little more about it:

I feel a little bad for the static wireframe. It’s had a bad year. In fact, UX deliverables in general have had a bad couple of years. There’s a growing skepticism about the value of Personas and other traditional UX artefacts, as well as an onslaught of “get out of the deliverables business” refrains from Lean methodologies.

All of this led me to lots of introspection about deliverables, and if it’s actually possible to create deliverables that are useful to help create better products.

In this talk I’ll tell our story. How we stripped down all our deliverables to almost nothing, and then started building it all up again slowly by asking ourselves, “What is absolutely necessary for us to do a great job?” I’ll discuss some of the deliverables we’ve since created (such as Expanded Journey Maps and Content Slice Diagrams), how they’re useful to us, and how you might be able to use them in your design process as well.

We’ve come to realise that not all UX deliverables are bad. Only bad deliverables are bad.

I’m going all in on this — the day before the conference I’m also doing a full-day workshop called Using Customer Journey Maps for Effective Content-First Design. This will be a very practical day on what has become an essential deliverable for us:

More than just a journey with touchpoints, emotions, takeaways, etc., it’s also a representation of the Information Architecture and the content plan, with Personas (needs, goals, scenarios) serving as the starting point for everything — sort of like the glue that ties it all together.

You can think of this as the UX Strategy document. It incorporates Persona-based user needs and business goals with site structure and content planning in a way that really works. It also places content at the centre of the design process, which makes it easier to follow mobile first and responsive design strategies.

In this workshop we’ll discuss the value of this document and then go through a practical exercise to create an Expanded Customer User Map so you can apply it in your roles immediately.

So anyway, I’m really looking forward to it. And here’s the special bit. If you use the discount code rian, you can get conference tickets and/or workshop tickets for £40 off. That’s a pretty substantial discount. You can read more about the conference here, and register here. I hope to see you in Newcastle upon Tyne in April!

In Product Kyle Neath asks:

We are focused on likes, app opens, hours spent, pageviews, and company valuations — but do these translate to a better future? Are we using ads to provide for a connected humanity, or conning people into conspicuous consumption? It’s hard to judge. I do know that it just feels right when you build a good product. […]

That’s really the core of it: how can we create financially sustainable products that bring people joy and make the world a better place?

I think this is where side projects fit in so well. It’s our time to dream quietly about what could be, and take small steps towards making that dream a reality. Which reminds me, I just bought Rachel Andrew’s The Profitable Side Project Handbook. It’s getting some good reviews, so I’m excited to dig into it.

Poorna Bell’s So Long, FOMO is making the rounds today:

At nearly every restaurant table I saw, there was at least one person (if not most) who spent most of their time taking photos or video to put on Facebook later, or searching for something on the internet, or playing games or just checking for texts. For more and more of us, technology is taking over, invading even our most personal and private of moments.

This idea that technology is turning us into antisocial monkeys is getting pretty old. Putting photos on Facebook helps you connect with others around the experience. Searching for something on the internet helps you move conversations forward (or change direction completely). All these activities are inherently social. Jason Feifer’s impassioned rejection of Sherry Turkle’s doom-and-gloom ideas provides a very good counterargument to all the fear-mongering:

Turkle imagines that any interaction with technology somehow negates all the time spent doing other things. She also imagines that we must devote ourselves in only one way to every task: At a dinner table, we are only serious and focused on conversation; at a memorial service, we are only mournful. That is not the way we live. It’s never been the way we live. And that’s the beauty of technology, which Turkle cannot see: We can use it for all purposes, to express joy and sadness, to have long conversations or send short texts. We made it. It is us.

It’s time for us to realise that we are evolving the way we communicate with each other, and that’s ok. I’m not saying we shouldn’t be mindful about how much time we spend staring at our phones, but we should recognize how much more social our devices are making us. Clive Thompson points this out in his book Smarter Than You Think:

What are the central biases of today’s digital tools? There are many, but I see three big ones that have a huge impact on our cognition. First, they allow for prodigious external memory: smartphones, hard drives, cameras, and sensors routinely record more information than any tool before them. We’re shifting from a stance of rarely recording our ideas and the events of our lives to doing it habitually. Second, today’s tools make it easier for us to find connections—between ideas, pictures, people, bits of news—that were previously invisible. Third, they encourage a superfluity of communication and publishing. This last feature has many surprising effects that are often ill understood.

And we should also remember that it’s not up to us to tell people how to experience the moments that are important to them. As usual, XKCD says it best:

Vijay Sundaram takes the concept of technical debt and applies it to User Experience Design:

You know you’re a subprime borrower when your team decides to “clean this up next release”. But the next release has a backlog of critical bug fixes, must-have feature requests, and of course plenty of new design shortcuts that emerge in the process. What’s more, the usage data for the last release is showing great engagement and no one has complained yet about the shortcuts you took. Fixing those can’t possibly be a priority right now. Before long, the team is grafting one design shortcut onto another, and the only way to unwind them is a wholesale reboot.

The article made me think of Henrik Kniberg’s excellent Good and Bad Technical Debt (and how TDD helps), in which he explains the concepts of a “good mess” and the “technical debt ceiling”:

A fresh mess is not a problem. It’s the old mess that bites you. […]

If you are coding up a new feature, there are lots of different ways to do it. Somewhere there is probably a very simple elegant solution, but it’s really hard to figure it out upfront. It’s easier to experiment, play around, try some different approaches to the problem and see how they work. […]

The problem is, just like in the kitchen, we often forget to clean up before moving on. And that’s how technical debt goes bad. All that “temporary” experimental code, duplicated code, lack of test coverage — all that stuff will really slow you down later when you build the next feature.

So regardless of your reason for accumulating short-term debt, make sure you actually do pay it off quickly.

I’ve been wondering how this applies to UX debt. Is it ok to take some design shortcuts, knowing that you’ll come back later and fix it (up to a “UX debt ceiling”)? My gut feeling is to say no, because design is so path-dependent. Your early choices constrain your later design choices, so if you make the wrong choice it can really hurt down the line. For example, if you skip user research in the beginning of the project, you’re highly likely to make the wrong choice about what to build, which isn’t something you can fix easily later on.

The solution is to have shorter UX (and development) cycles, which is becoming commonplace anyway with the rise of the Lean movement. I’m reminded of IDEO Design Director David Aycan’s 2010 article in HBR, Don’t Let the Minimum Win Over the Viable, in which he explains the importance of taking small steps so that it’s easier to correct course when you realise you’re on the wrong track:

Sketching or mocking up experiential prototypes and then testing them with consumers or potential partners, while also explicitly jotting down your operating and business assumptions and using them to discuss the business with industry experts, allows you both to pick a promising route to invest in the development sprint and to pivot with confidence. For example, by prototyping multiple consumer experiences and business models before investing in an initial MVP, GoGo was able to launch an airline WiFi and in-flight service experience that combined the best of multiple alternative services that might be offered in flight. One might think of this approach as testing multiple MVPs in parallel.

Creating multiple options in tandem creates more confidence in the core variables, which in turn means that pivots may be less drastic or disruptive later on. This approach can be applied beyond product features to business models and operating approaches as well.

He uses this sketch to illustrate the approach:

This makes a lot of sense in the context of UX and technical debt as well. A pragmatic approach to dealing with software debt seems to be something like this:

1. Create different possible paths (variation)
2. Pick a direction and work towards it (iteration)
3. Get feedback, address debt and other issues, correct course if necessary
4. Repeat cycle

The trick is to be ok with the early messes, but not let them deteriorate so much that you’re unable to clean things up when you finally decide it’s time. Remember the broken windows theory: “maintaining and monitoring urban software environments in a well-ordered condition may stop further vandalism neglegence and escalation into more serious crime technical issues.”

It took me a while to get through Michael Pepi’s The Postmodernity of Big Data. It’s dense, and the premise seemed so far-fetched that I wasn’t sure it would be worth the time investment:

But beyond economic motivations for Big Data’s rise, are there also epistemological ones? Has Big Data come to try to fill the vacuum of certainty left by postmodernism? Does data science address the insecurities of the postmodern thought?

Yes, I know, that sounds like a bit of a stretch. But I’m glad I stuck with it. The essay brings up some really interesting thoughts around the certainty promised by Big Data (even though some view it as nothing more than a clever marketing campaign for something that has been around a long time), and how that might be a response to the relativism of postmodernism:

Though both are projects that address positions about empiricism and meaning making, postmodernism and Big Data are in some senses opposites: Big Data is an empirically grounded quest for truth writ large, accelerated by exponentially expanding computing power. Postmodernism casts doubt on the very idea that reason can unearth an inalienable truth. Whereas Big Data sees a plurality of data points contributing to a singular definition of the individual, postmodernism negates the idea that a single definition of any entity could outweigh its contingent relations. Big Data aims for certainties — sometimes called “analytic insights” — that fly in the face of postmodernist doubt about knowledge. Postmodernism was confined to the faculty lounge and the academic conference, but Big Data has the ability to dictate new rules of behavior and commerce. An e-commerce outfit is almost foolish not to analyze browsing data and algorithmically determine likely future purchases, or as Jaron Lanier put it in Who Owns the Future, “your lack of privacy is someone else’s wealth.”

Consider this your difficult but satisfying weekend reading project.

Jeffrey Zeldman in a strong defense of web standards:

While many of us prefer to concentrate on design, content, and experience, it continues to be necessary to remind our work comrades (or inform younguns) about web standards, accessibility, and progressive enhancement. When a site like Facebook stops functioning when a script forgets to load, that is a failure of education and understanding, and all of us have a stake in reaching out to our fellow developers to make sure that, in addition to the new fancy tricks they’ve mastered, they also learn the basics of web standards, without which our whole shared system implodes.

I’ll add this to the ever-growing case for progressive enhancement.