Archive for the ‘design’ Category

Accessibility is an important and worthy goal, but it is not at odds with good design. We should settle for nothing less than beautiful and accessible currency. This isn’t it. 

— John Gruber, April 3, 2008

Recently the U.S. Mint released new five dollar bills that have been redesigned in the same style as all the other denominations. Larger numerals have been added to the obverse sides of each bill, presumably to aid in identification by the sight impaired. The bills also contain further deterrents for would-be counterfeiters, like UV inks and special watermarks. But the money still looks the same. It looks like a multi-car pileup on the freeway of design by committee. And the worst part is most of the committee members never even lived in the same century. It seems as though American currency design has gone the way of most design here: an act of contrition to the flow of time, an act of desperation against petty (and not so petty) crime, and a half-hearted nod to those less fortunate than ourselves.

The goal of “beautiful currency” is probably meaningless to most people. Money is a means, a way to buy lunch and put gas in the tank. But more than any official document or printed decree, money is an ambassador. When the U.S. dollar was strong, millions of these little treaties on American ideals were in circulation in parts of the world where few knew anything about us, testifying for us—even if we could never measure up to all those hopelessly noble faces and mighty monuments of architectural achievement.

The five dollar bill I fidgeted with tonight in line at the grocery store looked like a ransom note from some amateurish kidnapper, stained with red Kool-Aid and ham-fisted attempts at foiling teenagers at Kinko’s late at night. The enormous Helvetica “5″ on its back seemed placed there if not totally by accident then at least without care. Held up to the light I saw the lovingly engraved portrait of Lincoln, the president who managed to give his life convincing half a nation that maybe owning humans like cattle was a terribly bad idea, bemusedly looking on at that purple numeral in reverse.

American money, in addition to being stinky, is ugly. And it’s getting worse. But look on the bright side: at least now its looks and its value are getting in synch. The worse our money gets in terms of its aesthetic value, the more it slips in international market value. Am I suggesting that somehow all the world is as shallow as we are? That somehow, entire Saudi families loved the look of the 1967 fifty-dollar bill so much that they stock-piled them in their palaces by the millions and swam around in them like Scrooge McDuck based solely on looks? In a word, no. But design, as Steve Jobs likes to say, is not how it looks; it’s how it works.

So ask yourself next time you’re at the pump putting eight of these new bills in your gas tank if design makes any difference to you. Would it make any difference if the money you used to do it were beautiful, with slogans that reminded you of a bygone part of our shared history that through perseverance and sound governance we could return to? Or would you rather have the key to a Holiday Inn, with a sticker on the back marked by hand in ball-point pen: do not copy?

1.) When my dog amiably holds my gaze for just a second too long and I realize he is probably a reincarnated Buddhist monk, thanking me for the scrap of turkey I gave him under the table.

2.) When my wife calls me three times in a row in a twenty minute period to converse about essentially nothing, just so that she can say “I love you” at the end.

3.) When my in-laws give me a birthday card signed “may the force be with you” to accompany a Star Wars DVD boxed set.

4.) When people look at me–straight-faced–and call Internet Explorer version 6 a “web browser” in an non-ironic way when in fact IE6 is really just a trap, sent here by evil demons from another dimension; the same demons who want me to spend the rest of my life breaking perfectly good code instead of reveling in the first two things on this list.

I wonder if every line of work has an “IE6″? I’m sure it does. But this one, as they say in the marines, is mine. Yet again I’ve spent an evening wrestling my own hands to the desk where they can’t fly through my computer screen, thinking the same thoughts about just what would make a group of humans make a piece of technology–in general such a liberating and beautiful thing–so awful. It’s like being given an endless bankroll and a clock with no hands with which to make a piece of art and making You, Me and Dupree instead. I just don’t get it.

For now, though, I have the other two things. They’re enough. I didn’t code a single table today. Buddha and my wife are winning.

An inescapable fact of life in web development and product design is meetings. Frankly when I was first freelancing I thought the notion of the hours long info share was sort of a myth; as I began to work in teams later I realized they were not mythical, but rather nightmarish. Often, meetings would drag on for hours or even consume entire workdays. It seemed that no one was able to hold focus for much longer than an hour, but the meetings would continue anyway. In fact, these marathons stretched the meaning of the term meetings and veered dangerously toward seminars. Most of them had no real agendas, and almost everyone in the meeting was seeing new information for the first time.

I found myself yesterday in a planning session with a large group of people. We were asked to, among other things, talk a little bit about the stuff we’re asked to do too often in our office lives. Unsurprisingly almost every group mentioned meetings. So the object of this post is to share some ideas for making meetings—something I stress really are important in development—something more useful than they may be for you right now.

I. Meeting types
Meetings are not one-size-fits-all. In so many offices, meetings are held because it “seems like the right thing to do”; you want to build consensus for a project, or take the pulse of several team members about their status while on a project and a meeting with everyone involved seems like the best way. Instead, consider a ten minute standup meeting—all parties standing and looking directly at the features, code or colors in question. Another type of meeting that happens constantly is a document review, where a team might get together to go over a timeline or other shared document. The kiss of death in these meetings is twofold: letting them run over about half an hour, and not giving all attendees an opportunity to see the document beforehand. I can’t think of anything more frustrating than watching someone edit a spreadsheet on an overhead projector that I have either never seen before, or that I only occupy a couple of rows in.

