What I used to think I knew isn't helping: adventures in higher ed open source

UX Principles

with 5 comments

In the midst of trying to shape a conceptual structure for communicating the Sakai 3 Design work, I’m riffing on an idea from the Drupal UX Project. At the top of all their pages they put:

Our UX Principles: 1. Make the most frequent tasks easy and less frequent tasks achievable. 2. Design for the 80% 3. Privilege the Content Creator 4. Make the default settings smart

I’m playing around with what they might be for Sakai. Here’s what I have right now:

  1. Make Good things easy, and the Best thing achievable.
  2. Design for user journeys, not institutional boundaries.
  3. Collaboration is core; administration is superficial.
  4. Make the user look and feel smart.

Update: Feel like I want to add a #5:

Learners are Researchers.


Written by khomotso

December 11, 2009 at 6:45 pm

Posted in Sakai

5 Responses

Subscribe to comments with RSS.

  1. “administration is superficial” would be better of as “administration is essential”. The people involved in managing those 1000+ student undergrad courses that are _only_ manageable with online support wouldn’t thank you for describing the key enabling features for them as superficial.

    I would also tweak #1 to something like “Make Good things the default” capturing the notion of choice architecture that helps people “do the right thing” without thinking about it or too much effort.

    Stephen Marquard

    December 11, 2009 at 8:08 pm

    • Yes, I need a word that can make the structural point without being confused for an evaluative one.


      December 11, 2009 at 8:13 pm

  2. For 5, “learners are also teachers; both are researchers” ?

    Stephen Marquard

    December 11, 2009 at 8:10 pm

  3. “Administration is collaboration.” 🙂

    Ray Davis

    December 11, 2009 at 9:50 pm

    • To expand that aphorism a bit… A lot of what our “end users” do (and a lot of what Sakai, Moodle, Drupal, and so on help them do) involves activity that a traditional IT department or commercial product might think of as “administrative.”

      In the interviews I’ve conducted for groups-and-roles, people especially treasured products that let them connect to the outside world in a straightforward way. Even if an instructor or tutor is fortunate enough to have someone else hook log-ins to personal names and email addresses, and hook enrollments to online memberships, they’ll still need to override those hooks and to understand how changes happened and what can be done about them. And we need to consider the sanity of their support staff, who are likely juggling many other jobs and software systems. And also the fact that instructors, administrators, assistants, and so on might _all_ be working on such tasks in an overlapping fashion.

      As a broader example, think of how many “integration” tasks have been nicely taken care of by RSS and Atom feeds. And as an extreme example, look at the mileage that Moodle and WordPress get out of being installable by “end users”.

      So when someone describes an “administrative” requirement, I agree it shouldn’t delay or warp the sort of collaborative work which takes place more often and with greater pleasure. But if it’s a real requirement, it needs some loving care. An urgent task that you don’t do very frequently isn’t the place for unclear UX.

      Ray Davis

      December 15, 2009 at 5:03 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: