how not to destroy a great user experience
Download
Skip this Video
Download Presentation
How (Not) To Destroy A Great User Experience

Loading in 2 Seconds...

play fullscreen
1 / 46

How (Not) To Destroy A Great User Experience - PowerPoint PPT Presentation


  • 663 Views
  • Uploaded on

How (Not) To Destroy A Great User Experience Stories from the 2 nd 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'How (Not) To Destroy A Great User Experience' - Ava


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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
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
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
2 nd generation design at tivo
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
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
topic overview7
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
Learning How a Design Emerged
  • Document Archeology
    • From design team
    • From other teams
  • Identify Research Allies
  • Identify UI Historian
document archeology
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 archeology10
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 archeology11
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
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
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
topic overview14
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
continuing a design tradition
Continuing a Design Tradition
  • Foster a Design Culture of Collaboration
  • Include other Teams
  • Create a Shared Design Vision
foster a design culture of collaboration
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
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
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
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
Style Guidelines

Does anyone ever have time to write guidelines?

style guidelines21
Style Guidelines

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

style guidelines22
Style Guidelines

Don’t forget the “spirit”

extending the design
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
topic overview27
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
growing a strong design team
Growing a Strong Design Team
  • Adding new members
  • Conducting interviews
  • Initial projects for new hires
  • The Buddy system
adding new members
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
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
grading design exercises
“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
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
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
Keeping the Team Energized
  • Fix Known Problems
  • Create Concepts for Future Ideas
  • Get Ideas in Releases
fix known problems
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
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
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
topic overview39
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
documenting design
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
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
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
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
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
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
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?
ad