Free UI reviews: World usability day tommorow

World usability day

Tommorow is the first annual world usability day. Free events all over the world are taking place to promote ease of use and good design in everything.

I’m surprised not to see more events in the SF Bay area or Seattle (Nothing at Microsoft, Amazon.com, Zaaz, Blink, Real, Saltmine, Adobe ?) so I’ll do my part:

I’ll do 100% free expert reviews of the first 3 websites people submit in comments (I will likely do many more but I can only promise 3). It can be your website, your company’s, a site you use or something you think would be interesting (or entertaining) to have me critique.

Update: About ten in already but do keep them coming. I will do as many of these as I can tommorow and more over the next week. It’s not too late.

The data death spiral

Whenever data is misused as the only means for making decisions, a death spiral begins. Blind faith in data creates a false confidence that overwhelms reason. Decision makers forget their wisdom and wait for numbers, fueling an addiction to unnecessary, biased and distracting data. Cowardly decision makers thrive in unnecessary information, their fears can hide there, and the data can be used to the wise with blankets of endless numbers and facts of dubious value.

Data can be good: it can dispels ignorance and raises questions. But data doesn’t make decisions or find good ideas: people do. As soon as you discount people in the name of data, the downward spiral begins.

You know you’re in a data death spiral if:

  1. Confusion over what the hard part is. If you are working on anything challenging, data will only define the landscape. It won’t dictate a particular strategy: good data has different interpretations. If you present data to justify a decision you are emphasizing some data over others: which is an act of creativity and opinion, not fact and figure. Opinion is everywhere and is most dangerous when it’s hiding behind spreadsheets.
  2. No opinions are considered without data. Opinions are good if they come from smart thoughtful experts. If you are in a world where you, as an expert, can’t make obvious improvements without 10 pages of supporting material, guess what happens? Nothing happens. People spend all their time defending the obvious and the scale of work, and the energy to improve, drops dramatically.
  3. Creatives are hiding in the corner. Good designers and creatives know how to make things. Lots of things. They experiment and explore. When used properly they are a piston of progress. But if the landscape is data and analysis obsessed, creative types are relegated to refinement work, the least leveraged use of their talents. The team gets a fraction of their possible value.
  4. No one questions data. Not all data is the same. To collapse data down into “70% of our customers prefer green” requires several layers of simplification of the truth. Which customers? What alternatives were they shown (were there just 5 kinds of green)? How many customers were there? If no one every questions the data and understands its nuances the gates are open for people to throw more misinterpreted data at each other. You need data quality not just data volume.

Death spiral
How death spirals start

The spiral begins with ignorance. Leaders confuse the collection of research with thought. People who throw more data (not better) at problems are rewarded and others follow. Soon no idea can be suggested without a data armory. Meetings are data battlegrounds. Or worse, data massacres. When someone says “Morale is low. People are crying in the halls. We must do something.” another says “but where is your data?” and the conversation ends.

As the spiral bottoms out, people are proud of numbers and slide decks: not the results.

