Fluid Content Management Research User Matrix

User research needs to cover a broad and diverse range of users. We want to make sure we are hearing from all the representative groups on Higher Education Campuses.

These profile matrices are meant to help us think through to kinds of people we want to talk to.  Many of these attributes will belong to a single user as we go out and talk to people. This is a way to help us make sure we are hearing from people that may have different goals and thus needs from our systems. For instance, a student might be in a graduate program and returning to school and have both project and course sites with medium amounts of content, etc.; There are also combinations of attributes from different boxes that is the make-up of a particular type of person we want to talk to. For instance, We'll want to make sure we talk to instructors from the various regions with various course structures.

This was initially one big matrix with user roles on the vertical axis and all the attributes on the horizontal axis.  The scrolling became much so I've broken them down into several matrices.

Planning Matrices

User characteristics, attributes and behaviors to keep in mind when choosing users to talk to

User Types

Application Use

Class Structure

Question:  Do class structures makes sense for educational technologists?  I'm thinking not but left them in for now.

Group Size

Questions/Concerns:

• We need to define what is meant by Small, Medium, Large.
• Do we really need to identify these attributes or are these really aspects that we'll learn about because of other attributes?  For instance, do we talk to instructors, TAs and students from small, medium and large classes since we'll talk to people in all those roles for the different course structures?

Technical Level

Country / Region

Question:  Others?

Type of Institution

Overall Questions:

• We originally identified designers and developers as users, which is true, they are users of the components we build and will have to understand and new UI models we create.  However, this is user research which focuses on user's of the system.  We will need to keep designers and developers in mind in how we communicate our solutions based on the research but I don't see them as specific Sakai users.  Other thoughts?
• I'm wondering if we should include support staff in our list users here.  Keeping in mind that content management is the scope, are support staff really managing content in Sakai.  I suppose they may be helping others manage their content.  This may be one way to decrease the scope of this work.  However, I don't want to miss something important either.  Thoughts?