Fluid Course Administration & Content Management Personas
The Fluid Course Administration & Content Management [Personas] are models used to represent the information gathered during the user research done in the Fluid [Content Management Research] project. They are models of archetypical users in this domain, and are used to inform the design and development process of Fluid [Components]. Some of these personas are provisional, which means they were not based directly on this user research, but represent user types we know from previous research are important and should be represented. \[<span style="color: #cc0000">we have a page that describes personas. i wonder if we should just add any of this information that isn't already there and have this page just be about the personas. or at least move it to after the personas?]</span>
These personas will also be useful to communities working on projects in the Course Administration & Content Management domain. We anticipate the need to add additional information to these personas for more focused domains (e.g. Content Authoring). \[<span style="color: #cc0000">let's talk about this. i think content authoring falls nicely into the core course admin and content management realm]</span>represented.
These personas will also be useful to communities working on projects in the Course Administration & Content Management domain. We anticipate the need to add additional information to these personas for more focused domains (e.g. Collections Management).
Types of Personas
The design of all Fluid Components will be informed directly by the Primary & Secondary personas below. By definition, each primary persona requires their own user interface in a particular application. A secondary persona is one whose needs will be mostly served if the needs of the primary persona is met. There may be small additions to the interface necessary to meet the needs of a secondary persona, but these additions should not negatively affect the experience of the primary persona. (If this were the case, this secondary persona should be another primary persona and have their own interface.)
Auxiliary personas do represent models of users we saw in the field, but we don't believe are different enough from the primary and secondary personas that it is helpful to keep them in mind. However, we are making them available so that they can be used in a particular problem space as necessary. For example, Michael Demsky, the Departmental Support Person, is not that different from Anita Stalmach, who does Departmental Pedagogy Support. However, if there was a use case that involved this person doing a lot of section management, it may be more helpful to use Michael.
Additional personas may also be created based as additional user research is done (or as provisional personas if user research is not an option). This may prove necessary if we realize we don't have enough information on users in a particular problem space. For example, if we are working on reordering images, we may want to have a professor in the Art History Department as a primary persona to inform our design & development process. \[<span style="color: #cc0000">This distinction about when we would have different primary and secondary personas is a tricky one. i think we want to think about in regards to problem spaces rather than tasks. So reordering is a task that can be done many different problem spaces. Our current personas are great for typical image work - including reordering images. If we want to tackle the problem space of managing personal media than we would want to talk to people in art history and architecture to understand how image/media-heavy</span> <span style="color: #cc0000">disciplines might differ in goals & needs</span>.\]on a reorderer component in a context/problem space where reordering large collections of images is the primary use case, we may want to have a professor in a media-heavy discipline, such as Art History or Architecture, as a primary persona to inform our design & development process.