I’ve long held the opinion that it’s important to think long and hard before upgrading to new technologies. Often a single technology purchase causes a daisy-chain of purchases, as illustrated below:

Nintendo Wii > Big, giant, flat TV > Cable > Premium Channels (Total upgrade cost = $250 + $1,000 + $60/mo + $10/mo = More than $1,300, plus a contract with the cable company…)
or

Apple Macbook > New Case + Parallels + Windows Vista > Software for both operating systems (Total upgrade cost = $1,600 + $40 + $80 + $200 + $500 = ~$2,500)
and my current quandary:

Blackberry Pearl > Bluetooth headset (& other devices) + Mobile Internet Subscription + Media Card

The thing is, I’ve had my current phone for more than 3 years. It’s getting dated, but it still works well and does pretty much everything I need it to. Well, at least it does everything I’ve become accustomed to needing. Other than weighing pure costs, the most important thing I do before buying a new technology is ask this simple question:

How will this technology change my life?

It’s important that I understand this, because if I don’t think about it then I risk throwing money away on crappy, needless technology. It’s more than just thinking about the technology’s features, but about how those features will impact my daily life. So, let’s run through this question, applied to the Blackberry Pearl. So, how will the Blackberry Pearl change my life?

Positives:

• No need for a separate iPod or similar device.
• The Pearl’s media card holds music, and my headphones will fit in the phone itself.
• No need for a separate digital camera.
• Well, that’s not entirely true, but the Pearl does have a 2 megapixel camera…which is good enough for most point and shoot needs. The real question is, will Verizon lock these pictures on to my camera, or allow me to easily and freely transfer them to my (or others’) computers?
• Email from anywhere
• I’ll be able to get my Gmail from anywhere…on the train or walking down the street, or even at a client site that doesn’t allow me to check personal mail on their network.
• Chat from anywhere
• Same as with email, but I’ll be able to chat with people from anywhere.
• Internet capable
• This could be life changing. If I can use the internet from anywhere then I can do tons of other things. I can check competitive prices while I shop at target, or blog from the street corner. This could make life very interesting.
• GPS directions mean I’m less likely to be lost
• I’m using up to date technology
• This might seem like a minor detail, but I think it’s pretty important for someone whose job it is to design experiences based on technology. It’s important for me to know the potential of the current devices and tools, and I have to admit that my old phone doesn’t really allow me to do that anymore.

Negatives:

• Who wants or needs to get email all the time?
• I certainly won’t be hooking this up to all my email accounts. The last thing I want is some device to vibrate for each email I receive all day…
• “Crackberry” potential
• I also don’t want to get hooked to this device. I’ve already got my face in front of a computer screen for a majority of the day…the last thing I need is to be addicted to another screen.
• It’s not an iPhone (or Google Phone).
• ‘Nuff said.
• I’m not sure if it will play nice with my mac…
• Can it sync up with my web-based stuff like Google Calendar? I guess maybe I can just view gCal from the browser?
• Big one: Once I advance to this technology, will I ever be able to go back to living life without? This has a little to do with addiction, and a lot to do with how the phone will change the way I do things. What if I’m at a point in my life where I can no longer afford to pay $80/mo for phone+internet service? Will I be able to go back?
• Extra $40/mo for mobile internet is pretty steep… (though work will cover it)

I’m sure there’s more, but for now I want to put this out into the world and see what you all think. Should I make the upgrade? Take the leap? Jump into the abyss? Or not?

Please weigh in in the comments…

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 most difficult expectations for me to overcome with respect to my coworkers is the idea that I’m here to simply make the software look pretty. It’s difficult for so many to understand. I do understand principles of typography, layout, color, and design in general…and yes, I do have the ability to decorate an app to make it seem “prettier” to the untrained eye.

The thing is, I’m not necessarily here to apply typographical, layout, color, etc. changes to a system. Before that can happen, the tool has to have a logical flow. Input fields that are displayed have to make sense. Everything that has been placed on the screen up to this point must be there for a reason. I take it as my first job to understand exactly why you’ve placed that input box above that drop-down menu, for example. Sometimes this part of my job is easy. Other times it is not.

My point is that I will not (and cannot) make your system look nice unless the basic interaction part is already taken care of. In fact, having a cordial interaction with the user is core to the system looking nice. Sorry to burst your bubble, but the colors themselves don’t matter if the user can’t figure out what he’s supposed to do.

