It is truly one of my favorite design “tools:” A good notebook. Personally, I like the full size Moleskine models, but whatever you can manage to carry around will work best. I carry mine everywhere with me, always with a pencil attached.

Check out these notes, if you dare, which preceded my recent talk with Jeff Patton at Interaction08.

Here’s a first page of general notes about what could happen during the talk.

The crux of my thoughts here is that many Designers, Interaction Designers included, don’t really tend to think about software development methodologies in their day-to-day life. Thus, they may need a little brush-up on what a development methodology is, with some examples.

Still, it’s important for IxDers to understand why software is developed the way it is in their organization, and to be a stakeholder in this process.

The prevalent development methodology in use today is waterfall. It should probably look familiar to most designers & developers.

With Agile Methodologies, we have the opportunity to get our software working, and out in the real world quickly. This allows our concepts to see the light of day, so that they can be improved upon. Of course, these methods do have their drawbacks…

Some snapshots of what agile methods look like.

So, the big question is whether Interaction Design methods can fit within the Agile Context, or vice versa. The answer to this is complex, but I think the talk covered the topic well.

Back to the point — Sketching really helped me sort out these topics in my head. Sure, it took longer than just bullet-pointing out a PowerPoint…but I was able to visualize my thoughts, and look at them later with clarity, and pass them on to others to digest. Visualizing my thoughts really helps my process, and maybe it’ll help yours too.

How do you visualize your thoughts?

The greatest lesson I learned at Interaction08 last weekend was from Bill Buxton, during his keynote talk. Here’s his list of things that, as a designer, you must know:

1. What makes you distinct.
2. Your value lies in your distinctiveness.
3. That makes you a minority.
4. There will be pressure to conform.
5. Your value is lost in assimilation.

Also, he made sure to counter Don Norman’s feeling by saying emphatically, Everybody is not a designer.

Great stuff. Can’t agree more.

As I’ve mentioned before, election night is one of my favorite nights of the year. All the big media outlets pull out their infographic design “big guns.”

One of my favorites for the Super Tuesday 2008 Primary results is at the New York Times:

It simply describes the current situation in the largest states that vote on Super Tuesday. I can quickly tell what percent of precincts are reporting, and know instantly which results should remain stable. One thing that I find a bit strange about this graphic, however, is the fact that the states are laid out in alphabetical order, rather than a more informative order. My preferred order would probably be a descending order starting with the state with the most delegates. The alphabetical order has led me to ask myself the question, “Why didn’t Obama focus more on the states following ‘I’ in the alphabet? And likewise, how come Hillary focused on ‘M’ through ‘Z’?” Strange coincidence.

Now, for a little compare and contrast, check out the live results from CNN.com’s homepage:

This graphic just seems to be lacking a whole lot of substance. Unlike the NYTimes graphic, it’s hard to abstract the big picture. We don’t know as much without looking a little deeper at the numbers. They even went out of their way to include a legend in the bottom right, as if we didn’t know what the check stands for. There is also very little contrast between the state abbreviations and candidate names. The state abbreviation is only one pixel larger than the candidate name, certainly not enough to denote a difference in meaning (most people won’t notice they are different sizes at all).

Finally, just for good measure, let’s have a look at NPR.org’s entry:

The information that NPR adds here is the closing time for the polls in each state. I don’t know if this is really all that important. Really, what most people want from a graphic like this is to find out who is winning in each state. A nice addition is the number of delegates committed from each state. I would have liked to see these numbers tallied up at the bottom, because that’s what this race is really all about. Also, this graphic makes it somewhat difficult to tell if there is a clear winner on either side. For all I know, McCain and Huckabee might be neck-and-neck (which they’re not). Overall, not bad.

My personal fav is the NYTimes graphic, but judge for yourself. I’d love to hear (and see) your favorite Super Tuesday infographics. Send me a link in the comments.

Apparently, my battery is dying. As you can see in the photo, my computer is proudly displaying the fact that my battery is “reaching the end of its usable life.” I’m not sure what that means, but boy would I like to know more.

Unfortunately, when I click on that little weird box that does not look like any other information dialog on my computer, it simply disappears. Is this Dell warning me that something really bad is about to happen to my battery, or are they just giving a simple nudge that maybe the support team at work should ship me a new one, on the double? Alternatively, is this a sign of malicious activity on my machine?

