[DG: Teaching & Learning] [DG: User Experience] User Goals

[Clay Fenlason]

I suppose I was thinking of a couple different ways in which themes
might be useful:

- remind us of things we left off, as we realize that certain themes
haven't been adequately fleshed out
- coloring in the backdrop of our users' worlds, for the benefit of
designers (e.g. it seems instructive to keep in mind how the first two
weeks of term often have different pressures and expectations than the
rest of the course lifecycle, and likewise the last couple weeks)
- provide cross-cutting insight into similarities between goals and capabilities

So I'd agree that the themes needn't always be resolved to user
expressions or frames of mind, and that they are ways to help us
organize and make sense of things.

At bottom, I'm taking this spreadsheet primarily as a way for those
with expertise and insight into our user population and its activities
- people on the functional side - to codify and communicate their
acquired wisdom to a design process, and to do so in a way that will
make the most difference to that design process. It is in my mind a
supplement to the user research underway, qualitatively different but
with complementary strengths. Though in some respects this expression
of practical wisdom is less pure in its methodology than user
research, it can also be more shrewd and incisive.

I have this picture in my head:

Functional experts & User Researchers  -->  Designers  -->  UI
Developers  -->  Back End Developers

At each gap along the way there is a bridging document which serves as
two-way communication or contract.  Between back-end development and
UI development there is an API specification. Between UI Developers
and Designers there is this budding pattern/component library. And
between pedagogists, user researchers and the designers there are
personas, contextual inquiries, user journeys ... and this spreadsheet
linking basic user needs to a rich array of capabilities.

~Clay

PS David is also gently nudging us to stop just talking and help with
the doing. I'm on it, though it's sometimes hard to do without feeling
disruptive.

