Archive for August, 2009

nitro-burnin’ funny fones!

Tuesday, August 11th, 2009



Photo by Jan Chipchase

Today I ran across Jan Chipchase’s blog about how, while conducting Nokia research, they were able to collect a huge number of Personalized Phone Cases in phone-recycling bins around Japan. Finding this entry by Jan coincidentally touched upon some things we’ve been talking about a lot here at Little Springs; specifically the notions of what the human elements of personalization bring to the interactive experience with a device.

We’ve all seen modded-out computers, from far-out and funny gaming boxes to Steampunk Verne-cising of modern machines. I’ve seen stickers and paint on laptops, and I’ve seen dangles, sparkles, and doo-dads on cell phones. Historically, whether its a hammer or a hard-drive, we want to make our tools “ours,” and to operate as extensions of our own personalities. Our modern mobile devices are as much accessories that speak to the world that we’re “ultra-clean,” “ultra-edgy,” “ultra-us,” etc.

As interaction designers, however, we have no control about this part of a user’s experience; we design, we create, we market, we let go of the product and let it become and mutate into what it will in the hands of the public. Leo Fender designed guitars, but he had no idea Jimi Hendrix would melt the sky with one (and Fender sees the value in offering customization). Henry Ford designed vehicles for transportation, but had no idea how they would be “kustomized” and reconfigured to the extremes we see in this day and age (such as these Japanese kustoms, for example). Would computer designers in the 70’s anticipate the modding and hacking of the physical machines they were creating (such as this great list of the variety of mods out there)? Would Alexander Graham Bell anticipate that a phone would eventually become a personalized device that would offer it’s user literally the world at the touch of a button?

What does all of this say about us, socially and anthropologically? Well, it says we like our stuff, and even if our stuff is like everyone else’s, we still want to bring something of our own personality to it, as it is that much more of a “calling card,” and in the relation to a mobile device, this is literally the case (no pun intended).

Let’s go back to this idea of car customizing. Or, more properly, “Kar Kustomizing.” Doesn’t that just feel better? The words themselves (like the products) are altered to give them more fit, more personality, more truth to what the spirit behind them is.

More than ever, this notion of tools and their kustomization is an important dialog these days. Here at Little Springs, Steven Hoober and I talk about the merits of humans being “tool-oriented creatures,” even to the extent of what that means in regards to the idea of having NO tools, as in how we might interact gesturally with future technologies? He and I plan to do some more podcast/vidcasts of these conversations by revisiting the tools in our very own workshops, so keep a look out for these.

Personally, I think we will always HAVE tools, devices, gizmos, gadgets (and their inherent mod-abilities), for this very notion: we are hunters and gatherers “by trade” as humans. We like to collect things. We like to have things in our hand to see what we can do with them. We like to see how something reacts to our own physicality, how it represents our own “spin of English” on it, our opportunity to literally swing the bat at it. Mostly, we just like to show off.

Just like the Japanese phones with the art on them, the hot-rod builders of American Kustom Kutlture, the box-modders of the Steampunk movement… it’s all about crafting something individual out of something generic. It’s D.I.Y., and I look forward to seeing what kinds of specialty kustomization happens with some of the future-facing technologies being explored currently.

our work in action

Monday, August 10th, 2009
The Weather Channel's iPhone site showing a storm cell bearing down on the Little Springs Design offices

Here comes the storm. Okay, this week's storm. No tornados at least.

why bother with design objectives?

Friday, August 7th, 2009

Yesterday, Chris sent me the document that everyone had made as a result of the working sessions the other day. And I sent back my usual detail gripes, but also a more generalized one that was (at least partly) my fault. It didn't have any words to speak of.

I mean that in the sense that you can see in this sample (764kb PDF).

This uses all of the exercises outlined in my design process book, seeking problems and goals, analyzing them with design morphology, and coming up with a set of actionable design objectives. The end state of these exercises is then placed right in the first concept documents you hand over to the client, pretty much first thing.

So as you get to explaining design options – when you communicate the value of any idea, that description should automatically refer to the problem, and design objectives you put up front.

Solutions have to be communicated and grounded, not just drawn.

You cannot usually just get away with drawing your perfect solution. You have to communicate it, and ground the concept in the reality in which product owners, other designers and technical resources work and live.