The UI needs tending, and it can’t just be fixed at one point in the process…beginning, middle, or end. It needs attention throughout the design and implementation phases. Each development iteration can also be an interface design iteration. Slowly but surely I’m learning that it’s not a good idea to just try to save an interface in one fell swoop. Everybody involved in the software development process should take this lesson to heart as well.

For now, I’ll keep busy on projects chugging away at finding interactions that make little sense from a user’s perspective and helping to ameliorate these issues. It’s my hope for each project that one day I’ll get to the point where I can help the user have an experience that is not only easy, but fulfilling and emotionally pleasing as well.

I almost missed my flight this evening. Nearly every Sunday for the past few months I’ve taken a flight to Raleigh, NC. This flight is preceded by a trip in a taxi from my house to the airport.

Except tonight it didn’t go as planned.

As routine turned to complacency, I wasn’t alarmed when the cab wasn’t there 5 minutes early…nor was I alarmed that it still hadn’t shown up 10 minutes late. Then 20 minutes late. Finally at 23 minutes late I picked up the phone.

Me: Um…I ordered a cab for 7:15 and I just wanted to check the status of my ride.

Operator: Oh, he should have been there a while ago. Let me contact the driver.

…Waiting…

Operator: Yeah, he’s right down the street. You should go outside…he should be there any minute.

Me: Great! I’ll be out there.

…10 more minutes pass…

Me: *Muttering* I better call again… (This time was same as before, just with a new operator.)

Operator: Yep, my system shows that the driver is right up the street. He should be there any minute.

Me: Great! I’ll be out here. (I don’t know why I’m endlessly positive with people in service industries. I have patience well beyond my needs…)

Eventually Karen noticed that I was still outside and offered to drive me to the airport. I took her up on it…and it’s a good thing I did. The cab never showed.

But why did all this miscommunication occur in the first place? Perhaps it has something to do with the communications systems that the cabs are using. This technology is a likely culprit. If you look around at the driver’s seat in any cab in the US, you’ll find that it’s a mess of wires, screens, and sounds…and this is before you take into account the fact that the driver has to drive. Of course the driver says he’s right up the street…that’s how he gets the operator to leave him alone, so he can get to his destination/talk on his mobile phone (by the way, who do these cab drivers talk to on their phones all day? My guess is that they talk to each other. It couldn’t be their family members…could it?).

All of this is turning into one big rant. The point is, a cab driver’s seat holds endless opportunities for innovation. It is ripe and ready to be tapped. So, somebody, please (pay me to) do some ethnographic research and redesign this workplace. I’m sure us regular taxi riders would benefit immensely.

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.

Call me a Design+OSS fanboy, but UbuntuStudio looks awesome. Finally an Open Source operating system aimed at us designerly folks. I know, I know, all that software has been around for a while, but it will be nice for it to be all wrapped up in a tightly wound package. I’ll let you know if I love it or hate it after I give it a try…

to a poor design. I stumbled across this newish area of the Apple site this morning. I won’t go into details, just because I’m lazy, but from this designer’s perspective this page is U-G-L-Y. So many gradients and colors and flashing boxes. Not to mention the fact that it has slowed my computer to a grinding halt. Painful. Wake up, Apple…don’t lose your fabulous eye for detail.

It’s true, there’s definitely a time and a place for getting one’s hands dirty. Sometimes there’s just no way around digging into the details and making things right. Sometimes, even as a designer, you’re going to have to play with the CSS to get the alignment right, because if not you, who will? Still, it’s important to remember that at the outset of a project, and even beyond that, limitless imagination is a requirement…because limiting yourself to a technology will hamper one’s ability to truly solve a problem.

It becomes so easy to get wrapped up in technology, but we need to remember that a client and user’s true need is to solve a problem, not have a piece of software. Before deciding to build software, we should consider the true problems, and discover what should be done to fix them. Sometimes it’s a policy that has grown stale. Other times it’s as easy as adding a whiteboard to your kitchen so that people don’t forget to communicate. And even other times it might be imperative to create a digital, internet connected, multi-touch capable whiteboard in the kitchen so that it can sync up with your local events database, rather than a new intranet.

My point is that we shouldn’t underestimate the power of imagination. When exploring design solutions. Your first idea will (in all likelihood) not be your best. Look beyond the obvious.

Oh, and be sure to staff a tactical, imaginative designer.