How (Not) To Destroy A Great User Experience

How (Not) To DestroyA Great User Experience Stories from the 2nd generation of UI designers at TiVo Rich Fulcher, Zing Rachel Garb, Google Alex Liston, TiVo Donna Slote, Good Works Design

About Us • From the TiVo UI Design Team • Rachel: 2001- 2005 • Donna: 2001- 2005 • Alex: 2003 - present • Rich: 2004 - 2005 • Overlapped for a period of two years (2003 – 2005)

About TiVo • TiVo is both a product and a service • The TiVo “Box” is a Digital Video Recorder (DVR) • Records television shows on a hard drive • Users interact with a TV UI via a remote control • The TiVo Service delivers programming data to the DVR • Knows time and channel every show is on • Users can search by name, setup Season Passes to record every instance of their favorite shows, and more • DVR and Service communicate • Via phone line, satellite feed, or internet connection • Internet connection enables additional features

Generations of TiVo UI Design • 1st Generation: 1998 – 1999 • One UI Designer in collaboration with engineers and video production team • 1st UI Designer left, and a couple more came onboard • 2nd Generation: 1999 - 2005 • TiVo emerged as leading DVR brand • New UI Design Manager joined to grow team and its processes • Focus on evolving features and platforms • 3rd Generation: 2005 - present • New CEO and executive team, corporate restructuring • Turnover of UI Designers from 1st & 2nd Generation • Huge company growth, including UI Designers

2nd Generation Design at TiVo • Millions of users • Well recognized brand • Extremely passionate users who evangelize the product • Our job: “Don’t screw it up!”

Topic Overview • Learning the story behind an established user experience • Continuing and extending an established design tradition • Adding new designers to a team, and keeping veteran designers engaged • Documenting in a way the helps future generations of products and designers

Learning How a Design Emerged • Document Archeology • From design team • From other teams • Identify Research Allies • Identify UI Historian

Document Archeology • Collect docs from previous design teams • Wireframes and detailed mockups • Block flows and detailed flows • Functional specs • Style guides and pattern libraries • Scenarios and use cases • Personae • Object Models • Prototypes

Document Archeology • Collect docs from UR & marketing • User research • Research findings • Research questions • Log/traffic analysis • Marketing • Branding guidelines • Market segmentations • Surveys • Competitive analysis

Document Archeology • Collect docs from other teams • Executive mantras / tenets • E.g. “Don’t break my television” • Engineering Artifacts • Architectural documents, object models, use cases, etc • Comments in code or bugs • Customer service reports • Email archives • Knowledge nuggets that haven’t been archived elsewhere • Other serendipitous discoveries on shared resources

Identify Research Allies • User Researchers • Get old reports, highlight tapes, etc • Learn their pet peeves / existing issues • Market Research • Surveys, user satisfaction results, etc • May be source of segmentation data that can guide personae • Get invited to their meetings • Research roundtable

Identify a UI Historian • Your UI Historian(s) may come from design, engineering, or even product management • Find a passionate grizzled veteran • Original builder/designer • Someone who would know the arcane reasons behind particular design decisions • Architectural / performance / legal constraints • High-risk areas • Things that have failed in the past • Include and empower them • Make them extension of design team

Continuing a Design Tradition • Foster a Design Culture of Collaboration • Include other Teams • Create a Shared Design Vision

Foster a design culture of collaboration • Sit together • Cover the physical space with design ideas • Act like a team • Form an identity with the corporate culture • Leverage the team’s strengths • Have multiple design meetings each week • Bring designs to be critiqued • Try different brainstorming techniques • Invite research and your UI Historians • Learn from each other • Task analysis methods • Design skills • Presentation techniques

Include other Teams • Engineering • Include developers in design reviews • File bugs • Attend bug councils • Build and maintain relationships with teams that are directly affected by the UI • Customer Support • Documentation • Weekly Homework Meetings

Create a Shared Design Vision • Adopt, Elaborate, and Evangelizing the Design Principles: • It’s TV, damn it! • “Lean back” user experience • Document the Design Language • Common UI specification • Style Guidelines

Common UI Specification • Document global behaviors and elements in one place • Navigation model • Widgets • Sounds • Agree on a shared vocabulary • The process of defining the vocabulary is useful • “Unique” but descriptive vocabulary helped with adoption

Style Guidelines Does anyone ever have time to write guidelines?

Style Guidelines Create a new screen? A widget? Capture it for the guidelines.

Style Guidelines Don’t forget the “spirit”

Extending the Design • Don’t sacrifice existing, fundamental behaviors (or introduce conflicting behaviors) • Do take advantage of new capabilities if it enhances the UE • Identify the core elements of the design language which must be carried through to maintain tonal consistency

Extending the Design - Examples

Growing a Strong Design Team • Adding new members • Conducting interviews • Initial projects for new hires • The Buddy system

Adding New Members • A single bad hire can disrupt an effective team • Be particular when hiring new members • Allow bulk of team to participate in interviews, plus representatives from teams with critical relationships • Always interview multiple candidates to gain “perspective” • Make sure there is a attitudinal fit • Do they believe in the design & research partnership? • Can they be free of ego in their design work? • Do they have passion for the product? • Don’t rely solely on pedigree / credentials • To see their skills at work, use design exercises