Steps to preventing death spirals

  1. Separate good data from bad. Good data self describes its biases. A smart person uses data with consideration for what things the data can’t tell you, and they include this understanding in their story. Encourage people to play devil’s advocate on their data and make data inquiry part of the discussion any time data is presented. Diffuse data obsession.
  2. Data and ideas are partners. Make sure developments happen both ways: ideas that are pulled out from data, and ideas that come from minds, with supporting data found later. At its best it’s an itterative process: you have ideas, you research data, you refine ideas, you research more, etc.
  3. Instincts matter. The Gladwell book Blink explores how our instincts serve us: are the instincts of your group serving you? Layers of process and data bury our hearts. Some people have better instincts about certain decisions and you want to harness that talent, not dilute it. It can be fine to say “Fred has the best perspective on this. It’s his decision.” And allow Fred to define how much or how little research is needed.
  4. Let go of the fear. Many people collect data to defend their choices should things go wrong. When bad things happen they point to the data and say “See! We did the right thing!” despite the results. This kind of paranoid, self-protective thinking weighs on a team: instead of ensuring success, people are protecting their asses. Most of us can smell it when a leader is in this mode and it puts the entire project on its heels. Insurance is for the birds: A good manager earns the trust of his team and lets them know that even in failure, he’ll take responsibility for what was done.
  5. Kill contrived group think meetings. Data obsession and consensus-driven teams go hand in hand. It’s on big, cowardly teams with leaders who demand everyone agree before decisions are made that people show up armed to the teeth with handouts and marathon presentations. Not everyone needs to agree to everything. Define who is in the best position to decide and give them the power. If necessary, pick a handful of people who disagree to go off and fight it out in private, reporting back when a decision has been made.
  6. People are better than data. Much of a person’s talent is difficult to capture in numbers. Their experiences, instincts and passions all factor into what makes them good at what they do. As a manager, I want to make sure I have channels open to these assets, channels that don’t require the same kind of data in order for me to listen. If I shut these things out, I’m denying myself the benefits of true expertise. If I’m working on something hard, and with tight deadlines, the more good decisions I can have my team make without days of research, the better off our team will be.

See also:

Book tour wrap-up

Judging by the low number of comments, my book tour travelog has been a snorefest so I’ll wrap up the remains in one post.

Friday 10/14: I dropped in at Razorfish and Google NYC and talked about user centered design, leading development teams and the challenges of making good things. One of the folks at Razorfish, Vincent Santo, was an Interactionary survivor and we chatted about that. Karen McGrane, my excellent host, was great and as cool as I expected. Over at Google I was hosted by Leslie Yeh, who worked on my team for awhile back at Microsoft. Their office near Broadway was slick: 3 stories cut away into a central opening, with enough room for two basketball hoops. My kind of office.

Monday 10/17: As a kid I walked by the Cooper Union campus dreaming about going there one day. Well the day came: I got to speak to 120 students and faculty about lessons I learned at Microsoft. It turned out much of the crowd were freshmen, so I quickly ditched most of my slides and let them ask me questions for an hour. It was a thrill and an honor: after a few jabs at MSFT the focus turned to business, innovation and the differences between being a student and a professional. Best question asked: Who would win in a fight, Bill Gates or Steve Jobs?

Tuesday 10/18: The full circle was complete: I spoke at CMU where I graduated in ’94. Catherine Copetas was my fantastic host with CS department and set up two talks: a small informal talk and a big lecture. The lecture was in Wean 7500: A room I had fallen asleep in countless times as a student. Speaking in that huge cavern of a room was a right of passage. Bonnie John, the director of the masters program at the CMU HCI institute, and a former professor of mine was there and we chatted afterwards. It’s fantastic to see that what was a collection of courses when I left, has blossomed into an entire HCI group: they’re setting an example for other CS departments to follow.

Wednesday 10/19. Had I planned better, I’d have used this day to see more friends in Pittsburgh. But I was exhausted and mostly slept late at Faisal‘s and then crawled out to Shadyside and wrote in a coffeeshop on Walnut Street. I ate a late breakfast at the legendary Pamelas, bought a sandwhich to bring home to my wife at the Peruvian place (La Feria), and spent a ton of cash on cool CDs at the world music store. Walnut street still has a special quiet hip charm hard to find in most cities.

Thursday 10/20: Homeward bound. By 4pm I was back in the woods and sleeping comfortably, with my dog Max, on the couch. 12 days, 3 cities, 9 talks, lots of cool new people and old friends, but time for sweet dreams.

If you want lesssons learned from this, my 2nd book tour, comment away. Otherwise I’ll leave the tour behind.

Cooper union poster

This week: Making handoffs

This week in the pm-clinic discussion forum: Topic #51 – Making handoffs.

