Sakai UI -- On Lightweight Design Processes

Here's a post I made to the sakai-dg-ui list in response to a thread about using some fairly "heavyweight" design processes:

===

I agree with Kathy about being careful not to set artificially high barriers to entry wrt improving Sakai UI/design.

While the results from "Contextual Inquiry" may or may not be provably better than from "Contextual Design" which may or may not be provably better than whatever other methodology has been mentioned, (all of which rely heavily on the skills and experience of the practitioner), Joel Sposky (go down to rule #12):

http://www.joelonsoftware.com/articles/fog0000000043.html

seems to agree with Jacob Neilson:

http://www.useit.com/alertbox/20000319.html

that even informal usability testing with a handful of users can see dramatic improvements to an interface. My experience is the same.

And, let's be honest, I suspect that every member of this list has their "Top-5" list of problems they'd like to see solved. Put all those together, and I know the UI would see a dramatic step forward.

(Thought experiment: why not eliminate all 2.5 OOB skins except for the "main" one and four spots for "new" ones, and let this group self-organize to create the "new" ones? No voting, they all go in... a nice combination of freedom to experiment with some responsibility to work together. With a little bit of publicity to the rest of the community, the feedback loop will occur naturally as the members take each of them for a spin before choosing which to customize to be their local skin.)

One of the things I was really surprised to hear at Atlanta was the widely differing views on just what Sakai should "be". I heard arguments
for increasing the learning component; I heard arguments for focusing on the collaboration component; I also heard arguments that MyWorkspace is what it should all be about (!).

Assuming that all are correct, and also assuming that Sakai's usage will continue to grow into colleges, middle and high schools, and commercial venues, trying to pin down "exact" users or "exact" use cases for some of the "larger" or "more generic" pieces of functionality will probably become more and more meaningless every month.

Discussion forums, chat, email archives, "portals" (web apps where you log in and see customized content)... we should all have seen other examples of these on the web; so should most Sakai users, regardless of who they are. I think it should be possible to design these for a "generic" Sakai user with a "standard" level of web experience. (This is where the "hallway" testing or "grab 5 users" comes in handy: they both make it easy to see if we're basically on track.)

The opposite, however, is also true: more "heavyweight" design processes will probably become more and more necessary for tools that become more and more specific for "University/International Research Collaboration" or "Commercial/Learning" or "K-12/MyWorkspace" uses. (Tools like OSP, Melete, Samigo/Mneme, Gradebook....)

So, coming back to what Katherine said, I would suggest that it may be beneficial for this group to consider the lowest common denominator, to
start with easily attainable goals, and to determine lightweight processes that *more* of us can *easily* use to contribute meaningful data and UI "patches", and that are, therefore, easily transferable to new members.

Just another way of thinking about it.