I’m finishing up my slides for a talk next week at UIE 13 in Cambridge, MA. The title is “Why designers fail and what to do about it”.

I’m sure there are a zillion reason’s designers, like any professionals, fail. What I’m looking for are habits you’ve identified in designers you think sets them up not to achieve what they seem to want to (making great, easy to use, things).

Here’s a sample of the long list I’ve identified:

• Assuming other people understand design and care about good design
• Not seeking power when power is required to deliver on an idea
• Being shy / passing opportunities to pitch ideas
• General incompetence (not as good at designing things as they think they are )

My goal isn’t to bash designers here, and in the talk I offer solutions & positive examples.

Instead here’s what I’m hoping for: there are many proffessional designers in the world, but not many things we can buy that are designed as well as i-phones and Porsches - why is that? How do designers fail, whether it’s their fault or not, to bring great things to the world?

I’m thinking there are 3 categories: Failures of the designer’s psychology, Failures of the designer’s skill, and failures of the organization.

Love to hear your opinions - thanks.

Posted in Design | 6 Comments »

Probably the best single website for explanations, background and summaries on what happened, what it means, what might happened next. Includes comparisons to previous crises.

The Money Meltdown.

Posted in politics | 1 Comment »

For a few hours today my nice little RSS Feed, with close to 20k subscribers, was replaced by a pile of ads for some record label called True Tiger Recordings.

As much as I often consider ditching the whole writing/speaking career to be a lead singer in a rock band, that’s not what happened today.

A few kind folks, Peter, Kirill, Dave, Adam, Neil, Greg, Meh (hey, that’s the name you left) - let me know almost immediately that something strange was up, and as I don’t check my own RSS Feed often, and they saw it well before I did. Thanks guys, I’m in your debt.

I assumed I’d been hacked, which has happened before. I run mostly vanilla stuff, so usually if I’m hacked it’s an old one, and I can find a patch or a solution online. Not the case. So the hunt began.

In about an hour I’d sorted it out. My web-dev had fixed another problem with redirects earlier today, and reinstalled a WP plug-in called Permanent Redirect (you can see where this is going, can’t ya?). Either by a fluke or some weird config behavior, it defaulted to using a feedburner URL for ALL feed redirects.

Now I don’t use feedburner. Never have. Worse, I don’t understand how it could have magically defaulted to a generic feedburner URL that works: http://feeds.feedburner.com/feed, much less one as comically unrelated to the normal going’s on here, but I need to chat with my web-dev to sort out if anything odd happened during the other fix.

Anyway, apologies for the interruption in any case. Fun bit of drama for me today: now to find a nice bottle of wine :)

Posted in this site | 2 Comments »

• Education and the inner city. I know many parents going through the public vs. private debate, and here’s an interesting take on the topic.
• Careful Senator, your politics are showing. Post by Dan Roam, author of back of the napkin, showing the drawings he made for senators based on their economic data.
• Dominoes made of dominoes. Random cool video of the week #1.
• What agents hate. I’m sniffing around various agents and if you are too, this at least made me laugh.
• Creativity Myths roundup. Nice post summarizing myths around creativity.
• Average age of tech CEO’s: 39!. Good article about the mythology we have for young tech sector CEOs.
• How to never forget anything . I don’t worry much about forgetting things, but found this article interesting anyway.
• 24 hour world air-traffic visualization . Random cool video of the week #2

Posted in linkfest | 4 Comments »

Running a bug bash is a dirty secret of software development. You won’t read about them in software engineering classes, or in agile method workshops. But some managers, when overwhelmed with undocumented bugs and not sure what else to do, demand the whole team stop what they’re doing and get as many bugs into the bug database as possible. This is what’s known as a bug bash, and often they’re a waste of time.

It’s true that a proper QA effort, or test-driven development, minimizes the need for this sort of thing, but few software organizations truly qualify. Hell, many so called “first class” organizations don’t have any testers, or a quality assurance plan at all. I bet bug bashes are one of the most common QA techniques used in the world.

And they can be useful - but the most common mistake is doing them by half. A half-assed bug bash sends the message software quality is lip-service. But doing it the right way can turn a project around, raise morale and sharpen a team’s ability to find and manage issues.

How to run a successful bug bash:

