Best Defense

The Best Defense (Support) is a Good Offense (Design)

Christine DohertyUser Support Specialist, Stanford University

Background• User Support Specialist at Stanford since January 2007

• Running Sakai in full production since June 2007

• CourseWork Team: Project Manager (1), Developers (3), Designers (2), QA (1), System Admin (1), Support (1)

• Answer all help tickets, get most direct feedback from users, understand the pain points of using the system

• Role of user advocate, adding user feedback into development process as part of UX team

• My goal/struggle is always how to help users help themselves or use the system without help

July 2009 10th Sakai Conference - Boston, MA, U.S.A. 2

What’s the Problem?

• Ran Self-Help Resources panel at last year’s conference, in an effort to help users find answers

• Experimented with different types/placement of self-help content

• Found that same support issues came up every quarter, despite best efforts to “educate” users

• Self-help resources did little to reduce the main support issues


Why so important?

• Selfish reasons: Tedious to copy/paste boilerplate answers to same question 50 times a day, 2 weeks every quarter

• Legitimate reasons: Support time could be better spent on other tasks, valued-added services

• Best reasons: Critical for end users to have good experience with system, to be able to complete basic/necessary tasks without stopping to submit a ticket (causing wasted time/frustration)


Case Study: Site Tabs

• Most common support problem: “I can’t find my course site” (mostly students)

• Common cause of problem: User didn’t see the ‘more’ drop-down menu with additional sites



• Attempts at educating users:

• Created FAQ, Quick Start Guide, video tutorial about how to find course sites

• Gave demos to departments

• Created Top Questions section on gateway page with link to FAQ about how to find course sites, also appeared in My Workspace Home page

• Tickets concerning access to course sites still largely caused by ‘more’ drop-down menu



• Solution: apply My Active Sites tab, feature contributed by Indiana University• Clear, intuitive name• Better placement (always right next to last site tab)• Better display of sites organized by term/type



• My Active Sites tab was scheduled to be part of Stanford’s Spring 2009 release

• Nearing end of code freeze period, there was some talk of deferring this feature for another release, due to time involved in applying/styling

• Why? This feature has always been viewed as a nice-to-have enhancement

• I insisted this was of critical importance, as I now had years of explaining the ‘more’ drop-down menu to users



• Thankfully, this feature was given priority over some other bugs and made it to the Spring 2009 release

• Took 3-4 days of designer time working on CSS, organization of display

• Took 5 days of developer time merging code

• Not so much compared to amount of time answering tickets every quarter for years, creating many different forms of self-help documentation, holding training sessions



• My Active Sites tab was highly successful in resolving that particular interface issue

• Only 4 help tickets in the first few days; a few javascript issues and some mild resistance to change

• No more tickets regarding access to course sites caused by sites in overspill menu



Why didn’t we do this sooner?

• Major interface/usability issues sometimes seem daunting

• We had long list of bugs and feature requests; taking time for applying this feature would require sacrificing other things

• In early days, I didn’t put enough focus on influencing priorities with support issue trends


When/Why Design is the Answer

• Interface/Usability issues are not well served by help documentation• Users don’t expect to need guidance on using the interface

• Users don’t want to read documentation

• Users are very busy; need to complete basic tasks in minimal time

• Users are too panicked about issues like access to course sites to think of turning to self-help



• How do I know that is true?• Feedback from users submitting help tickets indicates their

feeling that the system should be as intuitive as other web sites (Google, Facebook)

• Surveys indicate that students don’t read help documentation and don’t feel they need training; they are more likely to figure problems out themselves



• Design can’t be the solution for all problems: speed, stability, storage

• However, our users continue to indicate in surveys that the interface is their biggest complaint (from pilot surveys in 2006 to the latest survey in Spring 2009)

• Any solution that allows users to intuitively do what they need to do without having to think about it or stop to read about it will be more effective


Stanford UX Process

• User Experience group combines design and support staff to feed support into design and share efforts

• Weekly meetings to discuss:• Support problems• Communication/outreach efforts • Soliciting feedback from users• Evaluating new tools/designs


Stanford UX Process

Release cycle:

• Prioritizing bugs/features• Design specs/mockups• Review designs• Work with developers as coding is in process• Review QA test plans• Conduct preliminary QA during coding• Help test bugs during QA period• Post announcement about downtime for release• Post announcement/release notes after release complete


My Support Philosophy


Support time is better spent fighting for a design solution to cure a usability problem, rather than spending time treating the symptoms of that problem over and over.

Recommendations for Support Staff

• Support is a very important part of entire development process; see yourself are the users’ advocate

• Make the case for integrating efforts of support and design

• Involve yourself in release prioritization, design reviews, QA to spot potential support issues early (before released to users)


Recommendations for Support Staff

• Use ticket tracking system or find way to collect statistics on support issues to identify biggest problems, especially those caused by interface/usability issues, and to help make your case for priorities

• Seek feedback from users about the scope and impact of problems they report

• Review Sakai JIRA for solutions to these problems; make case for applying patches/designs that will have greatest impact on users


Discussion

• Does your school integrate support into the design/development process?

• How so?• Or why not?


Education

Best Defense