Every time someone writes about smart cities my ears perk up. Sommer Mathis just published a great interview with Anthony Townsend (the author of the new book Smart Cities: Big Data, Civic Hackers, and the Quest for a New Utopia). From The Rise and Fall and Eventual Rise Again of the ‘Smart City’, quoting Townsend:

But our “smart” cities are going to look much more like the web, where there’s going to be a lot of things deployed by individual decision, talking to each other through open standards in very ad hoc, loosely knit ways.

And what I like about that is that kind of architecture is actually what a good urbanist would tell you builds a good city. You build an open grid, you allow people to customize the pieces of it that they have jurisdiction over, and you get this fine-grained, resilient, vibrant kind of system with a lot of complexity, as opposed to a very controlled, hierarchical system that’s actually fairly brittle when it comes under stress.

It’s great to see smart city thinking evolve away from large centralised systems to citizen-inspired networks. Some more interesting articles on this topic:

• Death, life and place in great digital cities
• Clever cities: The multiplexed metropolis
• Smart cities and smart citizens
• 4 Smart Designs For New Cities That Can Withstand Any Storm

I’ve been thinking about Miya Tokumitsu’s In the Name of Love for days now. Miya argues that the mantra “Do what you love” devalues work and hurts workers:

There’s little doubt that “do what you love” (DWYL) is now the unofficial work mantra for our time. The problem with DWYL, however, is that it leads not to salvation but to the devaluation of actual work—and more importantly, the dehumanization of the vast majority of laborers. […]

“Do what you love” disguises the fact that being able to choose a career primarily for personal reward is a privilege, a sign of socioeconomic class. Even if a self-employed graphic designer had parents who could pay for art school and co-sign a lease for a slick Brooklyn apartment, she can bestow DWYL as career advice upon those covetous of her success.

If we believe that working as a Silicon Valley entrepreneur or a museum publicist or a think-tank acolyte is essential to being true to ourselves, what do we believe about the inner lives and hopes of those who clean hotel rooms and stock shelves at big-box stores? The answer is: nothing.

It’s a tough critique, and at first I was looking for reasons to dismiss the argument. But the more I think about it, the more sense it makes to me. The “do what you love” idea is related to another theme I often see on social networks. It’s some variation of the message “If you don’t want to go back to work after vacation, you should find a job that doesn’t make you want to go on vacation all the time.” This has always felt wrong to me. I love my job — I really do. But that doesn’t mean I can’t also enjoy spending several days with my family, hiking, climbing, and hopefully with my nose buried in a zombie book.

This doesn’t mean I’m lazy, it doesn’t mean my job isn’t meaningful, it doesn’t mean I don’t like the people I work with. I will just always find a different kind of enjoyment in actively doing nothing than I do when I work. And it turns out that leisure time — and in particular, being bored — is really good for us. Nicholas Carr says this in The web expands to fill all boredom:

We don’t like being bored because boredom is the absence of engaging stimulus, but boredom is valuable because it requires us to fill that absence out of our own resources, which is process of discovery, of doors opening. The pain of boredom is a spur to action, but because it’s pain we’re happy to avoid it. Gadgetry means never having to feel that pain, or that spur. The web expands to fill all boredom.¹

So I just think that it’s ok to split up work and leisure. If we’re lucky we get to have jobs that we love doing — and we should absolutely work hard to accomplish that goal. But spending time away from work (or working on side projects) is important and healthy, and we shouldn’t be afraid to acknowledge that. It doesn’t diminish your job satisfaction or dedication if you enjoy being on vacation.

Anyway, I’ll have Miya have the last word:

Do what you love and you’ll never work a day in your life! Before succumbing to the intoxicating warmth of that promise, it’s critical to ask, “Who, exactly, benefits from making work feel like nonwork?” “Why should workers feel as if they aren’t working when they are?” In masking the very exploitative mechanisms of labor that it fuels, DWYL is, in fact, the most perfect ideological tool of capitalism. If we acknowledged all of our work as work, we could set appropriate limits for it, demanding fair compensation and humane schedules that allow for family and leisure time.

And if we did that, more of us could get around to doing what it is we really love.

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.”