Meta-Moments: Thoughtfulness by Design is a great post by Andrew Grimes on the benefits of making users pause and think in certain areas of an interface:

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.

John Naughton wrote another interesting “the machines are coming for our jobs!” article¹. This one is from the angle of “combinatorial innovation”—the idea that innovation happens when a bunch of disparate advances in technology come together in an unexpected way. His point in We are ignoring the new machine age at our peril is that it’s hard to see the implications of this kind of innovation:

The implications of [the self-driving] vehicle stretch far beyond the future of the automobile industry or even the future of transport. What it signals is that vast swaths of human activity – and employment – which were hitherto regarded as beyond the reach of “intelligent” machines may now be susceptible to automation. So we need to revise our assumptions about the future of work in the light of combinatorial innovation.

This is sure to be a bit controversial, but Jon Kolko makes some great points about design-led vs. lean development in Lean Doesn’t Always Create the Best Products:

And with this, we arrive at perhaps the most important distinction between an empathetic design-led approach and Lean. Lean is fast. Design is slow. Design is more contemplative, reflective, and because it demands systems thinking and marinating in the ambiguity of cultural data, it simply takes longer. The benefit is in producing emotionally sound products: products that people love, not just products people use. Increasingly, people expect more from the products and services they engage with. They expect quality, and use it both as a selection criteria for purchase and as a constraint for sustained use.

I don’t think Lean principles are necessarily in conflict with design principles (there is, after all, a thriving Lean UX movement). But the part that resonates here is the speed pressure that the Lean movement has placed on design activities. All research, prototyping, and graphic design is expected to happen much faster now. Speed is good, but not if it comes at the cost of not truly understanding the problems and user needs you’re designing for. And that’s where Jon’s points are worth taking to heart.

Kate Heddleston makes some great points in The Null Process:

When people say they don’t want process, what they’re really saying is they don’t want formalized process. There is really no such thing as “no process.” A process is simply the steps it takes to complete a task, so if a task is completed then by definition a process was used. Without formalized process everyone does things their own way, and there is no documentation for how problems are solved. This informal, undocumented process is the “null process,” and, if used incorrectly, the null process can have major implications for a company.

This reminds me of two things. The first is Rebekah Cox’s definition of Product Design:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

What this implies is that everything you do in product design has a consequence. So just “letting things happen” is also a decision. It’s just a pretty bad one. Maybe that should be called “null design.” I don’t know, I’m not good at naming things¹.

The second is Michael Lopp’s The Process Myth. The whole thing is great, but this quote in particular has always stuck in my mind:

Engineers don’t hate process. They hate process that can’t defend itself.

Also this advice:

Healthy process is awesome if it not only documents what we care about, but is willing to defend itself. It is required to stand up to scrutiny and when a process fails to do so, it must change.

For more reading on what it takes to build good processes (because let’s be honest, what else are you going to do on a Friday night?), I recommend Adam Wuerl’s Avoiding Process Hell and Jeff Gothelf’s Applying Product Thinking to Process Improvement.

The big news in our neck of the woods this week is the launch of Facebook’s Instant Articles. Although the handwringing about the open web and the future of publishing is important, there’s a tangential discussion going on in the web community that I find particularly interesting. It’s about the focus Facebook puts on the speed of the feature. It starts with the name Instant, and continues to play a big role in their marketing materials:

Articles load instantly, as much as 10 times faster than the standard mobile web.

Even the phrase “standard mobile web” is an interesting choice of words, and a subtle shot across the bow with a clear message: the web is sloooooooowwwwwww. Well, the web community took notice, and is gearing up for a fight. Here’s Jason Grigsby:

You can make your sites load faster or you can give complete ownership of your content to Facebook which doesn’t share your interests. Hmm…

— Jason Grigsby, ☁4 (@grigs) May 13, 2015

Tim Kadlec followed up with a great post called Choosing performance:

[The web is so slow at the moment] not because of any sort of technical limitations. No, if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.

This goes back to what many have been stating as of late: performance is a cultural problem.

I agree with them that this is the heart of the matter. Focusing on the instant aspect of the articles is a brilliant marketing move by Facebook. They looked at all the giant, slow, over-designed sites out there, saw an opportunity, and went for it. Let’s admit it: they won this round.

The big question now is: how are we going to respond? I think our best response is to fight fire with fire. Instead of trying to kill Instant Articles with the wrath of a righteous anger, let’s rather do something we should have done ages ago: prioritize performance. And Lara Hogan’s Designing for Performance is an excellent place to start.

Shaun McCormick describes Why the way we look at technical debt is wrong:

Technical debt is ok, and often a solid product strategy. The importance is getting to market. When launching a new system or feature, focus your effort and time on areas of the product that need to be agile, and move quickly through areas that don’t. Later, if the product proves that it can drive revenue, you can revisit those areas and improve if they need to scale.

This is an excellent sentiment, and I agree 100% in theory. The problem is that in most organizations, “later” = “never.” Or as Jeff Gothelf puts it, the biggest lie in corporate america is Phase 2.

That’s why I really like Henrik Kniberg’s concept of a “technical debt ceiling.” Read his post Good and Bad Technical Debt (and how TDD helps) for the whole explanation, but here’s a diagram that explains his point:

Source: Henrik Kniberg

This forces teams to pay attention to technical debt, and make a conscious effort to reduce it when it becomes a problem.

“Mobile first” is more about progressive enhancement and making important design hierarchy decisions than it is about thinking about small screens, so I don’t agree with the “outdated” bit in Paul Adams’s Why ‘mobile first’ may already be outdated. That said, he makes a good point about enterprise software:

Many businesses being advised to go all in on mobile screens, should consider how often they are accessed while people are at work. Software that people probably shouldn’t, but do, look at on their work computer: news, sports, social, messaging, personal email. The large screen matters.

Now imagine that you actually build software specifically for people to use at work. This may be software for getting work done, such as Google Docs, Intercom, Slack, Basecamp, Trello, etc. The likelihood now is that the larger screen is the most important one. The large screen app is more important than the mobile app. The mobile app plays a different role to the large screen app, and in many cases a supporting role.

I see this is in our user research all the time. If we do usability testing on our mobile apps, one of the first questions is always, “Will I be able to use this on my desktop”? For software that gets used mostly at work, focusing on desktop — as unsexy as it might sound — is still hugely important.

Emily Badger wrote a very interesting article on the politics of sunlight and shade in urban design. From In the shadows of booming cities, a tension between sunlight and prosperity:

For cities, shadows present both a technical challenge — one that can be modeled in 3-D and measured in “theoretical annual sunlight hours” lost — and an ethereal one. They change the feel of space and the value of property in ways that are hard to define. They’re a stark reminder that the new growth needed in healthy cities can come at the expense of people already living there. And in some ways, shadows even turn light into another medium of inequality — a resource that can be bought by the wealthy, eclipsed from the poor.