In short, keep meeting relevant and short. When only three people need to talk, three people should talk. Avoid concepts and words, and seek concrete actions that you can dole out to everyone at the table. It may seem childish, obvious, or elementary at first to hear yourself saying, “Bob, crank this widget”—but when everyone leaves the room feeling like they have something real to do, they feel much better.

II. Handouts
In our office we’ve gotten as far as doing meeting agendas, and they really help. Agendas at least make participants feel like there’s a map out of the madness, and if all else fails it’s something you can point to to get back on track. One thing we don’t do is a pre-meeting info share of some kind. The pre-meet can be a short email sent to everyone invited that says:

“Hi all-

We’ll be meeting about Project X Wednesday @ 11am. The agenda is attached to this email. At this meeting the project planner, Bob, will expect the following from the team:

• Sue: Wireframes uploaded to Basecamp
• Erik: An answer from Google about the foo API
• Matt: Status update on the data import scripts from WordPress to Joomla

This gives you guys two more full days to bash these things out. You can expect another task from the list at the end of the meeting.

See you then!

-Bob”

The pre-meet puts everyone on the same page. It takes the meeting from the land of the abstract concept to the land of the concrete task check-in. We have to assume that no one is going to do meeting specific preparation, so substitute the actual work for the meeting related busy work and then talk about that.

It might also be a good idea to send along your meeting agenda, as suggested in the example. If it isn’t ready yet, try to send it along no more or less than one day before the meeting. More than two days no one remembers, and twenty∏ minutes before you might as well not bother.

III. Meeting math
If all else fails, and you literally cannot get a hold on meetings consider this formula.

E(Employees) x Pr(Pay rate) x Ml(Meeting length)

If the cost of the meeting in contrast to the profit or cost of your project makes you want to jump out of a window , someone may end up managing meetings for you.

Warning: This is a post about my job. If you think you may be offended by such a thing, now would be a good time to close this tab.

I have a friend who’s almost universally joshed for being the guy most likely to march into work early Monday morning and announce he hasn’t slept in days, because he’s been coding his way through some problem. For months I had no idea what he was talking about; I was able to turn work off if I wanted to once I walked through the door, so why couldn’t he? Slowly, given enough time pressure, almost any designer or developer can start doing the same thing. I realized this when I sat in front of my Mac Book Pro on Sunday and coded for fourteen straight hours—really only breaking for the bathroom and to eat. The reasons for this are myriad, and are the basis for an anecdote about deadlines and such.

Our company has a tendency to talk about things a lot. Given almost any project, we can find a way to have at least a dozen meetings just about how to get started. Once we’ve figured that out, we’ll have a dozen more to decide what the next steps are. The meetings we tend not to have are the ones about scope, requirements or audience. These things always seem to be someone else’s job. The head of the department I’m attached to has it far worse than me, however, as he gets pulled into essentially every meeting ever planned; it’s left to him to sit through them all offering advice and guidance where applicable, and making the hard choices about milestones and even some development issues. It’s fair to say that we have a ‘meeting culture’, and that we tend to manage by committee. This often leads to deadlines that are set by such committees.

What tends to happen when committees don’t know much about requirements or project scope is that boat docks get built in the desert; one hand is totally unaware of the difficulty (or triviality) of the tasks being performed by the other, unrealistic deadlines are set, and the end product is a mess. I found this out the hard way with my last product launch, which was governed by an arbitrary deadline that could only be met by means of several 90 hour work weeks in the dev room. The “extra time” needed to make things better after launch was almost exactly the amount of time the dev team asked for on the front end of the project. Score one for the immovable, immutable deadline. In the interest of fairness I do understand the business case for setting deadlines and/or milestones on major projects; in large organizations it’s often necessary to attach revenue to projects that haven’t happened just yet.

I guess the only advice I have for planning a project is this: understand that most of what you’ll be doing in the initial phases is really only a guess, and that you need to check your work frequently against your map to make sure you’re on track. You need to give your people the leeway to say “this map does not match this road”, and change the map. But I also understand why this is so hard to do. It’s very difficult, especially in an overcrowded and ever more cutthroat online market, to take the time to breathe through a milestone meeting where you hear things are slipping. It’s also difficult to trust that the project is worth the extra weeks of design and testing and coding and recoding; but if you show up for work everyday anyhow, then you must believe that at least a little, right?

Today when I sat in a meeting and heard all of those things happening—the deadline slipping, the map changing, the request for more time—I felt as though cooler heads had prevailed. I felt like the project managers were sticking their necks out for the dev team, and that my fourteen hour coding sprees might no longer be necessary. Even though I left the office tired of meetings I felt renewed to some degree, even if for a few minutes. Will we return to endless meetings and arbitrary deadlines? Of course we will, but for today we can pretend there is no phantom deadline. That’s worth a meeting or two for me.

Related update: I’ve just been directed to the WikiPedia entry for “Scrum“, a project management system that seems to have some really nice ideas. Your mileage may vary.