Why Products Suck #5: Wrong Technology
Part V in an ongoing series of Why Products Suck (and what we can do about it).
Bill Buxton, author of Sketching User Experiences
Poor technology choices can stretch from the choice of overall medium (mechanical/analog vs. digital), to platform (web vs. mobile vs. desktop vs. kiosk vs. environment vs. robot vs. etc.), to the implementation of a single feature.
Take Fuelly for instance. Fuelly is a perfectly fine idea for a product: it helps track your car’s fuel economy. But a website as the major point of use seems wrong; few of us at online at that moment we’re filling up our cars. A mobile application, or better yet, an application built into the car or the GPS unit, would seem to be a better platform for the functionality.
No one is immune to this, not even Apple. I contend that the “classic” iPods made better use of technology (the clickable scrollwheel) than the iPod Touch. As much as I love a good touchscreen, I find touch controls for a music player frustrating. The ease of skipping songs and controlling volume (two actions that are done very frequently) has been lost with the move to touchscreens. The functional cartography needs work. (Of course, the iPod Touch is trying to be a lot more than a music player…but this too might be part of the problem.)
Start with the tasks that need to be performed, and the context in which they will be used. Then choose the technology that will best support the activities and the environment. (Of course, this means designers being able to exert considerable influence over the production and development of the product, which often doesn’t happen. Which is itself another reason Why Products Suck.)
ABOUT KICKER STUDIOCASE STUDIES
SERVICES
TEAM
BLOG
CONTACT US
3 Comments
Worse yet with the iPod Touch, the fastest way to “play” or “pause” is two button-taps and a screen-press. That’s the action that I find myself needing to perform most often, rather than “skip song” (which can be accomplished via a quick shake, assuming you’re in ‘shuffle’ mode) or “change volume” (which has two dedicated buttons, and considering it’s a ‘set it and leave it’ control rather than a ‘I need to react to something’ control, I’m OK with losing the granularity of the scroll-wheel volume control).
I guess, to stop it, I could yank the headphone cords out of the iPod… but that takes even longer when I want to start the music back up. At best, it’s inelegant, and at worst, it’s encouraging the user to break their headphones.
I’d go back to an iPod Classic if I didn’t value the web browsing, email client, and myriad applications so heavily.
I’m quite confident that the technology-centric process goes something like this: Business guy makes a bullet list of features of competitors’ products implemented in various technologies, hands it to an engineer and says “Make this”.
Engineers speak in terms of implementation, as if they’re building whatever it is in their heads as they speak. If the boss mentions a specific technology, they latch onto it. If not, they just use whatever pet technology they like the most.
Businesspeople and engineers don’t need designers to make something that technically works and that can be sold. The happy couple has been functioning like this for centuries (depending on how you count).
Where the designer comes in is to turn something that would otherwise be marginally successful into something stellar. That role, in my opinion, is between business and technical interests, interpreting back and forth and synthesizing a plan.
What if you are working backwards, trying to define your customers and how this new to the world technology might match up? Seems their would be some level of ambiguity as to how the technology could be implemented.