I enjoyed this post by Yuhki Yamashita (CPO at Figma) about how design is always “Work in Progress,” and how to deal with that:

Our work never feels done because it isn’t. Our collaborators jump in and out of files, leaving feedback and iterating on designs while we’re creating them. Many of us can ship whenever, so it’s hard to know when new designs are actually ready. It’s the chaotic reality of modern product design and development.

He gives some really good recommendations for how to work in this type of world where nothing is ever quite “done”. The post also introduced me to the concept of flashtags, which I quite like. It comes from Hubspot (See FlashTags: A Simple Hack For Conveying Context Without Confusion), and it’s a way for leaders to indicate how strongly they feel about the feedback they’re giving:

• #fyi means there’s no hill to die on.
• #suggestion means they’ve seen the hill but don’t feel strongly enough to commit the energy to climb it. Take it or leave it.
• #recommendation means the hill was climbed. They thought about dying on it, but walked back down.
• And finally, #plea means that they do, in fact, want to die on the hill. So if you see this flashtag, you better make sure it’s prioritized!

And finally, speaking of Yuhki… I am not really a podcast person, but I really enjoyed his recent interview on Lenny’s Podcast: An inside look at how Figma builds product.

My friend Allan sent me an article about the city of Brasília, and how its architecture affected the recent insurrection (Ryan wrote the best overview about what happened that I’ve seen). I have long been fascinated with Brasília, every since I researched it for a product management article called Usable yet Useless: Why Every Business Needs Product Discovery:

A “shiny citadel” from far away, as The Guardian once wrote, up close Brasília has “degraded into a violent, crime-ridden sprawl of cacophonous traffic jams. The real Brazil has spilled into its utopian vision.”

This problem echoes across today’s web landscape as well, where the needs of ordinary users spill constantly into designers’ utopian vision.

So I read In Brasília, Modernist Architecture Met Political Violence with great interest:

Brasília’s so-called Monumental Axis, or Eixo Monumental, isn’t a walkable touristic path dotted by free museums. Instead, it is an otherworldly landscape of red earth, open grass and enormous roadways, an anti-pedestrian landscape best viewed from the air. So vast are its voids that the sheer scale of the space may have helped temper the energies of the crowds.

The city’s design had specific consequences for the political unrest:

More than 60 years later, Brasília’s real-world shortcomings are well known: Its population far outgrew what its designers imagined, with most residents living in satellite developments that sprawl far from Costa’s planned central district. Many politicians commute via plane, making the city more a symbolic site than a place where one finds gatherings of politicians. President Lula was not in Brasília at the time of the riot, nor were legislators of Brazil’s National Congress, which is in recess: The protesters attacked mostly empty buildings.

This is a really interesting look at how urban design affects the behavior of citizens.

Kate Clayton wrote an excellent essay on simplicity in design that goes way beyond the usual platitudes. From Be an Elegant Simplifier:

When I saw Danny Kahneman speak at a meeting last year, he shared a similar principle to the Crystal Goblet he took from psychologist Kurt Lewin, who, like Beatrice Warde, was active in the 1930s. Imagine, Lewin said, you have an object with forces pushing against it from opposite sides. Human nature would say if you want it to move one way, add more force to one side. But Lewin advised against this. A much stronger solution, Kahneman said, is to remove the force blocking the user’s way. Eliminate some of the muck.

This principle is very close to the product forces concept of Jobs-to-be-Done, and it’s great to see it framed from a slightly different perspective.

Page Laubheimer explains that The 3-Click Rule for Navigation Is False:

The 3-click rule is a persistent, unofficial heuristic that says that no page should take more than 3 clicks (or taps on a touchscreen) to access. A variation pronounces that the most important information should take no more than 3 clicks to get to. […]

The big problem with the 3-click rule is that it has not been supported by data in any published studies to date. In fact, a study by Joshua Porter has debunked it; the study showed that user drop-off does not increase when the task involves more than 3 clicks, nor does satisfaction decrease. Limiting interaction cost is indeed important, but the picture is more complicated than simply counting clicks and having a rule of thumb for the maximum number allowed.

YES. I’ve been on this bandwagon for a long time. In 2013 I wrote in Don’t optimize for the fewest number of clicks:

Let’s get away from this idea that we should optimize for the fewest number of clicks and taps. Instead, we should optimize for an information architecture and visual hierarchy that makes the next step as obvious as possible.

Brad Frost argues that design tools are holding us back because “they require a specific toolchain in order to function”. Instead, what we need is closer collaboration:

Tooling can help, sure, but it’s not a silver bullet. To truly address the realities of the medium for which you’re designing, designers and developers should collaborate as equals to solve problems together. That means more talking and real-time collaboration and less time spent throwing static artifacts and Zeplin links at each other.

Shaun Juncal makes a compelling argument in Product Accessibility Shouldn’t Be an Afterthought:

But addressing accessibility early and often—if not making it an ongoing pillar of product quality—is a best practice every product team should embrace. Accessibility enables the maximum number of potential users to engage with products, increasing the total addressable market and avoiding frustrated customers from getting tripped up on accessibility shortcomings. […]

When a product doesn’t fully incorporate accessibility, the company is essentially telling a cohort of potential users that “this product isn’t for you.”

He shares some good advice on how to make accessibility efforts a natural part of the product development process.

Katy Cowan’s interview with Frank Chimero is really great from start to finish, and covers so much ground on design and technology and how to think about our work. Frank’s view on the importance of not overworking yourself is refreshing, and we’ll hopefully continue to see more of this kind of thinking:

It’s really easy to think that not working full bore is somehow failing your teammates or that withholding effort is poor work ethic and moral weakness. That thought is worth interrogating, though, and it all seems kind of ridiculous once you get it out in the open. There should be no guilt for refusing to work hysterically.

The Buzzfeed News article Behind Twitter’s Plan To Get People To Stop Yelling At Each Other is not the kind of thing I usually link to here, but I found it really fascinating from a product management perspective. Author Nicole Nguyen goes deep into the research and development process of the team responsible for “twttr” — an external, public prototype to experiment with new features. The sections that give us insight into the thinking of Sara Haider (Director of Product Management) and Lisa Ding (Senior Product Designer) are particularly interesting:

Haider and her twttr team are hoping to “nudge” people’s behavior in another way. Their hypothesis: Making the design for replies as minimal as possible, in addition to revealing how the conversation’s participants are related to you, may encourage people to read the entire back-and-forth before they react.

“We have this opportunity to learn about how not having likes and retweets could potentially change how people read things,” said senior product designer Lisa Ding. “Does it make you read something that you maybe would have guessed to be popular but actually isn’t that popular? How does that change the way you interact in a conversation? That’s super interesting.”

I also love Lisa’s sketches of the layout of twttr, and wish I could see more of that notebook!

Google UX Designer David Hogue shares his thoughts on How to Reverse Over-Complication in Product Design and How to Avoid It Altogether. It’s a very good read for product managers. Here he describes how do build a process to avoid over-complication:

Critically evaluate every new and existing feature for the value it provides weighed against the costs of including in a product or service. Does a feature introduce friction or ambiguity? Does adding something more make flows, paths, and choices harder to understand? What are the potential positive AND negative outcomes of adding something, and is it worth it?

Constant vigilance against entropy, scope creep, and the accumulation of friction is necessary. Pausing for review after major releases, conducting retrospectives after updates or changes, critical analysis of product performance before and after a change, and ongoing quantitative and qualitative research can all provide information about and indicators of increasing and unintended complication.