12.1 Open source software and the user experience in higher education  (Page 3/8)

However, distributed teams introduce several UX challenges. Requirements developed in the silo of a remote team tend to focus on the requirements and business rules as expressed in that environment. For example, UC Berkeley might tend toward defining the business rules for the Gradebook based upon our campus policies rather than doing the extra work required to generalize across a wide range of institutions and global cultures. This behavior makes good local sense since as institutions we are driven by enlightened self-interest and need to ensure that we meet the needs of our local users with our local resources. However, producing a tool that only creates interactions based on the primacy of UC Berkeley’s business rules often effectively lowers the ability for other schools to leverage the tools and increases the total cost of adoption.

Another UX challenge is that working in tool silos makes it difficult to create a coherent, “holistic” environment for the end-user. Many user goals are based on work flows that cut across tool sets. This has been an oft-cited usability problem within Sakai. Users don’t think within the same categories and silos as the development teams work.

A code-centric culture

Open source software has historically been developed for and by developers. It is a meritocracy where individuals gain respect through their direct contributions to the end product. This creates an intrinsic reward system for the developers whereby respect and privileges are accorded to those who do things like “play well with others,” provide good feedback and assistance, but most importantly contribute good, solid, workable code.

UI Designers generally don’t produce code. UI Designer Rashmi Sinha talks about this issue in her blog ,

“…The problem of currency: In any system people exchange goods and services using some type of currency. The currency could be any arbitrary thing - it could be fish, cows, or massages. In the open source world, it happens to be code. The problem is that usability professionals generally do not write code.”

While quite successful for projects such as Linux and Apache, this is problematic for end-user applications that are used by the faculty and students in higher ed to support their daily scholarly, teaching, and learning activities. Developers can no longer design for themselves; they have to design for users whose goals are nothing like their own (a good read on this is Alan Cooper’s book, “ The Inmates are running the Asylum “). Developers need UI Designers and Instructional designers to help them translate instructional, scholarly goals into specifications and prototypes. However, in an environment where code is king, what rewards are available for individuals with these other critical skills to participate? Do we even have the right ecosystem in which for them to engage them in the first place?

The right people for the right job

As IT managers, we are probably the first to advocate for the right tool for the right job. However, we continually seem to hire a relative monoculture of IT professionals, thinking that if we just add another programmer all our problems will be solved! After talking with many IT managers across higher ed, it appears that UI design (whether it be User Research, Interaction Design, Visual Design, or Information Architecture) is rarely a formal part of their cycle or designers a regular part of the team. If UI Designers are part of the team, they are often so sparse a resource as to absolutely ensure that they won’t have enough time to get engaged early enough or long enough. This means that the few teams that are able to contribute UI designers to an open source effort, have a hard time being impactful. This is made worse by the fact that designers are often embedded in distributed teams and not looking across the product, inhibiting a holistic user-centered approach.