Squeezing in Design

By Mike S | February 21, 2008

When it boils down to it, three main things make very successful technology products: capability, viability, and desirability. As an example, let’s look at digital audio player history. In the late 90’s, digital music becoming more popular, and manufacturers thought to themselves, “here is a huge market that we can tap into”. The technology was there: hard drives were able to be small enough, there was an abundance of digital music already out there, and no one had done this yet. In other words, a digital audio player was capable from a technical standpoint and it was viable from a business standpoint.

So different manufacturers built digital music players. In 1998, Diamond Multimedia released the Rio PMP300 (pictured below).

It was $200, able to play about 12 songs at fairly low quality and ran on a single AA battery that lasted for about 8 hours. So not only did users have to spend money on batteries every week or so, they had to continually transfer new songs to it (considering they probably had more than 12 songs). Every time they wanted new songs, they had to get on their knees, possibly unplug their computer, and plug in this device to the computer’s parallel port. Talk about forcing a user to bend over backwards for your product.

In 2002, Archos released the JukeBox 6000 (pictured below).

I actually remember my dad bought one of these when it first came out. Like most users out there, my dad didn’t have the patience to sit down with 50-page user manuals and read them … so he would make his technologically-competent son do it and “dumb things down” so I could teach him. Well, I hated this thing. It was heavy and shaped awkwardly with these blue bumpers (I am guessing to prevent injury for when people play catch with it?), weighed almost a full pound, and had this information on an LCD screen:

Typical consumers didn’t know what an mp3 was, but for some reason, they thought showing the sample rate, bit rate and version of the id3 tags were an important thing to those same consumers. On the software side, users updated songs using MusicMatch Jukebox, which forced the users to go deep into the file system to keep their songs in sync. Given this player was plugged into the computer via USB and could hold more than 12 songs (it could actually hold 6 GB), it was a step up from the Rio … but still not a desirable product. It was discontinued a few years later, and my dad threw it out months after he got it.

Then came the Apple iPod for Windows and Macs and it was leaps ahead of its competition. With a brand new way of interacting with the device, automatic syncing with their iTunes software, and compelling aesthetics, the iPod became an instant hit. What made the iPod different from all the rest? It wasn’t that Apple’s engineers were smarter than its competitors, or that a new market for it emerged. It was the single fact that the iPod was desirable by its users. Now the problem is, how do we create desirable technology products?

Let’s take a look at other fields of engineering where both creative and technical skills must be combined to create a finished product:

Skyscrapers and bridges. Architects design the look, feel and aesthetics, civil or structural engineers design how the architect’s design can actually be built, and contractors and iron workers do the building.

Cars. Industrial designers determine the shape, body, and interior of a car, and mechanical engineers determine how that design could be realized. At this point, the design is passed onto the assembly plants where the cars themselves are manufactured.

Now let’s turn to software development. Typically there is a market for some kind of software product and upper management determines what “features” there are a need for. This list of features get passed down to developers, who then have to come up with a high-level software design and architecture. After a design is determined, developers then code all the functionality and test it. After the core functionality is in place, a user interface is determined to map core functionality to what the user sees. The developers then have to design this user interface, code and test it. Does anyone see a problem here?

Developers are overworked, having to take on too many roles in the software development process at once. To make things worse, developers or managers often will come up with new, “cool” features to add, and the developers will have to expand (or ruin) their architecture to include these changes in functionality. Does an architect come in half-way through the construction of a home and say “wouldn’t it be cool if …”? I can guarantee that contractors would just laugh at that architect if that did happen. But because software isn’t physically manufactured, there is little-to-no overhead cost to make changes like that. But just because you can make those changes, should you?

Most software development processes used to go like this:

List features > Code the functionality> Develop UI > Test for bugs > Tweak

That’s great, but how do we know if the user interface is good? So people thought, let’s add user testing into the mix:

List features > Code the functionality> Develop UI > Test for bugs & User test > Tweak

But there is still a problem in that model too. After something has been coded, it is a lot harder for developers to change their code. Developers spend hours planning their code, designing very elegant architectures, and coming up with fast, clever algorithms to accomplish a feature. To change that seems like time wasted to most developers. Additionally, after writing the code, they have an attachment to it. Even when they are forced to change their code because of a usability issue, most of the foundation has already been laid. Adding these changes introduces more bugs, making even more work for those same developers.

So what is the solution? Do your research and design up-front. Build products from a user standpoint first, then from a technical standpoint.

Interaction Design > Code the functionality > Tests for bugs & user test > Tweak

This is what Apple did with the iPod, and what they continue to do to all their products. It is this reason that Apple creates some of the most desired products in the industry and some of the most loyal customers. By putting design first, you can discover first hand what users want, what users need, and just how to deliver it to them. So after reading this blog about bad mp3 players and software methodologies, you are probably thinking, how does this all relate to LimeWire?

There is no doubt that LimeWire is extremely powerful; you can tweak LimeWire to do almost anything you want. There is also no doubt that people have a use for sharing their files (60 million users can’t be wrong). I have been here for a month and I can see first-hand how ridiculously smart the developers are here, but when you are the one coding the software, it is hard to detach yourself from thinking like a developer. So I’ve heard similar things: “that would be an awesome feature to add”, “wouldn’t it be cool if …”, “think of all the things we can do with this protocol”, instead of asking the questions that add directly to LimeWire’s desirability: “how useful would this be to a specific type of user”, “how would that contribute to the overall goal of a specific type of user”, “how would these features integrate into an overall, cohesive design of the product”.

That is where I come in … I’m working with the client team on user experience design, being an advocate for our users, and helping to roll out version 5.0, including new features and a brand new user interface. Right now I’m doing research, trying to assemble patterns of various types of users. If you’re interested in helping our team creating the best possible LimeWire it could be, (for those who took the survey, thanks for helping out).

For those of you who are interested, many stories and facts from this blog post were taken from a book called The Inmates are Running the Asylum by Alan Cooper, an interaction designer. I recommend that book for all developers (and managers) interested in methodologies to make software products easier to use.