Welcome back, picnickers. 

The name of this newsletter is finally appropriate – it’s 80 degrees in Brooklyn. Get out there before the rain ruins it, then head home and read the rest of this post. 

Ok, back? Ready? Let’s begin. 

Archimedes once said, “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.” Last week, we talked about how to find that fulcrum. Today, we’re going to talk about the lever. Moving the world will have to wait until next week. 

Good Questions 

“Designers should X” is a common refrain in the discourse. For the past ten years we’ve been hearing “should designers code?” slowly transform into “should designers learn business?” 

These are not the good questions. These are in fact very bad questions. They are asked from the perspective of a discipline without either a vision for itself or influence with its partners; they frame our role as a human band-aid fulfilling requirements set by other functions. 

The better question was asked when I was complaining about this two years ago: 

If designers cannot coherently answer that question, we will never be taken seriously. And while I am already hearing echoes of “it depends” reverberating from my monitor before even publishing this, I think there is a succinct answer. Design wants to be part of the strategy – not just being in the room where it happens, but using our tools to frame and inform the decisions. 

Reading Material 

This is because business-as-usual has failed not just designers but the whole product team. Instead of teaching the business the basics of their own craft while they try to reinvent Research 101 insights, it’s time for us to lead on our own terms. A team member who can think in systems is more valuable to a product team than a redundant junior product manager. 

(As an aside: “strategy” often sounds very intimidating, especially to junior and intermediate grade designers. There’s really not that much to it. Read this and then think about how design methods can make every single approach faster, safer, and more effective.) 

Designers do not, I think, have a coherent sense of what systems thinking is (I have heard it used to refer to design systems more than once and I am sorry to say, that is not it). A good start on systems thinking is Indi Young’s piece on thinking critically; sweeping away the assumptions that drive the majority of decision-making. Systems thinking relies on tools for thinking; problematizing what you see rather than shrugging off the details (or worse: becoming dependent on an LLM’s highly generic overview).  

But the product is only a part of the system; what we work towards and how we can get better at it are inextricable from the objects we produce. Gil Broza’s experience here illustrates just how tangled that web of incentives and “fixes” can really go. 

One of the best and most designerly ways of untangling that web is through diagramming. Ruth Malan has composed an excellent diagramming toolkit for systems seeing and Karen Holtzblatt’s contextual design remains a priceless resource. And if you need another user journey mapping framework, you can now do it with Jobs to be Done, because why not. 

The Timeline 

One of the goals of this newsletter is to bring together the scattered pieces of design discourse. Partly to make sure that cool ideas don’t end up siloed in just one post-Twitter discussion space, and partly to catch trends and overlaps. And while UX is mostly still talking about how UX and/or Figma are dead, content design is alive and well. 

Any proper systems thinking is going to take content into account, since it is half of the dang system. In the language of pace layering, while the “web as a software interface” side evolves at the pace of fashion, information architecture is infrastructure. The front-end presentation might change, but the back-end is forever.

And when companies don’t think about enduring needs and design that layer based on the fashion of the day, that backend bakes in bad design decisions permanently. Effective navigation (or even search) is hard; slapping a chatbot or algorithmic feed on top of semantic soup is easy. Fortunately there are things you can do even after a product has launched to staunch the bleeding somewhat and pay back your ontological debt. 

If this feels a little abstract, here are two cool case studies that demonstrate exactly what information architecture looks like in practice - one from Intercom and another one from Dan Mall.  

You are the design community 

Back when there was a Design Twitter, designers frequently complained that it was full of stupid people with rancid takes. To which I would respond: why are you following stupid people with rancid takes? 

Now, there is no more Design Twitter and designers are adrift; people periodically ask me “where is the conversation happening?” as though there is ever again going to be just one place for it. 

But the conversation can happen everywhere you choose to have it. Click a link above and tell the author what you thought about their piece. Or just tell them they’re wrong. Or just tell me I’m wrong. Better yet, send me what you’ve been reading and writing – new points of view, new work, new websites where you can vote for which of Erika Hall’s chickens is more lugubrious or ebullient. 

That’s what the picnic is all about – having the conversation. 

–Pavel from the Product Picnic