flights

I might expand this into a larger article at some point, but for now it’s just something I decided to cobble together for a quick post. Thinking about data visualization was a big part of my job at Scout Labs, and this represents my palette for expressing data in picture form.

	Since color consists of three factors (hue, value and saturation), it’s three for the price of one from a data visualization standpoint. Hue can communicate difference, but value and saturation can communicate other dimensions - like degree of difference. Color is tricky though. You have to be careful to accommodate colorblind people and black and white printing.
	Size is good for expressing one dimension of difference between things. It suggests something quantitative. If precision matters, then it’s safer to vary size along just one axis (e.g. length). Studies show that people are bad at judging area and angles. They can tell when one line is roughly twice as long as another, but they’re wildly off when they try to guess the exact difference in area between, say, two adjacent circles or two sections of a pie chart.
	Shape is a good way of creating very basic distinctions between things - or classes of things. It works well, for example, in scatter diagrams and other visualizations that plot data in two- or three-dimensional space.
	Decoration is good when you want to make an item or a small subset of items stand out from a larger set. Decoration can be more or less subtle, so I like to use it to represent variation as opposed to difference.
	For position to mean anything, it helps to have stable reference points - like x and y axes (i.e. a grid). Meaning is expressed by the position of objects relative to each other of course, but more importantly it’s expressed in the position of objects relative to the axes.
	Motion can be a powerful way to add directional nuance around things like trends, or to wrap in concepts like velocity, but the biggest drawback, obviously, is that motion isn’t possible on paper and needs to be translated into something else.

Obviously these aren’t mutually exclusive. People are capable of grokking a number of concepts from a single visualization, so I usually combine dimensions from the palette. Sometimes I combine things just for efficiency - to get more out of each pixel so to speak. More often, I combine things when I feel like they make sense together.

For example, I might use hue to represent positive or negative sentiment in a product review, saturation or value to represent the intensity of the sentiment, and size to represent the reach of the source.

Please indulge a moment of self-pity…

I know a designer’s job isn’t rocket science, but that doesn’t mean everyone is qualified to make design decisions. Unfortunately for me, that doesn’t ever seem to stop people.

Why do they call these things “circulars?” The word makes me think of my mom, clipping coupons from the Sunday paper for the weekly trip to the Shop-N-Bag.

Anyway, this one came in the mail from Target. I usually toss these things right into the recycling bin, but I thought it was pretty clever.

I used to love flip books as a kid. I even made one once, as a Christmas present for my younger brother - a mix-n-match sports thing where, for example, you could put a football player’s head on a baseball middle and a pair of hockey legs.

Anyway, kudos to Target for having fun with something so everyday. You actually got me to look at all the coupons as I played with different face combinations.

I can barely remember now, but before the age of MapQuest (and, subsequently, Google Maps), if I needed to go somewhere I’d never been to before, I rarely planned my route. If, for example, I wanted to go to a furniture store in a suburb on the other side of town, my process went something like this…

1. Get in the car and start driving in the general direction of my destination.
2. Once in the general vicinity of the destination, consult a map or get exact directions from a knowledgeable human.

This makes perfect sense to certain kinds of people, but various of my friends and past significant others found it absolutely maddening. How can a person get in a car and start driving if they don’t know exactly where to go?

I was thinking about this today in the context of product development. Recently, I wrote about the value of “process,” and I think this makes for a pretty good analogy.

The Web is a very forgiving platform in the sense that building things for it is very easy, and making changes is often trivial. It’s all just pixels and code. I love this because it allows for experiments and mistakes. It encourages mistakes, because you can learn and adjust so quickly.

I have no problem putting something imperfect into the hands of the crowd and then watching it to see how and where it falls short - within reason. If the breaking of something will result in loss of life, or a lot of money, I’m very very careful of course, but such situations are rare.

I have no “brand” to protect - or, rather, a willingness to experiment is consistent with my “brand” - so this is easy for me.

What’s really difficult sometimes, though, is to get clients and stakeholders to feel comfortable with things unfinished and imperfect. Companies are understandably careful about everything they unveil that has their mark on it. When careful goes too far, however, one pitfall is a culture of fear, where people are afraid to make mistakes or deviate from what is safe and known and familiar. This is the same kind of culture where people are unwilling to deliver bad news to the boss.

Not to venture too far into another analogy, but I once had a music teacher say to me, “if you’re going to make a mistake, make it loud.”

I love this philosophy, but to make it work for a company or a client requires certain controls. Some options are…

• Brand it with beta. This is a popular Web 2.0 approach. Just put a “beta” badge on it, and people will know it’s a work-in-progress.
• Launch a laboratory. Google and Digg have pretty nifty public ones.
• Encourage your employees. There’s no encouragement like time and money. Google, again, is the obvious example. They famously encourage their employees to use 20% of their time to work on side projects. Some of these - like Gmail - have become key parts of Google’s portfolio.
• Limit exposure. Create a panel of people with whom you can share your wild ideas and works-in-progress. Or do live A-B testing, where the experimental stuff is only put in front of people who meet certain criteria.