Here’s this week’s situation:

I’m a lead programmer at a software development shop. My problem is handoffs: my group stinks at them. We have business folks that write requirements docs, but the way they hand them off to my team is a joke. They don’t involve us in the process and don’t help us resolve ambiguities in what they created. Then there are poor handoffs to test, and again to marketing. It seems almost every handoff is done poorly: it’s almost expected.

How can/does a team learn to make better handoffs with work that cuts across jobs/roles?

– Death by fumbling

Stories from the road: the train experience

Thursday was my first day off: a travel day. A short cab ride and I was in Boston’s historic south station. To my delight, they even had a bookstore in the center of the main concourse.

Boston train station

The train is a better experience than air travel, hands down. The stations are often beautiful old buildings with dramatic large spaces and high ceilings. Getting on and off doesn’t require snaking security lines and obsessive ID and boarding pass checks. Wandering around South station I kept looking up, entertained by the sheer size of the waiting area. They just don’t build buildings like that anymore. Unlike airports, you get a sense that you’re really somewhere, even while you’re waiting to go somewhere else.

Train window

On the trains themselves there’s more room, power access and a dining car (the food ain’t great, but you’re choices are better than airplane’s standard chicken or pasta). And unlike air-travel where there’s a rush hour panic vibe and people’s smelly elbows in your face, the train is downright civilized. Plenty of space. Wide seats. Quiet cars. I suspect the 8am train would have been crazier than my 11:15, but I had a most enjoyable ride.

Perhaps I have train envy. In Seattle, where I live, it doesn’t seem we’ll ever have train service of any kind. The history of mass transit here is a tragic tale than spans decades and is simply too sad to get into here. It’s a classic tale of bad project management.

3 hours later I arrived at Penn Station and had my ritualistic thrill of walking up to the chaos of the midtown NYC streets. That energy rush always gets a rise out of me: it’s the lovable insanity of home.

The evil wall of requirements

One of the things stupid people do is this: Person A (aka Mr. stupid) writes a requirements document. He makes it super detailed and 50 pages long. He then throws it blindly over a wall (thud!) to person B and says “Do this.”

This is evil and dumb for the following reasons:

  1. It guarantees resentment. Person B is being dictated to, which is less than fun (unless you’re a masochist). He is confined by person A’s (unnecessary) details. If ever person B has power over A, the negative energy will be returned.
  2. It ensures poor quality work. Person B has no vested interest. The requirements are not his and he’s unlikely to feel positive about fulfilling them. I would not expect B to stay late, ever, to help fullfill requirements he didn’t beleive in.
  3. It’s limiting. How does person A know that person B doesn’t have suggestions for making the requirements better? Or that his requirements aren’t completely insane and contradictory? He doesn’t.
  4. It’s unecessarily territorial. Fighting over documents is absurd, since the document is not the product. Requirements, prototypes and wireframes should be fodder for collaborating on the best ideas, not for putting your pet ones in locked boxes.

Every time I hear about organizations that draft requirements in private, I choke. It’s a sure sign that creative thinking of any kind is seen as disruptive rather than constructive.

Requirements should be built in the open, with invitations to designers of all kinds to vet out requirements early on with rough prototypes and mock-ups to prove (or disprove) the assumptions made by the requirements. If quality requirements are the goal, there is every motivation to involve the people who will do the work in the their definition.

You want overlap of involvement in the production of any requirement (or document) between the creators and the users, as in this diagram. Ideas show flow freely between them. It should be a dance of analysis (business dude) and synthesis (designers/engineers).

Requirements diagram

You can replace the legend with any pairing of creators and consumers within a team and it still works. Programmers/Testers, Product managers/Program Managers, Designers/Engineers, etc.

You could argue that the lines should run in parallel for longer, with two or more people working as peers in the process until there is enough stability for a handoff. My point with the squiggly lines is that it fluctuates, but that it’s always clear who the primary driver is.

