The Momentum of a City is Proportional to its Density

I’m stating the obvious, I know, but having lived in Hamburg for a year and then returning to Manhattan, especially midtown, reminds me of the energy that propelled my career when I was younger: the masses of people crammed into giant buildings, filling the wide sidewalks, filling every space available.

It’s not necessarily a good thing. Hamburg is a balance between the advantages of modern life and the needs of humans: many more green spaces, almost no very tall buildings, an emphasis on quality rather than efficiency.

Categorized as Cities

Doctorow on Real (Climate) Innovation vs Silicon Valley Nonsense

“Silicon Valley is the land of low-capital, low-labor growth. Software development requires fewer people than infrastructure and hard goods manufacturing, both to get started and to run as an ongoing operation. Silicon Valley is the place where you get rich without creating jobs. It’s run by investors who hate the idea of paying people. That’s why AI is so exciting for Silicon Valley types: it lets them fantasize about making humans obsolete. A company without employees is a company without labor issues, without messy co-determination fights, without any moral consideration for others. It’s the natural progression for an industry that started by misclassifying the workers in its buildings as “contractors,” and then graduated to pretending that millions of workers were actually ‘independent small businesses’.”


Why Machine Learning Scares Us

So it turns out that the flavor of AI that is finally reaching the mainstream is the large language model. And we’re uncomfortable with it not only for the obvious reasons that there’s a machine acting eerily like a human, but also because we can’t explain precisely how it’s doing what it’s doing. And in that sense it’s like our own brains, and by extension so much about our universe. We’ve developed staggeringly complex science and simultaneously can’t explain how we think or where the universe came from or even make general relativity and quantum mechanics play nice together. This general situation has been unsettling for a long time, so we invented gods to explain the universe. But the gods didn’t make AI.

Dall-e created image
An image created for me by DALL-E

Passwords Are Now Outdated

There’s a lot to be said about how to secure our online information while providing a good experience; hasn’t anyone written this book yet? In any case, I think a good, uncommon, guideline would be:

Do not use human memory

To remember and recall takes work, and I’d rather not expend my precious attention and cognition on computers. And, human memory is fallible. Most passwords break this guideline, but we now have biometrics and password managers to provide security without relying on memory and it’s time our security practices catch up to the technology.

Two-factor authentication, similarly, feels like a lazy, flawed approach which requires too much human work.

My Critique of the RGT Start Up Sound

In this video I listen to the sound as it’s used in real life, talk about what the sound is intended to accomplish, and then give it a sound score. And then I try to improve on it.

RGT is a great, freemium service that’s fun for cycling indoors. It connects to your bike and let’s you cycle through one of several virtual worlds along with other people. If you’ve heard of Zwift, it’s similar.

Track Buying Not Spending

When I designed software for personal finance, I thought a lot about helping people simplify and understand their cash flow. One method I created is an exceedingly simple way to track spending on projects that my wife and I have been using for years.

Most people track their money by tracking their spending. On the computer, there are websites such as Mint or You Need a Budget that will track everything you buy down to the cent, help you categorize every one of those expenses, and track it all on a regular basis.

We think that’s insane. Well, maybe once in a while it’s good to do a financial checkup to revisit where you’re spending your money. But really, all that time tracking expenses could be better spent making money or enjoying life.

Here’s the secret to how we do it: Instead of tracking spending, we track buying. We do this with our Things To Buy List.

Why don’t we track spending? We don’t track spending on fixed costs like our mortgage or the water bill since those 1) don’t change much and 2) need to be paid whether we like it or not. Any large expenses we’ve saving for, from retirement to the kids’ college education, is automatically deducted from our account. What’s left is money we can use for incidental expenses such as home projects, and for this task we want to track our buying. Tracking stuff we want to buy is also more fun than tracking money that’s already left us!

To track what we buy, we start by creating a list of things we want to buy. We’ll do this someplace digital so that it’s easy to share, re-prioritize, and cross items off the list. We use a wiki, but you could use a Google Doc, a shared to-do list, or a paper list on your refrigerator. Here’s what the top of our list actually looks like right now:

Then, as we have time to work on these projects, we’ll look at our checking account to see how much extra money is there and use it to buy things starting at the top of the list.

That’s it. That’s our entire method: Check the account, buy the stuff, and occasionally update the list.

Could a Things to Buy List work for you?

Which methods and resources should we deploy when users are suffering?

In the field of user experience design, we research users and often talk about the user pain points we’ve observed. When I use pain here I don’t mean inconveniences, as when I can’t find just the right streaming music playlist to match my mood. I mean tasks that emotionally hurt, such as knowing you need to file a timesheet by a deadline but you can’t figure out how do that with the enterprise timesheet software you’re forced to use, to the point you are cursing the software.

The phrase “pain points” implies discrete things or points in time. But in some cases users are interacting with a system on an ongoing basis and that pain is continuous. Usually when someone is in pain for an extended period we call it suffering. When it comes to our bodies we make this distinction between minor pain and suffering all the time. A minor pain we tolerate and wait for it to go away. When we’re suffering we go to the doctor.

When designing for users of software, differentiating between minor pain and suffering helps me make different choices about how to design solutions.

One consideration is how long to spend designing a solution. If we reduce either the pain or the time someone is in pain then we reduce the suffering. But this can involve a trade off: we can design an amazing solution that removes all users’ pain, but that could take a lot of time. We could design something and release it to users quickly, but it might only relieve part of their pain. Or we might find a middle road where we alleviate the worst pain first and then gradually alleviate the rest with subsequent releases.

Mathematically we can phrase it like this:

Pain x Time = Suffering

