LW 5: Post Mortem

By Mike S | February 4, 2009

It’s a July afternoon and Sam, our team lead, called a meeting. He’s got a smile and he starts writing dates on the board. Alpha: in months, Beta: a few weeks later. Final release: Christmas 2008. The remainder of the team is in silence, just nodding their heads in agreement at him while we were all thinking the same thing to ourselves: “Is he f*%&!ing crazy?”

The next few blog posts are about the gritty details of taking LimeWire, the 9 year old product that 60 million users have come to love, and having a hard look at it. We’ll talk about how we did a complete redesign of the user’s experience and front-end code, integrated social features, and reworked the way we develop software. What went right and how it couldn’t have gone better … and how when something went wrong … it really went wrong.

Some things That Went Right

Iterative design in development, by Mike S

“Redoing this UI has been a pipe dream for me”, Sam said.

Two year ago, the LimeWire team was 4 developers. One year later (when I first started), the team grew to about 6 developers, 1 technical writer and 1 user experience designer. Currently, we have a team of 17 people: 6 network developers, 4 core developers, 2 UI developers, 2 visual designers, a user experience designer, a technical writer and a product manager.

The point isn’t that more people build a better product, but getting people of varying skills help make the best product possible. Developers constantly questioned one another about the best way to code something, I questioned when the visual design was excessively “artsy”, the developers questioned things I came up with wanting more power, and Anthony, our visual designer, told me I am over thinking the solution to a problem. There was a checks and balances system in place and even though there were countless arguments and disagreements (and there still are — even after the release), just having different people thinking about different things helped make sure that we weren’t doing one thing that just one person really wanted.

For this release, we tried to give focus to answer the question, “What is LimeWire?” Once we did some initial user research, surveys, scenarios, requirements, we started wire-frames, doing paper prototype usability tests, and then eventually building a flash prototype that we tested with users. All before any front-end swing code was written. In the meantime, the developers tested front-end toolkits and made all the back-end changes that were needed to get this design up and running. Once we were ready to integrate, I wrote interaction spec documents that got handed off to the developers. While they were doing that, Anthony wrote visual spec documents. By the time he finished those, the developers were done with my specs and they started on his. We got into a great circular flow between the developers and designers.