Well I just don’t know. Weird little non-modal appear-at-random-times popup friend, who are you? And what do you really mean to tell me?

The holidays are over, folks, time to head back. Keep your heads high, it’s a new year. Let’s do this.

So this evening I’m reinstalling Java. Not by choice, but because the annoying little balloon keeps on popping up in the corner of my screen. Then, while it’s installing, the installer has the audacity to say something extremely stupid like:

By installing Java, you will be able to experience the power of Java…”

NO WAY! That is AWESMOE*! Well thank you very much Java, for allowing me to experience the power of JAVA!

Alright, maybe I’m being a little hard on these designers…but seriously people, words matter! By putting silly little mistakes like this into an installer you’re immensely hurting your credibility. In fact, if I didn’t know better I’d think this might be a virus written by a kid in his basement, not a development platform backed by a company with nearly 35,000 people.

So, Sun, how about a little fixer upper?

* Awesmoe = Awesome to the power of 10

Alternatively titled: On Covering Your Ass

Check out that picture on the right. That’s from my credit card’s website. My favorite part is the red link on the bottom that proclaims, “See fewer choices.” You know what that option is? That’s a designer or usability person saying to the team, “Hello team, we have heard from users that there are too many choices on the screen.” Then the usability/design person recommends that we prioritize the options on the screen and progressively disclose them so that only the most used choices will be shown up front.

Then someone on the team shouts, “But we can’t remove links that are already there! Users will haaaaate that! Maybe we can just put an option to ‘See fewer choices,’ that way we can make everyone happy!” The designer/usability person shakes their head in disapproval. What the team did in is take the easy way out. Rather than analyzing user needs on a deeper level and getting an understanding about what choices are valuable at each point in time, they simply put a link to “See fewer choices.”

Lazy, lazy, lazy.

Building usable tools is about more than giving the user exactly what they ask for. It’s about designing for needs…needs that the users themselves can sometimes be blind to. It’s about thinking deeply about problems, and crafting creative solutions based on data (that has been gathered from the real world of the users).

Let’s work a little harder to make better software, shall we? I shall. Who’s with me?

One of the greatest things about being in Israel is the abundance of amazing hummos places. These small restaurants sometimes serve foods other than hummos, but many times it’s the main course. The hummos here is different than in the US. It’s smooth & creamy, with actual garbanzo or other beans in tact.

Of course, as a tourist I have found myself in a number of the highest quality hummos places here. Places that can be compared to In-N-Out burger in California…there’s always a line and they never disappoint.

But if you come in after 1 PM, you might not get any food at all.

In the morning, the restaurants make a good amount of hummos. When they run out, the restaurant closes. The owners know that their product is amazing, and they know they could sell just about any amount that they make, but they don’t. This is amazing to me.

This is a mindset one rarely sees in the US. The common line of thought is that if you’re selling out today, then tomorrow you should sell out more. The thing is, the fact that these restaurants sell out every day actually helps their brand. People are willing to stand in line in the heat, and come earlier than they would have liked…just to have some of that great hummos.

Anyway, this was an inspiring situation to me. A business that strived not just for money, but for balance as well.

Whatever happened to clear, consistent language? Why do we use words that have inconsistent meaning in contexts where they’ll be unfamiliar? Why, oh why?

Day in and day out I work with clients in an Agile development setting. I use words that have been trained into me, that I’ve been taught over and over again. But when I sit back and think about these words, they just don’t make sense. Let’s look at two of my favorite examples. First, some standard definitions:

Story - the plot or succession of incidents of a novel, poem, drama, etc.

Narrative - a story or account of events, experiences, or the like, whether true or fictitious.

Sounds pretty familiar, no?

Well in Agile these words take on a whole new meaning. A story is the encapsulation of some sort of requirement, based on a given user’s needs or wants. It generally takes the form of:

As a [user]
I’d like to [some action]
So that [resolution of need]

But wait, is that really a story?

A narrative is the document that describes this story in detail. Chock full of high level objectives, UI prototypes, test cases, and other minutae. If you asked a person on the street what a “narrative” is, there’s no way they would describe it this way.

So why do we insist on using these terms, with their off-the-mark definitions? I don’t know. They probably seemed all cutesy and different at the start, something that sounds fun and light when compared to heavier terms like REQUIREMENTS DEFINITION DOCUMENT. When it comes down to it, “Story” just sounds less beefy than “Requirement.”

