Jason Kottke wrote what I guess can be described as a review of Apple Watch reviews. He makes a particularly interesting point about the common assertion that we’ll start using our phones less because of the watch. From Apple Watch and the induced demand of communication:

In the entire history of the world, if you make it easier for people to do something compelling, people don’t do that thing less: they’ll do it more. If you give people more food, they eat it. If you make it easier to get credit, people will use it. If you add another two lanes to a traffic-clogged highway, you get a larger traffic-clogged highway. And if you put a device on their wrist that makes it easier to communicate with friends, guess what? They’re going to use the shit out of it, potentially way more than they ever used their phones.

He also quotes from the same article I had a visceral reaction to in The Apple Watch won’t save you time. In that article I made a similar point:

I’m not saying the Apple Watch won’t be wildly successful, or that I don’t want one — I definitely want one. I just don’t think we should fool ourselves into thinking it will somehow give us more time because we might look at our phones less. If history teaches us anything, it’s that we’ll find a way for the watch to fill up our “saved” time in other ways — and then some.

My daughters love the Toca Boca apps—especially Robot Lab. Ingrid Simone’s article on their approach to gender is great. From Gender in Play: How Toca Boca Creates Apps for All Kids:

Toys have a large impact on how kids play together and relate to other kids. But kids of today are fostered into watching different shows and playing with different toys according to their gender.

We know that when a toy reaches a child a choice has already been made for them, someone has picked a blue or pink toy, an action figure or a doll. We believe this is limiting to kids, not to be able to decide on your own what your interests are, and that gender-targeted toys create an unnecessary barrier between girls and boys. And we believe that girls and boys, brothers and sisters want to play together!

And on the redesign of Robot Lab specifically:

Since the robot theme has historically been so targeted towards boys, we felt like we, as many before us, had somehow fallen in the trap of using conventional “boyish” colors, shapes and attributes. And we really wanted to see if we could make the app more appealing to both boys and girls.

Alina Senderzon defends realignment strategies in Resist the Redesign:

Yet, designers are quick to jump on redesign opportunities—after all, it’s exciting to start anew. In reality, however, a redesign isn’t always the right solution to the problem. The roadblock for users may lie in the pricing of your product, which could be discovered through customer development. Or your messaging isn’t compelling and could be saved by some clever copywriting. Or maybe customers feel compelled to convert, but the checkout process is too long and needs to be streamlined. Any number of changes could generate dramatic value for the business, and though they likely involve some design decisions, they rarely require a clean slate.

This is similar to the approach I wrote about a couple years ago in The Data-Pixel Approach To Improving User Experience.

If I link to a listicle, it has to be good enough to overcome my unnaturally strong negative feelings about those types of article. Alas, Mike Fishbein’s 4 steps to make experimentation a repeatable process in your business is that good. It’s a great overview of the importance of hypothesis testing over “requirements gathering” in product management:

Most new products fail, and most frequently because they do not meet user needs. Running experiments helps product managers validate customer demand for a product concept earlier in the product lifecycle.

By running experiments instead of launching a minimum viable product, product managers in large organizations can gain more autonomy, limit risk and brand exposure, and gain user insights even earlier in the product lifecycle. With this speed to user insight, product managers become better informed to build successful products.

I also especially liked this bit:

In the next evolution of product management, the product leader’s role shifts from making bold assumptions to fostering a culture that encourages learning in an efficient and effective way.

Scott Sehlhorst wrote a really good defense of good product roadmaps in Features do not a Product Roadmap Make:

If your roadmap says “Will include update quantity control in shopping cart” you’re doing it wrong.  Your roadmap should say “Improved shopping experience on mobile” or “Better shopping experience for spearfisher  persona.” […]

When a roadmap is being used to communicate “what” the product will be, it should be in the language of describing which problems will be addressed, for whom, or in what context.  This is the most important type of theme which would be part of a thematic roadmap.  Other themes could be “improve our positioning relative to competitor X” or “fill in a missing component in our portfolio strategy.”

And this, in the context of agile, is a great point as well:

A backlog – a prioritized list of features – is not a roadmap. It is a reflection of a set of design choices which happen to fulfill in product what the roadmap sets out as a manifestation of strategy.

A roadmap tells you both “why” and “what;” a backlog tells you only “what.”

This reminds me of an article I wrote in 2011 called Product roadmaps are safe. Good times.

Marty Cagan has some really insightful thoughts (as usual) on autonomous teams in Autonomy vs. Mission:

In healthy teams and organizations, the way we normally reconcile these views [where the team might have one perspective and the leadership might very well have another] is that the leadership has control of two major inputs to the decision process. The first is the overall product vision, and the second are the specific business objectives assigned to each team.

Problems arise if the leadership does not provide clarity on these two critical pieces of context. If they don’t, there’s a vacuum and that leads to real ambiguity over what a team can decide and what they can’t.

The section on how to ensure consistency in design across different teams is also really good:

In the name of empowerment and also speed, my personal preference is to invest in the necessary automation (with pattern libraries and style guides) so that the team can get the design (interaction and visual) mostly right pretty easily, and acknowledge that on occasion, you will incur some “design debt” where we realize that the design needs to be corrected, and that’s fixed as soon as the problem is spotted. I like this approach because the manager of design is still responsible for developing a strong set of designers, but doesn’t have to be in the review cycle for everything (which tends to slow things way down, as well as undermine autonomy).

John Willshire wrote a good post on the difference between fidelity and resolution in design. From Want to improve your design process? Question your fidelity:

For us, fidelity is all about the people axis; how close is this to the real world? That’s the future point, when the product is out in front of lots of people, being used often, at scale. If you want to increase fidelity, then you show whatever you have to more people.

Which leaves the vertical axis, things, to be all about resolution. Resolution is a much more technical description of what we have in front of us, used across many different fields to description the detailed specifications of what the thing involves. It’s been much more useful when you’re using that language around the thing you’re working on.

There are some good illustrations in the post to make the point clear. I think this is a pretty important distinction, since it shows how user feedback can be helpful during each phase of a project.

Judy Wajcman’s Who’s to blame for the digital time deficit? starts off like many similar articles as she ponders the role smart phones play in making us feel time-starved. But then she takes an unexpected and well-reasoned turn:

If technology is going to contribute to a better world, people must think about the world in which they want to live. Put simply, it means thinking about social problems first and then thinking of technological solutions, rather than inventing technologies and trying to find problems they might solve.

We can’t do this while the people who design our technology and decide what is made are so unrepresentative of society. The most powerful companies in the world today—such as Microsoft, Apple and Google—are basically engineering companies and, whether in the US or Japan, they employ few women, minorities or people over 40. […] Such skewed organisational demographics inevitably influence the kind of technology produced.

And later on:

If we want technology to bring us a better future, we must contest the imperative of speed and democratise engineering. We must bring more imagination to the field of technological innovation. Most of all, we must ask bigger questions about what kind of society we want. Technology will follow, as it usually does.