I say, a lot, that it's good to step back from prototyping, high fidelity drawing and even drawing as a whole in order to gain perspective and to design and communicate in a common manner to which everyone can contribute. For this early, analytical phase, and their communication, it's worth re-stating again what it gets you:

  • The process of creating design objectives provides you a solid understanding of the client, the brand, the product, the project, the brand and the scope.
  • Communicating this to the client proves you have absorbed this, and are on the same page as them.
  • If there is a mismatch when you first publish the problem statement and design objectives, that's the best time to get it out in the open. Even if only caught when the first design concepts are offered up, it's early enough to fix and reconsider.
  • The words can, and should, be referred back to throughout the design process to prove to yourself you are on the right track. It is especially key to consider design objectives as you move from higher level to more detailed documentation.
  • I also find it helpful when changes are considered late in the project. Instead of the quickest, easiest design, read those statements about the original needs of the project and consider what solution best meets them.
  • Unless you work entirely alone, others in your organization need to be on the same page as you. If they are just looking at design documents, they are still guessing your intent. Even better is having your whole team help you create them, even if they will not all be working on it right away. Bring in the graphics folks and prototypers to help create design objectives up front.

And in the same way it's good to write things down so you understand and remember, it's good for me to write about this occasionally. As I said up top, I pretty much forgot about this. Projects get exciting, and you jump into them. But taking just a few minutes to make sure you are starting the right way is the best way to design, and much more efficient in the end.

Now I guess I have to go back and read my book myself, again.

smartphone is a state of mind

Tuesday, August 4th, 2009

Yes, this whole thing again. Sorta. Bear with me.

The definition of a smartphone (vs. featurephone) is... well it has varied over time. Mobile phones used to be pretty much restricted to making and receiving calls, with a tiny address book to support it. A few had some sort of paging, and eventually real text messaging came about pretty universally.

Then these PDA-phones came out. Which were, well, PDA phones. They added:

  • Calendar
  • Contacts list (larger and with more fields than a phone address book)
  • The ability to synch these to a computer

How smart is that smartphone? How much does it matter?

Sure, some of them had additional features. The one shown above was a Palm, with the ability to take (as I recall) any old Palm III software. But others were sold right alongside with locked feature sets, in proprietary software. And hardly anyone seemed to care.

Today, the definition of smartphone seems to be:

  • Identifiable operating system
  • Ability to add applications

Which strikes me as awfully technical all of a sudden. I have always been somewhat leery of defining devices by technical features when we're really talking about how consumers use the item. So I wonder how this happened, and do end users really care?


And some recent data reminded me if all this. Some percentage of iPhone users (though 7% sounds low) never install any applications. A huge number download only one. If a key definition of smartphone is downloads, then I ask if those users are really even carrying a smartphone? Sounds like they are perfectly happy with their feature-phones, however hi-falutin' the feature-set is.


The other the stuff that's made me think of this is that I've been observing (and hearing on the radio, and seeing on TV) about what makes a cool phone. When you get past technical (and especially mobile) blogs, magazines and so on, what makes something cool are specific features, or even specific media.

My phone does essentially everything that can be done by a phone (but touch, or have a QWERTY keyboard, if that's really a feature), but one of the few things that makes people go "wow, that's cool" (and then some of them want one) is that when NPR gets lame in the evenings and weekends, I use internet radio to listen to the BBC World Service (and plug it into the car through the lame cassette tape thingy. It involves cables and is semi-kludgy (not sure it would be sillier if I got a shortwave radio and plugged it into the car instead.

And, they don't necessarily want one of my phones. They want: that feature. On their phone, or on something else that meets the rest of their needs, but also has this extra feature. I even did much the same with other devices, some of which had radio transmitters so did it without cables. And they were featurephones. Locked down operating systems, that maybe you can add a J2ME app on top of. If you'd bother to.


A similar focus on features bears out in studies of, say, iPhone users, "the ability to add applications is only the #4 priority for iPhone users, below browsing, e-mail, and 3G capability." (Quote). Browsing, email and "speed" are features. Adding apps is something to enable more features, and not a feature in itself.

While users might get more and more used to downloading to add functions their phones, it will always be an enabling technology. Aside from us phone nerds, who cares about technology and tweaking the UI? Users want performance, utility, value. They want features and functions, and I see that continuing no matter what the future looks like.

Users are the smart ones.

Yes, this should be obvious. Design for users. But I am not seeing a lot of it lately. Mobile seems very focused on targeting the experience to the device. Additional cleverness around some device repositories will help with this.

But I wonder if – aside from using screen size to display the best image, and so on – I care very much. Can I really divine anything about a user's context, needs, intent, values, desires, or anything else from device detection?

Of course not. Oh, maybe a tiny bit in aggregate, but whenever I see data there's a lot more correlation between access to this site or that, or through this entry point or the other, than there is for device type. And so I say we need to remember users again. Step back, think hard, and if you have made assumptions about users based on handsets, consider stopping that.

Even if it ends up being true, because you have a limited user base (e.g. a corporate site where executives are issued Blackberries) start with the user. Crack open those UCD books, and come up with at least a few quick and dirty personas. Do task inventories and other things to make sure you are focusing your technical team efforts on the right areas.

As always, keeping the user in mind throughout the design process should help bring you one step closer to success.