I used to own (until it was stolen:-( ) a Magellan Roadmate 700 series portable GPS system. The system was so simple to use – it did one thing – GPS and it did it very well. The controls were very easy to use and programming it for a trip was a breeze.
On my new Toyota Camry, I now have the built-in navigation system.
The system controls not only the GPS, but also my bluetooth telephone via speed dial, phonebook etc, the four disc CD changer and a bunch of other things. Operating it is probably as complicated as a 747 cockpit – you have so many options and one wrong click you end up starting over. The other day my wife was going to Boston for dinner. If she had followed the GPS, she would have taken the longest route possible and got there an hour and a half later for what normally takes 45 minutes.
So what has probably happened here – Toyota had to create this one product that integrates the GPS, CD changer, the blue tooth telephone, the trip information and the other 15 things I have not discovered yet. It probably started as one component, which then had to be reworked to integrate the second component and so on. When everything was said and done, we have what I get to use now. It sure does meet all product functionality requirements that it was set to achieve, but it falls well short of usability requriements – thanks to product integrations. Do your products suffer from this same problem?
Software Product Manager by Gopal Shenoy 
http://www.processforusability.co.uk/Documents/BSJ_brief_CV.htm#stammi has the non-integrated version, which was the nightmare future of 15 years ago.
Sorry to hear that Toyota have come up with something hard to use, and surprising given their reputation. The industry ought to have learnt from the BMW 7 series problems with the zillion function joystick.
The point from Sridhar at 2 about the relationship between usability and utility is an important one; a good definition of usability ought to deal with utility. A simple to use rating scale is at
Click to access QIUSS.pdf
You raise an interesting discussion, however, your example doesn’t provide support for your argument. You don’t list any particular usability problems; the system’s multi-functionality is not sufficient evidence for the cause of the bad route in Boston. (It could be incorrect map data, for example.) If you had not been able to input the address in the first place, that would have been better evidence of usability problems.
(By the way, I also have a Toyota system — make sure you have allow-freeways and toll-roads turned on, otherwise it will avoid some obvious routes and can cause this sort of problem.)
It is tougher to make usable products & services when a lot of devices & functionalities are integrated to one interface or product. Having a product or interface / function would be just as bad though (with all those little or big screens cluttering car’s dashboard). The worst cases are 1) integration where all features are equal and driven by the same interface structure – no matter how much more important starting the car would be compared to switching passenger’s airbag off and 2) interface or product / function model where everything has their own logic of operation.
The aim for designing to be usable is to serve the functions so that the user meets her goal – so that the important parts can be utilized.
I have had my take both on tractor and forrest harvester design. Tractor can be fitted with harvester equipment, but the interface and interaction can’t be designed as efficient as farmer needs to do a lot of other stuff with it. (And does not have room or money to have a separate vehicle for each type of plough either).
Tractor’s and harvester’s interface can be designed to be usable, as the requirements for usability vary. Product management plays an important role defining what the products actually are / should be.
I think the issue here is actually poor usability… convergence is going to be key in the 21st century – even Apple has come down from it’s high horse… the products apple is looking to drive the future [iphone, ipod touch] are convergence devices… even Front Row on OS X & Apple TV are on that road…
The same display to control everything would be pretty cool if more time was spent on make it more useable… also it seems like they have bugs in their routing system… if I were Toyota, I’d partner up with someone like Garmin to provide the GPS & Routing technology, and have my product team work with Garmin to provide an integrated, usable interface.
Does integration make sense? Does presenting the various views on a common display mean that the underlying functionality is integrated? No.
In the Toyota example, the radio controls could be integrated. But, the radio has nothing to do with the MAP (GPS) other than displaying some content. You don’t see any cell phone controls, but the MAP and the cell phone could be integrated, if you were augmenting the GPS with cell tower navigation. Maybe the AM/FM signals contain location data, integrating that would be interesting. But, as it is, the functions are not integrated.
Usability isn’t just an issue of the interface or view. Bad models give rise to bad interfaces. Too often interfaces are after the fact add ons developed by a graphics/interaction designer, instead of the developers that built the model. The former have to paper over model issues.
Personally, I want my cell phone to act like a phone. If it acts like a web browser or anthing other than a phone, it won’t be my phone.
Gopal,
Good point, I agree with you that it is very important to address usability and usefulness simultaneously. I’ve found that this is especially hard to explain to engineering teams, but PMs should persist in explaining it to engineering nevertheless.
I think balancing usability with usefulness (aka features) is one of the key areas where product managers can add a lot of value. I wrote a more detailed post about this in our new blog Practical Product Management. Keep up your excellent blog!
Sridhar,
If a product does not solve a problem or solves a problem nobody cares about (Sharper Image comes to mind at being very good at this and where are they now), it is not going to succeed no matter how usable it is.
But I think it is a fallacy to believe that you have to make the product usable first before you work on usability – they can and need to be done at the same time.
This is the excuse that I have heard over and over again from engineering – we will improve the usability later, let us make sure we get the product out first – this may have worked in the 90’s, but times have changed.
hi,
As a novice(aspiring a role) in Product Management,I always wonder whether usability or usefulness comes first.
I had a product that ran a similar course to the GPS system you describe. It started out as a straight-forward platform for a well-defined set of core solutions. However, over the next few years it became a huge, feature-filled mess. One of the biggest problems was the need to put any feature that might be used twice or more into the “platform” because “that’s where common features go.” When I took over I said “no” to a lot of groups and was not the most popular guy. But we made good progress.
I’ve since moved on to another company where I have control over the entire product set. It’s refreshing!