Monthly Archives: March 2008


Before jumping on others, assuming this is their fault, let’s take a moment and look at ourselves.

My job is to be an advocate for good user experience, but more than that, it’s to contribute to a successful project delivery. It’s good to remind ourselves, and our team mates, of that. Often, the business owners are concerned with getting their features in the next release, the engineers just want to build something that works, and we want to design the best experience possible. The conflicts are obvious. Something that is important to the business may not be desirable for the users. The great design we come up with may be very difficult to implement.

So step back. We’re all in this together.

To be successful, we must balance the business needs, the user needs, and the technical needs. These are the three legs that our project stands on. If one is short, we fall.

This doesn’t mean give in to the needs of the other groups. It means show some sympathy for the pressures they face. Try to understand what is driving them and their needs. This helps us make better design proposals and will likely make others more sympathetic to what we are trying to do.

Do you think this is the way to go or are there enough others fighting for what they want and we should defend our turn?


Sorry for the delay in posting. I’ve been battling the flu for a week now. I’m much better, but not yet healthy. However, I can finally concentrate enough to write something coherent.

First of all, I want to thank those who wrote for their thoughtful and articulate comments. I think you nailed some of the core issues from a variety of perspectives. I won’t address all of them individually here, but they will give me material for a number of posts.

To some extent, this has validated, and also refined, my idea of the biggest root cause. What is clear is that it isn’t part of the traditional design process. Novel ways to gather user research don’t help you convince someone of the need for it in the first place or that a project should sacrifice time used for feature development for validation instead. Improving requirements gathering, use cases/stories, wireframes, etc. aren’t what is holding us back.

Initially, I would have said that the root cause was the sales process. That perspective comes mostly from a consultant’s point of view, but its the same in product companies as well. Everyone has customers. Sometimes those customers are who you sell your product to. For others, the customers are internal. Before design begins, promises are made. That’s where our problems begin. The sales process. The commitment phase. I’ll-say-anything-just-sign-here. Whatever you call it, it’s a problem of inheritance. We are given conditions to work within that handicap the project before it has even begun.

Do you agree? How much impact do you have upstream on the conditions your design team inherits?

In upcoming posts, we’ll look at why this happens and what we can do to effect positive change.

The Root of the Problem

I was going to start out by addressing what I see as the biggest cause of frustration in the course of creating useful, usable, and beautiful work. However, I too have learned from the Zuckerberg fiasco, so I would like to ask you what you think is the most significant root of the problem that prevents you from creating the best solution. Leave your thoughts as comments. After a few days, I’ll see how your experiences compare with mine and post some thoughts.


There are a lot of blogs out there. Why start another one? Same reasons as everyone else. Hopefully, I can share some experiences and ideas and start some conversations that might be helpful to others.

Who is this blog written for?
Anyone working on improving the user experience of web sites or software, including experience designers, IAs, usability practitioners and those whom we work with.

What’s the issue?
As I talk to colleagues, there is a lot of frustration. Things aren’t as easy as they should be. There are a lot of talented people who are not able to do their best work.

It seems to me that process can help. That doesn’t mean you should all follow my process. Heck, I don’t really have a process. I believe in creating the right process to fit the situation at hand. For some, that means adding some rigor and focus to a chaotic process, and for others, it means adding some flexibility and streamlining an overly restrictive process. Don’t expect to get it right. Expect to constantly change. As a radar expert told me once, a missile doesn’t fly in a straight line. It constantly veers off course and then corrects itself, typically overcompensating, and then adjusting again.

I also don’t want to limit the conversation to just the design process, but everything around it as well. How do you lead a team of designers? How do you prove the value of what you do? I’m open.

I’ll also talk about how to work within an agile/iterative process. This is an experiment with my current start-up. I’ll post what works and what doesn’t.

Are there any topics you’d like to see covered? Leave them in comments.