Designer’s Field Guide

Change over Time

Technical people monitor metrics — numbers that report change over time — to keep systems running smoothly. This is not news.

What is news is that as streams of data continue flow into and alter every aspect of modern life, UX designers are increasingly being asked to create experiences anyone can use to monitor systems they care about.

The framework is simple:

1. Define a set of measurements — metrics — that report useful things about the status of a system.
2. Capture the value of these metrics at regular intervals and store them as a time series: a data set indexed by the metric name and the exact time each new value was recorded, called a timestamp. …

Yesterday evening I went for an urban hike in San Francisco.

I do that a lot, and have for years.

Yesterday’s hike was different. Really different. The trails, stairs, and open spaces I usually have nearly to myself were crowded like I have never seen them before.

Hikers, couples, families — everyone was out, walking, exercising, promenading. Social distancing was respected: family groups moved together maintaining space from other groups; teen-agers were shooting hoops, each player with his own ball. People in the sidewalk talked with people on balconies. Despite the unreal conditions people were sharing smiles, greetings, and an acknowledgement that we were all having the same upsetting, confusing experience. …

Designer’s Field Guide

So, you want to design developer experiences?

Awesome! Your timing is great. The employment picture is bright for folks who know how to create products for programmatic or declarative developers. Your first step is to develop empathy for these people by learning what it is like to spend your working life inside a computer.

Inside a computer is an odd place. Everything is literal, nothing is implied. A thousand words are worth more than a picture and being creative means following strict rules perfectly. …

Learning to speak data

In 2001 the fallout from the dot com bust was making it hard to find software development work anywhere in the Bay Area. I was out of work for seven months before a connection my father had made for me a few months earlier turned into a paying gig as Director of Design at Pharsight, a start up that developed statistical software for Big Pharma.

My father was a scientific advisor to Pharsight; in fact, the company’s science was entirely based on theory and methods he had invented as a professor at UCSF. This was nepotism of a fairly benign sort: I needed a job, Pharsight needed a designer, and my dad was thrilled for me to be learning the “family” business. …

By “works” I mean:

1. Build great products

2. Everyone involved has fun doing it.

How do you do this?

A partnership of business, design and engineering.

The partnership has 2 rules:

A partner can require either an outcome or a schedule from another partner. One or the other, never both at the same time.

A partner may not ever, under any circumstances, require a process of another partner.

The partners collaborate on the product like this:

Business owns the value model.

Design owns the interaction model.

Engineering owns the data model.

Everyone owns the object model.

(I explain these models in this post: Designing Digital Products with Mental Models.) …

In April 1992 I returned from living in Barcelona and got my first real job after design school with MenloCare, a medical products start up. My time there was effectively an apprenticeship that enabled me to grow from a green design grad to a (semi-)seasoned product designer. Among the many, many things I learned there, two stories from that time that I tell here became the basis for the ethical framework I have used to guide my career ever since.

Do the best you can to protect people’s wellbeing

At MenloCare, product designers also designed and built manufacturing equipment. My most complicated project was a pneumatically powered robot that, on the push of a button, executed a series of automated movements to assemble product. …

The Problem is Translation

Years ago while traveling in India I bought an inexpensive English translation of Dostoevsky’s Crime and Punishment. I was excited to read this famous piece of Russian literature but after slogging my way through it, I was not impressed and couldn’t understand why it was so revered. The answer, it turned out, was that the words I had read did not convey Dostoevsky’s original meaning. I discovered this only when I got to Bangkok and tried to sell the book to a used book dealer who refused to buy because, as he told me, that translation was awful!

This anecdote highlights the challenge of translation: not only is it hard to do well, only an expert can tell when it is done badly. Developing digital products that automate tasks for people involves solving a very difficult version of this challenge. First there is the fundamental issue of translating an analog, observational understanding of human work into a digital representation that a computer can interpret. Second, there is the equally difficult problem of coming up with words to describe the analog-digital mapping that mean the same things to the engineers, designers, product managers on your team who each use different vocabularies to describe ideas. As the story above illustrates, preserving meaning through one layer of translation is hard enough, and digital product development requires getting past two! …

A story about making.

This space in my house could be nicer:

Along came an idea.