Michael Sacasas has an interesting viewpoint on the “machines are taking our jobs” argument. In Machines, Work, and the Value of People he argues that since we’ve so closely linked our value as human beings to the work we do, the issue of machines taking over hits us pretty hard:

So, to sum up: Some time ago, identity and a sense of self-worth got hitched to labor and productivity. Consequently, each new technological displacement of human work appears to those being displaced as an affront to the their dignity as human beings. Those advancing new technologies that displace human labor do so by demeaning existing work as below our humanity and promising more humane work as a consequence of technological change. While this is sometimes true–some work that human beings have been forced to perform has been inhuman–deployed as a universal truth, it is little more than rhetorical cover for a significantly more complex and ambivalent reality.

On the surface, Ian Bogost’s Video Games Are Better Without Characters is a nostalgia piece about SimCity:

Such was the payload of SimCity: not a game about people, even though its residents, the Sims, would later get their own spin-off. Nor is it a game about particular cities, for it is difficult to recreate one with the game’s brittle, indirect tools. Rather, SimCity is a game about urban societies, about the relationship between land value, pollution, industry, taxation, growth, and other factors. It’s not really a simulation, despite its name, nor is it an educational game. Nobody would want a SimCity expert running their town’s urban planning office. But the game got us all to think about the relationships that make a city run, succeed, and decay, and in so doing to rise above our individual interests, even if only for a moment.

But later on it turns into a strong argument for games that are about bigger issues in society. Games not about fighting one’s way out of a prison or getting off a deserted planet, but games that focus on living systems, politics, and the economy. Great article.

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.