• Don’t create panic. If you say “Tomorrow! Everyone find bugs! Aaaah!” You are creating a panic and look like an idiot. You should know a week or more in advance that the bug counts are soft, or the database needs scrubbing, and line up leads and key players to support the effort.
• Freeze the build. You can not do a bug bash on a moving target: you invalidate repro cases and bug findings. Pick a build, freeze it, and make sure no one, NO ONE touches the live codebase during the bugbash. This should go without saying, but you never know. If it’s your first team wide bugbash make sure the entire programming team understands this basic rule.
• Show what good bug reports look like. Remind everyone crappy bug reports create extra work. Provide two bug report examples: one good, one bad. In the good example show well written description, clear repro steps, and a search for duplicate bugs. In the bad, show incomprehensible descriptions, impossible repro steps, etc. If you don’t provide examples, don’t expect people to magically know what you’re looking for. Finding 1000 crappy bugs that need to be heavily cleaned up is a waste of everyone’s time.
• Have an area or type of bug to focus on . Saying “find bugs” is a shot in the dark. It shows you have no clue what’s going on in your project. Think through what the weakest areas are, or what types of bugs you are most afraid of, and designate them the primary goals of the bug bash. Or offer bonus points (e.g. bugs in area 6 are worth x2) for people who find the specific type of bug most valuable to you.
• Clear the afternoon from everyone’s schedule. A bug bash should be an entire team activity and a half-day is the perfect amount of time. Everyone should be working on the same goal: getting good data into the bug database, and getting that database in shape. If it’s voluntary, or only half the team is asked to do it, the bash will fail. People will smell you’re not serious about the effort, and will contribute accordingly. Get permission to reschedule all team meetings for that afternoon to later in the week, and send out a new meeting invite to the team for the entire bug bash time slot. Include details (see below) on where bug bash HQ is, what the prizes are, etc.
• Get support from big shots. Brad Silverberg, my VP on Internet Explorer 4.0, used to file bug reports regularly. When bug bashes started he’d set the tone: everyone gets involved. With the support of leaders it sets the tone of how important the activity is, and eliminates the BS excuses people find not to participate (”If Fred, our best programmer is doing it, I should be doing it too”). Find the key players on your team, either key leaders or the star programmers, and get them to help promote and contribute.
• Have a bug bash HQ. Finding bugs can be a social activity: have a bug bash headquarters. Grab a conference room, order pizza and beer, and invite people with laptops to hang out and find bugs together. This invites people to help each other find repro-cases, share knowledge and bug database tricks, makes keeping a scoreboard easy, and makes the bug bash a proper morale event. A case of beer and few pizzas costs $60. Well worth it.
• Keep score and have real prizes. Geeks are competitive. Use this to your advantage. Any bug database allows queries for open bugs by date: Get this up on a website or hallway monitor and show it in real time. Buy some nerf weapons, dinner gift certificates, or even some X-box video games, and have them visible at HQ - give them away as prizes, or set up a betting pool: $10 per person, and the winner gets the pot. You can get fancy and have special prizes for most twisted bug, the bug least likely to ever get fixed, etc.
• Create rival teams. If you are totally poor, use ego prizes. Have the designers challenge the programmers, or the marketing team challenge the management team. Throw down: “I’ll bet the whole marketing team dinner at Ruth Chris’ my 3 reports can find more bugs than your whole team can”. If you don’t have cash, bet embarrassment: loser shaves their heads, has to dress in costume the next day, has to wash the opponents cars, etc. Get two sets of people who have some built in animosity or rivalry, especially if it’s well known, to openly challenge each other. This rivalry will draw more people in, if only to follow along. Do this once and you’ll have a tradition to build on for the next bug bash.

Posted in Software/Web development | Leave a comment »

When Making things happen came out in March, I did a few talks here and there to help promote the new edition, including a stop at a little place called Microsoft, in Redmond, WA. They videotaped the talk and it’s now available online.

You need to be running IE, or using the IE plugin for firefox, for the video to play. Sadly it appears to run on Windows only (I know, I know - its not my choice):

Title: How to make things happen

Description: What are the secret tactics used by successful project managers? How can people in any role, from development to management to design, benefit from their playbook?This fun, fast-paced, and interactive talk, loosely based on the bestseller Making Things Happen (formerly known as The Art of Project Management), explains how to make good things happen, and how to triumph over powerful people who are annoying and frustrating. Bring your toughest questions and situations for the Q and A, where Scott gives away signed copies of the brand-new, updated edition of Making Things Happen.

Watch the video for How to make things happen

Posted in Design, Making things happen, Management, Microsoft | 3 Comments »

I get tons of comments/email in response to this post on how to write a book. Here’s another interesting, and life-grounding, question from the mailbag:

I found your website hand thought it was awesome. I watched your videos and decided I could use some advice from you.

My house burnt down 3 weeks ago in Burnsville, Minnesota. I lost a 38 foot RV, a 69 Plymouth Fury Convertible, and monster truck and trailer in the driveway and my 16 years old sons car he worked on so hard and never got to drive. I also lost 5 animals in the fire and that really hurts. I still have my 3 children ages 23, 16 and a 10 year old daughter who is having night mares with all this life changing overnight experience. Guess what? I want to write a book about my life and how it changed so quickly. I am very grateful we are all alive and ok. Like everyone else I dont know where to start. I am living my worst night mare in a hotel gong on a month. We have nothing but the cloths we were wearing that day. Any advice would be greatly appreciated. Please contact me.

