Speaking of Turds (A Technological Term)

httpv://www.youtube.com/watch?v=yiJ9fy1qSFI

I use the term “turd” often when talking about products, either hardware or software but I’m not always sure people know what I mean.

A turd is something your company “has to do”. Sometimes they sink and sometimes they float, but they are always mandatory.

A turd can be polished and it can be of any shape or size, but at it’s core, it’s still excrement.

Turds always come from somewhere. Sometimes, usually the ones that float, turds come from good things. The right things. Things like user needs, innovation, obvious holes in the market demanding to be filled.  Many times, however, turds come from bad places, these are usually the ones that sink (and stink). Stinky turds come from fear, they come from reactions to competitors, they come from “obligations”.

Everyone makes turds. The iPod Touch is a floating turd. Apple was obligated to make it. How could they resist? They’ve sold a ton because of the branding and the apps and the advertising, so it’s a shiny turd, but a turd no less.

Most (all?) of the iPad “killers” are turds. They are reactionary. They aren’t innovations, they are year late catchups powered by software that went from being something new to a turd the day the App Store launched.

The Facebook platform was, in it’s inception, pretty awesome. It’s turned in to a turd through, what I can only imagine has been, some epic bikeshedding,  beauracracy and abuse. I bet Zuck would kill it if he could, but instead he’s “obligated” to keep it going.

I don’t even think turds are bad. Turds can be great. They can be just what a company needs. But lets call a spade, a spade, or a turd.

Minimalism & The Simplest Thing That Could Possibly Work

One of the core tenants of Agile/XP/TDD/Getting Real/Lean (etc) is doing the simplest thing that could possibly work. TDD says you should write a test and then only write enough code to make it pass. Lean says you should think about “minimal marketable features”. Paul Graham says you should launch just as soon as you have 1 feature that anyone would care about (here and here). Why is this so important? The fact of the matter is that 80% of your users use 20% of your app. That is to say, most people don’t care about most of what you have built. So why build it?

It turns out it’s really hard to know what people want before you make it. There are certainly ways to mitigate it, user observation testing, paper prototyping, but sometimes these things end up taking more time than just doing the simplest thing that could possibly work. In the end, you just need to build it, get it out there and see if anyone cares.

Well, the other side of this coin is that it’s also really hard to limit yourself to doing the simplest thing that could possibly work. You have to say “no” to many things and many people, including yourself, and people just aren’t good at that. No one wants to be the guy that always “puts down others ideas”.

Helvetification

Helvetireader

I’m very happy to be seeing a new trend in web apps, minimalism. I can only hope, that it continues to pervade all corners of software, both web based and desktop based. The tip of the spear seems to be the “helvetification” of popular apps. Some examples:

So what is so interesting about some new skins for some web apps? Is it just that I really like Helvetica? Well, I do like Helvetica, but the really interesting thing about these skins is not that they change the fonts and colors, it’s that they actually hide or remove significant parts of the apps. I’ve been using Helvetireader for probably over a year now, and I can’t stand to use google reader without it. I *hate* what GReader has become. It’s got tons of stuff I could care less about (probably say, 80% of it’s functionality). Starred Items? I use delicious. Trends? Really? And my favorite “Browse for stuff”. Uh, what? Isn’t that what using the internet is? What if Google Reader was the simplest thing that could possibly work? I think it would look like Helvetireader.

But Wait, There’s more!

So how does a couple skins for a couple web apps me that this is a trend? Well my friends, I didn’t think it did until I saw this:

lite.facebook.com

What is this? It looks like facebook, but they’ve gotten rid of all the crap I don’t care about. Lite.Facebook.com is supposed to be a version for “low bandwidth users”, but boy it sure does look like a minimal version of Facebook to me, and I like it. Compare it to say, myspace, and we’re talking Donald Judd levels of minimalism. And have you seen an Amazon Kindle? What about Readability from Arc90 (which happens to be really popular)? All of a sudden, we’re starting to get into trend categories, and I haven’t even mentioned how minimalism is the entire strategy of Apple, 37Signals, Twitter, and Tumblr.

But Features Are Good!

Gist Dashboard

