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

17. 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.
July 2009 10th Sakai Conference - Boston, MA, U.S.A. 17

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 2009 10th 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 2009 10th 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 2009 10th Sakai Conference - Boston, MA, U.S.A. 20