22 years ago I helped a group of undergraduate Information Technology students set up CQ-PAN – Central Queensland – Public Access Network. An early attempt to allow CQ residents get on the Internet. CQ-PAN got used by a range of people for a range of tasks. In 1994 CQ-PAN started hosting mailing lists for a range of purposes, including for courses being taught by my then employer, the Department of Mathematics and Computing (who were funding the hardware).
Thus began my life of producing feral or shadow IT systems. IT systems that were “feral” because they were not produced by the central IT group officially charged by the organisation to support its strategic goals. IT systems that I needed to write because central IT never seem to know and/or be able to deliver the type of IT-based functionality that were needed to improve learning and teaching.
Here were are decades later, living in the new age of digital learning and still suffering from the same problem. For example, a week or so ago Jon Dron wrote about A waste of time in which he talks about IT systems that
requires individuals to do the work of a machine. For instance, leave-reporting systems that require you to calculate how much leave you have left, how many hours there are in a day, or which days are public holidays
Personally, I’ve spent the last 3+ years since starting at my new institution engaging in various forms of bricolage to develop kludges that fill the gap between the concrete lounges provided by the institution and what’s required to be effective. Just like I did at my old institution.
Which brings me to the question…
Who should design the functionality of an IT system? Particularly one used for learning and teaching?
It’s stupid to ask the user
A few days ago @EdwardTufte re-tweeted (not necessarily a sign of approval) the following partial answer to this question provide by @MrAlanCooper (two gentlemen with a lot of runs on the board around these types of topics)
The idea that asking users what they might need is stupid generated a few responses similar to this one.
Cooper expanded with
Leave it to central IT and/or L&T
In a University context this generally means that folk from central IT or learning and teaching (though in the worst cases it’s some senior manager who some something in a airline magazine) are given this responsibility. However, if the experiences of Dron, myself, and countless others in Universities is anything to go by, then the track record hasn’t been all that good.
Why is this the case?
No deep understanding
In a post titled “Never delegate understanding” Tim Kastelle the in-depth process used by Charles Eames and Eero Saarinen to win a home furnishings design competition and link it to organisational design. Kastelle’s conclusion is
When we try to design better organisations and better outcomes for people, there are no shortcuts. We have to start with building a deep understanding of how they are now and operate within that framework.
I’ve never worked in a University where central IT and learning and teaching people have a “deep understanding” of how students and teachers engage with the daily process of learning and teaching. Given my recent experience, I’d have to say I’m not sure that the people responsible for designing systems have a deep understanding of an administrative task like process final results or booking travel.
Dron identifies one reason that may contribute to this lack of understanding
This is one of those tragedies of hierarchically managed systems. Our ICT department has been set the task of saving money and its managers only control their own staff and systems, so the only place they can make ‘savings’ is in getting rid of the support burden of making and managing cogs.
Rather than develop the deep understanding to design something effective, the focus is on saving money on the “staff and systems” within the budget reporting line of that particular department.
What are the alternatives
Better design approaches – ux/lx design
Of course design could always be done better. It could be focused on developing the type of “deep understanding” required to effectively design a change. User experience design and its offshoot learning experience design offer a range of techniques and processes for doing this.
The question is whether or not these approaches can battle the “tragedy of hierarchically managed systems” and other factors that are contributing to the long-term problem with University IT systems? After all, I’ve known a number of people who have worked in central IT and learning and teaching (including myself) who didn’t want to design crap systems.
I also wonder whether or not learning experience design (lxdesign) will have a broader problem caused by the problems of hierarchy? As I understand it lxdesign focuses on the design of learning experiences. In a university context, learning experiences typically take place within courses, which in turn are located within programs, which in turn are the responsibility of specific units within the university. For me, it looks like the tragedy of hierarchical systems all over again, but only worse.
Learning from Steve Jobs
For better or for worse, Apple remain a reasonable benchmark – if perhaps a somewhat extreme example – for designing quality artefacts. Can anything be learned from Apple and Jobs?
One of Jobs more famous quotes echoes the point made by Cooper at the start
it’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.
And if you have a company that includes world-class designers and an explicit focus on producing the highest quality products, then you might be use this as a template for success.
Personally, I find a couple other Jobs quotes more broadly useful. For example, in a 1985 interview with Playboy he’s quoted as saying
We built [the Mac] for ourselves. We were the group of people who were going to judge whether it was great or not. We weren’t going to go out and do market research.
This speaks to me as the importance of the people designing systems also being people who use the system. People specifying and developing a system should – In Taleb’s phrase have “skin in the game”. In AntiFragile, Taleb cites the Hammurabi code and quotes the following
If a builder builds a house and the house collapses and causes the death of the owner of the house – the build shall be put to death
. Poor software for learning and teaching (hopefully) won’t cause death, but some sort of “skin in the game” might be useful. Of course, with large organisational software projects it would be unfair to apply this to the developers. The project board might be a better recipient.
End-user development is the other form of “skin in the game” and that’s where all my (and most) “feral” systems come from. People who actually have to use these systems and know they suck. So they build work-arounds. But it’s not enough to allow developers, even end-user developers, to work alone.
It’s not a quote, but this article on “How Twitter users can generate better ideas” describes Job’s instructions to the architects of the Pixar headquarters as
to design physical space that encouraged staff to get out of their offices and mingle, particularly with those with whom they normally wouldn’t interact. Jobs believed that serendipitous exchanges fueled innovation.
Increasingly designing physical spaces that allow “serendipitous exchanges” isn’t possible in Australian multi-campus universities. Increasingly staff in such institutions aren’t physically co-located. Leaving at least two possibilities for encouraging the production of this type of innovation fuel.
First, is the practice of hackfests and similar. Get disparate people together from all over the organisation (and beyond?) and share problems and desires. Group people with problems and desires with people who can implement them, and then have a crack at implementing them.
Second, recognise that increasingly people are often using the same digital space. Design the digital space so that “serendipitous exchanges” can take place in the digital space. That’s one of the aims of this project.
Both these approaches break the “tragedy of hierarchically managed systems”. Pair them with approaches like UX and LX design and you might have something.
But for these approaches to work will rely on what Dron describes as “tools that make cog production fast and simple”. Traditional monolithic enterprise systems are not such tools. The technologies that make up the current move toward API centric architectures are such tools.
One of the problems with enterprise systems is that “decisions” about the design of the system are essentially forever. Once they are made, it’s very, very hard to change. “Tools that make cog production fast and simple” allow for decisions to be made, tested, and re-made when and if they fail. They allow for learning.