Why We Blame Bikes

A cyclist friend posted a link to a nice analysis of the ways people tend to blame bikes disproportionately for pedestrian problems (pun intended).

I did a lot of bike-commuting in college but moved afterwards to a city that, at the time, was far less amenable to such activities than either place is today. I fell completely out of the habit, and a large part of that was about feeling blamed—sometimes with dangerous backlash—for what we should see as reasonable and even desirable changes to the urban environment.

As I read the Alviani piece, what I really wanted to ask was, “But why?” Why, ultimately on psychological terms, do people heap all this blame on the humble cyclist?

I have two hypotheses, one for pedestrians and one for drivers. I’m sure the real situation has a multivalence that I’m not accounting for here, but:

I think what makes bikes disproportionately scary for pedestrians is that we can’t really hear them coming. We use sound to take in our surroundings broadly and alert ourselves of potential danger that our narrow field of vision might miss. We can’t do that reliably with bikes, so we worry and blame cyclists irrationally. (Not that their aren’t some crazy ones, but again, the backlash is out of proportion as compared to pedestrian fear of crazy drivers.)

And when we’re driving, I think bikes force us to confront the fact that we’re not the rational creatures we like to believe we are. We know that the law is the law, but we resent the minor hassle of having to share the road and so make up all kinds of rationalizations about why the biker is in the wrong. But those break down in a way our similar thoughts about other cars do not, because with bikes and their fragile, unprotected human riders, we are so much more directly confronted with the fact that our desire for convenience could so easily cost somebody else’s life if we’re not careful.

TL;DR: We’re only human! Pure rationality evades us always.

Posted in Life | Comments closed

Not-not-design: Confessions of a Terrible Designer

I’m a terrible designer. I’m an amateur with Adobe Creative Suite, I know almost nothing about color theory or typography, and I don’t—in fact, I can’t—make your website or software interface “pretty,” a role often rightly understood as the designer’s. I’d guess that at least three-quarters of my work isn’t even meaningfully visual; I spend most of the day reading and writing, talking and listening.

The problem is, I’m a senior designer at a well-respected healthcare software firm.

My boss likes to call what we do “‘Big-D’ design,’” a term architect Larry Barrow seems to have coined. That means we don’t just (“just”) crank out detailed designs and styleguides, but we also tackle all the research, analysis, and communication that leads up to that final step. It’s a nod to the importance of the thinking behind the final design deliverables—also leading to the concept “design thinking,” popularized at IDEO and Stanford’s d.school.

I like the idea of elevating design’s reputation among non-designers into Big-D territory, but the mere addition of a capital letter doesn’t communicate how much worse I am at the lowercase version than my colleagues. So, I’ve also taken to explaining that my work is “not-not-design,” a less intuitive term, but a productive one in that it allows me to tell a good story:

In one of the interviews for the job I have now, I was feeling skeptical that I could or should end up in a design position. As I showed one of my wireframes, I wanted everyone in the room to understand that such barebones presentations are as high as I climb on Fidelity Mountain. I said something to that effect, and the design group’s second-in-command said, “But that’s not not design.”

And she was right, that’s not not design. If design is the process of learning about users and business needs and working towards concepts and eventually some visual deliverable, then I’m doing at least three-quarters of that work. What I do is (not-not-)design if anything is.

So why do I have such a hangup? Why do I feel it’s awkward to be introduced around our enormous parent organization as “the designer on the project?” Why do I need to rally behind a term like “not-not-design” in the first place?

My own problem probably starts with web marketing agencies, where I spent my professionally formative years, and where, until recently, design and user experience (UX) didn’t often overlap as disciplines. UXers worked on strategy and architecture; designers tackled the visuals and brought the interactivity one step closer to its eventual life in code. In the best cases, the two might collaborate some as they worked. Sometimes there’d even be a developer at the table.

The UX field does also have a well-documented terminological problem (OK, one more), which is that even those of us inside it don’t often feel certain what it means to call ourselves UX designers, architects, or strategists. It’s easier for some firms, like my current employer, to sidestep that question by just calling everybody “designer,” and to explain the depth of that term later. It’s just that between the moment when somebody sees my business card and the moment when they learn what I do (and do not), I feel a little bit like a liar—and perhaps a little bit undervalued, too.

Misunderstanding the role of the designer—ignoring not-not-design, in other words—is bad for everybody. If I were a designer at an agency like the ones in my past, I’d want very badly to get to spend as much time as the UXers do talking to users and stakeholders and poring over secondary research before I even started thinking about layout and type. If I were a UXer at one of those places, I’d want to feel like I had a strong influence on the final visual representation of the product, even if I lacked the skills to help create that representation directly. (In other words, I’ve found a pretty good fit in my current employer.)

I don’t mean to suggest that there’s no value in identifying and articulating the differences among these many roles. There is and ought to be a community of people talking productively about how to do better work in the areas that will probably always elude me. Likewise, I like talking and learning about things that may never interest some of those people.

All I’m saying is, despite my protestations in the job interview, I do belong on something called “a design team,” because not-not-design is design, too.

Posted in Technology, Web | Comments closed

Exercises for New Parents

  • kidlifting (all muscle groups)
  • swaying/bouncing (quads, patience)
  • sex (imagination)
  • rageful clenching (jaw, glutes, adrenal glands)
  • spouse-shouting (abs, rectum [if neurotic])
  • door-slamming (anterior delts, lats, eardrums)
  • house-fleeing (right lower leg, right wrist and forearm [if manual transmission], teeth / inventiveness [when pulled over])
  • divorce paperwork (small muscles of the dominant hand)
  • loneliness (small muscles of the dominant hand)
