Design for Objectives; Not Requirements

Yesterday I was evaluating early design comps for a new project just getting underway here at AutoTrader.com and I fell into the trap of what I call Designing for Requirements, Not Objectives.

Neil and I were discussing the new versions of the comps that have surfaced since we returned from San Francisco and the improvements around them–at least, some of them.  With one comp in particular, Neil began to repeat the phrase “yeah, but it’s not poppin’ off!”  and the only argument I seemed to be able to formulate in reply was “True, but it’s doing this to meet business requirement x.”  After a few minutes of this, I was forced to concede the point that Neil was right and I was arguing from a hollow perspective.  Ask anyone who knows both of us and they’ll tell you that Neil has taken to using me as affirmation–as in, “Oh you know I must be right if Crescimanno is agreeing with me!”  Long story short, we disagree often–if only as an exercise to keep the other thinking on the right path.

I’d fallen into the trap of seeing the design purely as a function of meeting the business requirements that have been defined for the project and failed to evaluate it based on the stated project objectives.  While the design presented did a fantastic job of meeting all of the business rules and requirements that had been created around it, the design completely fails to accomplish the primary goal of the project.  When there are many, many forces pulling projects in many, many directions, it’s easy to get lost in things like business requirements, advertising specs, reporting, and other measures and to lose sight of the reason the project exists in the first place. It happened to me here; it’s happened to many others in the past, and it will likely happen to others in the future.

In design, we often have to cater to multiple, often very disparate groups.  That’s certainly the case in this project, and while this design caters to one group quite well–it doesn’t serve the other at all.

Remember, when designing anything:

  1. Take into account all of your audiences and do your best to serve all of them (recognizing that no one perfect solution for all of them at once exists)
  2. Always keep the primary objectives of the project at the forefront of the design–and fit the business requirements within that framework.

At the end of the day, you can satisfy every business requirement in the specs–but if your design fails to meet it’s objectives, it won’t be successful.  

Adobe’s Open Screen Project: What does it mean?

Adobe today announced the creation of the Open Screen Project to help facilitate the adoption of Flash and Flash-based technologies on a wide range of platforms. There’s plenty of coverage out there today about this initiative–and it’s no surprise. For years developers have been calling for an opening up of Flash and it looks like Adobe is ready to give it to us.

The big takeaway: Developers are now free to create their own versions of Flash Player.

First, this is fantastic news for the open source community and projects like Ubuntu who now have the opportunity to create a true “free software” version of the Flash player. Free software purists around the world rejoice!

But there’s more to it than just Free Software. Apple’s current SLA for the iPhone SDK would not allow Adobe’s Flash Player to be ported to the iPhone platform (barring special exception, which I’m not entirely convinced Apple would be unwilling to give). Could Apple develop its own version of Flash Player optimized for the iPhone? The Open Screen Project certainly looks that way–and I honestly can’t help but wonder if that’s part of the reason Adobe’s decided that now is the proper time to announce this project. Given the number of partners (and the conspicuous-in-their-absence-Apple) I’d hesitate to say that the iPhone SDK was a cause for this action; but it certainly may have influenced the timing. One thing’s for certain; it very much puts the ball back into Apple’s court on the issue of Flash on the iPhone.

I am one of the camp that believes Apple has no interest in seeing Flash on the iPhone. Flash competes too directly with a major Apple technology–Quicktime–for Apple to want to see it there. That said, with the onus now on Apple with regard to Flash on the iPhone, I think the boys at Adobe might have out-maneuvered ol’ Steve on this one.

And that might be the most impressive part of it all.