But the core of my point is overlap of involvement. Regardless of method (agile, waterfall, VP whim, utter chaos) you want to collaborate over important decisions, exploring alternatives and using cross-disciplinary perspective to draw the best thinking to the surface. There’s never a reason not to.

Lecture #2 at MIT: Why software sucks

MIT poster for the talk I quickly lost myself in the MIT campus. It was fun to poke my nose into classrooms and departments observing everyone busily doing their things. I must have fit right in, as two different people asked me for directions.

The talk, Why software sucks, was nearly canceled. Someone was upset about the title and it was cancelled from the seminar series. I called (ok begged) the fine folks at the student run SIPB and they came through, rescheduling the talk and hosting me on campus. Kudos to Jeff Arnold and Jennifer Tu. They had posters up all over the place (see photo above) and spread the word.

There were about 100 people in the 54-100 lecture hall (see photo). Despite the size I had lots of good questions and a good two dozen people stuck around for a long Q&A session. I was impressed with how many questions there were about process and engineering. Someone asked about why certain bugs in Word (or other v 12 software) will never be fixed: and we talked about the challenges of platforms.. how the risks for certain bits of code can become higher than the return value in making changes (a reverse econony of scale for software). Somewhere in there is a business/engineeing case study waiting to happen.

MIT 54-100 lecture hall

This week: How to be the wolf

This week in the pm-clinic discussion forum: Topic #50 – How to be the Wolf.

Here’s this week’s situation:

Imagine that you are made a job offer where you need to “whip into shape” the organization. You’ve been briefed on some of the issues they’ve been facing and are brought in to turn the team around. What kind of questions should you ask before taking such a job? What resources would you ask for? What authority would you need? How much information does a candidate need before accepting such a task?

– How to be the Wolf

fyi: The Wolf is a character from the film Pulp Fiction that comes in to save the day. . Also related to “The cleaner” from La Feme Nikita.

BT: Lecturing at MIT

When I was a student at CMU, I thought of MIT as the school we wanted to compete with but who didn’t know who we were. It was kind of like picking a fight with someone twice your size: it’s not that you’d lose, it’s that they didn’t even care. So visiting MIT was a thrill: I’d read so much about the place, and the legendary hacks, that I had fun just walking around on campus. (It’d make an interesting contrast a few days later when I spoke at CMU).

MIT Strata centerI walked the 15 minutes from the ever swanky hotel Marlowe and met Daniel Jackson from the CS department. The Strata center, where his office is, is a wild Ghery designed skyline of buildings and it was a trippy thing to see early in the day. Jackson and I chatted about teaching programming and organizing teams, but soon I had to run off to talk at the Sloan school.

I had no idea what to expect: I’m entirely depedent on my host at each of these gigs to promote or advertise the talk, and for this one I expected to 8 or10 people and a small room, for an informal chat. Well, I was wrong. Yuntao Edward Shi (of the mediatech club), my host, filled the medium size room with nearly 100 MBA students. I was late to the building and scrambled to find the room, and had a sureal moment of “that room is really crowded it can’t be it. Wait. That’s it.”

Sticking with my plan I kept the talk informal. After a brief intro I asked the crowd what they wanted to talk about and let them veto entire sections from my slides. It was great. Someone asked about anti-trust, another about managing people smarter than you and the session just flew by. These guys are smart: looking forward to seeing what they do after they leave Sloan.

At 12:59pm we were kicked out by some TAs setting up for an exam. I had flashblacks to scrawling long missives in those little blue books they make you write in. I smiled inside, being so happy to never ever have to take an exam again.

The next talk at MIT wasn’t until 4:30pm. Robbie Allen, esteemed O’Reilly author and the man who made the talk possible, met me for lunch. Then I had two hours to kill before the next lecture on why software sucks.

BT: Lecture #2 at Boston CHI