Posted in Life, Sport | Comments closed

Why I’m Buying a Case for My iPhone 5

As documented by Geoff Barnes, I waited a long, long time to upgrade from my iPhone 3GS, skipping directly to the 5.

Besides my sharing Barnes’ experience of the near-impossibility of one-handed operation of the iPhone 5, I also continue to lament the squared-off form factor of the backside of the device.

Yes, the diamond-bit chamfer on the edges makes the phone feel better in the hand than the 4/4S did to me—or else I wouldn’t have bought the 5 any more than I did the 4 or 4S. I do feel those edges digging into me, but not as much as the 4S did when I auditioned it at the Apple Store.

What my 3GS provided that none of the newer models do, though, is some kind of safeguard against dropping the phone. The rounded back put more surface area of the phone in contact with my skin, making sliding toucher. The composite material, much tackier than the aluminum, doubled down on that friction. All told, I’ve probably lost control of the 5 more in a couple months than I did in more than three years.

The light weight of the 5 also means trouble, combined with the slipperiness of the aluminum. With a new baby at home, I spend lots of time in pajamas and gym shorts, and the svelte, smooth iPhone 5 is so susceptible to jostling and shifting that it falls out of my pocket literally every time I sit down on my couch or in our glider (when I’m wearing those clothes). It’s hit our hardwood floor more than once, and I feel sure a cracked screen is in my future. The 3GS, of course, never fell out of any of my pockets. It was just too heavy, which again I preferred.

The sad bottom line is this: When I find one, I will buy a case for the phone that makes the back rounder and the device heavier. Like Farhad Manjoo, I’ve been derisive about cases in the past, but the fact is that having a case on this phone would make it a better phone, for my purposes. I’m glad it looks so pretty, but it just feels a mess.

Posted in Life, Technology | Comments closed

Also About Those Long Line Lengths

This morning, Tyler Galpin took a shot on Twitter at Stuff & Nonsense’s new redesign:

Yay for completely unreadable line lengths on a screen larger than a laptop. Constraints, dude. http://t.co/jusxIj4H

Andy Clarke defended the design choice, saying, among other things:

I don’t want to put constraints on line-length. That’s not a designers’ job. It’s a user’s job. If anyone wants to change the measure in a flexible layout, they can do it easily by changing the browser window width on their Mac or PC.

By me not limiting line-length, a user can let big text fill their screen and see more of it at a time. A constrained, narrow width would force them to scroll and I don’t want that. If you think my logic’s flawed, or you can think of a better solution, I’m all ears.

As luck would have it, I’m all mouth.

So let’s chat for a minute. Let’s chat about two things that users can do to improve readability, as needed:

  1. lean in to the display
  2. invert the colors of the screen image using OS-specific commands

These acts have dramatically different barriers. The first requires only a minimally functional set of core muscles—no conscious thought or fine motor control whatsoever. The second, some problem analysis, a conscious decision, prior advanced knowledge of one’s OS, and a modicum of fine motor skills, depending. (I still often botch the iOS home-button triple-tap.)

The greater the set of requirements to perform a task, the more the designer should do to prevent the user from having to perform that task. Absent some principle like that, how could we say that, in general, designs shouldn’t feature white-on-black body copy? Or, I don’t know, 6px body copy?

I would argue that the action Clarke empowers his users to take—constraining line lengths by adjusting browser window sizes—has more requirements than the scrolling he’s trying to help them avoid.

Scrolling is easy and barely conscious for many people in many cases. It’s such a fundamental act of web reading that we have many different ways to do it:

  • the arrows on the scroll bar
  • the whitespace in the scroll bar
  • the scroll position indicator in the scroll bar
  • the mousewheel
  • the trackpad
  • whatever you call the top of the Apple Mouse
  • the space bar
  • the down arrow key
  • tapping a phone’s screen and dragging (so easy I do it with my nose when I’m wearing gloves)

And so on.

(Okay, one more: In Instapaper’s iOS app, you can just tip your iPhone or iPad to scroll. Marco Arment seems to have taken scrolling to be so important in developing an app for reading that he wanted to make it even easier. This despite the tap-and-drag’s having been, again, an absolutely fundamental iOS interaction from day one.)

By contrast, resizing a browser window as Clarke would prefer we do requires, first, that we make the conscious decision to do so. Anecdotally, when I make the decision to resize a browser window, it feels like I’ve done a lot more analysis of the problem I’m having than when I scroll, a behavior that I started using in, I don’t know, 1987. I bet you feel more or less the same way.

There are also fewer ways to resize a window. Historically, you could use your OS’s maximize and related buttons or you could grab the bottom-right corner of the window. The buttons probably don’t help Clarke make his case, since they don’t resize with enough control or predictability to be useful in trying to adjust text sizes.

The latter method, grabbing the corner, was such an interface problem—with its small targets and somewhat sloppy, two-axis behavior—that, starting with Lion, Apple decided to change the model significantly. I’m stubbornly attached to Snow Leopard, so I can’t speak to the effectiveness of the new resizing features. (And to be fair, Apple tackled scrolling, too, not that I was jazzed about those changes.) But it’s tough to imagine an argument that resizing is easier than scrolling, the dilemma as Clarke figures it.

All told, if it were my site—and, at the moment you read this, it will be—I would much more readily encourage scrolling than resizing.

Posted in Web | Comments closed