That’s four ideas, and there are certainly lots more, so get in the car and start driving. Make loud mistakes.

The guys at 37 Signals have a list of what they call “red flag” words that often come up in business communications and can get teams into trouble. Words like “only” and “can’t” (as in, it should only take you a day to add this feature, and we can’t ship the product without it) lead down rat holes of feature creep and finger pointing.

For me, one of those red flags is “what if…”

What ifs are the sparks that ultimately generate every interesting, fresh, unconventional idea. They are the stuff of all the brainstorm sessions and experiments that characterize the really exciting parts of the product development process. What ifs produce ideas, and ideas are easy, so when a team is in the slog of getting things done, it’s hard not to get way ahead of them with lots of big and interesting ideas. You start to anticipate every possible scenario and edge case. You think about ways your product might tap into new markets before you’ve even addressed its core market.

Ideas are also impatient. They pile up behind the older ideas, and they push and they push until a few get through. And then a few more, and a few more, and while you may have started with something simple, you now risk ending up with this:

(Click thumbnail to enlarge. Photo courtesy John Maeda)

On the other hand, what ifs can be part of a sanity check. Asking “what if…” can be like hitting the pause button, allowing you to step back, size things up and gauge whether they’re on track. What ifs can also help you subtract and simplify. It’s a great exercise to look at your ideas and ask, “what if we got rid of…” and “what if it just…”

I think the “It’s about time” clock is a great example of this kind of thinking:

These guys asked themselves how many people really need precision around what time it is and effectively said, “what if clocks only told you what you need to know - in plain English?”

This isn’t to say that thinking small is always better than thinking big. Each has its place, but either way, “what if…” is a phrase to look out for in business communications. When you hear it, make sure it’s leading you in the right direction.

The state of Texas recently held an “e-vote” to choose a new license plate design. There were five designs in the running, and over 450,000 people cast their vote for the worst one. Just my opinion, but Design Observer agrees with me.

This always seems to happen when design meets democracy. Letting the masses into the design process always leads to cluttered, overdone hodgepodge or bland, predictable treacle.

But there’s an obvious paradox here. Namely, if we are designing for these same masses, then who are we to say their opinion is wrong? On what basis can we defend what we consider to be good design?

In my post yesterday, I questioned the value of “process” in web and software development and discussed my successes and failures both with and without it. The biggest problem with process is that it deludes people into thinking they have the fundamentals in place to guarantee a successful project. Process is too often a crutch in this way.

Over the course of decade and a long list of projects, I’ve worked with variations of waterfall, agile, RUP and other methodologies, and I’ve also done my share of winging it with no formal process at all. Process or not, I’ve learned that the successful projects I’ve worked on all had certain ingredients in common. Namely…

Smart people.
This is a no-brainer, but a team of smart people is key because smarter people work faster, make fewer mistakes and are able to adapt to unforeseen changes. All it takes is a one weak link, however, to cause things to break. You can’t rely on smart people alone.

Leadership.
A film has both a producer and a director. A restaurant has a chef, a manager and a maître d’. People need freedom to lead their respective domains, but smart people inevitably disagree with each other, and smart people without a recognized leader is a recipe for scope creep in the worst possible way. Everyone wants to put their best work into the mix, and a committee approach encourages quantity of ideas. Ultimate power needs to roll up to a single, clear authority with the tools to make good decisions and resolve conflicts within the team.

Constraints.
Frank Lloyd Wright once said, “Man built most nobly when limitations were at their greatest.” Jason Fried of 37 Signals says, “Embrace constraints.” Artists recognize that constraints help focus one’s creativity. In web and software development, constraints usually come in the form of hard deadlines or agreements around scope (often a bit of both). But constraints must be balanced with “a healthy disregard for the impossible,” as Marissa Ann Mayer - VP of search products and user experience at Google - put it. Innovative ideas by nature will often push at the very edges of constraints, so there should be some flexibility. The key to balancing constraints with a “disregard for the impossible” are good filters for managing new ideas. Which brings me to…

Filters.
You don’t want to discourage innovative, unconventional ideas, but you need some way to filter them. The same goes for the more typical dynamics that lead to scope creep. Stakeholders second guess their decisions. Important customers complain about something or make specific requests. Some jackass in a meeting spouts off about some edge case, and boom… more stuff to cram into the project. Leadership (see above) is important here, and so are constraints like deadlines and scope. New ideas mean an increase in scope, which means moving the deadline. Either that, or something already in scope drops out. Each incoming idea needs to be considered, scoped and prioritized against everything else. Edge-case thinking just needs to be stopped. This is what I mean by filters - a change-management process that the team leader needs to enforce. Too often, outside ideas are subject to this process, but ideas originating within the team get a free pass. Filters need to apply to everyone equally.