Damn Agile, You Just Stole My Words

Aside from the simple misappropriation of terminology, I have a bigger issue with the use of these terms. In the Design world, “Story” and “Narrative” have real, relevant meanings that align with the standard definitions of these terms.

Both of these terms are used to describe, in detail, a user’s experience, either today or in some envisioned happy future. The Narrative is generally a more detailed version of the story, which includes a narrated scenario in the context of the tool’s use.

I might be splitting hairs, because I think the Agile use of these terms tries to get at the same thing…but they just don’t. An Agile Narrative generally doesn’t tell a real story in detail, it describes a requirement in detail. Likewise, an Agile Story describes a requirement, not a user’s journey.

In Conclusion

We have to be careful with the words we use. In the end, we’re all trying to build software that solve real human problems. Surrounding these problems is real human drama that can, if described well and designed for, be turned into happier situations. I believe the use of words with alternate definitions muddies the water, but certainly doesn’t get in the way on a day-to-day basis.

Whatever words we use, we have to be sure that our solutions fit into the contexts of our users. We must ensure that our software fits into our users’ everyday stories.

This evening Kynthia’s thoughts got me thinking. Among other things, she said:

“[W]e design heads get in this place where, just because we wouldn’t be caught dead releasing something into the wild, we think there is nothing to learn from it.”

My brain took her thoughts on a tangent and went this way:

So since I started my job at ThoughtWorks, my role has pretty much been defined by this exact issue. See, we use agile development methods, which often means that the stuff I’m designing might be built tomorrow, or at the latest in the next few weeks, which leads to some pretty interesting questions, such as:

• If I had to hand over my design in the next [time limit], what would be the most important part(s) to get across? So what should I spend my time on?
• How can my design(s) make the greatest impact in the short run?
• How can my design(s) be flexible enough that they’ll support more advanced interactions and further redesign (without simply adding features) in the long run?
• How much does my design cost, in terms of real dollars and development time? Is there anything I can do to make it less expensive without hurting the users (too much)?
• Will the brilliant, awesome, amazing design I’ve just created embrace change if it turns out users really don’t like something about it? Or will it fail miserably…which might be a good thing if it motivates the product owners to spend more money to fix it.

Indeed, I believe us “design heads” need to wrap our brains around the idea that the “ideal design solution” can be super-difficult, and sometimes impossible to implement, if for no other reason than the person with the money doesn’t feel like splurging for a great user experience. Given this situation, it’s important that we release our ideas into the world early and often, even if they aren’t perfect. Putting our ideas out into the world lets them get stomped on, beat up, and improved to the point where while they may not be ideal, they’ll at least be better.

Iteration, baby, that’s the name of the game. It turns out when we designers draw and write and specify and prototype and mock-up our designs in our oh-so-ritualistic way, we end up with an unintended by-product: intimidation. See, even if our brilliant, perfected ideas aren’t intimidating to the teams of programmers that have to build them, they’ll often be super-intimidating to those who have to pay for them. See, the more realistic/difficult/etc. our designs look on paper or other prototyped form, the higher the perceived cost. Let’s look at a formula to really help this sink in:

C(p) = -I(L)

Now, I haven’t taken a math class in years, so that formula probably means nothing at all. Ignore it for now. What I mean to say is that the higher the perceived cost, the lower the likelihood of implementation. This all seems pretty simple, and it is, but sometimes it’s hard for us designers to break away from the idea that we need to perfect everything about our concepts. In fact, when we do this, it can be to our disadvantage.

Oh, and don’t think we’re not intimidating ourselves either! When was the last time you decided not to take on some project just because you knew it would take too long to really “do it right?” Yeah, it happens to me all the time too. We designers know how to intimidate ourselves as well.

So rather than perfecting, why don’t we try biting off just a little bit at a time? Design in terms of small, implementable, simple solutions to the problem at hand. Then expand on the concepts, and build them all the while…just a little at a time. Sure, some of that implementation will have to be redone as you go, but if it truly improves the end design, do it.

Of course, when you’re designing and building an enterprise level application, there’s a lot more structure and process that has to be involved in design, but I think for Kynthia’s case, an Agile development process is somewhat ideal. It gives you the opportunity to take a stab at a problem, implement something simple, learn from what you built/pondered/etc., and iterate.

Anyway, sorry for taking your thoughts on a tangent, Kynthia, but thank you for getting my brain cranking this evening.