Design deliverable & process working documents

[Anastasia Cheetham]

On Apr 10, 2007, at 7:26 PM, Daphne Ogle wrote:

> The UC Berkeley design team met with the ARTC FLUID development  
> team last week to continue thinking about design process and  
> deliverables for FLUID.  We thought it would be good to share our  
> discussion with this larger group.  I put the attached word doc  
> together as a starting point for last week's discussion.  Based on  
> our discussion I added a few more details to the doc and drafted  
> (very roughly) some diagrams to visualize a possible component  
> design process (very high level -- probably better labeled as a  
> requirements definition process) and what user profile matrices  
> might look like (both of which are outlined in the doc).  I've also  
> attached a matrix Charles Kerns (longtime instructional designer at  
> Stanford University) sent out on the Sakai list last week.  In much  
> more detail than my drawings, he gets at the kind of things that  
> affect how users have different goals and needs from the systems  
> that FLUID is focusing on.  It would be great to start discussing  
> and fleshing out the ideas in this larger group.  What do people  
> think?  What's missing, confusing?  Where do we go from here?  Of  
> course we can discuss and review these at our face to face next  
> week but perhaps we can start some preliminary discussions on this  
> list?

Daphne, these documents look great. I've written up some psuedo- 
random thoughts that came to me as I read the documents.

I'm not a designer, so forgive any naivete in my comments...


Regarding the definition of a component: "implementation of a design  
pattern for a particular persona (archetypical user) in a particular  
context (scenario)"

Is 'design pattern' too high-level in this case? I'm thinking about  
the design patterns that have been written up on the UI DG site in  
Sakai, and it seems to me that an 'implementation' of these patterns  
might involve more than one component. Maybe it's my engineer's  
brain, but I've been thinking of a component as something much more  
fine-grained.


Regarding users/personas: These always seem to be Sakai and UPortal  
people - should we include Kuali and Moodle?


Regarding swappability: At what point in the design process would  
consideration of swapping come into play? What is the relationship  
(if any) between the personas and the factors that would control  
swapping?



--
Anastasia Cheetham                   a.cheetham at utoronto.ca
Adaptive Technology Resource Centre / University of Toronto
(416)946-3582

        "I would rather have a mind opened by wonder
                 than one closed by belief."
                                 --Gerry Spence