This article was written in 2014 for the now-archived blog during the rebuild process of TED.com. I think the model is universally applicable to other projects so I decided to move it here.
In 2013 I convinced our Executive Director / Head of TED Media to rally around the idea of rebuilding TED.com. Not just the website that was originally built in 2007 and was now barely operational, but the entire platform that services it. It was an ambitious undertaking. Once the team came to terms with the need to rebuild TED.com from the ground up — and the freak-out phase subsided — we began sketching. As part of the process of figuring out what to change, what features to add and how to sharpen our design, there was a big question that we had to ask of our users:
What do YOU want?
Now, this is a well-known, important and obvious question for designers everywhere. But getting it right is where it packs a big punch. We’re talking about YOU, plural. It’s the you that speaks English, and the you that speaks 103 other languages. It’s the you that’s so busy you don’t have time to think, and the you that has all the time in the world on a weekend to learn new things. It’s the you who is interested in talks on a specific subject, and the you who wants to be delighted by something unexpected. It’s the you that stops by TED.com once in a blue moon, following a link some friend sent, and the you who lives and breathes TED Talks daily.
Balancing these conflicting wants becomes chaotic very fast. Without a solid decision structure in place, it’s easy to slip into the narcissistic mode of assuming that “what we want” is synonymous with “what you want.” So we needed to lay down some rules.
We set out to turn user archetypes into a decision model. But first — how to define archetypes? I kickstarted a super fun social science project with our customer support expert, our lead information architect expert, and some data science nerds. The project entailed culling through over 3000 emails from customer support then categorizing the asks, conducting online surveys with those visiting ted.com, interviewing fans of TED from all communities, and of course asking questions everywhere people congregate online. The result started out like this:
If you can’t read the spreadsheet, don’t worry. Catch a summary of 12 TED archetypes here. Once we have a rough outline of who comes to TED.com and why, we defined the size of each group of people against two core behavior scales: “frequency of visits” and “the nature of content this user seeks.” And then charted it:
We then applied this diagram to design decisions in the following ways:
1. Find high-value features that many groups might want. For example, the “watch later” feature. We created this because “the link follower” might be interested in the content shared, but might not have 18 minutes to dive in right away. Similarly, “the commuter” has a short period of time to binge on talks so would like being able to save them and watch during the 30 minute train ride in the morning. Once a feature idea was defined, we came back to this chart and put on the hat of each archetype, asking ourselves, “OK, how might I use this feature?” We used this to make sure that the experience flow worked across varying needs.
2. Validate our incoming wish list, and help us determine feature priority. We’ve been getting a lot of asks — and we love them all. But we wanted to make sure to respond to requests that mattered to a lot of people. This map gives us a tool to ask: is this request valuable to a certain archetype? Yes. Multiple archetypes? Even better. If the ask maps to the behavior set of a larger group of people, then a bunch of people must be wishing on the same star. In that case, we’ll build it. If not, then the ask gets objectively prioritized accordingly. This chart also helped us figure out which regular features weren’t being commonly used and could be retired. (Hint: this is a great tool to help product people say “no.”)
3. Craft layout priority. The number 1 reason to come to TED.com is to watch a talk. This means that the area where you browse talks will likely get a lot of eyeball traffic from all sorts of archetypes. Here is an example of how we used that information to determine page layout.
This is one of many talk browsing wireframes we lovingly fought over:
We made a concerted effort to prioritize passive browsing over active browsing, because we assume that if you are looking for something specific you would be more motivated to scroll around.
4. Determine development priority. Back to the talk browsing example. Below, the left screen is the final design of the talk browsing. The right screen is what we released.
With an agile development process, we build and release features in bits. Archetypes give us a good understanding of user behavior, which makes it easier to determine what to build first. What comes out first is not necessarily the most important feature for the most important audience. It is more a “baseline” acceptance level that fits the largest need. Then we expand bit by bit from there.
This is the stuff we get excited about that might not be apparent or visible. It’s the nerdy psych underlayer of our product work that we get so excited about. The journey — and the graphs — are half the fun.
With thanks to Francesco Bertelli (@brtli) for the collaboration on this work.
