This past summer, I was building some new website interfaces (it's part of my day job) and thinking about TiVo's combination of power and simplicity in their interface and I got to thinking about all the things I wished I could ask someone about the TiVo UI but was afraid to ask. Then I realized I could track down someone at TiVo HQ and corner them for an interview. Thanks to a few designer friends in the Bay Area, I ended up speaking directly to the top, the head honcho of all that is TiVo User Experience, Margret Schmidt.
Margret was kind enough to answer ten questions about how TiVo's UI was originally developed, how new features are added, and how the sound UI came to be, among others. I'm grateful for TiVo and Margret taking the time to do this, so without further adieu, here's the interview:
Matt Haughey: TiVo is a revolutionary product and aside from the basic recording features, the interface is often seen as a key killer feature among both typical users and the design-savvy. I'm constantly hearing it referenced as the hallmark of useful design that masks powerful features. Was an easy-to-use interface a key design goal from the beginning of TiVo's development? (considering TiVo was developed in 1997-8 that was incredibly forward thinking at the time).
Margret Schmidt: In 1998 the "design mantras" for TiVo were:
- It's entertainment, stupid.
- It's TV, stupid.
- It's video, damnit.
- Everything is smooth and gentle.
- No modality or deep hierarchy.
- Respect the viewer's privacy.
- It's a robust appliance, like a TV.
From the very beginning ease-of-use was a goal of the team. They were inspired by appliances and interfaces that "just work" and don't require reading manuals or learning the controls. Donald Norman's "The Design of Everyday Things" was required reading. They spent a lot of time talking to "TV people" about what made for good broadcast television design.
As TiVo has evolved, we've revised our design mantras, but with many of the same themes:
The TiVo box makes TV better...
- It is reliable.
- It puts me in control.
- It's easy to use.
- It's smart and helpful.
- It's responsive.
- It's all about entertainment.
I can't imagine life without it.
MH: I'm guessing UI feature development is a relatively long process, involving much internal debate and testing. Can you take us through the process? As a feature goes from idea to deployed to users, about how long does it take and what steps does the UI team take along the way?
MS: The business case for product features and functionality originates in Product Management. The UI Designer works closely with the Product Manager and Technical Lead to refine the requirements.
Depending on the nature of the feature we may do some early user needs research to understand how users think about a concept, and what they might be looking for in a feature. From the requirements and the research findings the Designer creates an initial design concept which is reviewed first with the User Experience team, and then with the stakeholders for the project.
The design concept is a walkthrough of the most frequent tasks we expect users to undertake. If the stakeholders believe the concept meets the requirements, we begin usability testing of the design. TiVo has an on-site lab and a strong research team. Typically we will create a fully functional prototype that we can display on a TV and control with a TiVo remote -- it feels just like the real thing! Based on the findings, we iterate on the design. (Some times *many* iterations!)
The Designer then creates a written specification for engineering that details every screen, error condition, edge case, and final text. Engineering starts building it, and we can begin using the feature at home, and then deploying it to Alpha and Beta testers.
The Researcher designs the tasks and surveys for the testers to complete in order to get further user feedback. Some tasks can't be easily modeled in the lab and need to be evaluated when the user can live with the product. For instance, dual tuner channel surfing behavior didn't lend itself easily to lab-based testing. We received much better feedback when users could live with the product and accurately report how they used it and not how they *thought* they would use it.
We continue to make tweaks to the user experience throughout the development cycle, always conscious about our need to stay on schedule. The Design and Research leads are on the project from the initial investigation until the moment it ships. The length of the process varies with the complexity of the release.
MH: When you've got a breakthrough product like TiVo, you're constantly innovating in a space that doesn't have a ton of established competition and I bet user research can be tough. How do you ensure that you're developing something that is usable, desirable, etc. when it's never existed before? Do you have to build a lot of proof-of-concept prototypes and test with users to see if people want it?
MS: Innovation is a by product of a talented team. We regularly brainstorm, collect, and categorize new product ideas. We have a cross functional approach to refining the ideas into product features. We have one person dedicated to creating prototypes so we can iterate quickly.
It can be difficult to test an innovative product because people are often not good at predicting their own future behavior. We overcome this by using a variety of research methods including in home studies, usability studies, in depth interviews, card sorts, surveys, field experiments, data analysis of existing behaviors to a name a few. By using different methods we are able to triangulate and get a sense of future use in the development process.
MH: Does market research play a big role into user experience? Do you check out what publications, forums, and sites are saying they wished TiVo did, then use that to develop new features, or are feature ideas more home-grown?
MS: We keep a catalog of good ideas called "RFEs" (requests for enhancement). These RFEs can come from anywhere -- from employees, Beta testers, Customer Support, the TiVo Community forum. We categorize the RFEs by feature, like Season Pass(TM) recording or WishList(TM) search.
When a UI Designer is tasked with changes to a particular feature he reviews all of the related RFEs to see which ones are appropriate to incorporate into the design. In addition, the User Experience team keeps a "Hit List" of the features or improvements we would most like to see addressed in the product. We routinely review this list with the Product Management team to get the business justification for spending engineering effort on specific features or improvements.
MH: As I've watched TiVo over the years, I've seen it morph from a company that challenged Hollywood to one that was eventually embraced it. Have there ever been problems weighing what users are asking for, and what TV studios are comfortable with? I would imagine the upcoming TiVoToGo features would be a good example.
MS: It is actually pretty easy to balance the needs of the two groups, because in general they have the same goals. Users want to watch quality programming when, where, and how they want to. Studios want their programming enjoyed by the masses. TiVo simply empowers users to control their TV consumption within the guidelines of fair use. We have strong security system called TiVo Guard(TM) that protects the interests of the studios. We don't support the inappropriate distribution of copyrighted content, and our users aren't asking for it.
MH: Given the large current userbase of TiVo and their comfort with the interface, I see parallels with eBay in terms of a rabid fanbase that has historical problems dealing with major UI changes. Has stability in the UI ever been a problem when developing new features?
MS: We are very careful not to change the UI just for change's sake. For example, three years ago, when we were shipping our 2.5 release we were thinking of changing the behavior of the ADVANCE button on the remote. Instead of simply jumping to the end of a program and then jumping to the beginning of a program we wanted it to stop on every 15-minute tickmark on the status bar. We thought this would be a handy way to get to a different part of the program more quickly.
We went to Beta and our testers complained. They were used to easily jumping to the end of a program and pressing LEFT to be prompted to delete it. Some had even programmed their Pronto remotes with this functionality. We quickly changed the design, and now the mode only applies if you are in fast forward or rewind mode.
Now we challenge each other to remember the "skip-to-tick incident" if we are considering making behavioral changes to fundamental UI behaviors. To mitigate having these problems, we try to design for the future (where we want to eventually take the feature) and then pare it down to what we are going to ship in a particular release. This lets us show how the experience will naturally evolve rather than having to radically change it to accommodate future functionality. We try to add to the experience rather than change it or take away something users rely on.
MH: How does your team decide when a feature or functionality is too complex to fit into the TiVo paradigm?
MS: In general a feature won't be ruled out as "too complex" because we have strong design team that can make anything easy to use. A feature will get ruled out if it doesn't apply or appeal to enough users. The TiVo service is for anyone who watches TV. My grandmother can use it. My toddler can use it. We are unlikely to add a specialized or power-user feature when our engineering effort can be better spent making entertainment better for everyone.
MH: What's the one feature or concept people find most confusing and how did you determine that?
MS: We learn about user confusion by tracking emails and calls to Customer Support, survey responses, issues in usability testing, watching people use the product in their homes, Beta reports, etc. There isn't one area that stands out as the most confusing, but there are areas of the UI we want to make as easy as possible. We would like the experience of un-packing the TiVo DVR, hooking it up to your TV, and configuring it for your cable or satellite provider to be simple and fun. We are working on innovative UI to help with this.
MH: TiVo is not only one of the best examples of powerful-yet-easy visual interfaces, I'd say TiVo is probably the only device that I actually enjoy hearing. The sound interface is a helpful, effective addition to the UI and rarely gets in the way. I can't point to many products that use sound effectively aside from TiVo and I'm curious how the team developed it. Were there long discussions or testing involved to help determine how intrusive sounds should be?
MS: Since TVs aren't silent, we didn't want the TiVo interface to be silent either. The initial sound concepts fell into a few categories. Some were mechanical, some synthesized, others more organic. We quickly identified the organic, happy sounds as better in line with our brand value of "playful". It actually didn't take too many iterations to get it right.
MH: The remote control that comes with a TiVo has been the subject of much writing in the past, but I'd love to hear about how that came about as well. While the TiVo UI was a breakthrough without equal, in the case of the remote, TiVo took something with 30+ years of history and remade it into something more useful than anything that had come before. How long did it take to develop the new remote? Did user testing prompt the team to make the pause button the largest or was that an early design that stuck around?
MS: The creation of the TiVo remote is well detailed in this New York Times article.
We continue to evolve the remote. The Consumer Design and User Experience teams work closely together to evaluate every button and question whether we *really* need it. We use the same research methodologies we use to evaluate the on-screen interface, only our prototypes are made of foam. A complex remote leads you to believe it is a complex product. Our remote is simple and elegant just like our UI.
Note: Paul Newby (Director, TiVo Consumer Design) and Margret Schmidt will be speaking at the monthly meeting of BayCHI (Bay Area Computer Human Interaction group) on Tuesday, December 14 in Palo Alto (open to the interested public).