The lessons of David Travis’ Fable of the User-Centered Designer seem obvious: Start by getting to know who you are designing for, test your assumptions, and iterate.
But the approach is not quite so obvious because, as the fable’s protagonist discovers, there is no manual for user-centered design. You can’t just go by the book. You have to engage with your users at every step of the process.
I wish I knew this back in 2008. I was leading beta tests for a social music website. When I came to the project in February of that year, there was already a spec outlining all of the features the site was to offer. All that was left was to build the site (we hired a boutique company who gave us a non-profit rate), and fill it with great Creative Commons music (that was my job).
We had imagined that the site would appeal to many different types of users. But we had not done any user testing outside the world of our small nonprofit.
As the beta testing began, I discovered that the red routes were not as clear as we had imagined. I had to outline step-by-step instructions for how to do key things like upload a song, or create a playlist. My first round of beta tests were conducted by remote, without the ability to observe. I learned much more by actually watching people use the site, and talking through the process.
Some of these lessons wouldn’t really hit home until the site was opened to the public. At that point, I started to identify who our users really were. The categories we had initially envisioned didn’t fit the reality of our userbase. I fielded help emails describing issues I never imagined anyone might ask, mostly because I’d been living with the site for so long I had never thought to question. Additionally, many of the features from the original spec went unused. The design looked nice, but in reality it was too cluttered. A user-centered design process could have helped prioritize the information.
At the time, I was more concerned with testing functionality than with testing the user experience. The site was developed with a grant, and we had a limited timeframe to do what we said we would do, and we said we would do a lot of things. In hindsight, we should have allocated resources to learn more about our potential users as part of a more iterative design process.
Instead, I learned more about our users after the site launched. Many of the users who we’d imagined showed no interest in the site. For example, we thought remix artists would use the site to find legal samples. The original grant proposal even described an area of the site that would be dedicated to remix artists. But I vividly remember my first on-the-job conversation with an actual remix artist, because I found that she didn’t care about “legal music” because—the idea was actually quite insulting to her because she believed that, as an artist, her sampling is protected under fair use. Instead, it turned out that online video producers would become the primary audience. With more user research, we might have been able to predict this and either focus the site’s features, or reprioritize the goals of the site to cater to the other users we had hoped to attract. As we began to focus more on content for video producers, this audience continued to grow, but it also raised new issues that would have been better served by an iterative, user-centered design process.
And that’s why I came to ITP!