In his book Well Designed, Jon Kolko explores “how to use empathy to create products people love.” We start from understanding real people, both in what we rather too abstractly refer to as “human nature”, and explore their specific needs, desires, likes, and limits. Kolko argues that we have to see beyond the product, which is not the end in itself. We design for a journey that takes the user to where they want to be. The story rarely ends with the software itself. People don’t want to be using software. They don’t even really want to be using technology (Douglas Adams famously remarked that “technology is the name we give to things that don’t work yet”). It doesn’t at all feature on the hierarchy of needs, except for a minority of people who fetishise technology. What people want is to be happy, to enjoy being with other people, to enjoy the sensuous delights of food, places, sounds and more, to enjoy developing and using their capabilities (see Martha Nussbaum’s great book on this Creating Capabilities), and to be providing those same goods for others.
Education (and understanding) is essential to this as a core capability, both as an enabler of good ends, and as a thing to be enjoyed in itself. Educational technology, as with other things we hope to design well, is a (sometimes) necessary tool for more satisfactorily achieving these ends. So we begin our designing with people, where they are at now, where they want to be, what gets in the way, and we look for ways to improve the journey. Great designers are able to articulate and refine such journeys as arrangements of all of the elements that can be designed to work together. For educational technology systems, that includes the detailed configurations of hardware, software, data, communications, interface design, processes, language, aesthetics and much more. We bring those things together into something that fits with the capabilities, needs, likes, and limits of the users, to help them to achieve goals. The user, the design, and the goals fit tightly together. Kolko describes the techniques used by designers to achieve this. But most importantly, there is the commitment to designing to help real people to achieve real goals that matter to them.
This does not always happen. There’s a lot of very bad designing, especially in the malleable world of software. Malleable in that it’s easy to change or add features with little up-front cost, regardless of impacts on end users. That, combined with a lack of vision and design discipline, creates bad software.
You might know where this is going! Microsoft! Not known for designing great software. Rarely the best, but often the first to market.
When they released Teams a couple of years ago it was met with surprise. Teams is a front-end to other Microsoft platforms, principally that Sharepoint…thing. I’m not even sure what to categorise Sharepoint as. It’s an amorphous mess of features. It’s worth thinking about how Sharepoint ended up like that, and how Teams might go the same way.
There are two ways in which the tech industry designs products. Some are designer-led. Design decisions are made so as to coherently and effectively meet a closely-related well-defined set of goals for real people. Other tech companies are sales-led. Features are added in response to “business insights” so as to maximise the number and range of people spending money. From the consumer’s perspective, this can look like a good deal: a Swiss-Army knife of a system that can do lots of different jobs may seem to be cheaper and less hassle (in terms of getting set up and becoming familiar with using it). But this can lead to incoherent and unpredictable results, with many poorly implemented hacky features, and ultimately to confusion and frustration. Which of these do you think is Microsoft? Which approach does Apple usually take? But that doesn’t translate into one of those companies being more successful than the other. Microsoft, over the years, has balanced precariously between providing Swiss-Army knives and a totally unusable mess. Sometimes it gets it right. Then other times it slips into chaos. Perhaps they should read this Harvard Business Review article on “Defeating Feature Fatigue“.
So Sharepoint was a mess. Hence the need for an additional layer of interface (Teams) to make it usable. Teams was, at least initially, a revelation. Microsoft had kicked the habit of a lifetime to make something quite well designed. It was nicely focussed on being a platform for team work. It wasn’t overloaded with features, and was built upon “concepts” that fitted well with the goals of the people using it: to be able to get together synchronously or asynchronously, from anywhere with an internet connection, and collaborate in a free-flowing manner, without all of the usual barriers (permissions, complex data structures).
Three years into the life of Microsoft Teams, we have it fairly well adopted in the University for supporting team work. It is helping people to achieve things better, and as we are now mostly working from home, to do things that would otherwise be impossible. Many people are creating Teams spaces, adding colleagues (or letting them join with no barriers), sharing files, having discussions etc. It mostly happens in an emergent and just-in-time way, with no hierarchy. A team-working kind of way. And that is contributing to satisfaction, happiness, and the creation of capabilities. But it’s not ending there.
We’re getting requests for advice on how to bulk create Teams spaces with elaborate structures. Private channels in which students are assigned. Assignment workflows. Timed activities. Granular limits on what students can do in spaces, and sometimes, on what teachers can do. Data. Learning analytics. And more. People want it to be like a Virtual Learning Environment (and what that actually means is a Virtual Teaching Environment, in which the technology is used to control, direct and measure behaviour). That’s all possible. Microsoft have even added a Class Teams template to do some of the configuration work. Anything is possible using the powerful automation and configuration tools built into the Microsoft platforms.
But remember the definition of well designed given above? Teams as a Virtual Teaching Environment is never going to be well designed, if we want more than a good team-work platform. And VLEs are not that. As is often the case with Microsoft (and many other companies), they stretch their product to fit as many uses as possible, to monopolise markets, to generate as much income as possible. In this case, VLEs don’t have some of the very attractive features of Teams: document collaboration, fluid movement between synchronous and asynchronous, the ability for team members to dramatically modify their work spaces. So Teams draws in a new market. But it brings with it a different set of goals and features, that contradicts the original design goals of the platform. That gets messy and confusing.
To conclude: it would be really nice to have a very well designed Virtual Learning (Teaching) Environment and a well designed team-working platform. But the two don’t need to be the same thing. We can connect them. We can help users to understand the difference and to move fluidly between them as needed. But for the purposes of good design, it’s best to differentiate. This does require an increase in the effort and resource that goes into training, learning design and support. But that’s a necessary investment to improve the quality of outcomes and ultimately save the time, money and patience that would otherwise be wasted on pursuing ill-fitting and incoherent approaches.
One final further thought for Microsoft. They did a good job of creating a team-work platform on top of Sharepoint and their other tools. Why not create a dedicated VLE using the same approach? I suspect that in the past there just wasn’t enough interest or money in doing that. But maybe that has changed.
In my next article in this series, I look in more depth at what characterises team-working, and the design principles required for platforms that support it.