One of the fun things about doing no-frills book tours is how much I have to rely on the kindness of strangers. People can be cool if given the chance. Matt Belge, chair of the Boston ACM-CHI chapter, kindly offered to give me a ride to the meeting in Burlington, MA. We quickly hit real traffic, east coast traffic, not the wimpy arterial kind Seattlites are fond of complaining about. Matt wonders if we’ll be late, but then we laugh as we realize that with the chair and the speaker in the car, the event starts when we show up.

Boston-CHIStupid mistake #1: At Sun, the host for boston-chi, I realize I left my power cable back at Northeastern. Yes, I made the same mistake on tour #1. And yes, I am a moron. A quick call to Peter and there’s a shot it might still be in the room (it’s recovered later thx to him).

Nicole Yankelovich graciously donates her Powerbook, who’s screensaver provided entertainment at various intervals during the talk (I made up stories about the photos every time they came on: improv training comes in handy).

The crowd of about 50 people was great: they asked good questions, played along with my jokes and we had a fun time. I spoke about What to do when things wrong (slides / audio), a topic from the book.

Relying on kindness again, I snagged a ride from the rising design star Sam Aquillano from IDSA Boston. I see great things in his future. Plus he has an ungodly gift for finding his way through dark and confusing parts of Boston.

Back at the hotel at 9:30pm, I snagged another cab (#3 for the trip so far), met Peter at Northeastern, and then doubled back to the hotel, power cable intact. Back at the hotel at 10:30pm, I realize lunch at O’reilly was the only meal I’d had all day. I stay up late preping for Wednesday’s lectures at MIT and chowing down on the most expensive Turkey sandwhich in history via room service. 2 lectures down, 7 to go.

BT: Speaking at Northeastern university

I instructed the cab to make two stops: one back at the hotel to drop off most of the books, the other at Northeastern, near the core of Boston. At the hotel I run up inside, look longingly at the comfy bed I’d left so early, and run back down to the cab. We speed away to Huntington avenue, which splits the Northeastern campus roughly in half. The problem is street numbers: somehow less than half of the buildings feel obligated to help us figure out where the hell we are, so we move slowly up the street, cranning our necks, calling out numbers. Finally we see a tower of a building ahead on the left, and I know it’s it. We turn around and I run inside.

Peter Tarasewich, my kind host at the Computer & Information Sciences department, showed me around their cool offices and then takes me to another building for the lecture.

Northeastern UniversityAt 3:30pm I talk to 70 or 80 students and faculty about software design in a talk called “Why software sucks: and what to do about it” (essay here). 30 seconds into the talk I’m interupted by an imporant, but distruptive question. A few minutes later there’s another question from the same man, and then another. It turns out this was the highly esteemed Matthias Felleisen and this approach to lectures is simply his way (The questions were good, but the timing and tone was less than friendly). The rest of the crowd had more patience for me and we had some good discussions about the meaning of “code is poetry” and what it means to make good things. The post talk e-mail was good: lots of follow up questions which is always fun.

At 4:30pm I called Matt, the chair of the bostonchi.org chapter for a ride to next gig: speaking at BostonCHI.

Book tour(BT): Tuesday, O’Reilly

Over the next week I’ll be posting about the tour. If this bores the pants off of you just watch for the BT flag and skip.

Tuesday 10/12: First thing Tuesday morning (ok – first thing after I woke up) i made my way via cab to the O’Reilly office in Cambridge. I’d been warned the place was to hard to find: they were right. I didn’t trust the cab driver as he zig-zagged me through tiny suburban streets, the meter running higher as my confidence declined. There’s always a moment in cab rides when I think “Wait. I have no idea where I am and he could be taking me anywhere”. After a few false positives (him “is this it?” me “How would I know?”) we arrived at a simple but mostly unmarked two story office complex. I wandered inside (asking the reluctant cabbie to wait) and soon found a wall of O’Reilly books: I’d arrived at the world of tomes with animal covers.

I soon met Marlowe Shaefer, the fantastic production editor for The art of project management. Production editors are the PMs for the making of books and Marlowe simply kicked ass. There’s something wonderfully bizzare about meeting someone for the first time, despite working with them intensely over the phone for months. After a nice, but quick, lunch with Mike (the main editor for artofpm) and Mary, two O’reilly editors, I grabbed the box of promotional books they’d provided for me and headed to Northeastern University for Talk #1 of 9. I gave the cab driver the address, which he shrugged at, despite pulling away from the curb, and I hoped for the best.

This week: Death by autonomy

This week in the pm-clinic discussion forum: Topic #49 -Death by autonomy.

Here’s this week’s situation:

I’m an engineer at a well known search company (rhymes with frugal). My loosely structured team is big on indepenendence but is starting to be low on maintenance: there’s some work that needs to be done to support the work 4 or 5 of us are doing, but that no one really loves or wants to do. So often it doesn’t get done.

How to you make sure maintenance and grunt tasks actually get done (especially if you’re working in a highly independent environment (intentionally weak hierarchy))?

– Signed D.B.A.

Book tour: hurry up and wait

On tour, day 1: Columbus day (10/10). There’s something pathetic about waiting 5 extra hours in your own airport. Somehow waiting in distant airports is more dignified: at least you’ve moved. But given that the entire radar system in boston was down, travel was a bad idea all around: I didn’t protest. I briefly considered flying into NYC and driving up, but the math didn’t work out. I had faith (perhaps blind) in the unkown Boston radar mechanics which worked out. I arrived at the swanky Hotel marlowe near midnight (a splurge to compensate for nights on friends couches), and prayed to the book tour gods for better luck on the rest of my 10 day, 9 lecture trip.

Next: Lecturing at Northeastern and Boston-CHI

Boston: Social time change, now 8pm

Due to problems with the radar at Logan airport my flight was delayed by 5 hours. A few things need to be shuffled around. As a result, the glorious and wonderful social night will move back an hour to 8pm on Wed at Miracle of Science.

If you show, I’ll buy you a beer. I’ll talk about whatever you like. I may have a few free copies of the book . I may even be there before 8pm, and it’s a cool place so don’t wait for me to relax and have a drink.

Apologies for the reschedule. Hope to see ya.

ArtofPM Book Tour: Oct 11-19, details

Details almost complete. Social night will be at Miracle of science. New boston date added. Still waiting for final details from Cooper Union.

Tu 10/11 – Boston 3:30-4:30pm, Why software sucks and what to do about it, Northeastern University, room Behrakis 10 (health sciences bldg)
Tu 10/11 – Boston 7:00-8:00pm, What to do when things go wrong, details at Bostonchi.org
10/12 – Boston 12-1pm, “What I wish they told me before I left college”, MIT, Sloan, Bldg E51 room 145
10/12- Boston 4-5:30pm , “Why software sucks: and what to do about it”, MIT CS building, G449 Room 54-100
10/12 – Boston 7 8pm-?, Social night, Miracle of science bar, Cambridge, MA
10/13 – Travel
10 /14- NYC , Razorfish, Private
10 /14 – NYC Google, Private
M 10/17- NYC 12pm-1pm Cooper Union, details TBD
10/18- Pittsburgh 12:00pm, “How to lead software projects (the art of pm)” , Carnegie Mellon University, location TBD
10/18- Pittsburgh 4:00pm, “What I wish they told me before I left college”, Carnegie Mellon University, Newell-Simon Hall 3305
10/19- Pittsburgh 5pm?, University of Pittsburgh, details TBD

The “What I wish” talk will be really fun: – a crossover of business, leadership and life advice I’ve collected that would have saved me oh so much suffering. I’ll be collecting new advice from the audience as well.

Hope to see you. If you’re interested in pub night in Boston comment here and I’ll make sure to follow up.