Alright, I know, it’s Thursday. Still, we’re cutting ourselves some slack this week because tomorrow is a day off. Happy independence day everyone. Enjoy these:

1. 
   
   
2. 
   I know, random, right? Posted by flickr user hhhitshayley

happy bokeh wednesday! by Disco ♥ Tetris.

It’s been a really freaking long road trip. After 18 days away, I’m ready to be home for a while. It just blows my mind that I’ll be back on a plane on Sunday. Ahh, the glamorous life of a traveling consultant.

So, my favorite story to tell on Valentine’s day involves my little sister. See, when she was little instead of saying “Valentine’s Day” she said “Valenstein Day.” I don’t think there was a reason behind it, that’s just how she thought it was said. My parents thought this was really funny, and I guess I did too a little bit (apart from her getting all the laughs and stealing attention from me ;-)). My parents always used to say, “Ooooooh, Valenstein day. She must be talking about the Jewish version of Valentine’s Day.” Funny funny. I guess you had to be there.

Anyway, Happy Valentines Day everyone. Enjoy it.

So, did it work?

Great question, weblog.

Well, for the past few weeks I’ve been in Chicago, toiling away on the ThoughtWorks beach. Man, I never feel so busy as when I’m on the beach (the time you get when you’re not on a project). There are always a ton of projects to work on…people constantly asking for some time. But it’s fun. I get to see a lot of new stuff, and occasionally get the feeling that I really am helping. But that’s work, and I want to talk about play…

Right now I’m in Phoenix, AZ, preparing for my cousin Lindsay’s Bat Mitzvah, which is tomorrow morning. She’s gonna rock it. Until then I’m working and hanging with family.

Then it gets interesting. After Lindsay’s party tomorrow evening, I’m headed straight to the airport. Then I’ll jump on a redeye flight to New York, which will put me there in time to catch another flight to Israel. “ISRAEL!?” I hear you say. Yup, cool huh?

Karen’s already there and we’re going to be doing some real, relaxing vacationing. Can you tell I’m psyched? Well I am.

There will be a lot going on in Israel, touristy stuff, a wedding here and there, and some hanging out with family. Good times. I should still have regular internet access though, so feel free to drop a line.

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.

iPhone presentation
Originally uploaded by Dan_H.

One distinction many people make when defining a design project is whether the design will be another evolution of an existing technique, set of tools, or technologies, or if it will be a revolutionary implementation. This decision is most often made implicitly, generally without any direct thought about revolutionary design…the creation of ideas that enable a new paradigm of designed interactions.

Such was the case in the mobile phone industry until last month. For years we had seen absolute crap when it came to the design of mobile phones. Motorola, Nokia, LG, Samsung…they’re all guilty. Each of them simply evolved their phone solutions, simply adding functonality year after year, rather than assessing how users’ experiences might be enhanced as technology evolved.

Now, Apple has designed the iPhone, which rethinks how people can interact with their mobile phones. Apple didn’t simply sit around and design the next thing that makes sense…they did the leg work of thinking how the mobile phone could be simplified, how specific interactions could be made easier, how to make functionality make better sense.

Why was Apple able to do this? Why is it ok for them to rethink the design of the phone, while all the other big names just sat around and evolved? I’ve got a few ideas:

1. They had nothing to lose.
2. They’re not afraid of losing a few customers to excite many others.
3. They realize that good design doesn’t necessarily cater to everyone, but works well for those who are meant to use it.
4. Design is a first class citizen at Apple.

We should all take a lesson from Apple and their iPhone. Sometimes playing it safe, and simply evolving, is not the best progress. Sometimes it is ok to shock and awe…when the end product is much better than anything else available. We need to rethink our interactions with customers, and not necessarily just stand by the same ol’ same old, but rethinking the way the computer can enhance human performance.

Most people who have worked with me up to this point have probably noticed that I have a strong urge to think about solving problems using Design methods and methodologies. This is not accidental. In my heart of hearts, I believe that the work I do each day will help make the world a better place…not through the success of particular technologies or companies, but through human interactions aided by supportive tools. The only way this will happen is with a healthy dose of good Design. With this in mind, I’d like to pass on the most important thing I learned in my post-graduate education: The Seven Themes of Good Design.

I think about these themes often, and am indebted to a great educator, mentor and friend for teaching me these oft-forgotten ideas.

Without further ado, Good Design is all of the following:

1. Is user-centered, not machine-centered - That’s right folks. The name of the game is people, not machines. It’s about helping people to do what they would likely do anyway, only to help them do it better. And also to allow people to do things they never dreamed possible. Either way, good design is about people, not the tools that get them there.
2. Employs the computer as a transparent medium - Ideally, a person never even notices the computer, it just fades into their normal flow. Every Interaction Designer should know that if a user makes a remark about the UI, then the designer has failed in some way.
3. Creates computer imaginative interactions - Good design takes full advantage of the medium upon which it is built. In our era of technology, we should be using the computer in ways that people only a few years ago would never have dreamed of, not just the next logical way. Desktop computing? Probably not for long. Ubiquitous computing? Coming sooner than you think.
4. Provides for ease of learning - A well designed tool is easy to learn. It may be complex, but initial use should be possible without a training course. This cannot be understated.
5. Entails continual redesign - A good design is never “done.” As is recognized in the agile development community, software tools continually evolve, because people and their environments are ever-changing. Designers constantly see room for improvement in their prior work.
6. Is more craft than art - Design isn’t some mystical, magical world. It can be learned and taught, but doing so requires a lot of work of both teacher and student. Some people are simply gifted artists at birth. Most great designers have honed their skills over time.
7. Always involves tradeoffs - There will always be something that would make a design better, but could not be included because of a particular constraint. Always.
8. *

And there you have it. The Seven Themes of Good Design. Credit goes to Marty Siegel. The most influential lesson I’ve received in my professional career, and the basis of my Design Philosophy.

* There is an eighth theme of good Design, I’ll have you know. That one is a bit of a secret, though. If you’re interested in learning about the most important theme, you’ll have to ask me about it. I’ll be glad to share, but the only way to do it is face to face.

So I tried my hand at building a new theme for my blog. Let me know what you think. The actual implementation is a little buggy, but it’s getting there. All feedback is wanted, even if you think it might sound mean! Bring it on.

Just a question. Feel free to introduce yourselves.