Default. According to Homer Simpson the two sweetest words in the English dictionary.
To me though, default is more insidious. It represents choices denied and the removal of control by eliminating the opportunity for discussion to occur at the place and time it should – before decisions are made.
This post was triggered by some fairly innocuous tweets from Rolin Moe but they struck something that had been sitting there for some time.
While on the surface these are small fry complaints they point to something big:
What are the consequences of the default?
I’ve been doing some work on designing spaces over the last year looking at spaces that promote creativity and group work. One of the key issues we are facing is that space is at a premium, so a “feature” of these designs is that they are required to have multiple configurations. They need to be able to be re-designed and re-configured to suit a range of purposes and activities.
The work has involved visiting a range of spaces across our campuses but also looking more broadly at other universities and places which enable the kinds of work we are seeking to promote.
I’ve taken a few key things from this:
- Furniture is too often bolted to the floor and thus it actually inhibits true flexibility. Furniture needs to return to its root and once again become mobile rather than a structure.
- Technology is still fixed. The reality is that it still requires wiring, connections, setup, support and central control. These fixtures limit the flexibility that’s possible. Wires and cables are still the reality when it comes to technology – wireless just isn’t there in any way shape or form just yet.
But perhaps the biggest lesson was this:
The Default is what defines the space. No matter how flexible the room and the furniture in it is, it has to have a default position. No matter how flexible the space is, it has to have a starting point, a point zero that it can return to. It’s this default that defines what the space is, how it is perceived, how it is defined and inevitably how it will be used.
The simple reason is that people rarely move beyond the default.
Yes, the room may have a million-and-one configurations, but the reality is people stick with what’s there. They won’t move anything because they are used to the notion that the choice has already been made. That the default isn’t a starting point, but the end of a designed process. That someone else with more skills has looked at all this and made decisions on our behalf, whether this is true or not.
I get the reasoning behind the default. It’s something that’s necessary because decisions can’t be made all the time. There’s a cognitive load related to making decisions that is often at the expense of focussing on what really matters. Yes configurations are important, but at what cost and for what benefit?
Should we simply accept the default or be actively working to change it?
Defaults aren’t bad, and they can actually be sweet, but we have to start questioning the consequence of them:
- What it is they entrench?
- What do they avoid?
- What do they hide?
- What do they improve?
- What do they enhance?
- What to they leave behind?
And more importantly WHO?
- Who it is they entrench?
- Who do they avoid?
- Who do they hide?
- Who do they improve?
- Who do they enhance?
- Who to they leave behind?
Questioning the defaults is perhaps really interesting when applied to opt-in/opt-out scenarios. Take organ donation. It’s an area where the default has a significant effect on the outcome (It’s also one of the few occasions where I can mention the work of my brother!). Changing the default organ donation setting from opt-in to opt-out increases the number of transplants. You don’t remove or deny choice – it’s just switching the default position. It speaks to the power of The Default. It sets the agenda, it defines the space, it changes the argument and resets the tone. It’s the kind of trigger needed to move beyond the ‘gift of life’.
So perhaps we just need better defaults?
It’s important to note that the default often hide difficult and complex decisions. Those PowerPoint templates? Well they hide a huge range of design choices about fonts, line heights, placement, styles, colours, look, tone and feel. The problem is that PowerPoint hides all those decisions by not exposing you to them. There is just the default. You don’t find out about them until you actually sit down to develop your own template and you realise how messed up the system is. The Default is the choice because there are few alternatives. Customisation is a chore, or more realistically something closer to a layer in Dante’s hell, and what are consequence of changing the default?
But if you take that lack customisation into something like an LMS? Well the stakes get a lot higher. The consequences rack up quickly when you’re talking about the cost of a course and the potential impact on a life! Bad design when it comes to learning has real and definite impact. There are consequences. Big ones.
Better defaults, better modifications
I think we need to start questioning the default. Yes they’re necessary, but we need to better understand what their impact is. Simple defaults in PowerPoint effect the look and feel, but are how consequential are they? Complex defaults, like those employed in an LMS or a course design, can and do effect lives. We need to question the assumptions they make and the impacts they have.
The other area that needs considerable work are the tools that allow us to customise. At the moment they tend to suck, badly. They’re either too light weight to just too complex. This points to a design problem, one that is built on assumptions about the consequences (or inconcequences) of the default. Making customisation not only accessible, but transparent as well, is vital in enabling accountability but also encouraging learning and improvement. It provides a way for us to not just accept the default, but to move beyond it.
One way I’ve been thinking about this, particularly in the educational context is through the development of patterns and blueprints.
Patterns & Blueprints
Patterns are ways of defining components relating to structure, tone, material and activity. They are abstracted so that they do not define the entirety of a design, but make up the pieces through which it is constructed. They are multifaceted which allows them to be reconfigured in a variety of ways to suit specific applications.
Blueprints on the other hand provide a way of sharing a design. They show how various patterns fit together. They highlight areas where adjustments needs to be made but essentially what they allow is for design to be communicated and shared. They bring transparency to the process by providing insight into the design. You can see how the default has been made, what decisions have been made and what areas could be changed.
In many ways Patterns are like Lego pieces and Blueprints are the instructions.
Watching Amy Colliers videos at the end of her awesome blog post Not-yetness was an interesting way of thinking about this analogy. Blueprints can suck the creative joy out, but at the same time they provide a default. They specify the patterns required and usually in the box are multiple variations of the blueprint on the front of the box. The Blueprints provide a marketable and packagable default, but the underlying point is the Patterns they contain are able to be re-formed and re-constructed.
I’ve used the terminology patterns and blueprints very specifically. I don’t want to talk about templates, learning objects, learning designs, OERs, LAMS etc – because they don’t do what I think they need to do.
They lack a form that enables remix. They are like wooden blocks rather than Lego. Yes you can build similar structures, but you lack the ability for those components to be integrated. Blocks tend to sit on top rather than connect and integrate into the structure. They’re often too big and cumbersome to be shaped into exactly what you want. This leads to a compromised, rather than customised design.
What we need are ways of working that not only embrace the remix, but enhance it.
One reply on “Moving Beyond The Default”
[…] Moving Beyond The DefaultThe – – Cynefin framework […]