1. The Best Defense (Support) is a Good Offense (Design) Christine Doherty User Support Specialist, Stanford University

2. 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 200910th Sakai Conference - Boston, MA, U.S.A.2

3. 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 July 200910th Sakai Conference - Boston, MA, U.S.A.3

4. 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) July 200910th Sakai Conference - Boston, MA, U.S.A.4

5. 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 July 200910th Sakai Conference - Boston, MA, U.S.A.5

6. Case Study: Site Tabs 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 July 200910th Sakai Conference - Boston, MA, U.S.A.6

7. Case Study: Site Tabs 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 July 200910th Sakai Conference - Boston, MA, U.S.A.7

8. Case Study: Site Tabs 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 July 200910th Sakai Conference - Boston, MA, U.S.A.8

9. Case Study: Site Tabs 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 July 200910th Sakai Conference - Boston, MA, U.S.A.9

10. Case Study: Site Tabs 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 July 200910th Sakai Conference - Boston, MA, U.S.A.10

11. Case Study: Site Tabs 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 July 200910th Sakai Conference - Boston, MA, U.S.A.11

12. 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 July 200910th Sakai Conference - Boston, MA, U.S.A.12

13. When/Why Design is the Answer 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 July 200910th Sakai Conference - Boston, MA, U.S.A.13

14. When/Why Design is the Answer 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 July 200910th Sakai Conference - Boston, MA, U.S.A.14

15. 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 July 200910th Sakai Conference - Boston, MA, U.S.A.15

16. 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 July 200910th Sakai Conference - Boston, MA, U.S.A.16

17. My Support Philosophy July 200910th Sakai Conference - Boston, MA, U.S.A.17 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.

18. 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) July 200910th Sakai Conference - Boston, MA, U.S.A.18

19. 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 July 200910th Sakai Conference - Boston, MA, U.S.A.19

20. Discussion Does your school integrate support into the design/development process? How so? Or why not? July 200910th Sakai Conference - Boston, MA, U.S.A.20