February 8 and 9, 2010

Meeting Goals

We have completed the first part of the User and Domain Analysis document, which includes findings and 12 persona descriptions. Before we finalize this, we want to check in to make sure that the personas cover the most important aspects of the users that were interviewed.

Part 1 document is posted--you may review it, or you may wait first for a verbal overview on Monday or Tuesday's meeting before diving in.

Update: the PPT from this meeting has been posted with Persona photos.

Who

Anyone in the T&L and UX communities, especially those who conducted end-user interviews for this project. However, if you didn't participate, please review the background for this project, as we will be diving straight into results.

If you think you will come, please add your name under the attendance notes so we can get a sense of who is coming when.

Where and When

Notes

In attendance Monday Feb 8

• Robin Hill

In attendance Tues Feb 9

• Mark Notess
• Daphne Ogle
• Clay Fenlason
• Kristol Hancock
• Salwa Khan
• Ann Jensen
• John Norman
• Robin Hill
• Brian Dashew
• Makoto Tsuchitani

Summary

We were lucky that representatives from 6 of the 8 participating schools could attend, as well as others involved in the design initiative for Sakai 3. Keli presented overall findings and 12 personas, as well as possible next steps.

The interviewers who attended said that the persona, for the most part, represented the interviews they conducted (see full notes for exceptions). Since this was just an overview, they still have the chance to read the document  in full and comment further. I am hoping to get comment from VT and Michigan, as well as from schools who didn't conduct interviews. I'd like to get comments by Feb 22 (will be on vacation and working on local projects between now and then).

With only 60 minutes, however, there wasn't a lot of time to gather feedback on other things, like the problem/vision statement and the potential next steps, so please read on.

Problem and vision statements

I wanted to make sure we reviewed the persona, so we skipped over the problem and vision statements. Although it sounds grand, they are simply terms from the goal directed design process. The problem statement is essentially a summary of the findings, and the vision statement is a direct inversion of that; they are included in the full notes.** Vision statement is a recommendation for future direction and doesn't imply immediate next steps. It hasn't been bought into by anyone, but the sponsored work by Sam Peck, with it's unified views and integrated communication, seems to already be headed in this direction.

Next steps: focus decision

We also had to rush through potential next steps before I could get comment. As described at the kickoff of this project, we're using the 6 step goal directed design process. We've completed two steps of goal directed design, Research and Modeling. Before we move onto the last two,  Design and Development, are two bridging steps: Requirements Definition and Framework Definition.

We don't mean "requirements" in the strict, traditional development or contract sense, but simply, a) what are the persona's expectations for what this should do and how it should behave, b) what are the context scenarios that describe at a high level what the persona has to do c)  based on that, what are the data and functional needs.

The framework definition is the beginning of the sketching. Data and functional needs are given homes and shown in orientation to each other. One uses scenarios to walk users through them.

The question is where to focus efforts next: cross-activity needs or activity-specific needs. Sam has essentially started the framework definition mostly for paper submission; it would be interesting however, to create scenarios that test to see how that design might need to be adjusted to meet the needs of specific persona (or see if it already works). This would not for immediate design but for plotting future directions; it could occur in parallel and would result in narrative, not pixels. Alternately we could delve into areas that are completely untouched, such as problem-set specific needs that aren't common at all and haven't been touched.
Thank you

Keli Amann

User Experience Specialist

Academic Computing Services, Stanford University

*Feedback on Personas (extended to 90 minutes)

-Robin said that maybe we needed to represent an older humanities professor who is not really using Sakai and doesn't really know what it can do. I suggested perhaps Landon, though young, could represent this. I may not have understood the extent of Robin's comment, so maybe we can touch base later.

-Ann or Salwa said that in their case, Amanda would have a much more active role in design. I plan to follow up, as well as with other folks who interviewed instructional designers. It's possible we can tweak the division of labor between Bob and Amanda, though making Amanda more active might take it away from other directions. Or Bob and Amanda are overextended and we need another persona or two.

-Daphne also said that she wasn't sure if Amanda represented their instructional technologists. I said that Amanda was more of a hands-on role, though she had aspirations to be more advisory and think creatively about technology, because she was also representing people we talked to who were in charge of integrating content into the system. Like I said, she might be doing too much

-A couple folks also pointed out that no one interviewed a TA. There was one TA interviewed (by someone not at the meeting) but was very different from Irina. Also, another type of TA would be a undergraduate grader type---someone like the persona Terry might work with this person, so we might need a provisional person.

**Problem Statement

•  Instructors and students have to manage multiple tools for different assignments in their class or classes.
• Often these tools are outside the CMS, which offer them flexibility but also additional management burden.
• They communicate about the assignment separately (announcing it, asking and answering questions about it), meaning information about an assignment loses its context.
• When an activity can't be described, answered, or graded with simple text or a button selection, instructors and students must use external applications and/or print/scan their work to create or complete an assignment.
• Instructors have separate process for managing related, offline problem sets.

Vision Statement

To create unified creation, deployment, and access to all learning activities by

• Giving instructors and students a common view across activities and classes to help them plan,  direct their attention, and improve.
• Planning for peer involvement and adjustments in deployment
• Integrating communication into the context of the assignment
• Making it possible/easier to create and submit assignments that require rich text or multimedia expression directly online
• Allow offline activities to take advantage of online capabilities.