The Audience Matrix Evolves (and how you can play at home)

leisareichelt's picture

We've just added a new video to the YouTube Channel which we refer to in this post - check it out now:
http://www.youtube.com/watch?v=ShBPEL_ckJw

Over the past week or so Mark and I have been working out the details that go on the panels of the Audience Matrix that we shared with you last week (http://www.disambiguity.com/understanding-our-audience-part-1-drupal7-ux...) (or dress-up-doll document as it has otherwise been named). We’ve made a few changes and added a bunch of definitions.

Here’s what we’ve come up with so far:

ROLES:

* Content Creator: a user who primarily creates, reviews, and edits content for a site. Key tasks: Add  content, edit content, find existing content, view list of content creation/revision tasks.
* Site Editor: a user who has authority to approve, edit or reject content and who may be able to manage some editorial workflow and user permissions. Key tasks: Add  content, edit content, find existing content, view list of content creation/revision tasks, review content, reject/feedback on content to original author, schedule content,
* Site Admin: manage user permissions, manage site structure, adding new content types, create and review reports and manage some site settings (RSS Publishing, IP Address Blocking). Key tasks: Manage user permissions, Add / Edit / Delete Content Types, Manage Information Architecture (site sections, sub-sections, taxonomy (as in, vocabulary), Create a report, Review a report.
* Site Builder: creates site from scratch by choosing, writing, customising modules and/or themes, manages setup and maintenance. Is a developer (for the purposes of audience definition, themers are considered developers). Key Tasks: Develop site functionality, implement site design.

question: who can/should be able to create new content types? who can create new site sections and subsections (vocabulary and/or terms) etc.

TYPE OF SITE:

* Brochureware Site: hierarchical structure of relatively static content, often includes forms (eg. contact/feedback), may be multi-author
* Blog: sequence of chronological posts that may be assigned to categories, may also include ‘fixed’ pages, often includes comments, trackbacks, RSS feed, most often single author
* News: a categorical/hierarchical grouping of content usually ordered chronologically but often ‘curated’ by an editorial team, may also include  comments, trackbacks, RSS feed, often multi-author, often requires multiple templates
* Events: a combination of content supporting an event, including content about the event, a schedule/calendar of events, list of participants,  online registration, may also require online submissions, social networking functionality, news, email update list
* Social Site: comprises member profiles and communication between those member in the form of discussion forums, wikis, events, blogs, require member signup, subscription, RSS,

NO. OF USERS

* 1 : no permissions, no workflow, that user does everything (one stop shop) BUT most like to have simple requirements (how manage giving access to all functionality when the mostly won’t need it). Likely to generate small amounts of content.
* 2-5 : multiple authors, may require permissions, may require workflow (simple approval process), may require separation between content management tasks and site management tasks but usually not overly complicated requirements.
* 6-15: multiple authors and editors, likely to require permissions, likely to require workflow, likely to require separation between content management tasks and site management tasks may have some complex requirements, will have significant amount of content generated.
* 15+ : requires permission management (several permission profiles), probably requires workflow (content review/approval), likely to generate a lot of content to be managed and require content scheduling - it’s a complicated machine and it needs a whole section around managing the machine, let alone making the content to feed the machine. Involves a lot of content and likely complex taxonomy.

question: should it matter how much ‘experience’ you have with Drupal? Should we add another row for this? (Insider/Midsider/Outsider) - we can’t decide. One one level it seems like it does matter, but we also think that it shouldn’t matter… would adding this add unnecessary complexity? (For the time being we’re leaving this out).

PLAY ALONG AT HOME!

This is going to be a pretty instrumental tool for us on this project and we’ll be referring to it regularly. If you’re interested in checking it out in more detail or if you’d like to get more involved in this project, the perhaps you’d like your very own copy. Yes? Well, you’re in luck because you can now download a copy here: http://www.disambiguity.com/Drupal7UX_AudienceMatrix_V2.pdf

HOW TO USE THE MATRIX:

Over the coming weeks we’re going to be inviting you to submit your ideas for revisions to the Drupal7 Admin interface and overall user experience. It will be very helpful for us all to use this document to help make sure that we’re designing for the 80% and not necessarily just for ourselves! And it is also a really great way to expose missing elements and possible flaws in our concepts. Using the document to test the example we show in the video above helped us to realise that we needed things like a close button on the dashboard (I know, d’uh!), a place to hold the user generated content from things like comment as well as contact forms, and got us thinking about a whole host of thorny permissions and workflow issues. (Don’t get me started!)

This is, however, a living document - we welcome your feedback and questions on the changes we’ve made and how we’re using it - so, please - let us have it :) (but don’t pay too much heed to the concept we’ve presented as an example in the video, it is very early days and it’s just one of many ideas we’re working on.)

x-posted at http://www.disambiguity.com/drupal7ux-audience-matrix-evolves/

Comments

like it!

kyle_mathews's picture

This isn't very interesting feedback. . . but on the PDF, the "social site" text is a dup of the "site builder" role.

I really like how you've broken down things down into roles/type of site/num. users. It's a very nice conceptual framework.

I don't think experience should be another field -- if the admin UI is simple to learn/use -- any Drupal newbies should become experts fairly quickly making the question of experience mute.

Kyle Mathews

Kyle Mathews

As it relates to your role

michaelfavia's picture

As it relates to your role definitions above i would place content type creation in the "builders" hands and reserve vocabulary management for the administrators. This leave editors and content creators with the ability to use content types to their "built capability" and assign and possibly create vocabulary terms as they see fit.

The reasons i split these tasks along these lines are multifaceted but have alot to do with the domain specific knowledge required to carry out each task and how it relates to the other tasks such a role would be expected to perform. (e.g. An admin role shouldnt be expected to know that the content type XYZ is using the custom validator module ABC to make the system function as desired.)

Experience of users

EBacon's picture

Hi Leisa,

I've always found that Cooper's suggestion to design for the 'perpetual intermediate' was very helpful. Few people remain total noobs; few people become decidedly expert. Most remain a perpetual intermediate, encountering new things sometimes & repeating routine stuff sometimes. Considering what (little, admittedly!) I know of Drupal admin users, however, I'd bet there's a significant number of experts. If I were making personas, I'd probably consider the needs of an expert user of some role flavor while primarily serving the rest as perpetual intermediates.

Cheers,
LIz

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week