Simplicity.
This is its own kind of filter. The team and the stakeholders need to understand the essence of the thing they are building. They need to look at it holistically and know what it needs to do in order to be considered complete. It’s important not to look at features in isolation, because this encourages people to explore every possible expression of every nook and cranny of every feature (edge cases again). Instead, the team needs to determine only what is essential to each feature as it relates to the whole. Finally, the team needs to understand that the product can grow and evolve after it’s launched, so “complete” doesn’t mean perfect.

An understanding of “X” factors.
I mean “X” as in multiply. There is a list of things that add risk to a project and multiply its challenges and complexity. I’ll discuss these in detail in a follow-up post, but among them are:

• nature of client
• size and “spread” of team
• complexity and novelty of the thing being built
• time between designing and building
• depth of QA
• distance - with regard to both time and personnel - between deployment and maintenance

Good Tools.
Smart people can survive with just email and whiteboards. That might be the bare minimum, but I’ve had good experience using wikis and simple PM-ware like Basecamp.

Padding.
Because shit happens. A good project manager knows it’s necessary to add 50% to every individual person’s estimate of time and effort, and then add another 20% or so across the board for good measure.

A good contract.
Too many contracts are essentially crafted by BD people who don’t understand what a project will really take, and who don’t have a vested interest in whether it actually succeeds. Too many contracts fail to consider the “X” factors, or encourage constraints, simplicity or leadership.

Transparency.
Otherwise known as communication. But “communication” is a cliche, and every team thinks it’s doing a good job communicating to stakeholders. The bottom line is, stakeholders need a strong consensus around the essence of the thing being built. They need to understand the change-management process (filters), and they need to see steady progress.

Even knowing all this, I’ve still worked on projects that have gone awry. But it has always been because we failed to follow something on this list. The good news is, when a new project starts to take a southward turn, I just take an inventory of the ingredients above, and when I identify what’s missing, it’s usually not too late to put the project back on track.

UPDATE: There’s a Part 2 now.

When I started in the web development business about a decade ago, I worked at a small agency with a few smart people, and we were basically winging it. As the dotcom bubble expanded at a frenzied pace, we grew along with it, and inevitably we had a couple of projects take sharp turns south. People suffered on both sides, and it became clear that winging it was not scalable.

We needed a process - one we could articulate to clients, propagate through the organization and of course put into action in a repeatable way.

This is what “process” is supposed to do. It exists to mitigate unpleasant surprises by telling stakeholders what they can expect from a project. It’s also supposed to save teams from continually reinventing the wheel.

I worked with my bosses at that first agency job to define such a process, and we were very proud when it was complete. Some months later I left that job for an agency on the West coast. As it happened, I arrived just as this company too was in the midst of a campaign to define a process. People from every part of the agency worked on it for weeks, and the final product was a lovely thing to behold. We made posters for the office, and glossy booklets to give to would-be clients.

My next company - a large telecom - used a version of RUP that was the most over-engineered process I’ve ever experienced. When they laid me off, I returned to the agency world. I worked for two of the biggest interactive agencies, and both had processes that were beautifully-rendered in company collateral.

It might not surprise you to learn that all of these processes looked pretty much the same on paper - characterized by big phases with catchy labels. In fact it was only in these labels where the various processes really differed - one company’s “explore” is another’s “discover.” Even the language the agencies used to sell their respective processes was the same, with a lot of emphasis on words like flexible, adaptable and proven.

Finally, it’s worth adding that all of my agency work was in the service of clients who had their own processes, so at one time or another I’ve had to use variations of waterfall, RUP, agile, spiral and triple lindy. Kidding about that last one.

They all share similarities, but the really striking thing these processes have had in common in my experience is how quickly they broke down and became meaningless when put into practice - even by solid teams of nothing but smart people.

I had been a big believer in process, but because of repeated failures I eventually came to see the whole idea of “process” as a fantasy designed to woo clients and placate bosses. I began to believe that assembling a small team of really smart people and simply allowing them to wing it is the right approach after all.

At the very least, this approach doesn’t raise false hopes. If projects are destined for chaos or collapse, isn’t better not to expect them to go smoothly in the first place?

I’m joking of course. There are many reasons projects go south, and there are many ways to help make sure they don’t. Working within the framework of a heavy duty process is not the solution, but having no process at all amounts to blind luck, because successful projects depend on the right mix of a whole range of ingredients that aren’t likely to converge if you’re just winging it.

This is starting to run a bit long, so I’m going to push the rest to a sequel. In Part 2 of this series on process, I’ll talk about the ingredients that need to converge to make sure projects go well.

Came across this fun design exercise via the xblog today. My entry is above. Instructions below:

1. http://en.wikipedia.org/wiki/Special:Random
   The first article title on the page is the name of your band.
2. http://www.quotationspage.com/random.php3
   The last four words of the very last quote is the title of your album.
3. http://www.flickr.com/explore/interesting/7days/
   The third picture, no matter what it is, will be your album cover.
4. Tag it on flickr “CD Cover Meme”

Voila! Instant music career.