.

How user archetypes lead to design decisions

hello-header_beckydrawings_clean

Once our 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.

So we set out to turn user archetypes into a decision model — a super fun social science project. Our customer service specialist, Becky, wrote a great article –  with drawings — defining the 12 types of TED.com users.

Here’s a less crafty/more nerdy view of these archetypes:

Spreadsheet

Once we had an 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:

Screenshot 2:6:14, 4:33 PM

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:

Screenshot 2:6:14, 4:36 PM

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.

Screenshot-2_6_14,-4_40-PM

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.

 

hello_thaniyaThaniya Keereepart is Product Development Director and resident pokerface.  @thaniya

Francesco Bertelli_Associate Product Design Director_ccAnd special thanks to Francesco Bertelli, Associate Product Design Director at Huge, for his co-nerding out. @brtli