Inheritance

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.

Share this post

Leave A Reply

Your email address will not be published. Required fields are marked *