Design Exercises in Interviews • A good design exercise will be: • Focused (but still provide a variety of responses) • Accessible to those new to the domain • Short – not a lot of setup required • Many types: • “Blank slate” with only a few requirements • Take a “broken” design and improve it • Critique a new (unfamiliar) design • Don’t provide problem in advance • You want to see their “natural” problem-solving style • Each designer can re-use their favorite

Sample Design Exercise

“Grading” Design Exercises • You’ll get a “solution” you can evaluate, but at least as important is seeing how the designer works • Some good signs: • Talks about users, tasks, and contexts of use before diving in • Asks intelligent questions • Explicitly identifies assumptions they are making • Applies even modest knowledge of product space • Some bad signs: • Can’t meaningfully critique the example • Only follows one design path • Can’t communicate rationale behind their decisions • Becomes argumentative in response to feedback

Initial Projects for New Hires • Some approaches to first projects: • “The Shepherd”: guide a mature project to completion • Learn about existing products and documentation standards • Develop relationships with engineering, QA, etc • Might seem a bit dull • “Trial by Fire”: work a small, well-contained project start-to-end • Gives a sense of ownership and immediate contribution • Can be quite valuable if a languishing project needs fresh thinking • Potentially overwhelming • Avoid silo’d projects which prevent broader learning • “The Spec Monkey”: take all the spec bugs and fix ‘em • Can learn a lot about a variety of products • BUT … may not really feel like they’re making a real contribution • You may be able to “audition” designers by hiring them as contractors first, moving to full time later

The Buddy System • Assign the new designer a buddy designer more familiar with the process/products/culture • Buddy need not be more senior; merely more rooted in the organization • How a Buddy helps: • Introductions to co-workers and navigational guidance • Explanations of processes, documentation standards, etc • Sounding board for design ideas • Drags the new design along to helpful meetings • Being a good buddy takes effort • Don’t assume this comes for “free”; ear-mark 25% of the buddy’s time for at least a couple of weeks • Recognize the holes in “start-up” documentation and fix them

Keeping the Team Energized • Fix Known Problems • Create Concepts for Future Ideas • Get Ideas in Releases

Fix Known Problems • Too often, even features that are widely recognized as flawed don’t get attention • They’re not the “new thing”, or they’re “good enough” • The solution may not be simple or obvious • Their continued presence can drag down morale with each release that fails to address them • Give designers time to work these problems • Clearly state the problem • Explore multiple solutions and review with team • Test the best designs (tag-on studies) • If you find a solution, make it ready to implement • Document the design • Work out any required visual assets

Create Concepts for Future Ideas • Allow the team some time to brainstorm about some “what if…” scenarios unbounded by technical constraints, and then scale back • Create scenarios and storyboards describing this new experience • Useful for early user testing • Should clearly articulate the user benefit • Valuable for enticing product management • If interest, develop further • Concept “whitepaper” • Build prototypes

Getting Ideas into Releases • Sell the designs internally • Get them on product marketing’s radar • “Brand” simple fixes to turn them into Features • When an area gets touched, sneak in some fixes • Use all architectural overhauls as an excuse to “Do it the right way this time” • Make friends with passionate/maverick engineers • Excite them, and they may just build it on their own • Once implemented, even partly, it can be much more attractive to product managers looking to pad the feature list of a release

Documenting Design • Don’t just capture “now”, also capture “before” and “after”. • Don’t just capture “what”, also capture “why”. • Having a standard format for UI specs can help with this

Capturing “Before” • Track all UI design changes in a bug database so all design decisions and discussions are well archived and you know who was involved. • Include a Change History section in the UI specs and link changes to specific bug numbers. (This is good for CYA too…)

Capturing “After” • Use a bug database to submit all feature enhancements and store all futured behaviors. • If a feature gets futured, leave it in the spec (but grey it out) • Devote some time to “speculative” design: Work on wireframe concepts for new products and features that may be years down the road. • Hang them on the wall for inspiration • You may be gone when they finally get built, but you’ll help the next generation of designer

Capturing “Why” • Documenting “before” gives you a lot of the “why”. • Devote a place in the UI spec for any free form notes not covered well in bug history.

UI Specs • Design a standard format that helps both readers and writers of specs • Get input from Engineering, QA, Product Mgt., and UI Designers • Try it out on a sample project and work out the kinks. • Finalize it and make it the work product of the UI Design Team. • If necessary, include a “Read Me”.

Conclusions • It’s not uncommon to have significant generation gaps between design teams (especially small ones), but some digging can help fill these gaps • Clearly articulating a design vision benefits the design team both internally and externally • Making good hires, incorporating them into the team quickly, and keeping the design work moving forward helps keep the team’s energy high • A designer who cares about the product and their contributions to it should take on the responsibility of documenting their work for the future

The End • Paper and functional spec templateare on your conference proceedings CD • These slides will be posted to: • The conference web site • http://homepage.mac.com/rfulcher/upa2006(this URL is also in the paper on the CD) • Questions and Comments?

How (Not) To Destroy A Great User Experience