Well, features can be good, but they can also be terrible. Recently, an interesting sounding website called “Gist” launched. What does Gist do? “Gist is designed to help the professional email user who often opens up their inbox only to feel like it’s helplessly out of control” (via ReadWriteWeb).  When I think of designing a site that is supposed to “take control” of something which is in chaos, I think of clean, minimal, organization. I would think that this tool would help me get to inbox zero, where there’s nothing in my email inbox but whitespace and the freedom to actually get my work done. So when I see screen shots like the one to the right, I can’t but help to think, “Is this really the simplest thing that could possibly work?”  This is a site that’s coming out of beta today. Not something that has been around for a decade. How would anyone know where to look, or what any of those boxes do?

Minimalism != the simplest thing that could possibly work

I could give you a bunch of definitions from famous artists and architects about minimalism, but I’m going to just say that minimalism isn’t the simplest thing that could possibly work, it’s when you optimize tsttcpw. The important point here is that it’s important here is that if you do more than tsttcpw, then you’re much less likely to rip out the parts that no one cares about. And I hope it’s apparent that, people want you to remove this crap. They don’t want more features, they want better experiences. They want that 20% of your application to be 100% of your focus, and they want the 20% to get better, not slowly become 18%, then 12%, then 10% because you keep adding crap they don’t care about. Minimalism, whether it’s in design, or any thing else, is taking that 20% and making it 100%.

Agile User Centered Design

Recently, a group of folks (including myself) from AboutUs.org attended a workshop called “Agile Product Design with Jeff Patton“. Jeff is a really smart guy who has been doing some great work to bring Agile software development techniques to the product design and user-centered design fields.

Let’s step back and look at how most software and websites are developed. Companies often start a new software development cycle by having their business people identify a market opportunity. The business analysts and marketing people sit around and come up with either a new product or a feature that they can sell to their customers. Then they get the designers in, who make a “sweet” interface for it. Finally, a big specification file, describing the new feature and how it’s supposed to work, gets handed off to the developers. They’re supposed to make it all work.

This is what software people call the waterfall, because each step pours into the next. There are many problems with this process, but the biggest is that if any of the assumptions made at any one step are wrong, you don’t know until you get to the end of the entire development cycle. You’ve wasted a lot of time and resources.

Another frequent consequence of the waterfall method is that the final product can vary significantly from what the business analysts thought they getting. That’s because there was no opportunity to check back with the business case during the development cycle.

Here at AboutUs, we’ve always used the Agile method of software development. Now, with Jeff’s help, we feel like we’ve got a very cool improvement to Agile that helps us define what we’re going to build, how it’s going to work, and how it’s going to deliver value.

The Product Shaped Hole

©Jeff Patton - 2009

©2009 - Jeff Patton

Jeff’s process starts out by identifying who your customers are. This is user-centered design. At AboutUs, we have identified 14-15 different types of customer who use our site, each for a different set of reasons. We have fleshed these types out into profiles that we call “personas.”

Next we started to identify which tasks each customer type wanted to perform on our site. These tasks range from “logging in to edit,” to “reviewing recent edits for abuse,” to using new features we are still developing or would like to develop.

We can take these tasks, turn them into “stories,” and build a “story map” that describes the personas and their activities. Our business goals govern the entire process. They tell us which personas matter, and therefore, which tasks matter. That in turns informs every development choice we make.

marked_up_story_map

So what’s really cool about this story map is that it’s a physical object that everyone can see. It reminds us continually of our business goals and the people who use our site. It governs everything we do, right down to each small, actionable chunk of software, and each of these becomes its own particular story.

Some of these stories have been delivered — our site does lots of stuff already — and we still have plenty of stories we want to complete this week, next month and within the next year.

The coolest thing about this story map is that it’s still alive. You can see what’s done, what we still want to do, and, if you’re the type to read between the lines, what we haven’t thought about. And it’s those unfinished and unthought-of stories that are the “product shaped hole.”

This isn’t a complete description of Agile user-centered design. I haven’t covered paper-prototyping, sketchboarding, walking skeletons or other cool techniques. But story maps have really changed how I think about software and Agile, and it’s going to change how we build things at AboutUs.