Kevin Cheng  

The Optimal Design Roadmap

May 13th, 2005 by Kevin Cheng :: see related comic

Steve Jobs is often attributed with the quote, “real artists ship”. No matter how much of a perfectionist you are, to be successful you need to ship your product and that means cutting some features so you can ship it in time.

It’s often quite difficult to gauge what is too little or too much. Using our comic analogy, you could easily find less detailed artwork in more popular comics online or elsewhere. South Park is proof that animation need not consist of millions of polygons and light rendering engines to succeed.

As interaction designers, we often have to deal with what interaction pieces to include in a product. At some point, we come to a discussion with project management and it goes something like this:

Designer: “These interaction pieces need to be in this product for it to be usable”
PM: “Well we don’t have the time/money/people to do all of that.”

At which point you have to choose what to cut, or more accurately, what gets to stay. While it’s great to come up with what we believe to be an optimal user experience, it’s easy to forget that when realities of project schedules hit, something in the experience needs to be sacrificed.

Which begs the question, should a unified interface, designed to fit perfectly together, be done at all? Perhaps we should design something more piece meal, where we can prioritise how much each piece impacts the experience and thus elect to not implement certain aspects and mostly keep the experience at the best it can be.

The answer as always, is somewhere in between. When I design, I always look towards the optimal experience. This act is not to be unrealistic or utopian. Showing a vision of where the experience needs to be helps communicate for those building the blocks en route. Programmers already do this: they recognize the end product milestone they are trying to achieve, and build releases towards it. As designers, we not only need to build the optimal user experience, we also need to create a roadmap on how to get to there, whether through three steps, five steps or whatever the number of releases dictates.

7 Responses to “The Optimal Design Roadmap”
Josh wrote:

Moreover, if we don’t aim for the best concievable solution, we will most likely miss the best possible solution - i.e. the best solution given the constraints involved. By assuming constraints that may or may not actually exist, it’s easy to miss - or prematurely discard - opportunities that may be in fact possible, or may supercede previously desired features or functionality.

Zef wrote:

Yes, the reality is “aim for optimal”, but be realistic (prioritise!) - besides, we’ll end up being the one’s the fingers are pointed at if the project overruns. On short-run projects I will give the designers and developers plenty of freedom with the understanding that they’ll use my UX blueprint (user interface framework) as their guide. I then instruct them to let me know if they feel the need to deviate from the framework. So long as the user interface framework is maintained we usually end up with a (consistently) good user experience.

pomade wrote:

Few weeks back at a Baychi meeting (san franciso bayarea chapter of SIGCHI), we had a guest speaker talking about “What To Do When Things Go Wrong: Saving Design Train Wrecks”. Speaker was Scott Berkun, former program manager and interaction designer for Microsoft (he worked on Internet Explorer and other products…).

He mention that, worst train wreck project that he could remember was working on Internet Explorer 4.0…people who worked on it thought it had problems with usability, features, and etc…lot of people thought it was going to be a disaster project. But when it was released to the public, IE 4.0 received very positive feedback fromt the consumers/market. So what happened??….

Even though, product was missing features/best user experience, it satisfied the target user’s need during that time frame. Although, there was another competing product (Netscape), IE was able to deliever features and good enough UI that met people’s expectation.

This also confirmed my past experience….when I was young starting in this field (software product design), I felt very uncomfortable releasing a product that didn’t provide best user experience. But as I got older (8 years later)…my opinion has changed. I am still champion of providing best user experience in the products that I design, but I also take into other factors into the design consideration: Market, Technology, and Business Goals (long/short term). Which helped me understand why you need a product design roadmap to design a successful product )

David Heller wrote:

I think roadmapping is vital in terms of product design. Starting w/ a clear vision of an optimal destination is key in terms of being able to do better design. This to me isn’t so much about user experience, but rather about iteration management. Yes, we have to design to constraints, but the constraints themselves are not the design, but rather obstacles that through each iteration get worn down or even removed. Through that process a product can take more and more of the original design shape. But unless you know what shape you want to head towards you will just end up glomming on features in an uncontrolled (ie. undesigned) type manner. I feel this is the main issue w/ most product management that does not have the development and iterative analysis of the product roadmap.

One of the main tasks that I do as a designer to contribute to the product roadmap is concept car design. But unlike a real concept car which ends up more like being a hodge podge of ideas, I use the concept car as a true envisioning of what I feel the optimal direction of the product should be. It is a great feedback loop mechanism within the organizaiton and for closer customers it is a tool for giving them insight into where we are heading, and them being able to return to us good feedback about that direction, so we can evolve it a long the way.

John wrote:

The problem I face with many projects is this: the optimal design requires too much programming effort. After much discussion and negotiation, we determine that the programmers only have time to program a sub-par experience, and keeping to a schedule overrides almost all other issues. Once the product hits the marketplace as v1.0, it is almost impossible to go back and redo the interface later, as v2.0 simply adds new features.

Steve Kelley wrote:

Seven Deadly Excuses for Poor Design:

Robby Slaughter wrote:

It’s in the details! Projects can’t be completed unless someone focuses on the details. Usually in software, almost all the details are left to the programmers and done at the last minute.

Ironically, it’s quite difficult to select even *some* of the details to be handled in advance of development, such as the interface, the documentation, and the system architecture. Usually, though, the people with the authority aren’t interested in doing anything like this unless they can be shown it has some value. Now we’re back to the unsolvable problem—how do you prove to someone who is accustomed to often succeeding without much planning that they can succeed to an even greater degree with more planning?

Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?