A very handy guide to considering privacy at all stages of digital product design:
This guidance is written for technology professionals such as product and UX designers, software engineers, QA testers, and product managers.
Same:
Opening up my RSS reader, a cup of coffee in hand, still feels calm and peaceful in a way that trying to keep up with happenings in other ways just never has.
This describes how I iterate on The Session:
It comes down to this annoying, upsetting, stupid fact: the only way to build a great product is to use it every day, to stare at it, to hold it in your hands to feel its lumps. The data and customers will lie to you but the product never will.
This whole post reminded of the episode of the Clearleft podcast on measuring design.
The problem underlying all this is that when it comes to building a product, all data is garbage, a lie, or measuring the wrong thing. Folks will be obsessed with clicks and charts and NPS scores—the NFTs of product management—and in this sea of noise they believe they can see the product clearly. There are courses and books and talks all about measuring happiness and growth—surveys! surveys! surveys!—with everyone in the field believing that they’ve built a science when they’ve really built a cult.
It me (or at least, this is what I like to tell myself):
A lot of the time, it looks like I’m fucking about, but I’m really just internalising the problem at hand, and clearing space for it in my brain.
We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.
A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:
We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.
If you’re travelling around Ireland, you may come across some odd pieces of 19th century architecture—walls, bridges, buildings and roads that serve no purpose. They date back to The Great Hunger of the 1840s. These “famine follies” were the result of a public works scheme.
The thinking went something like this: people are starving so we should feed them but we can’t just give people food for nothing so let’s make people do pointless work in exchange for feeding them (kind of like an early iteration of proof of work for cryptobollocks on blockchains …except with a blockchain, you don’t even get a wall or a road, just ridiculous amounts of wasted energy).
This kind of thinking seems reprehensible from today’s perspective. But I still see its echo in the work ethic espoused by otherwise smart people.
Here’s the thing: there’s good work and there’s working hard. What matters is doing good work. Often, to do good work you need to work hard. And so people naturally conflate the two, thinking that what matters is working hard. But whether you work hard or not isn’t actually what’s important. What’s important is that you do good work.
If you can do good work without working hard, that’s not a bad thing. In fact, it’s great—you’ve managed to do good work and do it efficiently! But often this very efficiency is treated as laziness.
Sensible managers are rightly appalled by so-called productivity tracking because it measures exactly the wrong thing. Those instruments of workplace surveillance measure inputs, not outputs (and even measuring outputs is misguided when what really matters are outcomes).
They can attempt to measure how hard someone is working, but they don’t even attempt to measure whether someone is producing good work. If anything, they actively discourage good work; there’s plenty of evidence to show that more hours equates to less quality.
I used to think that must be some validity to the belief that hard work has intrinsic value. It was a position that was espoused so often by those around me that it seemed a truism.
But after a few decades of experience, I see no evidence for hard work as an intrinsically valuable activity, much less a useful measurement. If anything, I’ve seen the real harm that can be caused by tying your self-worth to how much you’re working. That way lies burnout.
We no longer make people build famine walls or famine roads. But I wonder how many of us are constructing little monuments in our inboxes and calendars, filling those spaces with work to be done in an attempt to chase the rewards we’ve been told will result from hard graft.
I’d rather spend my time pursuing the opposite: the least work for the most people.
This is very generous of Anna! She has a deck of cards with questions she asks in product planning meetings. You can download the pack for free.
A terrfic presentation from Matt Jones (with the best talk title ever). Pace layers, seamful design, solarpunk, and more.
I really enjoyed this deep dive into some design fiction work done by Fabien Girardin, Simone Rebaudengo, and Fred Scharmen.
(Remember when Simone spoke at dConstruct about toasters? That was great!)
I’ve done this and I can attest that it works, but I never knew it had a name.
Body-doubling is simply having another person in the room with you, working quietly alongside you. They can work on something similar, or something completely different.
I’m 100% convinced that working demo-to-demo is the secret formula to making successful creative products.
I think it was Jason who once told me that if you want to make someone’s life a misery, teach them about typography. After that they’ll be doomed to notice all the terrible type choices and kerning out there in the world. They won’t be able to unsee it. It’s like trying to unsee the arrow in the FedEx logo.
I think that Stewart Brand’s pace layers model is a similar kind of mind virus, albeit milder. Once you’ve been exposed to it, you start seeing in it in all kinds of systems.
Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.
Last month I sent out an edition of the Clearleft newsletter that was all about pace layers. I gathered together examples of people who have been infected with the pace-layer mindworm who were applying the same layered thinking to other areas:
My own little mash-up is applying pace layers to the World Wide Web. Tom even brought it to life as an animation.
See the Pen Web Layers Of Pace by Tom (@webrocker) on CodePen.
Recently I had another flare-up of the pace-layer pattern-matching infection.
I was talking to some visiting Austrian students on the weekend about design principles. I explained my mild obsession with design principles stemming from the fact that they sit between “purpose” (or values) and “patterns” (the actual outputs):
Purpose » Principles » Patterns
Your purpose is “why?”
That then influences your principles, “how?”
Those principles inform your patterns, “what?”
Hey, wait a minute! If you put that list in reverse order it looks an awful lot like the pace-layers model with the slowest moving layer at the bottom and the fastest moving layer at the top. Perhaps there’s even room for an additional layer when patterns go into production:
Your purpose should rarely—if ever—change. Your principles can change, but not too frequently. Your patterns need to change quite often. And what you’re actually putting out into production should be constantly updated.
As you travel from the most abstract layer—“purpose”—to the most concrete layer—“production”—the pace of change increases.
I can’t tell if I’m onto something here or if I’m just being apopheniac. Again.
The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern:
selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.
Baldur Bjarnason writes an immense treatise on the current sad state of software, grounded in the historical perspective of the past sad state of software.
Businesses focus on efficiencies—doing the things that net them the most money for the least effort. By contrast, taxpayer-funded public programs are designed and expected to cover everyone—including, and especially, the most marginalized. That’s why they’re taxpayer-funded; so they don’t face existential risk be eschewing profit-driven decision-making. Does this work perfectly? No. But I think about it a lot when people shit on the bigness and slowness of government. That bigness & slowness is supposed to create space and resources to account for the communities, that a “lean,” fast approach deliberately ignores.
I’ve written before about how I don’t have notifications on my phone or computer. But that doesn’t stop computer programmes waving at me, trying to attract my attention.
If I have my email client open on my computer there’s a red circle with a number in it telling me how many unread emails I have. It’s the same with Slack. If Slack is running and somebody writes something to me, or @here, or @everyone, then a red circle blinks into existence.
There’s a category of programmes like this that want my attention—email, Slack, calendars. In each case, emptiness is the desired end goal. Seeing an inbox too full of emails or a calendar too full of appointments makes me feel queasy. In theory these programmes are acting on my behalf, working for me, making my life easier. And in many ways they do. They help me keep things organised. But they also need to me to take steps: read that email, go to that appointment, catch up with that Slack message. Sometimes it can feel like the tail is wagging the dog and I’m the one doing the bidding of these pieces of software.
My RSS reader should, in theory, fall into the same category. It shows me the number of unread items, just like email or Slack. But for some reason, it feels different. When I open my RSS reader to catch up on the feeds I’m subscribed to, it doesn’t feel like opening my email client. It feels more like opening a book. And, yes, books are also things to be completed—a bookmark not only marks my current page, it also acts as a progress bar—but books are for pleasure. The pleasure might come from escapism, or stimulation, or the pursuit of knowledge. That’s a very different category to email, calendars, and Slack.
I’ve managed to wire my neurological pathways to put RSS in the books category instead of the productivity category. I’m very glad about that. I would hate if catching up on RSS feeds felt like catching up on email. Maybe that’s why I’m never entirely comfortable with newsletters—if there’s an option to subscribe by RSS instead of email, I’ll always take it.
I have two folders in my RSS reader: blogs and magazines. Reading blog posts feels like catching up with what my friends are up to (even if I don’t actually know the person). Reading magazine articles feels like spending a lazy Sunday catching up with some long-form journalism.
I should update this list of my subscriptions. It’s a bit out of date.
Matt made a nice website explaining RSS. And Nicky Case recently wrote about reviving RSS.
Oh, and if you want to have my words in your RSS reader, I have plenty of options for you.
A fascinating look at artificial life …for some definition of “life”.
This is an excellent framing for minimal viable products—what would the black box theatre production be?
Forget about all the production and complexity you could build. What’s the purpose you want to convey at the core?
Some good thought morsels from Robin on product design:
Bad product design is when folks talk more about the UI than what the UI is built on top of.
There’s a lot of talk about how great design is invisible—mostly boring conversations with little substance—but! I think that’s true when it comes to product design.
Bad product design is when your interface looks like your org chart.
How design fiction was co-opted. A piece by Tim Maughan with soundbites from Julian Bleecker, Anab Jain, and Scott Smith.