On Thu, Nov 5, 2009 at 5:52 PM, Daphne Ogle <daphne at media.berkeley.edu> wrote:
> Another thing we might want to keep in mind as we create themes, is at this
> point (at least I think) the themes are a way to help us make sense of the
> large amount of information we are creating.  The categories themselves will
> of course shape the way we think about these goals (which I think does mean
> we don't want to get stuck in old assumptions) but I don't think they say
> anything about how they end up in the application.  The activity flows on
> the other hand, might be quite insightful around which activities are
> closely related, happen together, need to talk to each other, etc.
> As far as whether the categories make sense to faculty, I think it would be
> interesting to see if our categorizations make sense to them but I'm not
> sure it's critical since this is really a tool for the development team at
> this point.  But  it does seem more critical that the activity flows make
> sense to faculty, particularly if they help structure the design/framework
> of the application.
> Just kind of talking out loud...
> -Daphne
>
> On Nov 5, 2009, at 9:18 AM, David Goodrum wrote:
>
> Hi Clay,
> I agree this idea of activity flows would be a very fertile ground to
> pursue.  I would suggest this be in addition to, not in place of, themese
> that emerged among participants so far.
> I've gone ahead and added an Activity Flow column next to the major themes
> column so that everyone can start exploring the idea further.
> I think some of these will be alternate ways of expressing the current ones
> you described as more traditional, and other activity flows will involve new
> orientations that is important for us to uncover. I think it will remind us
> to make sure we get to a mental escape velocity from a tool orientation.
> This probably goes without saying, but I'll state it just to be transparent:
> Our and our users frustration with current tools like gradebook, forums,
> syllabus, resources, tests, surveys, activities, etc. is not because those
> ideas or even these terms are in themselves limiting (in fact instructors
> and students recognize these as common collections of activities); but we've
> come to realize that Sakai's implementation of them was too narrow.  From
> day one we've had faculty and students who wanted to do exactly those kinds
> of activities, but be able to do them more broadly and more synthetically;
> so they asked all the time, why can't I link my students directly from here
> to there? why can't I grade and give feedback to everything? why can't I put
> some of this in the middle of that? and so on.
> Your feedback along the way has been very insightful and helpful.  And feel
> as free as anyone to contribute directly to the spreadsheet.
> Regards - David
> ________________________________
> From: Clay Fenlason <clay.fenlason at et.gatech.edu>
> To: David Goodrum <davidgoodrum at rocketmail.com>
> Cc: Robin Hill <hill at uwyo.edu>; pedagogy Learning
> <pedagogy at collab.sakaiproject.org>; Sakai UX
> <sakai-ux at collab.sakaiproject.org>
> Sent: Wed, November 4, 2009 6:44:14 PM
> Subject: Re: [DG: User Experience] [DG: Teaching & Learning] User Goals
>
> I was having another thought about the themes that are emerging.
> Again, they seem to be mainly functional clumpings along traditional
> lines, but what if instead they wrapped around activity flows that
> tend to have related patterns, pressures and frames of mind, e.g.
> here's one that's (partially) temporal:
>
> - Start of term: all the setup, syllabussy, "need to learn my
> student's names" kind of things you deal with in the first few weeks
> of term.
> - Assigning and completing work, providing feedback: the activity
> workflows that form the main body of coursework, whether as projects
> in teams, or papers and assignments submitted individually
> - Assessment, exams, grading and other administrivia
>
> I can think of other functionally-oriented sets which are however less
> tool-centric, e.g.
>
> - Tracking learning and engagement
> - Content authoring and publishing
> - Mentoring, peer review and feedback
> - Researching a topic, finding references and resources
>
> Are there other thematic structures that might help relate goals
> better? I think notions like 'content management' don't really wind
> themselves organically around course activities in ways that are
> especially instructive for designing for users in our settings.
>
> ~Clay
>
> On Wed, Nov 4, 2009 at 6:11 PM, David Goodrum
> <davidgoodrum at rocketmail.com> wrote:
>> Hi Robin,
>>
>> I think that is a really fine example and I appreciate you sharing and can
>> relate to the struggle it can take to evolve to the right level and kind of
>> description.
>>
>> Of course, a goal doesn't have to be that perfect to get a row started on
>> the document; and others can then help by putting suggested wording or
>> alternate wording in the same cell in the matrix.
>>
>> This early on in trying to build this document up, it's most important to
>> get the ideas out. A structured brainstorming exercise, one might say.
>>
>> We can revise and refine, sift and sort, clump and cluster, and summarize
>> and synthesize in the next phase.
>>
>> Best Regards - David
>>
>> On Nov 4, 2009, at 2:47 PM, Robin Hill <hill at uwyo.edu> wrote:
>>
>> Since I take this seriously, having spent years teaching computer
>> science students to separate design from implementaion, maybe I can
>> illustrate the process and the difficulty with a spreadsheet entry of my
>> own.
>>
>> ========
>> From the point of view of an instructor (of a logic course):
>>
>> 1.  I want an Example Bank.
>> Bad-- no functional description.
>>
>> 2.  I want a set of tagged text records in an associative array.
>> Bad-- assumes a particular mechanism.
>>
>> 3.  I want to maintain my examples in a personal blog that allows labels
>> on postings.
>> Bad-- assumes a particular tool.
>>
>> 4.  I want examples that I can look up and use.
>> Bad-- too general and vague.
>>
>> 5.  I want to save example of statements and reasoning when encountered
>> in daily life, and I want to retrieve them based on their properties
>> when composing course materials.
>> Good!
>> ========
>>
>> Clay is welcome to comment, especially if this is NOT what he has in mind.
>>
>>
>> Clay Fenlason wrote:
>> On Wed, Nov 4, 2009 at 1:15 PM, Luke Fernandez
>> <luke.fernandez at gmail.com> wrote:
>> I guess the question is whether there is a point where we should
>> take the technological needs which our faculty articulate at face
>> value.
>>
>> My experience is that this is most often counterproductive. I think
>> this is why UCD starts with user *research* as opposed to simply
>> asking the users what they want. The important considerations are
>> very often the ones we are not conscious of, let alone those we're
>> able to articulate well, not to mention articulate a solution that
>> will also work for other people and fit well with other technical
>> solutions in the same space, and so forth. It takes talent to
>> synthesize sets of needs and come up with good answers, and that
>> talent is not aided by leaping into implementation details too
>> quickly.
>>
>> My underlying aim is to see us build something helpful and useful,
>> not do a product comparison (and maybe that's why you are coming at
>> this from a different angle). We've got designers ready to do work,
>> and they're the ones with the sort of talent I indicated above. We
>> need to help them cut through to what's essential, not get distracted
>> by incidental detail.
>>
>> I think we're all familiar with conversations where someone confronts
>> us with their issue, we start to raise possibilities or workarounds
>> and press on details of what they're asking for, until they finally
>> throw up their hands and say, "Look, I just want something that will
>> <insert simple thing here> and not be a PITA, and if you can give me
>> that I'll be happy." When they get to the point of putting it that
>> way, then I think we're getting somewhere.
>>
>> ~Clay _______________________________________________ pedagogy
>> mailing list pedagogy at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>>
>> TO UNSUBSCRIBE: send email to
>> pedagogy-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>> --
>>  Robin Hill, Ph.D.       hill at uwyo.edu       307-766-5499
>>  Instructional Computing Services            http://www.uwyo.edu/ctl
>>  Ellbogen Center for Teaching and Learning   University of Wyoming
>>
>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email
>> to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>>
>>
>>
>>
>
> _______________________________________________
> pedagogy mailing list
> pedagogy at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email
> to pedagogy-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne at media.berkeley.edu
> cell (925)348-4372
>
>
>
>