Puffins!

From a recent trip to Maine (gallery now posted here)...

Let Your Designers Design!

We all know now that good design is a crucial element in a crowded market. But just because people in your company have strong feelings about design, doesn't make them good at it. Some of their ideas may be good, but that doesn't make them good at executing either. In the worst cases, they both think they have good ideas and think they can execute, and they can do neither. (Remember, incompetent people don't know they are incompetent.)

Signs of the problem in your org:

1. You have designers on staff, but they're demoralized and frustrated. Designers are a special breed of person, more likely to leave when they can't accomplish what makes them tick than many others; they're driven by their skills and talents more than promotion opportunity inside a company or a domain in which they work.
2. Consensus-driven culture has ground projects to a halt. You can't break out of decision-making meetings with a clear goal, and there are too many cooks involved. Because the designers aren't empowered to make the final design decision, and other (incompetent) people are weighing in or fighting with them. (See Scott Berkun's recent take on this, and an old take on why products don't end up usable that covers all this organizational stuff too.)
3. You may have a lipservice executive level belief in design as important (ever since Apple made it profitable), but you have no headcount for it, and no org process for it. There are no goals in the marketing pipeline that focus on it, there are no metrics to measure it, and it's no one department or person's job. It's handled diffusely, and not managed effectively.
4. Secretly, you or other middle-level managers think design is a technical thing, or the "fun" part for the technical folks, and it's best handled by developers as a kind of prize for the good ones. Don't bother trying to hire in this climate!
5. Final decisions about what gets in the product and what's shippable are based on criteria or opinions that don't know much about how customers respond to your stuff. Bugs that in a one-in-a-million system configuration cause a crash are prioritized about correcting a layout problem that makes you look amateurish, or a typo that makes you look like a busload of idiots.
6. You think it's all about the documentation - the customers just need to read more.
7. You outsource all of your visual design, and that's what you mean by "design" anyway.
8. You didn't realize people get degrees today in usability, human factors, interface design, interactive design, etc. In these degree programs they learn the correct ways to collect and interpret data, deliverables that communicate at different levels of fidelity, how to go from abstract to concrete, how to validate designs, and how to prototype. Corollary: You also think design is work that's "obvious" and easy, probably also because it doesn't involve writing (much) code.
9. You don't have actual project managers on your staff. You make it someone else's job, usually a development manager's; this means design as a phase and design deliverables are not scheduled and monitored in the way that code production is. Instead, it's all "where's that damn spec, we need to start making this thing."
10. Your designers are actually trying to steal the project management, so they can get some control over the process, but this is leaving them too busy to actually do design. They schedule meetings to get stakeholders together, they try to get the PM's to articulate what the heck the requirements are, they hire visual designers, they call customers... they never actually get to design, except after hours.
11. You've got innovation projects going on in your company, but there aren't any designers working on getting things right from the start. (Chances are, they are too busy with 9 and 10 to be contributing even if invited.) But basically you feel that design is "icing" to make it look pretty after the big ideas are implemented. You think the real breakthroughs come from technical ideas, not ideas that come from watching people work or new interaction techniques or novel workflows. Never mind how expensive it is to get requirements wrong up front and have to "fix" things later. (There are any number of software studies on this, drop me a note if you want refs. I've seen startups go under from this, before they even got out the door with their product.)
12. You've got internal folks like usability testers who are told they "facilitate" group processes but aren't empowered or able to make overruling design decisions. This is explicit support for consensus design or committee design, dangerous when everyone else is opinionated but incompetent.

Okay, I admit it felt good to get this list off my chest today. It's not the last time you'll see the subject cross this page. Let's hear it for design moving up the org chart; and for middle management and technical management understanding there are skills that might help with product big picture and end-game success!

Photos of Venice, April 08

I am finally getting these together - a sample from the week in Venice in April. There are a few unusual or creepy ones, because Venice can be rather weird, as well as the more typically touristy shots. Also notice how much laundry - why is it prettier in other countries?

Consulting References (How-To and Advice)

Having just finished a talk at the Boston MiniUPA conference on setting up as a consultant (an honest tell-all), I have collected a handful of references I wanted to share here. They're not necessarily the obvious books/links on consulting, but they informed me in one way or another.

• The Four Hour Work Week, a book by a crazy man that nevertheless gets right to the heart of your time usage and accounting for starting and running a business. Some good tips in it for testing out new business ideas on the Internet, and advice on kicking out your worst customers and clients who abuse your overhead.
• Getting Started in Consulting, by Tim Weiss.
• Talent is Not Enough: Business Secrets for Designers, by Shel Perkins.
• How to Be a Rockstar Freelancer, by the founders of FreelanceSwitch.com, a great resource site for design consultants. This is available as an ebook on their site for $29 too.
• An article from Salon, "What Every Freelancer Should Know." Especially the part about taxes.
• Some sample contracts for freelance work to modify, especially the engagement agreement to have a client sign.
• A few articles on borderline-bogus IT consulting pitches and firms, starting from Scott Berkun's The Problem(s) With Consultants (he is himself one, but more of a writer/speaker these days), Cringley's Truth About IT Consultants, and The Half-Truth About Consultants. Don't be one of these kinds of consultants.
• My observation on consulting is that a lot of jobs and clients are difficult, in that what they want is often not what they need or what you should do for their project success, and sometimes you need to cut that job down to manageable from a business and project perspective. Or cut it off entirely, if it's costing too much in unpaid time and stress. See the excellent (and funny) 12 Breeds of Client and How to Work with Them. Applicable to people who work inside organizations for multiple stakeholders, too - common for designers.
• FreelanceSwitch's 101 Essential Freelancing Resources.
• MOO Cards - these little suckers thrill everyone who gets one, you've got to have a lot on hand!

Finally, I've put my own slides up: "So You're Thinking About Consulting?" (pdf). They won't necessarily make full sense without the talking parts, but I'll be running a half-day workshop on how to get started in consulting co-taught with Greg Raiz of Raizlabs this summer. Stay tuned!