Very sorry to hear about your loss. I do hope there are local government agencies or non-profits that can offer you some assistance. Books aside, I do wish you and your family a better October.

On starting: there is no single easy way to start writing. There are some tricks to try, and I list my take on them in this essay on writing hacks. But everyone is different. How you start doesn’t matter, but if you wait for a perfect easy way to do it, you’ll likely never get started. If that essay doesn’t help, here are some additional tricks:

• Plan to come back. One trick that helps is to remember that the real work in writing is editing. I plan to come back later and revise, cut, rewrite and do all kinds of work later on. The “writing” part is just the beginning and believing this has a freeing effect. When I sit down with a blank page I have no preconceptions. I just start writing and plan to figure it all out later once there are a few pages of rambles and rants to work from.
• Go chronological. In your case you’re writing about things that have happened, or are happening to you. Great. Pick a date, say a week before the fire, and write about what happened every day from them to now. It could be as simple as two or three facts per day, or memories per day, or your recollection of your thoughts on those days, whatever you like. But anchor on time as the spine of your writing. It creates an easy way to divide up your memories, and to trigger thoughts or recollections. You then might choose to go to your family and friends and get their stories and recollections on every day, giving you even more material to work from.
• Keep a notebook with you. Have a place to write down ideas and thoughts about your experience and keep it with you all the time. Your rule should be whenever a thought crosses your mind, no matter how strange or personal, you write it down. Worry later if its good or interesting, but in the moment, commit yourself to writing something down. I have piles of old notebooks, and go through one every few weeks.
• Read other memoirs of experience. Many great writers have written books about their personal experience with tough times. Check out Joan Didion’s The year of magical thinking, about her experience with having two loved ones become seriously ill at the same time. It can help to see how other writers have tackled the same type of writing you’re going through. Worst case, you can critique their handling of personal crisis and write about that :)
• Write every day. Even if it’s just for 5 minutes, even if it’s just a sentence or a few words, sit down and write every single day. You have to get used to how it feels to sit there and that only happens if you put your ass in the chair every single day. Find a slot in your schedule that you can protect (early mornings or late nights often work) and ask family to respect that time.

I hope that helps get you started. Best wishes.

Have a question for the mailbag? Leave a comment or contact me here.

Posted in On writing, mailbag | 1 Comment »

With the first debate tonight (9pm EST), here’s the requisite list of drinking games:

Metafliters list of presidential debate drinking games

Have fun. I’ll be keeping track of any uses of the word innovation :)

Posted in politics | 1 Comment »

Google, as part of their 10 year anniversary, is launching Project 10¹⁰⁰, offering millions of dollars to the best ideas they can find for helping people.

From their FAQ:

What is Project 10¹⁰⁰? Project 10¹⁰⁰ (pronounced “Project 10 to the 100th”) is a call for ideas to change the world, in the hope of helping as many people as possible.

Why is Google doing this? The short answer is that we think helping people is a good thing, and empowering people to help others is an even better thing. Here’s the long answer.

How many ideas are you funding? We have committed $10 million to fund up to five ideas selected by our advisory board.

As best I can tell you don’t need to execute the idea or even have a plan. They are paying for the idea itself. A creative thinkers dream! Except of course you likely lose control over the idea after you win your cash.

Read the full FAQ here. Deadline is October 20th.

Posted in Innovation, Uncategorized, creative thinking | 8 Comments »

Hadn’t heard of this before, but there’s a design unconference here in Seattle this weekend: InfoCamp 2008.

$50 gets you in for two days of DIY sessions on information architecture, user-centered design, librarianship, and information management. According to their description, It features an egalitarian, community-driven format in which presentations are designed and delivered by attendees.

Their website has a wiki, full schedule, blog and info on registration. If you’ve never been to an unconference before and work in design, check it out.

If you’re thinking about running a session at an unconference, check this out.

Posted in Design, Seattle | Leave a comment »

I can’t say how accurate this thing is, but it’s both a great piece of design (By Terry Colon, formerly of Suck), and a polarizing commentary on immigration policy: this will either anger you or make you happy. I know for sure my great grandparents would never have made it through this - Instead of being here writing this, I, like they were, would probably be a peasant farmer somewhere in Eastern Europe.

And here’s the blog post it comes from with it’s own comment thread (Hat tip, metafilter)

What I’d like to see are: 1) similar flowcharts for other first world countries. 2) Similar flowcharts for 50, 100, and 150 years ago in the U.S.

Posted in Design, politics | 1 Comment »

45 days to go. We’ve got wars, bailouts, and natural disaster zones galore. What’s the best way to decide how to vote? Here’s my take on advice for how to pick a president in 1400 words.

Essay #59 - How to pick a president.

Posted in history, politics | 4 Comments »