This tradeoff also helps me think about using the appropriate design methods. Let’s say for example that the scope of my problem is large, perhaps helping the U.S. government create a better way for residents to understand and file federal taxes. I would need a design methodology that can encompass many types of users, information, and interaction, such as service design. If preliminary research revealed that the most user suffering is in knowing how much to pay in estimated taxes, then I might focus on that problem. In order to alleviate that particular suffering quickly I would need a design methodology that helped me rapidly find a solution, such as Lean UX.

I’ll stretch this analogy further to illustrate how I think of allocating resources based on design needs. Near where I grew up is a large hospital system that offers patient care on different time horizons. One, the hospital has an emergency room to triage critical patient needs. Two, it has doctors who can provide scheduled, annual checkups. Three, it has specialists who provide larger procedures such as surgery. And four, it has research labs where it can develop new cures.

Now imagine there’s a tragic accident nearby. The hospital could allocate more resources to the emergence room to handle demand. Alternately, imagine a new disease is causing a pandemic; the hospital could allocate more resources to the research labs for find a cure.

Similarly, my team allocates resources depending on the kinds of problems our users have. One, we embed designers in agile feature teams to quickly alleviate critical user suffering. Two, we perform proactive testing to track how usability has changed over time. Three, we occasionally dedicate a team to a large change, such as an information architecture change. And four, we do research to arrive at overall design patterns such as infinite scrolling vs pagination. Our job titles and work assignments are fluid enough to respond to (constant) change.

All that to say:

  1. I try to be open to all methods and try not to see all problems as nails I can hit with my favorite design method hammer.
  2. When there is clear user suffering, I factor time into my choice of design method to alleviate suffering quickly.
Categorized as Process

This Blog is Almost Old Enough to Drink in America

Recently the web turned 30 years old, and I realized that this blog was started almost exactly 10 years after the web, making it 20 years old this month. And maybe that makes it a good time to start blogging again? Not really.

Although I am losing faith in Medium and Facebook as places to share my thoughts, and it’s comforting to know I have this place that’s all my own to do as I please, free of ads and unpleasant people. Let’s write and be pleasant!

Another book?

I was talking with some folks the other night, one had written three books, another five. “It’s like having a baby,” they said, “it hurts so much you swear you won’t do it again, but you forget the pain.” I can proudly declare I stopped after one book. But but… there’s all these books that don’t exist yet but should. Who will write them?

One of those books that doesn’t seem to exist is the small (small as in fits-in-your-pocket small) book for product managers, programmers, and business people to understand how human-centered software design gets done. By that I don’t mean how to start doing human-centered software design, there’s plenty of good resources for that (e.g.). And there’s good resources for people willing to devote the hours of reading it takes to get through a 350+ page book (e.g.). But in my experience people just don’t have that much time to devote to anything outside their area of focus unless they’re changing careers.

My inspiration is this:
Scrum: A Breathtakingly Brief and Agile Introduction is a wonderful little book that does exactly what it says on the label. It slips neatly into your pocket for reading anywhere anytime. There’s even space in there for a few useful illustrations. As a non-programmer needing to understand how my programmer colleagues are working, it’s perfect. I want to give them the same kind of book to understand what I do.

What’s Next for Digital Product Design?


Working in the fast-changing world of digital product design, there’s always some new and exciting tools and techniques to learn. The flip side of this coin is that you must keep learning to keep up with the industry or your skills become irrelevant.

So naturally it would be helpful to know how our practice will change in the future so we can figure out what to learn next. This article is my attempt to look into this future.

Read more…

Designing Faster

I’m at an inflection point in my career of building digital services and reflecting on two things:

  1. How can we design better?
  2. How can we design faster?

While the thoughts are still in flux I’m going to set them down here and stew on them a bit.

  1. A Cadance is a cycle like a sprint, but every day is scheduled for a certain activity such as designing, studio, making tests, testing, reviewing tests, etc. If the schedule is set there’s less need to spend time discussing the schedule and less time figuring out what to do each day, instead you just do it. And if it’s an aggressive schedule you get a lot done fast. It relies on a project manager/product manager/leads to work in a parallel track to slot work into the cadence.
  2. Made-to-measure design recognizes that not every assignment requires bespoke design, and not every schedule or budget allows for bespoke design. And from the customer’s point of view we may want to leverage UI conventions that are familiar to them. So instead a made-to-measure approach uses not only frameworks (e.g. CSS and HTML such as Bootstrap) but genre-specific templates for dashboards etc.
  3. Inverting studio and desk time is something that often happens naturally when in war mode, but could be done all the time: spend most of the time together designing and rather than stop the studio at the post-it note or sketch level, keep iterating and adding details. Then spend the minority of time, say one day per week, working solo to document and refine the work.
  4. Testing constantly is now possible. Remote, asynchronous testing tools have become so easy and affordable we can bite off many more of our hypotheses and set up a queue of tests so feedback arrives as rapidly and as plentifully as analytics.

DAD Chord Chart for Merlin, Grand Strumstick, & DAD Dulcimers

Here’s a chord chart for instruments that have three strings tuned D-A-D like the Seagull Merlin, Grand Strumstick, & DAD Dulcimers. Also known as key of D, or diatonic D.

I had a few goals when designing this:

  • Correct chord names
  • Include chords in the root position (root note as the lowest note) and inversions and indicate which are inversions
  • Follow the graphic convention of guitar chords, for those of us coming from the guitar
  • Indicate the chord positions, so if you’ve thinking, “I want to play a blues in I-IV-V” you can find the chords easily.

In case you’re new to tab/tabulature, this one is set up like guitar tab: the lowest string is on the left, the highest string is on the right, the dots indicate at which fret to put your fingers.