UnLearned

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

Teachers Talking to Developers

with 2 comments

I often hear the problem of ensuring the relevance of development work to actual practice framed as “getting users and developers to talk to each other.” Now if by “developers” you mean anyone who has a constructive role in fashioning the end product, well, of course. That’s trivially true. But I think most of the time when I hear this it actually means getting end-users and coders to talk to each other, which sounds like a good idea but is not, I think, often very helpful.

Take the old Sakai requirements process of a few years back, which I think is generally regarded as a failure. Feature requests were itemized, voted on, and the biggest winners trumpeted, then very little happened. But I hear the failure described with variations of “developers didn’t implement” or “resource was not allocated to deliver,” and so forth. As though we had all the information we needed, and just didn’t execute. I think that really misunderstands the problem, mainly by not recognizing the design gap.

There is in fact something that needs to happen between the expression of user need and the coding, and it doesn’t get you very far to try to short-circuit it by bringing users and developers together. That approach just tends to leave you with a product that ticks off the right features, but leaves the users unsatisfied because it has poor design. What we really need is for user researchers to be talking to designers, those people who have a talent for not taking the user’s requests literally, but instead synthesize an elegant answer to several requests at once.

That’s why the old requirements process failed, not because people on the functional side couldn’t get the attention of developer resource, but because we left out the mediation of good design.

Happily, we’re doing this differently this time around, beginning by not trying to establish Sakai 3 requirements through the old pattern of feature requests. We’re instead using a model that David Goodrum championed in Boston this past Summer, with simple expressions of user need (abstracted from particular tool implementations) being mapped to the language of functions and capabilities in increasingly complex forms. It shows us how we can aim at a rich and sophisticated end goal, but still make simple and valuable steps along the way. This is the kind of information I think a designer can use, and then turn around and produce something that a (coder) developer can pick up and run with.

Google Spreadsheet of learning capabilities (open for public editing)

Still a work in progress – it might be better organized by theme, and expanded upon – but I think it’s a strong model.

Advertisements

Written by khomotso

October 22, 2009 at 7:48 pm

Posted in Sakai

2 Responses

Subscribe to comments with RSS.

  1. Great posting and I very much agree that we’re on the right track.

    I would propose that there may be an additional step that we need to take between the “simple expression of user needs” and design which is the gathering of more direct input from users with regards to workflow and use cases. Although many of us in the Sakai community who work closely with front end users have a great body of knowledge with regards to their needs and uses of Sakai, I’m constantly surprised by some of the unique and unexpected needs that surface when I sit down and really watch and talk with users. This is particularly the case with our “early adopters” who tend to think out of the box and push the envelope in terms of new technologies and new applications of those technologies.

    I would like to use a combined approach develop over time in which the “simple expression” model takes us to a certain stage, after which a more fine grain end-user driven “contextual inquiry” process helps us to define specific workflows and design parameters.

    This said, I am very encouraged and excited about the work that is emerging and look forward to contributing to it.

    Josh Baron

    October 22, 2009 at 11:31 pm

  2. I mostly agree, and I think this is partly why I mentioned user researchers above, in addition to designers and users. A body of user research can be essential.

    I think contextual inquiry has a particular technical meaning, and is only one method among many in user centered design methodology. It can be an important component, but I think it needs to be used advisedly as part of a composite process.

    khomotso

    October 22, 2009 at 11:47 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: